Re: Disassembly

Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
14 Sep 90 16:05:58 GMT

          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: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
In-Reply-To: phorgan@cup.portal.com's message of 9 Sep 90 17:32:55 GMT
Keywords: assembler, design
Organization: NCR Microelectronics, Ft. Collins, CO
References: <9009091032.1.139@cup.portal.com>
Date: 14 Sep 90 16:05:58 GMT



>>>>> On 9 Sep 90 17:32:55 GMT, phorgan@cup.portal.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.


Suggestion:


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.


Cheers,


Chuck Phillips MS440
NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp
--


Post a followup to this message

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