Is it important to obfuscate C++ application code?

Question

In the Java world, sometimes it seems to be a problem, but what about C++? Are there different solutions?

I was thinking about the fact that someone can replace the C++ library of a specific OS with a different version of the same library, but full of debug symbols to understand what my code does. Is it a good thing to use standard or popular libraries?

This can also happen with some dll library under Windows replaced with the "debug version" of that library. Is it better to prefer static compilation? In commercial applications, I see that for the core of their app they compile everything statically and for the most part, the DLLs (dynamic libraries in general) are used to offer some third party technologies like anti-piracy solutions (I see this in many games), GUI library (like Qt), OS libraries, etc.

Is static compilation the equivalent to obfuscation in the Java world? In better terms, is it the best and most affordable solution to protect your code?

Answer 1

Don't Waste Your Time on Losing Battles

As noted in many other similar answers for C++ and other languages, this is mostly useless.

Further Reading

Selected reads on the topic (not all are C++ specific, but the general principles apply):

StackExchange Answers

• The Case for Code Obfuscation?
• What Are the Advantages of Obfuscating Release Code?
• Decompilers - Myths or Facts?
• Can JS Code be Encrypted, Making it Hard for Someone to Copy?
• Obfuscate C/C++ Code? ^{(for tools for C++ obfuscation, if you really must...)}

Papers

• Code (De)Obfuscation (Madou, Anckaert, De Bosschere)
• On the Effectiveness of Source Code Transformations for Binary Obfuscation (Madou & al.)
• The Effectiveness of Source Code Obfuscation: an Experimental Assessment (Ceccato & al., 2009) [PDF]
• The Quality of Obfuscation and Obfuscation Techniques (Witkowska, 2006)

Famous Quotes on Obfuscation:

Then finally, there is that question of code privacy. This is a lost cause. There is no transformation that will keep a determined hacker from understanding your program. This turns out to be true for all programs in all languages, it is just more obviously true with JavaScript because it is delivered in source form. The privacy benefit provided by obfuscation is an illusion. If you don’t want people to see your programs, unplug your server. - Douglas Crockford

---

Never?

_{I'm not saying you should never obfuscate and that there aren't any good reasons for it, but I seriously question the need for it in most cases, and its cost-effectiveness.}

_{Furthermore, there are situations where obfuscation is a de-facto requirement. For instance, if you write viruses, obviously obfuscation (and a dynamic one, preferrably) is as good a thing for your program's survival as it's ability to replicate. However, this hardly constitutes a "common" case...}

Answer 2

No, this is not worth the effort, and I think it's completely unnecessary. The functions you call can probably be guessed by the functionality you provide.

The reason obfuscators exist for Java is because the mapping between Java byte code and Java source code is fairly well defined, and the names of all functions and member variables are stored in the byte code (regardless of whether they are public, private, or protected) so a Java byte code interpreter can present some generic Java which shows the structure of the original source fairly well for unobfuscated source.

C++ compiles directly to machine language. It can be disassembled, but assembly language is fairly tedious to deal with. Decompilation is much tricker because of all the changes optimizers make to the code during compilation.

Answer 3

Thinking about this, there are several different types of obfuscation. Let's start with obfuscation of source code, which is a complete waste of time; it's hard enough to understand without that! So let's instead focus on obfuscation of the delivery package, of how the code gets delivered to the user.

Minor obfuscation

Minor obfuscation exists to prevent the casual user from poking their fingers in and breaking things easily. It doesn't keep out the determined hacker, but it does have value in helping to ensure that the things you are asked to support are what you've actually delivered. The level of protection required for this sort of thing is really quite low; the delivery package merely has to not look readable and editable (without specialist tools) and that's quite good enough.

Javascript minification is an example of this, though it's not marketed as such. Nobody in their right mind would want to read and edit a minified JS file, even if it is quite technically possible to do so if you're determined/persistent enough.

Similarly with delivering Java applications. Merely packaging the code into an executable JAR will stop the majority of foolishness, even though it's got all the force of a polite “Please Keep Off The Grass” sign in a city park.

Even when delivering C++ code, stripping the unnecessary symbols from the executable will be enough to qualify as minor obfuscation. The key is that it is awkward to read the result as a user, but not a problem to execute it as a computer.

Major obfuscation

Major obfuscation is keeping the determined and knowledgeable user out. It's also a total losing game; if a computer can execute it, a person can pick it apart and work out what it does. The closest you could get would be to make the program decrypt itself continually, transforming what it does at one time into a completely different thing that it does at another time. Creating such thing would be rather difficult and still wouldn't keep a really good hacker out (though they would be really quite cross with you by the end of it at the amount of effort required to decrypt all that self-modifying code).

It's much better to think in terms of other solutions. For example, you could keep the “crown jewels” of the code on servers that you control and only permit service calls to it, making the client an essentially free giveaway that is a front-end to the valuable bits. Or you could go the more contract/legal route, and only hand over executables to organisations that formally agree to not poke around inside your code or compensate you if they do so (so that'd be some sort of NDA). The aim would be to create a strong incentive for the hacker to not hack, and for the users to keep the code away from any hackers not bound by the agreement.

But you must not assume that your code can never be cracked. With virtualisation, any program state of an execution can be examined and tracked, and anything that tries to defeat that (e.g., clock tracking to an external time source) will be much more likely to cause problems for legitimate users than hackers. (See the history of DRM for how even very determined publishers of information can't keep their systems secure once the code is in the hands of their opponents.) It's much better to focus on actually making legit users happy. The losses from the occasional crack will be as nothing compared to the extra money brought in through satisfying customers properly.

Answer 4

It is important not to obfuscate code - neither the compiled, binary code, nor the source code.

You should release your software along with the source code, and allow users to scrutinize it, make suggestions, contribute to your codebase, or even fork it and create their own versions.

If the economic model you are working on is based on non-access to the code, or restricting the copying or use of the code, then it is a usurious artifice, likely resulting in other people having to duplicate your efforts, as well as in less robust code. Disseminating closed-source code hinders the advancement of software in general.

---

The above may not be universally recognized fact, but I believe it to be true. For further reading, have a look at the GNU project's philosophical section.