

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

Lately I have been thinking of application security and binaries and decompilers. (FYI- Decompilers is just an anti-complier, the purpose is to get the source back from the binary)

  • Is there such thing as "Perfect Decompiler"? or are binaries safe from reverse engineering? (For clarity sake, by "Perfect" I mean the original source files with all the variable names/macros/functions/classes/if possible comments in the respective headers and source files used to get the binary)
  • What are some of the best practices used to prevent reverse engineering of software? Is it a major concern?
  • Also is obfuscation/file permissions the only way to prevent unauthorized hacks on scripts? (call me a script-junky if you should)
share|improve this question
Define "Perfect" in the context of "Perfect Decompiler". What do you think of as "perfection"? – S.Lott Mar 4 '11 at 14:38
Perfection as in: Get the complete set of source files. – Simon Mar 4 '11 at 14:39
I'm not 100% sure but I think that certain compiler options (inlining, maybe?) could make it impossible to decompile to the Exact original source code. – FrustratedWithFormsDesigner Mar 4 '11 at 14:40
@Simon: "Get the complete set of source files" is just as vague as "perfect". Please update the question to list what exact language features must be present to be "perfect". Comments? Spacing? Variable Names? Function Names? Macros and Preprocessor Content? What counts as "perfect"? Please be specific. – S.Lott Mar 4 '11 at 14:52
The original source is not needed to reverse engineer a binary. One only needs to know the machine architecture/instruction set and run-time organization of the compiler used to compile the code. Granted, it is tedious time consuming work, but I built several system-level software products for Windows back in the nineties that required reverse engineering to implement. – bit-twiddler Mar 4 '11 at 15:29

13 Answers 13

Is there such thing as "Perfect Decompiler"?

The original source is -- in some languages -- unrecoverable. A version of the source can be constructed, but it will lack meaningful names for variables. It will also lack comments and may have inline code expansions that are confusingly repetitive.

Note that optimizing compilers can make the recovered source pretty obscure-looking.

In other languages, there is enough debugging information that a reasonably readable version of the source can be recovered.


Never. Macros from the preprocessor are not part of the source, and are always lost forever.

"if possible comments" doesn't make much sense. I'll assume you mean that you want the comments. They're generally gone forever, also.

You can, however, get binary back from stuff that's missing macros and comments. So your definition of "perfect" is inconsistent.

binaries safe from reverse engineering?



Offer new versions so quickly that there's no value in reverse engineering the previous version.

Is it a major concern?

Only to lawyers.


What's an "unauthorized hack"? Indeed, what's to you mean by a "hack" on a script?

If you want to mess with a script, you just mess with it. Unless, of course, it's on a web server, and you're not. Then you don't have access to the script, just the web page presented by the script.

share|improve this answer
@Simon: Optimized C++ source is almost unrecoverable. All comments are lost. All use of the precompiler is completely unrecoverable. Turning off all debugging and profiling options when compiling and turning on maximum optimization really makes a hash of things. – S.Lott Mar 4 '11 at 14:50
Optimizing C/C++ compilers can make it essentially impossible to recover the original source code. However, you can always use a debugger to view the actual machine instructions generated by the compiler, so you may be able to ascertain what the code is doing. You just won't ever be able to recover the higher-level source code that has all the function names, classes, etc. – Channel72 Mar 4 '11 at 14:55
@Simon You can't really make it unreadable, it just won't look like your source code. If you can read assembly you're good to go with most decompilation tools. If you're a little smarter, you can write a decompiler of your own. This is not a problem that can be solved without a serious encryption scheme. – Steve Jackson Mar 4 '11 at 14:58
@Paul Nathan: Trade secrets are only important to lawyers. Perhaps they're important to someone else, but many of us get paid irrespective of the level of secrecy surrounding the algorithm, so we have little stake in the intellectual property management. – S.Lott Mar 4 '11 at 16:04
@Steve Jackson: This is not even a problem that can be solved with a serious encryption scheme, because somewhere that binary has to be decrypted into ordinary machine code for the CPU to be able to read it. – Mason Wheeler Mar 4 '11 at 17:10

Decompilers are definitely a Fact - Reflector is an excellent example.

Nothing I know of will actually stop a person from decompiling your code if they're smart enough and determined enough. That's what lawyers and software patents are for.

