decompiling back to C++?

sorry, but I don't know much about this topic, but I have used IDA a few times. My question is: is always possible to disassemble a program???
what are those exe protectors for?

Thanks in advance.

[what are those exe protectors for?]

To protect the exe from disassembled

To protect the exe from debugging

Originally Posted by hmora

sorry, but I don't know much about this topic, but I have used IDA a few times. My question is: is always possible to disassemble a program???
what are those exe protectors for?

Thanks in advance.

Yes, it is always possible to disassemble a program, but if the program is protected/packed, the code you see disassembled is the unpacking/protector code; the actual program gets unpacked at runtime. So, you either need to unpack the program to see its code in the disassembler, or you just look at the code at runtime using a debugger.

Regards

With C you can reach only a partial decompiling due to the complexities caused by the optimizations in the compiler. The source code can have many statements that are simply optimized away when it is complied.
With C++, well, sorry, it is impossible. How on the earth you can reach the source code of a STL vector or a Boost smart pointer by looking at the machine code? They are already lost in the first compilation phases and even dont make it to the backend....

Actually, I can remember true decompilers for FORTRAN created during the 70s and early 80s. Grad students would build such things during the wee hours. Each different machine had to have it's very own handcrafted version. The binary for a DEC and CDC were very different. As I recall, aside from the lost variable names, (no one commented their FORTRAN code), these programs did quite well in reproducing the original code. Of course by comparison, FORTRAN is a relatively simple language, no classes, simple data structures, etc.

I would be surprised if such custom-made decompilers don't exist for C++. I can't imagine that some kid from M$ with plenty of time at night hasn't coded one up for VC.

cheers, jsteed

It may be rewrite in C++, not decompile.

uncompiler is not a easy thing...
it needs more other experienced KB.
and more symbols and debug info ar lost during compiler,
so uncompiler endeaver recover these thing.
such as..
source code:
void SwapTwoNumber(int* a,in* b)
{.................
}

via uncompiler may be in these form:
sub_0121(DWORD* a1,DWORD* a2)
{......
}

yep,SwapTwoNumber is info, u maybe will soon master some funcs by name,,
So uncompiler will try to recover these name,this can be attained by AI.
the above is one easy instance...
Had time,we can dicuss these techz in detail..

Thre are actualy 2 asm>C plugins for IDA decompiler, sometimes I combine 2 of them to get more clear view on code. This are not serious decompilers only just one more look from other perspective. Decomile to C hase better output than Inquisition plugin but it sometimes skips some parts of code that can not understand. So you are back at asm and IDA representation of code

since there is optimization when compiling,compilier changed it too much.

I have try some decompiling tools before. But it very difficult to read and understand. The organization is very badly.

