Mail Archives: djgpp/1999/08/02/05:52:24
--------------A1F281BC9BE6AE21957669A1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Please read the following from the decompilation page
http://www.csee.uq.edu.au/~csmweb/decompilation/possible.html
Is Decompilation Possible?
Almost every week requests for decompilation programs are made in newsgroups (like
comp.lang.c), and these are usually
replied with: It is not possible!
Fully automated decompilation is not possible -- this problem is theoretically
equivalent to the Halting Problem, an undecidable
problem in Computer Science. What this means is that decompilation cannot be
achieved for all possible programs that are ever
written, and that the separation of data and code is hard to achieve. Further, even
if a certain degree of success is achieved, the
generated program lacks meaningful variable and function names as these are not
normally stored in an executable file (except
when stored for debugging purposes).
Some people believe it is only possible to recover the assembly sources, this in
itself is not a trivial problem, again, due to its
equivalence to the Halting Problem. However, in practice, there have been approaches
to deal with disassembly and
decompilation. The more successful ones make use of extra information (e.g.
knowledge of the compiler used) or require human
input at the hard parts of the disassembly process.
A good example of actual decompiling of X86 machine code to C is given on the dcc
home page.
There is a now a second version of the decompiler; mainly to distinguish it from the
first, we'll call it the "OO" version (it has the
beginnings of Object Orientation, but there is still much to be done). This version
has a bug fixed which caused the output to be
wrong some of the time (randomly; successive runs would result in different output).
It is also converted to C++.
Please keep in mind that this is a project carried out at the University of
Queensland in Australia. The for-profit versions of such decompilers are also
available. I will provide info upon request. The commercial versions tend to be
compiler specific and be rather pricey. So, if that is not sufficient evidence that
decompilation is possible, then holding your hand above a flame is not sufficient
evidence to make you believe that fire is hot!
David O.
Martin Ambuhl wrote:
> David Oppenheimer wrote:
> >
> > I must strenuously disagree here. First, if disassembly were impossible, then
> > why would programmers waste their time programming disassemlers?!
>
> Please note the subject header. Decompilation is no disassembly.
>
> --
> Martin Ambuhl mambuhl AT earthlink DOT net
>
> __________________________________________________________
> Fight spam now!
> Get your free anti-spam service: http://www.brightmail.com
--------------A1F281BC9BE6AE21957669A1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Please read the following from the decompilation page <a href="http://www.csee.uq.edu.au/~csmweb/decompilation/possible.html">http://www.csee.uq.edu.au/~csmweb/decompilation/possible.html</a>
<p>Is Decompilation Possible?
<p>Almost every week requests for decompilation programs are made in newsgroups
(like comp.lang.c), and these are usually
<br>replied with: It is not possible!
<p>Fully automated decompilation is not possible -- this problem is theoretically
equivalent to the Halting Problem, an undecidable
<br>problem in Computer Science. What this means is that decompilation
cannot be achieved for all possible programs that are ever
<br>written, and that the separation of data and code is hard to achieve.
Further, even if a certain degree of success is achieved, the
<br>generated program lacks meaningful variable and function names as these
are not normally stored in an executable file (except
<br>when stored for debugging purposes).
<p>Some people believe it is only possible to recover the assembly sources,
this in itself is not a trivial problem, again, due to its
<br>equivalence to the Halting Problem. However, in practice, there have
been approaches to deal with disassembly and
<br>decompilation. The more successful ones make use of extra information
(e.g. knowledge of the compiler used) or require human
<br>input at the hard parts of the disassembly process.
<p>A <a href="http://www.csee.uq.edu.au/~csmweb/dcc.html">good example</a>
of actual decompiling of X86 machine code to C is given on the dcc home
page.
<p>There is a now a second version of the decompiler; mainly to distinguish
it from the first, we'll call it the "OO" version (it has the
<br>beginnings of Object Orientation, but there is still much to be done).
This version has a bug fixed which caused the output to be
<br>wrong some of the time (randomly; successive runs would result in different
output). <b>It is also converted to C++.</b>
<p>Please keep in mind that this is a project carried out at the University
of Queensland in Australia. The for-profit versions of such decompilers
are also available. I will provide info upon request. The commercial
versions tend to be compiler specific and be rather pricey. <b>So,
if that is not sufficient evidence that decompilation is possible, then
holding your hand above a flame is not sufficient evidence to make you
believe that fire is hot!</b>
<p>David O.
<p>Martin Ambuhl wrote:
<blockquote TYPE=CITE>David Oppenheimer wrote:
<br>>
<br>> I must strenuously disagree here. First, if disassembly were
impossible, then
<br>> why would programmers waste their time programming disassemlers?!
<p>Please note the subject header. Decompilation is no disassembly.
<p>--
<br>Martin Ambuhl mambuhl AT earthlink DOT net
<p>__________________________________________________________
<br>Fight spam now!
<br>Get your free anti-spam service: <a href="http://www.brightmail.com">http://www.brightmail.com</a></blockquote>
</html>
--------------A1F281BC9BE6AE21957669A1--
- Raw text -