Very Computer

by **Thomas Dinee** » Thu, 05 Sep 2002 07:57:32

Gentle People:

Is there such a thing as a De-Compiler. A tool
that accepts as it input an object or executable file
and produces as its output say a C source file?

Now I know this synthesized source would be rather
mechanical in format. But has this ever been done?

Thomas Dineen

by **Vadim V. Kouevd** » Thu, 05 Sep 2002 08:12:28

> Gentle People:

> Is there such a thing as a De-Compiler. A tool
> that accepts as it input an object or executable file
> and produces as its output say a C source file?

CPU doesn't know about C. The only thing it knows -
assembler. And De-Compiler is called disassembler.
As example see below URL (they claim it works with SPARC
COFF).

> Now I know this synthesized source would be rather
> mechanical in format. But has this ever been done?

> Thomas Dineen

http://www.datarescue.com/freestuffuk.htm

by **Thomas Dinee** » Thu, 05 Sep 2002 10:50:57

Vadum:

"CPU doesn't know about C." I agree.

But from what I know of compilers you might
be able to work the process backwards? Think
about this: The compilation process from the
parsing of the source produces a token stream,
where the tokens are ultimately mapped to Assembly
Code Routines. I wonder if one could analyze these
routines and work the problem backwards?

Just a thought.

Thomas Dineen

> > Gentle People:

> > Is there such a thing as a De-Compiler. A tool
> > that accepts as it input an object or executable file
> > and produces as its output say a C source file?

> CPU doesn't know about C. The only thing it knows -
> assembler. And De-Compiler is called disassembler.
> As example see below URL (they claim it works with SPARC
> COFF).

> > Now I know this synthesized source would be rather
> > mechanical in format. But has this ever been done?

> > Thomas Dineen

> http://www.datarescue.com/freestuffuk.htm

by **Vadim V. Kouevd** » Thu, 05 Sep 2002 11:24:50

> But from what I know of compilers you might
> be able to work the process backwards? Think
> about this: The compilation process from the
> parsing of the source produces a token stream,
> where the tokens are ultimately mapped to Assembly
> Code Routines. I wonder if one could analyze these
> routines and work the problem backwards?

Let's see. You can produce assembler code by disassembler.
Write analyser+convertor_to_C and that's it (find some VC to
pay for a job and I'll do it) :-)

What will you do with result?! And why do you need it?
To hack some S/N for some program? It's done in assembler.
To decompile M$ Word and compile under Solaris? Hmmm...

It isn't worth of time/money/etc.

> > > Gentle People:

> > > Is there such a thing as a De-Compiler. A tool
> > > that accepts as it input an object or executable file
> > > and produces as its output say a C source file?

> > CPU doesn't know about C. The only thing it knows -
> > assembler. And De-Compiler is called disassembler.
> > As example see below URL (they claim it works with SPARC
> > COFF).

> > > Now I know this synthesized source would be rather
> > > mechanical in format. But has this ever been done?

> > http://www.datarescue.com/freestuffuk.htm

by FM » Thu, 05 Sep 2002 12:04:05

> Gentle People:

> Is there such a thing as a De-Compiler. A tool
> that accepts as it input an object or executable file
> and produces as its output say a C source file?

> Now I know this synthesized source would be rather
> mechanical in format. But has this ever been done?

It's pretty easy, but why? The resulting source code
is unlikely to be any more useful (or readable) than
the executable itself. Of course that depends on the
executable format.

Dan.

by **gswo** » Thu, 05 Sep 2002 20:55:37

> Gentle People:

> Is there such a thing as a De-Compiler. A tool
> that accepts as it input an object or executable file
> and produces as its output say a C source file?

There are various attempts at it. Generally though the best you can
hope for is a one-for-one translation of machine code to assembly
instructions, even then may not look like the original source.

You could try and divine what c code may have needed to be in order to
produce the executable though, but.....

Quote:> Now I know this synthesized source would be rather
> mechanical in format. But has this ever been done?

I recall using a 'c decompiler' few years ago, I don't remember the
name - it may have been a CS project or somesuch. It certainly
produced a .c file from an executable but the code was very very long
(much longer than the code needed to compile it in the first place)
and very difficult to read, and it wouldn't compile anyway!

It was a brave effort though.

by **srive** » Thu, 05 Sep 2002 21:00:04

I think the decompilers are also called REVERSE COMPILERS

by **Programmer Du** » Thu, 05 Sep 2002 23:38:00

> But from what I know of compilers you might
> be able to work the process backwards? Think
> about this: The compilation process from the
> parsing of the source produces a token stream,
> where the tokens are ultimately mapped to Assembly
> Code Routines. I wonder if one could analyze these
> routines and work the problem backwards?

De-compiling is not unlike, as they commonly say around here,
trying to re-create the cow from the hamburger. Compiling
is a one-way process in which information (variable names,
line numbers, etc.) is destroyed, so *IN GENERAL* you cannot
retrieve high-level source code from object code.

In special cases--particularly if the compiler is intimately
known--it can be possible to get some of the source back,
but it's usually not very good.

--

|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|

Opinions expressed herein are my own and may not represent those of my employer.

by **Chuck Swige** » Fri, 06 Sep 2002 03:16:25

Quote:> Is there such a thing as a De-Compiler. A tool
> that accepts as it input an object or executable file
> and produces as its output say a C source file?

Sure. But it's generally easier to work from the original sources, or roll
your own replacement.

Quote:> Now I know this synthesized source would be rather
> mechanical in format. But has this ever been done?

Yes, although you understate the results, somewhat. The synthesized sources
are completely mechanical and represent a functional transliteration, minus
variable names, comments, original control flow, etc...which makes them not
very useful to a human programmer.

-Chuck