It is worth seeing the home page of The International Obfuscated C Code Contest. (hxxp://www.ioccc.org)
I would be surprised if there would ever be such an AI that could retrieve those sources.
Just an example to taste it:

#include <stdio.h>
int l;int main(int o,char **O,
int I){char c,*D=O[1];if(o>0){
for(l=0;D[l              ];D[l
++]-=10){D   [l++]-=120;D[l]-=
110;while   (!main(0,O,l))D[l]
+=   20;   putchar((D[l]+1032)
/20   )   ;}putchar(10);}else{
c=o+     (D[I]+82)%10-(I>l/2)*
(D[I-l+I]+72)/10-9;D[I]+=I<0?0
:!(o=main(c/10,O,I-1))*((c+999
)%10-(D[I]+92)%10);}return o;}

This is a square root calculator, note the form of the whitespaces

Ok, this (and the others on the IOCCC page) are not real-life examples, but as LoveExeZ pointed there are substantial information in the source code that is simply impossible to get back.

On the other hand if we just get back only a small subset of this extra info, it can help a lot. If one gets back a part of the inheritance hierarchy, then it can be very useful.
Polymorph classes and virtual function calls can be recognized because they use the vptr (exact implementation details differ from compiler to compiler). The hierarchy can be reproduced from the constructors and the destructors as they again have a certain structure (calling the ctor of base's base, the ctor of base etc.)
Finding constructors and destructors is easy from the virtual table, and having these functions identified, lots of info can be given.
Just imagine the following:

Originally:

function1()
{
   int i1, i2, i3, i4, i5;
   function2( &i1 );
   function3( &i4 );
   function4( &i1 );
   function5( &i4 );
   function6( &i4 );
   function7( &i1 );
}

Having ctor/dtor pairs identified:

function1()
{
   Class1 Object1;
   Class2 Object2;
   Object1.Member1();
   Object2.Member2();
}

I think by it's very nature compilation is a one way process. You can reconstruct source code from a disassembled binary executable that may well closely resemble the original source code but as Sarge very astutely mentioned variable and function names will be mangled, comments will be lost, etc. Maybe if there was a decompiler that incorporated some kick-ass artificial intelligence that could magically analyze and emulate the personality and proclivities of the developer who wrote the code we'd see a decompiler of the nature discussed in this thread. Barring that, you can send me the money and I'll use it to buy crack.

Originally Posted by br00t_4_c

You can reconstruct source code from a disassembled binary executable that may well closely resemble the original source code but as Sarge very astutely mentioned variable and function names will be mangled, comments will be lost, etc.

Yes, that is the realistic view. These information are simply lost during compilation. Assuming there is no debug info, just the compiled, stripped .exe we can't do anything against this.
I am sure, however, that even such a source with names like variable1, variable2 etc. can be a great help for anyone who wants to understand the original ideas behind the code.
Don't forget that the other alternative is facing a huge, unorganized list of assembly functions.
Some information that I am sure can be (at least partly) recognized when the optimization doesn't hide it:
C++ specific:
- virtual tables
- ctors, dtors
- inheritance relationships
- dynamic_casts
- class sizes
- stack objects
- global objects
- member functions
- member pointers, member function pointers
- heap allocations
C specific:
- switch statements
- loops
- function calls
Assuming we have a tool that collects all these information and it is built into a debugger (OllyDbg for example), just imagine what help it could be.
OllyDbg supports writing comments next to the code. If this tool also supported naming of the recognized structures, complete parts of the original code could be reconstructed.

Originally Posted by br00t_4_c

Maybe if there was a decompiler that incorporated some kick-ass artificial intelligence that could magically analyze and emulate the personality and proclivities of the developer who wrote the code

Creating utopias
If we had such AI the programs probably wouldn't be written by humans. Humans would just assist defining the target conditions.
Then the abstraction level would be more far from the assembly level, and that AI would still be not enough. But there would be recognizable patterns in the created code and a tool could be created to display them. A lot of info would be lost, but with some patience complete parts of the original code (or target conditions) could be reconstructed manually.
Back to the ground
As the coder is (probably) a person, just another person is smart enough to recognize his/her thoughts. The automatically recognizable patterns should be shown, these are the language elements (cycles, function calls etc.), but the rest should be left to the user. I know that there are some coding patterns that could be easily recognized, but the rev.engineer is who should recognize and mark them. The best tool doesn't do everything, but it does it in a reliable way you can build on.

If anyone were interested in writing the OllyDbg plugin contoured above, I would give further details on the possible recognization of the mentioned structures with pleasure.

with me.
it's possible.
but convert this what for?
without understand of algorithm, a program like a death body.

i don't know any program to do that but anyone can convert it manually.

each c++ compiler has a own way to generate code from c++ to c and then from c to asm.

so if you want to convert code from program to c++ you must:
+ convert machine code to asm - ida pro can handle almost
+ convert this asm to c - the hardest step @@!!!@@
+ depend on what compiler that generated this code, convert this c code to c++ code - the easiest step.


hope this can help you.
regards

@mihaliczaj:

On the subject of decompiler development, it would be interesting to develop an application that could perhaps transform a disassembly into source code by making statistical comparisons of a given disassembly (having unknown source) with disassembly from known source code. I'm thinking of something along the lines of a "genetic" decompiler, that is to say one that over time the decompiler would be capable of some form of "learning" and would generate a more and more accurate reproduction of the original source code. If a sufficiently large database of disassembly to source mappings could be generated for a given set of languages and a suitable set of pattern recognition algorithms could be developed and these pattern recognition algorithms were "evolutionary" (i.e. we have a set of pattern recoginition algorithms that can either be selected or discarded based on how accurate an approximation of known source code can be generated from the corresponding disassembly) we might be able to arrive at a decompiler that reconstructs source code in a manner that is true to the original. I do however believe that such an application goes way, way beyond the scope of what can be accomplished with the olly plugin api. I think it would maybe be more appropriate to consider developing it as a stand-alone app. But that's just my opinion. Holler back if you want to discuss this further.

[Shub-Nigurrath]

Hi,
have you ever heard of Desquirr? An IDA plugin, free, sourceforge, which tries to do exactly what you are talking about..

hxxp://desquirr.sourceforge.net/desquirr/

Desquirr is a decompiler plugin for IDA Pro. It is currently capable of simple data flow analysis of binaries with Intel x86 machine code.

might give some nice ideas, beside Boomerang, another free decompiling tool, already mentioned in this forum..