Posts Tagged code obfuscation

Don’t bother obfuscating code.

Code obfuscation is rather pointless. To understand that, let’s first examine the reasons why you want to obfuscate your code in the first place:

  • Security by obscurity.
  • “To protect you intellectual property” as people normally put it.

Both reasons are understandable, but if either of both is what you’re trying to achieve, then code obfuscation will not really cut it except in a few selected cases.

From an evil villains perspective, code obfuscation doesn’t present the hindrance that you would like it to be, for a number of reasons:

  • Your actual source code is rarely needed to try crack your software or to “steal” it. In most cases, your software can be decompiled or disassembled into some sort of source code. It’s not going to be pretty, but it’s going to be good enough to run it in a debugger and find suitable entry points to hook into for whatever purpose. You’re “safe”┬áif your architecture is just a big ball of mud, but in that case you don’t have much worth protecting anyway.
  • Security by obscurity usually ends up shooting yourself in the foot. You have no way to actually guarantee security. You can only hope that no-one finds vulnerabilities, or that you are lucky enough to become aware of attackers and close the loopholes they were using. Most of the time, you will do much better using open, well-established and field-tested security mechanisms and guidelines. These are constantly driven forward by a whole number of very smart people. This doesn’t (necessarily) apply, if you work in defense or banking and have major funding to develop/buy reliable proprietary security mechanisms. But you very probably don’t.
  • When you look at software as “intellectual property”, then protecting your source code won’t protect the software. Designing great software with a good user experience is a very hard, resource intense, time consuming process, that involves a lot of learning about your actual problem domain. The real value of your software lies in that design. The effective value of the product that this software constitutes lies in how well it is marketed. You have gone through this whole process of iterating a great design and actually generating/defining the demand for a product such as yours. Reverse-engineering your implementation is far easier. Selling a product to meet an existing demand is far easier. You just add some crappy extra features, cut the price in half and people are going to fall for it.

The kind of paranoia that leads you to wanting obfuscation is bad for your creativity, because it pushes you in a defensive mental stance. This will harm you, because frankly, you get the best ideas when you feel free, safe, confident, positive and when you are undistracted. And also implementing obfuscation consumes a lot of time and energy, often yields bigger/slower results and might even impose restrictions (some obfuscation methods do not work with reflection). If you really want to stay ahead of your competition, you are going to need that creativity, that positiveness, that time and that energy, to focus on improving your design and to sell your product, which works a lot better with a smile in your face.

So to the contrary: you should consider open-sourcing and GPL-ing parts of your software. If those parts are really worth using, you will get peer reviews for free and marketing for free and an angry mob of free software lobbyists up your sleeve, if your competition decides to use your code but not to publish their enhancements. And also materials, training and support might in fact present a new revenue stream.


, ,

Leave a comment