-------------+-------------------+-----------------------------------
"The human race's favorite method for being in control of the facts
is to ignore them." -Celia Green

by **Richard Heathfiel** » Fri, 06 Sep 2002 02:52:38

> I think the decompilers are also called REVERSE COMPILERS

They are simply called "compilers".

A compiler is a program for translating a program written in one
language into the same program written in another language. That the
source language happens to be x86 machine code (or whatever) and the
target language C or C++ or whatever really makes no difference at all.

--

"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

by **Richard L. Hamilt** » Fri, 06 Sep 2002 04:27:09

>> But from what I know of compilers you might
>> be able to work the process backwards? Think
>> about this: The compilation process from the
>> parsing of the source produces a token stream,
>> where the tokens are ultimately mapped to Assembly
>> Code Routines. I wonder if one could analyze these
>> routines and work the problem backwards?

> De-compiling is not unlike, as they commonly say around here,
> trying to re-create the cow from the hamburger. Compiling
> is a one-way process in which information (variable names,
> line numbers, etc.) is destroyed, so *IN GENERAL* you cannot
> retrieve high-level source code from object code.

> In special cases--particularly if the compiler is intimately
> known--it can be possible to get some of the source back,
> but it's usually not very good.

And each compiler (version) is likely to have slightly different
code-generating idioms. Imagine the fun trying to decompile an executable
that was statically linked with .o (or .a) files compiled by different
compiler versions (or with even different code generation/optimization
options).

There are probably some commercial (or otherwise) reverse-engineering
tools out there. But using them on anything non-trivial probably takes a
lot of skill and a lot of effort, and while they might reveal quite a bit
about what the executable does and how it does it, they'd be quite useless
for recovering lost code (or ripping it off in its entirety).

Even for something much simpler to decompile (Java), there are obfuscation
tools that scramble all internal variable names, etc., to make the job
a lot more difficult.

--

by **Programmer Du** » Fri, 06 Sep 2002 04:52:10

>> I think the decompilers are also called REVERSE COMPILERS

> They are simply called "compilers".

> A compiler is a program for translating a program written in one
> language into the same program written in another language. That the
> source language happens to be x86 machine code (or whatever) and the
> target language C or C++ or whatever really makes no difference at all.

If you're being serious I don't think I agree, although I'm having a
hard time coming up with a cogent argument. Maybe it has something to
do with the x86 m/c input not really being (directly) "written" by a
user. I wonder, too, if "compile" doesn't imply going from high-level
source **text** (of some kind) to low-level **binary** (of some kind).

[shrug] Whatever. ;-)

--

|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|

Opinions expressed herein are my own and may not represent those of my employer.

by **Richard Heathfiel** » Fri, 06 Sep 2002 07:03:49

> >> I think the decompilers are also called REVERSE COMPILERS

> > They are simply called "compilers".

> > A compiler is a program for translating a program written in one
> > language into the same program written in another language. That the
> > source language happens to be x86 machine code (or whatever) and the
> > target language C or C++ or whatever really makes no difference at all.

> If you're being serious I don't think I agree, although I'm having a
> hard time coming up with a cogent argument. Maybe it has something to
> do with the x86 m/c input not really being (directly) "written" by a
> user. I wonder, too, if "compile" doesn't imply going from high-level
> source **text** (of some kind) to low-level **binary** (of some kind).

"Simply stated, a compiler is a program that reads a program written in
one language - the /source/ language - and translates it into an
equivalent program in another language - the /target/ language." - Aho,
Sethi, and Ullman, "Compilers: Principles, Techniques, and Tools".

Nothing in there about "levels". :-)

--

"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

by **Thomas Masle** » Fri, 06 Sep 2002 10:54:30

[...]

Quote:> Is there such a thing as a De-Compiler. A tool
>that accepts as it input an object or executable file
>and produces as its output say a C source file?

> Now I know this synthesized source would be rather
>mechanical in format. But has this ever been done?

Yes. Look up Cristina Cifuentes' work, e.g. some of the papers at

http://research.sun.com/people/cristina/decompilation-publications.html

http://www.itee.uq.edu.au/~cristina/

Thomas Maslen

by **Programmer Du** » Fri, 06 Sep 2002 23:33:29

>>>> I think the decompilers are also called REVERSE COMPILERS

>>> They are simply called "compilers".

>>> A compiler is a program for translating a program written in one
>>> language into the same program written in another language. That the
>>> source language happens to be x86 machine code (or whatever) and the
>>> target language C or C++ or whatever really makes no difference at
>>> all.

>> If you're being serious I don't think I agree, although I'm having a
>> hard time coming up with a cogent argument. Maybe it has something to
>> do with the x86 m/c input not really being (directly) "written" by a
>> user. I wonder, too, if "compile" doesn't imply going from high-level
>> source **text** (of some kind) to low-level **binary** (of some kind).

> "Simply stated, a compiler is a program that reads a program written in
> one language - the /source/ language - and translates it into an
> equivalent program in another language - the /target/ language." - Aho,
> Sethi, and Ullman, "Compilers: Principles, Techniques, and Tools".

> Nothing in there about "levels". :-)

Pretty authoritative source, too!

Nevertheless, I persist (in fun). Question: how many pieces of software
which *call* themselves "compilers" do you know that translate a low-
level source to a high-level source?

Also consider that compilers (almost always) take *text* files as input,
but de-compilation takes binary object code and emits text.

And I wonder if I can thrown in the idea that that object code isn't
"written" in the usual sense meant wrt source code.

Shooting off on a tangent, hey, how about an "assembler" that takes
*written* assembly and translates that to a high-level language?... ;-\
At least you'd have all the object names handy!

Wonder what the "optimizing" version would be like!

--

|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|

Opinions expressed herein are my own and may not represent those of my employer.

Very Computer

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?

De-Compiler Question?