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)."
Why (Score:0, Insightful)
I'd just leave it alone.
You can't (Score:5, Insightful)
Like turning hamburgers into cows...
Why not? (Score:5, Insightful)
Well, you can decompile every binary programm at least to assembler code, so why shouldnt it possible with C++?
Maybe he ment "you can't decipher the source of a C++ programm"
Re:Why (Score:5, Insightful)
1) Finding backdoors
2) Testing security
3) Fixing bugs
4) Adding features
5) Discovering copyright violations
6) Interfacing to non-supported clients
Pretty much anything and everything you would do if you had the source.
Re:Why (Score:5, Insightful)
Inline functions, templates and decompilation (Score:5, Insightful)
Re:Text of the article (Score:2, Insightful)
please stop breathing and kill any offspring you may have inexplicably fathered for the sake of our gene pool. Thanks.
Respectfully,
-- Human Race
Re:To all those, who think it's useless... (Score:4, Insightful)
A hidden API call - which can be easily found via ASM listings
A nice little algorithm - which can be found in comp sci books
An elegant piece of code - which can *not* be decompiled from ASM
So no, I disagree with you.
Re:Why (Score:2, Insightful)
Re:You can't (Score:5, Insightful)
I'll RTFA when it comes back to life :).
Reverse engineering has its uses... (Score:5, Insightful)
Re:hmm (Score:3, Insightful)
The barrier to entry is definately raised, but it is always possible to figure out what the compiled code is doing given enough time and effort. In fact, I've even heard of people who patch operating system kernel code without the source...
Re:Why (Score:2, Insightful)
What you need is a decent source control/backup system, not a decompiler.
Re:Why (Score:3, Insightful)
Decompiling to C++ is like... (Score:4, Insightful)
Thank you, thank you. I'm Mr. Metaphor and I'll be here all week.
Re:Why (Score:3, Insightful)
Re:Why (Score:5, Insightful)
nice try.
You must be either Bill Gates, Steve Ballmer or someone who works for the BSA.
How am I to tell if your close source program isn't full of my GPL code that you blatently stole and are trying to rob me blind by STEALING my IP? Being a closed source advocate as you seem to be you are for me trying to detect IP theft and the illegal STEALING of my code by PIRATES right?
Ok, I'm going overboard to make my point... I have EVERY right to use tools in a good and legal way. Why not outlaw hammers as anyone can perform a very grisly and horrible murder with one... Or better yet only allow licensed contractors to have hammers! as we know that the unlicensed public is only going to do very ewvil things with tools!
see my point now? A tool is exactly what it looks like.... a tool. it can be used for good and evil. and I dont have any respect for the self righteous like you condemning what I do before I even do it.
people with attitudes like you are what cause all the pain and suffering in this world...... STOP IT!
Decompilation = halting problem (Score:4, Insightful)
The long version: In a compiled computer program there is no distinction for either code or data. Every byte in memory can be data, but it can also be executed as valid computer code.
Now, the catch is that during compilation, data and code are mixed in the resulting binary. For instance take the compilation of a 'case' statement. There are several ways of compiling a case:
- you can write it as a list of IF's, which is perfectly fine decompilable
- you can write it as a jump, based on the case expression.
The fun part about the second possibility is that it's far more efficient, but it poses a problem: when decompiling this you have to know where the bounds of the case lie. What's the furthest jump that can be made? It's a jump based on a calculated value, so you should know which values are possible. But for that, you need to run the program, and more specifically, you must run all possible execution paths.
This can be rewritten as the instance of the halting problem: can a computer find out for any program whether or not it will halt? It is proven that a computer program cannot be written to do this task. Neither can a computer program decompile any other computer program.
Re:It's the other way around (Score:3, Insightful)
No, no, no. This is both empirically untrue, (Do you see many ML or even C++ decompilers out there?) and theoretically insensible.
The higher level a language is, the more changes there will be between the original source code and the assembly. Thus the more source data that will have been discarded by the original compiler, which is data the decompiler cannot reconstruct.
The reason Java decompilers work relatively well is not because Java's a high-level language (it isn't, really), but because the output program is at such a high level! Instead of working from binary code, a Java decompiler gets a more presentable bytecode, packed with the names of classes and methods. (Also, because optimization of Java programs is supposed to happen after compilation at a JIT stage, the bytecodes won't be as obfuscated as the output of a normal C++ optimizing compiler)
The closer the original source was to asm, the more the individual coder's style will be reflected in the asm
When decompiling, the "individual coder's style" is exactly what you're trying to get!
the more the obvious patterns the compiler uses every time for given constructs will be present.
Good compilers don't use "obvious patterns". Their transformation functions are very sensitive, so a tiny change in the input source (expanding a loop from 3 times to 4) can cross an optimization threshold and totally change the appearance of the output.
Halting is a red herring (Score:2, Insightful)
Now, the catch is that during compilation, data and code are mixed in the resulting binary.
Not last time I checked. My compiler emits at least four segments in a compiled program: .text (program code), .rodata (initialized data marked as 'const'), .data (initialized data), and .bss (zero-filled data, which is run-length encoded). Segments .text and .rodata are also write-protected.
Yes, there is a halting problem, but this isn't it. Segments make distinguishing code from data straightforward. I understand that a few programs make platform-specific API calls that write-enable .text would be harder to disassemble (and subsequently decompile), but do most user programs make such calls?
Besides, even if the halting problem were relevant, the halting problem can be solved in a real computer, which has limited memory and is thus a linear bounded automaton [netaxs.com] rather than a Turing machine.
Re:You can't (Score:3, Insightful)
Re:Decompilation = halting problem (Score:3, Insightful)
Furthermore, there is nothing saying that it has to do a 100% perfect job. Decompilation is already accepted to be imprecise; using some common sense (intuition if you want) to fill in some gaps is not an invalid method.
The problems that face decompilation that stem from real-world issues are far, far greater than this (rather theoretical) problem. For example, decompiling any STL-based source to a useful state will be far more difficult than a simple jumptable.
Re:Decompilation = halting problem (Score:1, Insightful)
Compilation is the process of converting one defined stream of data into another defined stream of data based on a ruleset. The ruleset usually discards useful meta information, like comments, but the core information is retained and the process is, for the most part, predictable--feeding the same source to the same compiler with the same settings will yield identical results as far as this discussion is concerned.
> It is proven that a computer program cannot be
> written to do this task
The simplicity of the ruleset for early versions of VB allowed for the proliferation of VB decompliers in the early 90's. That must tell you something.
The linked "book" itself (Score:2, Insightful)
Re:Why not? (Score:3, Insightful)
No. Assuming we're talking about software disassemblers here, not every program can be reliably disassembled. Disassemblers work by mainly following the execution paths of already disassembled code, so that it knows exactly where a subroutine begins. In many instruction sets, instructions have variable length, and not starting your decoding on the right byte will be a big mistake that cascades on to the next instructions. Now, knowing this, all we have to do is to change the execution path without the disassembler knowing. A function pointer (address loaded at run-time) already presents a serious problem to a disassembler, but simply asking the user to enter the instruction address to jump to will completely defeat the automatic disassembler. There's no way for the disassembler to know what the user will enter, and hence where the program will go to next.
Humans will still be able to disassemble your program, of course. However, you still won't get the original assembly source back. Assembly languages usually support macros and pseudo-instructions that improve readability, but have no correspondence in assembled form.
Re:Decompilation = halting problem (Score:1, Insightful)
Re:Why (Score:4, Insightful)
BTW: Nice job getting all those responses with two lines...
Re:You can't (Score:5, Insightful)
So what? Doing reasonable interpolations in context is what brains are for. Example: IIRC, when the Morris Worm appeared in 1989, Gene Spafford examined the binary and reverse-engineered the C code, sprinkling it with meaningful comments and good variable and function names. When the original source became available, his turned out to be cleaner program than the original. That is, he not only recreated the original in every way that counts, he overshot and did better than the original
Define decompile... (Score:2, Insightful)
The symbolic names make up the bulk of the lost information, but often times programmers will organize a sequence of code in a certain way to make it easier to understand. The compiler will often rearrange that code in a manner that makes it easier for the computer to understand. Compilers will do screwy things like increment a variable on the stack, while holding the original in a register for later usage. Where the original C code might have had the variable increment at the end like this:
while (x 10)
{
x++;
}
The way the compiler optimizes register usage may cause the assembly to actually increment x just after doing the conditional, then hold the non-incremented value in a register for use down below. The decompiled asm might look like this:
while (x 10)
{
int temp = x;
x++;
}
While this may seem like a trivial difference in the C code, it can often distort the intent of the algorithm. When a C programmer sees a construct like the latter, they naturally assume that the temp variable was used because more natural constructs would not. The C programmer then wastes time mulling it over only to discover that it was just dumb.
I am currently on a project where I am maintaining some pretty poorly written code. I can't tell you how much time I waste looking at a particularly ugly algorithm trying to figure out why they are doing all these screwy things, only to discover they were just idiots.
My point is, that the compiler and optimizer are going to mangle the logical order of the code in such a manner that it will be far more difficult to read.
Like I said at the beginning, simple translation of assembly to C is easy, getting back the meaning that gives the endeavor any value at all is much more difficult.
Re:You can't (Score:2, Insightful)
With regards the original article - well, that was a bunch of obvious guff really; what you'd expect from high-school geeks of the type I was, some number of years ago. Of note, is that it claimed to decompile C++, when actually it talked only of rather trivial C constructs, something that is a well understood practice already.
Some relatively recent classic decompilation work was done by Cristina Cifuentes [uq.edu.au] who put together a C decompiler that worked to a significant degree for common DOS-based compilers of the time. Effectively the job of "decompilation" can be thought of as "compilation" - instead of compiling C into ASM, you think of compiling ASM into C. Not as daft as it sounds, honest. You can download "dcc" from the above site to investigate further.
Boomerang [sourceforge.net] is a sourceforge project attempting to create a decompiler. Worth a look, as well.
It's worth noting, that there are a number of ways to "cheat". For example, it's often trivial to discover what compiler was used to generate a given object code, and there are usually masses of common library-type code that gives you a leg up. Add to that, the fact that a piece of code was generated by a compiler, and the problem of discovering what a given piece of object code does is drastically simplified - compilers add huge amounts of structure and predictability to the generated object code that can be absent in free-form handwritten assembler (and few people do that anymore!), and much can be made of this.
On the code/data issue mentioned by others in this thread - although separating code/data in general from mixed binaries can be considered hard, in reality it's often quite feasible and even simple. After all, the CPU manages to work it out. Again, the fact that there are so many short-cuts you can take really helps.
Of course, a quick cruise around the cracking community will turn up all sorts of ways and means to shortcut this sort of problem...
Here are the results of a quick googling [google.com]: