🚀 go-pugleaf

ara@zurich.ai.mit.edu (Allan Adler) writes:
>For years I have had an interest in understanding, in the absence of any
>documentation, what a given executable does.

Try running it.

>I understand that one can simply use a debugger, preferably a smart one,
>and follow it step by step in the hope of discovering what the code does.

Boring.  

>First, it seems to me that every compiler and every assembler must have its
>own idiosyncratic way of producing the executable. Is that true?

For compilers yes, for assemblers no.  With assemblers every byte of
the execuatable is under the programmers control.

>If so, then it might be possible to have a database of idiosyncrasies
>that lets one figure out what compiler or assembler produced the executable.

For compilers, it's easy just look at the startup code.  Every compiler
and compiler version has there own, pretty much unique start up code.
What makes this even is easier is the fact that this start up code often
contains giveaway copyright strings.

>For each compiler, there might be a specific decompiler that takes into
>account the special features of that compiler. Also, if by some miracle
>the code was compiled but not optimized, it seems like it would retain
>more features of the original.  Or if compiled with C and debugging
>information was not stripped from the executable, that would be quite
>helpful. Knowledge of the source language and the specific compiler seems
>like it would be quite helpful.

With BASIC you might have some luck, the code probably was a mess of
GOTO's anyways, but with other languages reverse compiling isn't going
to get you anything more intellegible then a simple disassembly.

>The second idea is that even if one knows nothing about the source language
>or the compiler, one can still imagine tools that will give an overview
>of the structure of the program. The trouble with debuggers and disassemblers
>is that they work at the lowest level, one instruction at a time. Imagine
>instead an attack on the entire executable.

[ much thought on how to "attack" an entire executable deleted ]

>Admittedly this does not solve the problem, but I feel that automating what
>I have described would put one in a position to take the next step.

You're talking about a whole mess of heuristics, something better
performed by a human than a computer.

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //