This is a very well written article. Good work, and it got me thinking from new angles! I politely disagree on a couple of premises, however. First, it is not best to presume that obfuscation techniques indicate bad behavior. In the most common use case, the software vendor is legitimate, the consumer trusts the software vendor, and the software vendor is aware that its customers try to get around licensing. Perhaps code signing would be a way to increase the consumer's trust level of obfuscated code, because there is a chance of installing software that poses as a legitimate vendor.

I am currently working on a project that involves digitally signing messages. To get at a client certificate's private key, I need to actually hard code a password. It's not reasonable to compile a password as cleartext in my binaries. I instead chose to use a weak, code-based obfuscation technique to make it more difficult to sign "fake" messages. It's not in the consumer's best interest for anyone to spoof messages going to my server, as it may pollute their own data.

Stepping back from obfuscation of executables, the next logical argument is to say that those who encrypt are maybe up to something. Amazon.com isn't necessarily hiding something from us by using SSL -- they're protecting us from fraud. Obfuscation can be just as innocuous as any use case for cryptography.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/498/35436#35436