|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)|
|From:||tmsoft!mason@uunet.UU.NET (Dave Mason)|
|Organization:||TM Software Associates, Toronto|
|Date:||15 Sep 90 14:21:03 EDT (Sat)|
In article <firstname.lastname@example.org> email@example.com writes:
>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.
As others have said, you must walk the code graph to determine all
possible code sections.
What I've done several times is to have an auxiliary file that contains hints
to the disassembler. This contains known addresses, useful names for same,
and the class of object, e.g:
ffd0 CONS_RCV word
ffd2 CONS_STS byte
d000 START code
d123 DISPTCH jump-table 16
d456 GETCHAR code
d678 HELP_MSG ascii
So you run the disassembler against the input and this file, then examine the
output, discover more about the program, fill in more labels, and iterate.
This can produce a pretty good version of a program. Particularly
useful for ROMs.
Return to the
Search the comp.compilers archives again.