My OS X Programming Blog

Today I read the paper Dynamic Self-Checking Techniques for Improved Tamper Resistance by Horne, Matheson, Sheehan, and Tarjan. The basic idea in it is quite simple: embed “testers” in the code to detect tampering. Each tester is responsible for the integrity of a region of the application code and a number of other testers. This mutual protection ensures that many testers have to be disabled before an attack can succeed. The details in the paper deal with placement of testers in the code, selection and assignment of coverage intervals, design of tester functions, and integration of the technique with watermarking.

Quite a reasonable idea. Applying it, however, requires first building a few rather complex tools (like modifying a compiler, for instance!). Perhaps certain elements can be taken from it to form a simpler scheme more suitable for a small shareware implementation. For shareware licensing, we’re often less interested in protecting the entire application code. Instead our goal is to protect the code that enables and provides additional functions to registered users. This code can be checked by a number of mutually protected testers placed at random locations in the application code.

Code Obfuscation

Thursday January 15, 2004

Read a paper today by Linn and Debray entitled Obfuscation of Executable code to Improve Resistance to Static Disassembly. It proposes transformation of programs’ machine code to make it hard for disassemblers to work correctly. This technique isn’t useful at all for implementing shareware licensing code for two reasons. A cracker only needs to disassemble small parts of your program to by-pass the licensing code checking. The “interesting” parts of the program to be examined can be deduced from the dynamic behavior of the program and execution traces will then be available to the disassembler. Something the paper doesn’t address.

Read another paper by Collberg, Thomborson, and Low called Breaking Abstractions and Unstructuring Data Structures. It reads like the opposite of “A Guide to Writing Clear and Readable Code”. Techniques discussed include opaque predicates (predicates that always evaluate to known values), split variables (representing single variables using sets of variables), convert static data to procedural data (so that the former is no longer in plain sight), table interpretation (using an internal interpreter to perform computations), etc. Each of these introduces some obfuscation to the code. The question one must ask is of course how much of it is enough.

I’ll read and report on the one on tamper proofing tomorrow. It’s probably of higher quality because Robert E. Tarjan is one of the authors. But that could also mean the paper won’t be too practical. We’ll see.

Watermarking, Tamper-Proofing, and Obfuscation

Wednesday January 14, 2004

Software protection is really quite an interesting topic. To avoid wasting time on snake-oil, ready-made solutions which don’t reveal how they work anyway, I’ve looked more towards academic publications. Today I’ve found and read a paper in IEEE Trans. on Software Engineering by Collberg and Thomborson called Watermarking, Tamper-Proofing, and Obfuscation - Tools for Software Protection. It’s quite a easy paper to read and it rather nicely summarizes the kinds of attacks on programs and makes references to papers on defense against these attacks.

What have I learned from it? That complete protection is generally believed to be an unattainable goal. And code obfuscation seems to be a necessity (regardless of how one may feel about security through obscurity). Also the security of solutions to other problems, such as tamper-proofing techniques, also depends on its use. There’s an example in the paper that shows how to obfuscate a boolean variable by using two integer variables instead. Can something like that really confuse the crackers?

It might be interesting to read a few more papers before proceeding, such as this one on tamper-proofing and this one on obfuscation. I’ll discuss what I’ve learned from these in tomorrow’s entry.

Using the Openssl Crypto Library

Tuesday January 13, 2004

I’ve written a test program to show how to use the RSA routines in the openssl crypto library to sign and verify signatures. That program also shows how to compute a MD5 message digest. Unfortunately the openssl routines require RSA keys to be a minimum of 384 bits before they will work correctly. This results in signatures, i.e., license codes, that are as long the keys. License codes that long will only be suitable for copying-and-pasting into a registration dialog but not for entering by users manually.

DSA can also be used, resulting in another test program. Regardless of how long the keys are, the DSA routines seem to always produce 384-bit signatures. Same problem.

If I want to work with shorter keys, the scheme will be less secure and I’ll have to write some code myself. If I publicize the exact method I use for a certain program, it’ll be like tell “crackers” to look for certain things (e.g., calls to certain openssl routines) in the executable. So if one doesn’t have extra time to spend on additional prevention measures, some degree of security through obscurity is probably desirable. That’s why I shouldn’t post the code I’ll be using.

Following a similiar reasoning, if one is willing to put a key in the executable, one can use a symmetric encryption method, which can achieve higher level of security with shorter keys and signatures. I’ve written a test program to demonstrate the use of the Blowfish routines.

It’s interesting that one can learn a lot about crack prevention from a cracker site. The danger is if one reads too many of these, one may draw the conclusion that shareware isn’t worth writing at all! At this point, I think I’ll start with a simple license code scheme and hope that a Mac MIDI program will not be of too much interest to crackers. And when it is, it’ll also mean that I’ll have many users and I’ll be willing to invest time and/or money into a more secure solution in a later version.

Implementating Software License Code

Monday January 12, 2004

I searched the web further today for information on software license code. There seem to be many libraries that implement license code authorization for use in PC shareware. I found a website, another, and yet another that provide lists of these libraries. Unfortunately, since most of these are themselves shareware, they are close source and it isn’t possible to look at how they are implemented.

I did find ActiveLock2 which is open source, although it is implemented in Visual Basic. It appears to use a public-key scheme similiar to the one I outlined last week. The disadvantage of using the a public-key system such as DSA to sign user information is that the signatures will be quite long. This isn’t most desirable since these signatures must be entered by the users as license codes. This question has also been asked in a newsgroup but did not result in any good answers.

I also searched for academic papers on the topic. Not too surprisingly I didn’t find any practical information. I did learn how to use advanced search to limit a Google search to a single site. This is very useful if the site is CiteSeer, for example.