Disassembly

tmsoft!mason@uunet.UU.NET (Dave Mason)
15 Sep 90 14:21:03 EDT (Sat)

          From comp.compilers
Related articles
Disassembly phorgan@cup.portal.com (1990-09-09)
Disassembly meissner@osf.org (1990-09-12)
Re: Disassembly pl@news.funet.fi.tut.fi (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 aglew@dwarfs.crhc.uiuc.edu (1990-09-19)
Re: Disassembly chris@cs.UMD.EDU (1990-09-20)
| List of all articles for this month |
Newsgroups: comp.compilers
From: tmsoft!mason@uunet.UU.NET (Dave Mason)
Followup-To: comp.compilers
Keywords: disassemble
Organization: TM Software Associates, Toronto
References: <9009091032.1.139@cup.portal.com>
Date: 15 Sep 90 14:21:03 EDT (Sat)

In article <9009091032.1.139@cup.portal.com> phorgan@cup.portal.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.
--

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.