Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #21986 > unrolled thread

decompile

Back to article view | Back to comp.lang.c

Contents

  decompile "Fred" <you@your.domain> - 2012-06-08 20:34 +0200
    Re: decompile gazelle@shell.xmission.com (Kenny McCormack) - 2012-06-08 18:48 +0000
      Re: decompile "Rowan K. Fullack III" <nospam@nospam.com> - 2012-06-09 19:03 +0000
    Re: decompile James Kuyper <jameskuyper@verizon.net> - 2012-06-08 14:53 -0400
    Re: decompile Jean-Christophe <5.d@free.fr> - 2012-06-08 12:00 -0700
    Re: decompile Keith Thompson <kst-u@mib.org> - 2012-06-08 14:15 -0700
      Re: decompile Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-08 17:38 -0400
        Re: decompile Jean-Christophe <5.d@free.fr> - 2012-06-08 14:46 -0700
    Re: decompile Datesfat Chicks <datesfat.chicks@gmail.com> - 2012-06-08 21:27 -0400
    Re: decompile Kenneth Brody <kenbrody@spamcop.net> - 2012-06-09 10:47 -0400
      Re: decompile Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-09 19:10 +0100
      Re: decompile "BartC" <bc@freeuk.com> - 2012-06-09 19:22 +0100
        Re: decompile Kenneth Brody <kenbrody@spamcop.net> - 2012-06-11 09:17 -0400
          Re: decompile pete <pfiland@mindspring.com> - 2012-06-11 22:45 -0400
    Re: decompile Geoff <geoff@invalid.invalid> - 2012-06-09 08:26 -0700
      Re: decompile gwowen <gwowen@gmail.com> - 2012-06-11 02:01 -0700
    Re: decompile "Fred" <you@your.domain> - 2012-06-09 20:43 +0200
      Re: decompile Jean-Christophe <5.d@free.fr> - 2012-06-09 13:09 -0700
        Re: decompile Sorry you're right "Fred" <you@your.domain> - 2012-06-09 23:12 +0200
    Re: decompile John Bode <jfbode1029@gmail.com> - 2012-06-11 07:53 -0700
    Re: decompile Michael Angelo Ravera <maravera@prodigy.net> - 2012-06-13 13:20 -0700
    Re: decompile Dann Corbit <dcorbit@connx.com> - 2012-06-13 16:46 -0700
      Re: decompile gordonb.v9y2l@burditt.org (Gordon Burditt) - 2012-06-18 19:42 -0500

Page 2 of 2 — ← Prev page 1 [2]

#22221

On Friday, June 8, 2012 11:34:30 AM UTC-7, Fred wrote:
> Hello
> 
> it is possible to decompile a program to c?

If you have the executable produced by the compiler for the unoptimized debug version, depending upon how much of the source-related information is kept in it, you MIGHT be able to produce a source code that is actually useful. This would be for the case when you deleted the source code file, but have all of the other pieces.

Once the code is optimized or built for release (which usually discards all of the symbol information), you SHOULD be able to produce C code that does the same thing, but it will not likely resemble anything that any human would actually write.

[toc] | [prev] | [next] | [standalone]

#22237

In article <4fd245b6$1@news.usenet4you.net>, you@your.domain says...
> 
> Hello
> 
> it is possible to decompile a program to c?

Yes.

It is not possible to decompile all programs from executable code into 
C.

It has been demonstrated that a generic decompiler is equivalent to 
solving the halting problem.

All that having been said, there are decompilers that do a pretty good 
job for special cases (e.g., assuming a certain operating system and 
limited set of source compilers and a few other preconditions).

For example:
http://www.hex-rays.com/products/decompiler/index.shtml

However, the C code generated will not be spectacularly better than just 
tracing through the assembly language to see what is going on.

HTH

[toc] | [prev] | [next] | [standalone]

#22385

>> it is possible to decompile a program to c?
> 
> Yes.
> 
> It is not possible to decompile all programs from executable code into 
> C.

If the objective is to produce C source code that when compiled
will do the same thing as the original executable, I have a cheat
that might work reasonably well.

Write a portable emulator in C for the CPU (and perhaps translation
of OS calls) involved (particularly if the CPU is a long-obsolete
model that is not used in current hardware and perhaps it is difficult
to find one that still works).  "Portable" here means implementing
the machine-specific functions of the target CPU in a portable way
on any CPU.  To "decompile" a specific executable, fill in an array
unsigned char memory[] = { ... }; from the executable, and link it
with the emulator.  It may even work with self-modifying code.

One advantage of this is that an executable that used to run on
only one specific CPU may run on several very different ones.  The
emulated run may end up faster than the native one.

A disadvantage is that attempting to make small changes to the
executable to fix bugs may be nearly impossible.  Also, the
"decompiled" version is no easier to understand than the original
executable.  This is also likely true of "real" decompilation.

> It has been demonstrated that a generic decompiler is equivalent to 
> solving the halting problem.
> 
> All that having been said, there are decompilers that do a pretty good 
> job for special cases (e.g., assuming a certain operating system and 
> limited set of source compilers and a few other preconditions).
> 
> For example:
> http://www.hex-rays.com/products/decompiler/index.shtml
> 
> However, the C code generated will not be spectacularly better than just 
> tracing through the assembly language to see what is going on.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web