Famous Last Words: You can't decompile a C++ program 479
The Great Jack Schitt writes "I've always heard that you couldn't decompile a program written with C++. This article describes how to do it. It's a bit lengthy and it doesn't seem like the author usually writes in English, but it might just work (haven't tried it, but will when I have time)."
To all those, who think it's useless... (Score:4, Interesting)
Reverse-engineering programs written in C/C++ (Score:2, Interesting)
I've done some reverse-engineering on programs written in C/C++ (Intel x86). After a while you learn how to recognize different things like virtual function calls, while/for-loops, switch and stuff like that. However, it's a totally different thing to decompile to C++. It may be possible to decompile compiled code to C, but don't expect that it will look much like the original source, especially if the code was optimized by the compiler :)
Java Decompiler? (Score:3, Interesting)
Something that will literally give me code I can re-compile immediately?
A good decompiler shows you what was written (Score:5, Interesting)
Losing source code and var names (name spaced globals aka statics and scoped locals) allows the cracker (these are rarely hacking tools, they're mostly cracking tools,) to focus on what the machine actually was told to do instead of smothering it with shades of meaning which interfere with understanding the code.
C++ or Java or Smalltalk, or almost any highly structured language using machine code libraries or virtual machines result in structured blocks of code and heap and stack allocation.
A good decompiler can take the machine code, peel away the name spaces and code calls, extract the patterns in the code and the hacker/cracker can read the patterns instead of wasting time on the code.
Forensic analysis work is extremely useful at telling you what happened when something dies but it is no good at telling you how something worked. For that you need code traces.
Map those code traces onto the structure the decompiler reveals and you understand the program better than the authors/coders.
Re:Why not? (Score:2, Interesting)
So, he's sort of right - you can decompile any binary program to assembler. It's usually called disassembly rather than decompilation, though.
Single sentence answer. (Score:1, Interesting)
thanks for nothing. (Score:4, Interesting)
Shame on you Davak, you should go find honest code. There's nothing wrong with trying to understand how things work. Some people are stuck with legacy equipment or code they can't replace easily and this is their only option for improvement or even fixing it. Those people would be better off if free code were available. Sometimes the only way to make that free code is to understand the original code. There's nothing wrong with reverse engineering software, ever. Republishing someone else's binary is not legal, but it's not immoral. If the code were honest to begin with, the reverse engineer part would not be required. These days, it's cheaper to throw out the dis-honest code and hardware and buy some hardware that's well understood. If you make hardware or software, I hope you understand the implications for your product - I'm not buying it.
Usefull for compatibility reasons (Score:2, Interesting)
If you make the reverse engineering in europe you could develop compatible software and then export it to US. So it may be great news for us. In fact it is becoming really complicated to develope software for/at US. Patents, legislation, compatibility. It seems that more lawers than programmers are needed to write something more complicated than HelloWorld.exe.
There is a need for tools that enable the compatibility of the programs or we will end with a monopoly of all kinds of progrmas (And it is illegal to use your O.S. monopoly to obtainthe monopoly of let say...web browsers).
Re:Java Decompiler? (Score:3, Interesting)
Re:hmm (Score:5, Interesting)
Create a program that preforms / understands the opcodes for the processor and addressing. And it follows both sides of a branch.
Now "run" the program, that maps out the all opcode and data areas.
Once done. Look at that Assemmebler equivatlent, map out commom subroutines and function calls. Data Storage become very clear. Lastly, commom storage with show external and internal common structures - so naming of fields and visualable.
It is striaght forward, can be time comsuming - and very helpful is understnad hinden or loss information.
Only Works for PE (.exe) and MS Visual C++ (Score:1, Interesting)
Decompiling is possible, but hard (Score:5, Interesting)
C decompilers exist; here's one. [backerstreet.com] There are others. Most aren't very good. It's a hard problem.
Without debugging information, decompilation tends to result in code with arbitrary variable and function names, of course. But you get names when a DLL or .so is entered, so at least you get the program's major interfaces.
Minimal C++ decompilation could be done by adding vtable recognition to a C decompiler.
A more difficult problem is recognition of idioms. Things like "for" statements tend to decompile as lower level constructs. That's OK as a first step. You need some internal representation Initial decompilation might represent all transfers of control with "goto"; higher level recognition then deals with that.
The key to doing a good job is "optimization", finding more concise source code that will generate the object code. The key to this problem is defining an internal representation that can represent any valid machine-language program, and which can be modified as higher level information about the program is discovered. The first step is usually to start at the starting address and build a code tree by following calls, like a good debugger does. Then you start to improve on the code tree, doing things like this:
Decompilation won't always succeed. But you should find all the places where the code is doing something the compiler doesn't understand, and get code back for everything else.
It's a big job, and somebody ought to do it. Among other things, it would be a valuable tool for finding compiler bugs.
Re:Why (Score:4, Interesting)
I have always felt the greatest problem with closed source was it forced you to trust someone who you were fairly certain had only one skill and that was salesmanship.
It of course raises the interesting question of if you find a copyright violation, in commercial software is your evidence void because the license agreement usually excludes all reverse engineering ?
Re:Why (Score:3, Interesting)
It may be a violation of the license agreement which would be a violation of a civil contract The enforcibility and applicability of said agreements have been a point of contention for nearly 30 years now.
Re:Why (Score:5, Interesting)
Reverse engineering is taking a black box and figuring out what it contains by giving it test inputs and watching the outputs. There are a few other things considered reverse engineering, but that describes most of it.
Of course, all of this ignores the fact that EULAs have never been tested in court. They could be proven invalid as contracts fairly easily since the exchange of goods occurs before you ever see the EULA and most stores don't accept returns of opened software. Therefore, if you don't agree to the EULA, you still have the right to use what you purchased.
On an interesting side note, various free trade laws specifically protect reverse engineering.
Re:You can't (Score:2, Interesting)
With straight C++ classes you probably could get something back resembling them. VC is a very regular compiler. Which is the one he used. Havent looked at what VC dose to templates. But I would be willing to bet it transforms them into type specific classes then into C. Would just need to use the preprocessor and see what it did to it.
Inline functions though would be imposible to get back. But then again they are inlined. So the code would be there. Just not necessaryly in the original form.
The VC compiler is just a transform engine. It transforms from C++ to C to PCODE to ASM. Course thats 5 year old info. When I used to care about what the compiler was doing to my code. Templates are probably similar.
Im sure the code that came back out of this thing would be UGLY. But if you look at the end of most exe's shipped these days most developers do not even bother stripping the exe anymore. You probably could even get back MOST of the classe names and function names maybe even the variables.
From the author (Score:5, Interesting)
Anyway i seen alot of people saying decompiling is impossible or at least not practical, well that is not true. Decompiling c++ is very practical because of high level keywords(if,while,for) ,local variables, and parameters. All of these generate certain instruction similer on every platform and just about every proccesser.
I also extending the artical to contain 92 pages in total which will cover OOP, and crt, and a whole bunch of other stuff
Re:Why not? (Score:3, Interesting)
The author can't take honest criticism. (Score:4, Interesting)
Not only does the author completely fail to realize that the technique he is describing doesn't remotely qualify as decompilation, and is is nothing but normal reverse engineering, but he figures that the appropriate response to negative criticism is to remove evidence of it rather than attempt to intelligently respond. I noticed that my vote of 1 of 5 was still intact on his voting page, though.
I was originally surprised when I first read the article that someone would think it had merit enough to write about, but having some insight into the mindset of the author that I did not have before (offered by his rapid censorship of my remarks), my surprise has waned completely.