decompiling back to C++?

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.

Originally Posted by phoenixodin2

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.

Yes, that is the point. This is what I mean. You should do this manually, but a program can help in this a lot. I think it is impossible to give an always-working automatical solution, but instead it is possible to give one that assists you in recreating a code that has an equivalent structure.

Originally Posted by phoenixodin2

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

This was true for a long time, but when new language features had been added this didn't work any more.
A referred to an excellent book about the details in a previous post.

Originally Posted by phoenixodin2

+ convert this asm to c - the hardest step @@!!!@@

This is not that hard, there are existing tools for this.
C is very near to asm.

Originally Posted by phoenixodin2

+ depend on what compiler that generated this code, convert this c code to c++ code - the easiest step.

This is the hardest.
The problem is that in C++ you don't just write what should the computer do (as you do in C), but at the same time you organize the code to mirror your thoughts. There is hidden information.
Just think about public, protected and private. It is some kind of documentation and error prevention, you cannot find anything about these in the generated code. This is why the assistance of a coder is needed to recognize such things.

IMHO, you can certainly get something.... Is it possible to extract some high level constructs from the binary... And this information can certainly be presented as C++.... Now, you will certainly not get any variable name, no classes/methods, just plain functions (it may be possible to get some information for virtual functions, but everytime the method is totally resolved at compile time, the information will not be available)... I don't think information on structures can be automatically extracted...

So what you will most likely get is a set of functions (which is not likely to be the same set of functions/methods used in the orginal code), accessing local and global variables, with un-precise types (some types can be inferred when the variable is used with known functions, but a variable is mostly a memory location.. can be anything).
The interesting information that can be extracted is part of the high-level constructs used in the function bodys: loops, tests... Some research project are already capable of extracting such information, which is then used to perform some optimization directly on the binary.

Anyway, to answer the original question, i would answer yes: it is IMHO possible to decompile to C++... For the most part, you can write assembly and C in C++, so it's not a big deal. However, you will get something which is more C than C++, and which may bear only small resemblance to the original code. And doing that would already need quite some time....

I'm glad you mentioned optimizing. I already though about a method.. If you make az abstarct representation of the semantics of the code (as I wrote in the first part of my previous post) then you can even transform it back to asm. Since you can describe asm with this language, you can create many representations back and choose the one that is most optimal for you. You just have to be sure that you transformed everything.
I'm not sure I can describe my idea well... so the algorithm could be like:
describe the asm instructions with these abstract statements (there could be more than one representation, of course). Then you look for these sequences in the abstract representation (doestn't have to be strictly a sequence, there canm be holes that will be represented by other instructions). Then, you will have many-many asm representations that do exactly the same. So you can make a function that computes you an optimality value, and choose the best.

I didn't know whether there is research in this direction, maybe I didn't find anything new

kp

I saw an article describing something similar while working on the automatic generation of multimedia instructions (MMX, SSE and the like). While most works tend to focus on generating optimized binary (or source code using special constructs to direct the use of multimedia opcodes), one group was studying instead the possibility of applying the same kind of optimization directly on the binaries, thus using an approach similar to one you picture.

Unfortunately, i can't find the references of the article i read... I'll post it if i find it later... In any case, it should be referenced on citeseer (hxxp://www.citeseer.com), and referenced through keywords like 'SIMD', 'vectorization' or 'multimedia instruction set', so you may want to try to look there if you are interested.

I think it will depend on how big and how complex the program is. If the program is very big like M$ office, I would say it's impossible.

[Shub-Nigurrath]

C++ get decompiled back to C to be exact, all the object things are converted to C structures such as the hierarchy, virtual functions and so on are effectively implemented using vtables and so on.

I read a study which described how to do object programming using simple plain c..it's not a hypothesis but a need on some platforms where there isn't available c++ compilers..

Certainly, it would be impossible to get the exact code, just as the programmers had written it. The code optimizations made by the compiler make this impossible.

You may get a C/C++ code, but it would be impossible to read. Have you tried to read a simple program written by a bad programmer? I'm a student and I had got to check some codes from other students, on their first programming course. Even if you know what the code should do, it's really hard to understand everything.

I think this would happen if you get something from ASM to C++. It would be a big mess. Maybe everything got sense thinking about classes, with functions making specific tasks. Now think the compiler will make a "few" changes. Then put it into assembler. Taking it back to C would complicate the things even more.

Why would you want to get SOME (and not THE) C code from a program? I still don't see what is the idea behind this.

[Polaris]

Hmm... I think that there is some confusion about this...

Decompilation to C++ is impossible. The decompiler can rebuild only information contained within its target: now, since its target is ASSEMBLER, which lacks anything related to HLL, it cannot surely rebuild things that are not included, like objects.

Also, consider that some C++ concept are completely discarded after the code checking phase, and are never really used within the compiler: for example the PRIVATE/PUBLIC/PROTECTED directives are used only for security checking.

Recently I have disassembled some programs in RISA,
it is very easy to rewrite program in C++ from disassemble
codes.If you want to decompile, maybe you should
do it in different ways in different Platterm(i386,hpoa and so
on).

If you are actually interested in learning about what the structures from c++ to assembly look like, Kris Kaspersky presents very clear and useful information in his book Hacker Disassembling Uncovered.

He presents lots of information about how compilers optimize code and why it would be impossible to write a program to decompile back to c++. IDAs FLIRT signatures are a big step, recognizing the patterns of known api's and displaying them, however even those arn't entirely correct. IDA often misrecognizes calling conventions, I can't imagine relying on a program to transform anything more complex than that if it isn't within reasonable amount of accuracy.