Obfuscation is a decent way to stop most people though. For example, I personally have no interest in hacking, however if I am trying to fix something and it can easily be decompiled using Reflector, I'll do it.

share|improve this answer
Reflector works well because of the nature of .NET (the same can be said of Java): The executable is in an intermediate language, not a native binary. Decompiling from a native binary resulting from compiling, say, a C program is not nearly as straightforward. The result won't be as "pretty" and not nearly as close to the original code. – MetalMikester Mar 4 '11 at 15:09
ILSpy (a project set up after Redgate announced that they will be charging for Reflector) does a really good job of intepreting obfuscated code. – James Love Mar 4 '11 at 18:50

The "Rule of thumb is" if they physically have it.. It's as good as hacked.

Even if it is encrypted, if the key is stored somewhere in the app .. that data can be got.

The ONLY way to secure anything is to keep it on your servers and have a gate keeper (IE a secure web service.).

share|improve this answer
The good thing about encryption ( hash functions anyone?) is that if it is strong enough it would require a lot of hardware, money and effort,not saying it is impossible though. But even that has flaws. – Simon Mar 4 '11 at 15:23
@Simon: but it would have to be decrypted to run, wouldn't it? Careful analysis of the running program could allow someone to reconstruct it. – FrustratedWithFormsDesigner Mar 4 '11 at 15:46
Nothing can be completely secured. – Matthew Read Mar 4 '11 at 15:50
decrypt-run-encrypt looks like an option but is it possible with current technology.I am not so sure. – Simon Mar 4 '11 at 16:29
@Simon the program would need to remain decrypted in memory for it to run - if you encrypt the .data portion of the image in memory you effectively corrupt the machine code that will be processed. – James Love Mar 4 '11 at 18:49

The hardest binary to decompile is the binary you don't have. With more and more software moving to an online subscription model, reverse engineering the client has some value but won't give away everything. Sure you could try hitting the server service over and over again with lots of inputs to try to determine the code from the output received but that's going to be so error prone as to be almost worthless in all but the simplest cases.

Also decompiling is a two way street. If someone decompiles your software and tries to sell or give away a modified version, you can decompile their code and compare. A huge amount of overlap is going to betray their actions. If you have a rather smart algorithm that you don't want anyone to see or something in the program that is considered a trade secret, making that a service call to a remote server is going to be the best protection (though obviously not workable in all cases).

share|improve this answer
+1: this is what I was going to say. Web applications are the hardest ones to reverse engineer. – Scott Whitlock Mar 4 '11 at 15:12
@Scott: I recall reading an article about applying machine learning algorithms to unknown network traffic in order to build a system that can run an unknown protocol. Neat stuff. – Zan Lynx Mar 4 '11 at 21:37
And this is why most licenses have clauses prohibiting decompilation. If you were to do this in order to try and prove copying you may find yourself in violation of license agreements. And in the eyes of the law, two wrongs don't make a right. – quickly_now Mar 7 '11 at 22:27

