|Disassembly firstname.lastname@example.org (1990-09-09)|
|Disassembly email@example.com (1990-09-12)|
|Re: Disassembly firstname.lastname@example.org (1990-09-14)|
|Re: Disassembly Chuck.Phillips@FtCollins.NCR.COM (1990-09-14)|
|Disassembly tmsoft!mason@uunet.UU.NET (1990-09-15)|
|Re: Disassembly albaugh@dms.UUCP (1990-09-17)|
|Re: Disassembly email@example.com (1990-09-19)|
|Re: Disassembly chris@cs.UMD.EDU (1990-09-20)|
|In-Reply-To:||firstname.lastname@example.org's message of 9 Sep 90 17:32:55 GMT|
|Organization:||NCR Microelectronics, Ft. Collins, CO|
|Date:||14 Sep 90 16:05:58 GMT|
>>>>> On 9 Sep 90 17:32:55 GMT, email@example.com said:
> The problem with disassembling arbitrary object code is that data
> bears a disturbing resemblance to code at times:) Even when
> running through code disassembling starting at known code, it's
> not always possible to determine when code stops and data begins.
> It is possible to reduce the problem with an algorithm that looks
> ahead starting byte-by-byte and sees which one generates a most
> successful string of instructions.
Use a program that starts with the first executable instruction, marking
and decoding as it goes every instruction except for conditional branches.
Upon encountering a conditional branch, follow _both_ branches. If
implemented recursively, the stop conditions are, 1) a branch to an already
marked instruction and b) an end-of-program. Even this can fail if there
is a conditional branch to garbage, which never happens in practice due to
the underlying algorithm.
> Even this fails in many cases of self modifying code...
Ouch! Now you're stuck.
> If you're familiar with coding practices for the processor though,
> heuristic methods can be applied with some success.
...and no guarantees.
Chuck Phillips MS440
NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp
Return to the
Search the comp.compilers archives again.