Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In the Java world, it seems to sometimes 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 tt 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?

share|improve this question
Remember, whatever you do, someone with too much time will be able to deobfuscate/decompile it –  Zavior Jul 1 '12 at 15:54
Many compilers come with a /O obfuscation switch. Some even have multiple levels of obfuscation, up to /O3 ;) –  MSalters Jul 1 '12 at 22:24
@MSalters No, g++ has -O3 ;) –  BЈовић Aug 3 '12 at 10:34

3 Answers 3

up vote 20 down vote accepted

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


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


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

share|improve this answer
We once used a hardware dongle where there was a licensing requirement to obsfurcate all the dongle function calls - and they supplied a tool to do it. Always made me a little suspicious about the quality of their 'protection' ! –  Martin Beckett Jul 2 '12 at 4:06
@MartinBeckett: a tad weird indeed. –  haylem Jul 2 '12 at 7:23

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.

share|improve this answer

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.

share|improve this answer

protected by gnat Sep 4 at 15:28

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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