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)
  • Define "Perfect" in the context of "Perfect Decompiler". What do you think of as "perfection"?
    – S.Lott
    Commented Mar 4, 2011 at 14:38
  • Perfection as in: Get the complete set of source files.
    – Simon
    Commented Mar 4, 2011 at 14:39
  • 6
    @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
    Commented Mar 4, 2011 at 14:52
  • 3
    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. Commented Mar 4, 2011 at 15:29
  • 1
    In some cases the decompiler output makes more sense than the original code. Any of the obfuscated C code contests for example.
    – Zan Lynx
    Commented Mar 4, 2011 at 21:33

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.

[perfect] 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)

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?


What are some of the best practices used to prevent reverse engineering of software?

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

Is it a major concern?

Only to lawyers.

Also is obfuscation/file permissions the only way to prevent unauthorized hacks on scripts?

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.

  • 8
    @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
    Commented Mar 4, 2011 at 14:50
  • 5
    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
    Commented Mar 4, 2011 at 14:55
  • 3
    @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. Commented Mar 4, 2011 at 14:58
  • 2
    @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
    Commented Mar 4, 2011 at 16:04
  • 4
    @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. Commented Mar 4, 2011 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.

  • 5
    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. Commented Mar 4, 2011 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
    Commented Mar 4, 2011 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.).

  • 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
    Commented Mar 4, 2011 at 15:23
  • 5
    @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. Commented Mar 4, 2011 at 15:46
  • 2
    Nothing can be completely secured. Commented Mar 4, 2011 at 15:50
  • 1
    @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
    Commented Mar 4, 2011 at 18:49
  • 1
    Any program that decrypyts in order to run MUST be definition have the decrypter built into the image, and not encrypted. Effectively its a little stub that treats the rest of the image as data, decrypts that, loads the result into RAM and then jumps into it. NOW, because the decrypter HAS to be there, it does not take a huge lot of time with a binary instruction level debugger to figure out how all that works, and write an extractor to perform the same operations, decrypting to a disk file. Whether anyone would want to go to this effort is another matter. Commented Mar 7, 2011 at 22:24

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).

  • +1: this is what I was going to say. Web applications are the hardest ones to reverse engineer. Commented Mar 4, 2011 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
    Commented Mar 4, 2011 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. Commented Mar 7, 2011 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.

  • 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
    Commented Mar 4, 2011 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.

  • 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. Commented Mar 8, 2011 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. Commented Mar 8, 2011 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! Commented Mar 8, 2011 at 9:21

What are some of the best practices used to prevent reverse engineering of software? Is it a major concern?

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.


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.


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.


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.


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.


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.


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. :)

  • 4
    "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
    Commented Mar 4, 2011 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.
    – Chinmoy
    Commented Mar 5, 2011 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. Commented Mar 8, 2011 at 6:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.