Path: utzoo!mnetor!uunet!husc6!uwvax!heurikon!lampman
From: lampman@heurikon.UUCP (Ray Lampman)
Newsgroups: comp.lang.c
Subject: Re: self-replicating program
Message-ID: <158@heurikon.UUCP>
Date: 22 Dec 87 23:46:53 GMT
References: <10921@brl-adm.ARPA>
Reply-To: lampman@heurikon.UUCP (Ray Lampman)
Followup-To: comp.lang.c
Organization: Heurikon Corp., Madison WI
Lines: 33
Summary: De-compilers anyone?

> In article <10921@brl-adm.ARPA> ADLER1%BRANDEIS.BITNET@CUNYVM.CUNY.EDU writes:
> It occurred to me that what I would really love to see would be a program
> which replicates the source code of other programs. It would be great to have
> a program which could throw together source code which could plausibly have
> given rise to the given executable, preferably in a choice of higher level
> languages. Has anyone ever encountered such a facility?
>
> ADLER1@BRANDEIS.BITNET

It sounds like you're talking about translating object code into the source
language of your choice. Some time ago, I investigated doing this for object
code created by a UCSD pascal system. I concluded that it was possible.

Many compiled languages retain enough information in their object code to
identify stack and global variables, but the symbolic names are usually lost.
Comments are almost always lost. Function or procedure names are lost too.
A de-compiler (as I call it), would have to generate the symbolic information
that the compiler removed. Some symbol names can be guessed, loop indices
are pretty easy, just generate "index", or something similar. Globals are
almost impossible, though. Now if you happen to have a symbol table, I can
just imagine ...

(generic-prompt) decc doit.o
... working
... external symbol table intact
... generating internal symbols
... condensing if-goto structures into while loops
... doit.c complete
(generic-prompt) vi doit.c

Has anyone else ever toyed with or know of efforts to write a decompiler?

                                        - Ray (lampman@heurikon.UUCP)