Of any of the features of our new trusted disassembler has provided, one of the most interesting to me is its ability to disassemble and analyze aliased program bytes.
Instruction aliasing is the overlapping of two execution targets onto each other, such that the begin of one instruction is somewhere in middle of another. An example of this is
00: jz 3
02: and al, 58h
04: ret
where depending on the ZF flag, execution will go to either address 02 or 03. At 03 in this example, we see a 58h (hex value). This corresponds to a pop eax in x86. In this example, program flow could be altered if the pop instruction were to execute.
Most disassemblers would return something very similar to the written example I’ve provided, in order to output program code in such a manner that it can later be reassembled back into a working program. Because of this output style, aliased instructions are ignored as erroneous data and often encoded as simply an extraneous data byte existing in tandem with the code. This works well on well-formed programs, but tends to fail (and sometimes exceptionally) on programs written by authors not willing to give away all their secrets.
Our new tool outputs every discoverable branch target, including those that are overlapped with other discovered instructions.
00: jz 3
02: and al, 58h
03: pop eax
04: ret
This is achieved by the simplest means possible: mapping a unique execution target to a unique instruction listing (or more simply: mapping an address to a disassembled instruction). While this statement may seem obvious, because of other tools preference for rebuildable output the effective mapping is from instruction bytes to disassembled instructions:
Byte-to-Instruction Mapped | Address-to-Instruction Mapped |
74 01 : jz 03 24 58 : and al, 58 __ c3 : ret |
00 : jz 03 02 : and al, 58 03 : pop eax 04 : ret |