I've always firmly held the belief that obfuscation is essentially useless. Obfuscated code is not impossible to read, only harder to read. I had the belief that a sufficiently skilled attacker would be able to bring the obfuscated code back into a more readable state.

However, OWASP recommends the usage of obfuscation for mobile clients, which makes me wonder if there is more credibility to obfuscation than I had given to it.

Hence my question: Does obfuscation give any measurable security benefit? Specifically, a benefit that outweighs the added cost, complexity and reduced performance.

Note: When I say "obfuscation", I am talking about deliberate steps taken to prevent reverse engineering. Compiler optimizations, even though they make the assembly less easy to read, are done for the purpose of improving performance, not to prevent reverse engineering.

  • 31
    In my experience, there's not a whole lot of measurement and empirical evidence gathering in the security world. It's mostly a lot of "well it SHOULD work like this", anecdotal experiences, and extrapolation. Personally I think code obfuscation is more about an attempt to protect business interests and code secrets than it is security. Commented Oct 9, 2019 at 14:52
  • 2
    One small benefit of obfuscation is information destruction. Things like spoken language, coding habits, etc. The process (ultimately code) can be re-understood, but identifiers are lost. Although, I can't think of a legitimate reason for this. Additionally, some obfuscation (e.g. Java back in the day) can introduce features in the output that cannot be easily rebuilt with the current technology/decompilers. This made Java excruciatingly cumbersome to decompile. Thus, deterring even experienced users from inferring the code. That's an obfuscation-is-better-than-its-competitors situation. Commented Oct 9, 2019 at 20:45
  • 2
    I find it fascinating that the possibility to deobfuscate depends heavily on the code style. Like how important the variable names are. The code could be written in a relatively low level language, and use very high level patterns. Like object oriented classes roughly on the level of java, all implemented partially as much as needed. Also, the use of design patterns, spanning even longer regions of code. All this structure is mostly expressed in terms of variable names. Two values of the same type could be of different classes, expressed in the name. Different classes can even be the same. Commented Oct 10, 2019 at 11:20
  • 6
    "OWASP recommends the usage of obfuscation for mobile clients" - might just be because, for instance minimizing JavaScript obfuscates it, but the real object is just to make it smaller, transferring less information and speeding up internet traffic & web page load times
    – Mawg
    Commented Oct 10, 2019 at 12:48
  • 2
    @Mawg Yet OWASP does not specifically recommend obfuscating JavaScript
    – user163495
    Commented Oct 10, 2019 at 12:49

5 Answers 5


There are two benefits to code obfuscation:

  1. It weeds out the shallow end of the attacker pool. Script kiddies who struggle to make sense of your code will go somewhere else.
  2. It increases effort required of skilled attackers. No matter how skilled they are, obfuscation is cheaper than de-obfuscation, and the result is generally less comprehensible than the original (variable names will remain generic, for example, where the originals were descriptive).

@SteveSether is doubly right in his comment - actual measurements will be almost impossible to find, and many code bases are obfuscated for proprietary reasons* rather than security reasons.

But for both security and proprietary reasons, code obfuscation's value is tied to its asymmetric quality - it's cheaper to obfuscate than it is to de-obfuscate.

*By "proprietary reasons" I mean "the desire to keep one's code and algorithms more private, or harder to reproduce, in the interest of maintaining competitive advantage in the market." Companies and individuals are both prone to this tendency.

  • For as long as I have seen obfuscated code (mostly in viruses and rootkits) on potentially everything able to receive from Internet (mail, ftp, web, dns etc., in requests, logs, file transfers), the human time involved in deobfuscating the code well enough to find essential information such as server address, admin id and the hashed password for a botnet, or sensitive strings or library calls for viruses is mostly counted in minutes.

    So in terms of protection against strange code, this is not a big job (if not trivial).

  • On the other hand, building editable sources from this kind of code could take a lot of time (to be counted in days, weeks or even more if the code is big. Anyway, the more deobfuscation processes progress, the more they are efficient and quick, as when light is coming).

  • About OWASP's recommendation, I agree: obfuscation implies human resources, so they represent some cost, making piracy less attractive.

  • About measurablility of security benefit... sorry, but I can't! Depending on who could be interested by hacking your code, which part of your code and why.

Overall, my own recommendation is: using obfuscation is not essentially a bad idea, but it's not to be considered as a big security improvement!

To be more clear: don't ever consider obfuscating code to hide secret keys/functions so that it would be more secure than if they where not obfuscated!

  • 4
    This might be true for malware, but for entire applications or games, the code becomes harder to reverse engineer. Certainly not a matter of minutes.
    – Hugo
    Commented Oct 10, 2019 at 9:08
  • 1
    @HugoZink I think he means the case that values of interest can be found unobfuscated. An IP address must be stored as value, for example. Basically gzip -d obfuscatedfile | strings | less Commented Oct 10, 2019 at 11:28
  • 3
    @VolkerSiegel I disagree. It can be generated algorithmically, or it can be decrypted from an encrypted string, forcing the attacker to work out the mechanisms of the decryption algorithm and where the key is stored, etc. Commented Oct 10, 2019 at 12:22
  • 10
    @JonBentley You can have the most wonderfully obfuscated/encrypted/generated IP address in the world, and it might take a team of 100 engineers 30 years to decipher it, yet eventually software has to supply it unencrypted to a system call like connect(). And those system calls are easy to log with strace and catch with gdb, at least on Linux. Commented Oct 11, 2019 at 5:52
  • 2
    @trognanders Simple way of running obfuscated code while tracing operation with strace, gdb, tcpdump, will procure a lot of light. As almost all strings, address, ports, etc will become readable. Commented Oct 11, 2019 at 9:52

Another point in obfuscation is that makes it harder for attackers to deny their reverse-engineering activity.

If you have a server which lets in any client that sends them a "Hello foobar" string, and someone exploits it, it may be hard to prove in court that the offender really had the intention to attack, and not just misunderstood your license agreement and assumed this was allowed. If your client authenticates with the server using an obfuscated secret key (contained within the client itself), you gain little in terms of security, but someone exploiting your server will have a hard time to prove that they got that key by chance, and not via an intentional reverse engineering effort.


Obfuscation increases the time cost of reverse engineering a program significantly. While perhaps it is quick to extract some small secrets from an obfuscated program, the work to make a non-obfuscated version of that program rivals simply rewriting it. Extracting a novel algorithm is possible but non-trivial.

Essentially obfuscated code can be reasoned about, but not reused.

Code obfuscation is the topic of considerable CS research... your axiom that obfuscation is essentially worthless would be contentious.

I would suggest the book Surreptitious Software: Obfuscation, Watermarking, and Tamperproofing for Software Protection. by Christian Collberg and Nagra Jasvir.

  • Sometimes even working with poorly written source code is bad enough that you are better off rewriting it. And sometimes understanding someone's algorithm in original source code can be non-trivial. Making it 10 or 100 times worse (or more)… OP might as well leave their home and vehicle doors unlocked and hanging wide open and their valuables in plain sight, as locks don't slow people down as much as code obfuscation.
    – Aaron
    Commented Oct 11, 2019 at 15:52

It increases the likelihood that, when the exploitable bugs in your software are found and exploited, it will be by highly motivated and likely well-funded attackers who specifically want to target you (or whoever is using your software) rather than skript kiddies, ransomware, etc.

For the most part, I would think you'd rather the bugs in your software be found by whitehat or grayhat researchers, with skript kiddies and ransomware as a second choice, and state-level attackers and such as the worst-case. But you need to make that call.

You must log in to answer this question.