Slashdot Mirror
Famous Last Words: You can't decompile a C++ program
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)."
Well, it isn't. Sure, if you're so lazy uou want to have source rebuilt from binaries with one click, complete with comments, makefile and documentation, that's of no use. But imagine the program does some very clever trick. Something you ooh about, "How the hell does he do that? It's impossible?". You want to include that trick in your code. You need it. So - you have three options: 1) Try to design it from scratch. Helluva work, you don't know where to start. 2) Look into the binary. If you're ASM guru, you MAY succeed. But ASM from high-level languages is hell to read. 3) Decompile the puppy, look for that piece through what looks like piles of junk, but is way more readable than ASM and find it. Then just rewrite it in pretty fashion, changing variable names and functions to your needs and include in your own software. It's "the best of the worst", last resort at finding a solution to a small problem. Not a way to edit the source and add a single feature to the original program, like remove print protection from Acrobat Reader. The decompiled program most probably won't be possible to compile. You won't make a cow from hamburgers. But with some luck you may find out the cow was a bull and got killed by a truck.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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 :)
Anyone recommend a java decompiler known to work on the most recent versions of java, properly?
Something that will literally give me code I can re-compile immediately?
not the source's lies.
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.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Actually, not quite true. Assembly code is usually considered to mean the mnemonic code intended for human (well, semi-human) consumption, whereas machine language is the actual binary opcodes and arguments.
So, he's sort of right - you can decompile any binary program to assembler. It's usually called disassembly rather than decompilation, though.
Updating Total Annihilation to use opengl, increasing the number of weapons (currently 256), and increasing the weapon limit (3 per unit).
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.
Friends don't help friends install M$ junk.
In europe it is legal to use reverse engineering for compatibility reasons enabling your software to work with others people software (mainly Microsoft)
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).
I wrote reverse compilers on IBM midrange equipment. where there are not stacks and self modifing code is VERY commom place. It is easy to do:
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.
Having finally gotten through to the server momentarily, it appears that the article in question only applies to MS Visual C++.
C decompilers exist; here's one. 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.
That list can also double as 6 things your vendors dont want you to be able to do.
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 ?
No its not.
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.
Nope. It (probably) wouldn't be admissible because of the part that says no reverse compiling. Reverse engineering is something totally different.
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.
You probably could get very close.
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.
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
Not directly, but inputting, say, the name of a function or command to call, looking that up in a table of function pointers, and executing the pointed-to function amounts to the same thing.
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.
File under 'M' for 'Manic ranting'