I was never very good at it, but when I tried it, even I was able to do amazingly (to someone who's never tried it, that is) complicated things with a simple monitor/debugger/disassembler a few years ago.

So I don't find it hard to imagine how every single protection scheme devised so far has been cracked. (Usually in less time than it took to develop.)

The power of human stubbornness and perseverance is often underestimated.

share|improve this answer
But they are a lot easier to steal the UI. If they're simple enough, figuring out the logic and data structure isn't too hard. – JeffO Mar 4 '11 at 16:55

If you want to really get a grasp of the possibility of decompilation of a C/C++/Delphi binary, look up Symantec's technical white paper on Stuxnet.

Pretty much any language that doesn't compile directly to native code seems to be relatively easy to decompile.

If this is a problem, try to figure out how to put the special sauce on a web server. One of the other mechanisms used is a physical dongle that holds encryption keys or portions of code. YMMV, depending on your application.

share|improve this answer
I looked at that. I could not find where they claim Stuxnet code was written in C / C++ or Delphi. It might have been. Enough clever people can look at an executable image and figure out what it does from the assembly code, you don't have to decompile in the sense of turning it back into sensible source code. – quickly_now Mar 8 '11 at 6:16
@quickly: My point was to point out the possibilities. Just because they wrote it in Assembly/Ada/Fortran/61131/C/whatever that dumped out to a native binary - you can reverse engineer the logic from the binary fairly well. – Paul Nathan Mar 8 '11 at 6:41
Oh, OK, sure. Agreed 100%. The amount of (human) effort required is generally greater for a compile-to-native-machine, but you are quite right it can be done. (And I've done it a few times over the decades, too.) By the way... that Symantec paper is a very interesting read. Thanks for that... made a nice diversion to the day! – quickly_now Mar 8 '11 at 9:21


If all you offer is code then it is a major concern, as you cannot do much outside lawsuits. So don't just offer code. Offer support, training and other services that compliment the code. Make sure your code is such that you can adapt to the ever-changing marketplace. The code can and should be the "core" of a software business but I really don't think it can exist on its own.

share|improve this answer

It really depends on the language, you can pack your binaries to provide an extra layer of security, but in most cases decompilation does not provide anything useful, a lot of decompilers can extract string references which if you have sensistive information in the code as strings can be bad.

Other decompilers can extract information such as form definitions etc.

share|improve this answer

Don't bother even wasting thought or effort on this. Decompiler protection is basically equivalent to copy protection, and it's trying to solve a problem that's known to be impossible.

In order for the CPU to execute it, your program has to be some in machine-readable format, and there's no way around that. Even if you encrypt it seven ways from Sunday, it has to be decrypted again before it can be run, and at that point a debugger can look into the memory and read the code. The only way to keep someone from decompiling your program is to keep it off of their system entirely, for example using a web service, as a few other people have mentioned.

share|improve this answer

I don't think reverse engineering is a concern if you mean using a decompiler and magically making your source code to appear with little effort. Any application simple enough to get perfectly by a compiler probably could have been written by someone else anyway (And probably has.).

There are a lot of enterprise applications that go for $100K+ that don't let you download their program from their website. They have a niche market and few if any of their potential business customers are going to try to steal the source code if they get a demo installed.

You really have to make something worth buying and convince people you will be around to support and improve it.

share|improve this answer

A decompiler is not an anti compiler, it will at best offer what the C or C++ code would look like (it's an example, since we are talking about compiled languages).

Try to look at what assembly code actually looks like to see what the compiler translate C/C++ in.

Obfuscation is not related to decompiling, you only obfuscate interpreted code like javascript, when someone will be able to read the code you actually wrote, not the code you compiled.

However, I guess there are some ways you can make some code harder to decompile, maybe for example, crypt internal offset addresses ? That would be an interesting subject, if of course execution time isn't important.

On the other hand, I guess pure C might be easier to decompile than C++. Imagine decompiling templates: if it's already a nightmare to code, I can't imagine how it can be decompiled.

share|improve this answer

Decompiling C# code is ridiculously easy.

I don't think anyone of our competitors would decompile our code to use it for themselves but that's the reason why we use obfuscation. Should be enough to stop 99% of all hackers and it keeps our management happy.

The level of your security needed really depends on your application. Will it be used by millions of high tech users? For most people simple obfuscation will suffice.

share|improve this answer

If you are using Java or C#, your code is extremely prone to decompilation. This is for the same reason that there are so many viruses for Windows. So, obfuscators work to some extent, but mostly, it saves against free decompilers. Those who want to reverse engineer your software, will do it anyway.

Commit logs reveal details too. So, don't waste your time thinking about this. If such was possible, MS would have bought that technology first. :)

share|improve this answer
"This is for the same reason that there are so many viruses for Windows." -- Totally unrelated. There were viruses for Windows long before .NET was invented. Viruses has nothing to do with decompilation. There are (were?) small and clever assembly language programs. – PhiLho Mar 4 '11 at 17:09
What I meant there was about familiarity. Linux is vulnerable too, but as more people around the world are using Windows PCs, viruses are more specific and found in Windows. Likewise, .NET and Java are popular and so, there are better decompilers for them as compared to decompilers for other languages. – r3st0r3 Mar 5 '11 at 4:55
Actually thats not correct either. The decompilers for .net are just easier to do because its an intermediate form, not a machine pure binary form. Simpler problem to solve. – quickly_now Mar 8 '11 at 6:18

Your Answer


