My OS X Programming Blog

Elliptice Curve Cryptography (ECC) is believed to achieve the same level of security as public-key encryption methods such as RSA and DSA using a much smaller modulus. So I looked into ECC libraries today for use in my license code scheme. There seems to be only one in the public domain called Crypto++. Like openssl, using it requires a bit of searching through the web for examples and documentation. I’ve written some sample code to sign and verify a message using ECDSA. Using the shortest recommended key size, the signatures are 30 bytes long. Quite a nice size to be sent as license codes to registered users.

Here is an article that briefly describes ECC.

Checking License Codes Without if Statements?

Thursday January 22, 2004

Suppose we’re implementing an application whose “Save Document” function is disabled unless the application is registered. For simplicity let’s assume that the license code is simply the signature of the name of the registered user, signed using the private key of a key pair. The “Save Document” function is enabled if we can verify that the signature corresponds to the user name, using the public key. Assuming that the key pair is secure, it will be impossible for attackers to produce a key generator for the application. The question that remains is whether they can patch the application to bypass the statements that verify the license code. Statements such as “if (isRegistered) ...” or “if (VerifySignature()) ...” or obfuscated versions of such statements can be bypassed by patching the machine code to always return a true value. Can such “if” statements be eliminate? Yes, and I believe the following is an original proposal.

Suppose M is the message digest of the user name and N is the result of decrypting the signature (i.e., the license code) using the public key. If N equals M, the software has been registered. Instead of testing for equality of M and N, we maintain D, the data to be stored to a file, as E = f(D, M). The “Save Document” function will always be enabled but before data is stored, it attempts to recover the value of D by evaluating g(E, N). The functions f and g are inverses of each other and can be as simple as an exclusive-or operator or the encryption and decryption functions of a symmetric key system. If M indeed equals N, data is correctly stored to a file. Otherwise the file will just contain garbage. To circumvent such protection, an attacker must discover both places in the code that compute E and D and bypass them.

Note that this method can be used for passing parameters into any functions or storing and retrieving global variables, or even for protecting function pointers. Introduction of a number of these into the application should make it difficult to patch.

Opaque Constructs

Wednesday January 21, 2004

Here’s a brief report on the paper Manufacturing Cheap, Resilient, and Stealthy Opaque Constructs by Collberg, Thomborson, and Low.

This paper makes use of the difficulty of alias analysis to design code obfuscating transforms for introducing opaque predicates. Aliases are pointer variables that point to the same memory location. An opaque predicate is one whose outcome is known by its creator, but not easily discovered by an attacker. Although the examples in the paper are written in Java, the technique applies as well to other programming languages. Unlike many of the other papers, the description of the technique is rather concrete. The obfuscating code maintains a graph and makes designed but seemingly random sequences of updates to it. Since updates to a pointer only make it point to different nodes in the same connected component of the graph, two pointers to nodes in different connected components can never be equal (this is the opaque predicate to be checked). The paper also outlines another technique that makes use of concurrent threads to make static analysis difficult.

Oblivious Hashing

Monday January 19, 2004

The paper Oblivious Hashing: A Stealthy Software Integrity Verification Primitive by Chen, Venkatesan, Cary, Pang, Sinha, and Jakubowski claims that it is straightforward to identify code verification routines in an attack because such routines read the application’s code segments. Horne et al. addressed this problem in their implementation of “testers” by obfuscating the instructions for such reads. In any case oblivious hashing is an interesting idea of interspersing hashing code in application code that needs to be protected. The hash results depend on data used exclusively by the hashing code as well as application data. Therefore the dynamic behavior of the application is checked. The biggest problem with the paper is that it hasn’t worked out a scheme to check the hash results! One would think a paper written by six authors would do much better than that. Oh well!

For another overview of software protection, I’ve found an article on IEEE Computer entitled Preventing Piracy, Reverse Engineering, and Tampering. This is a less technical introduction to software protection than the IEEE Trans. on SE paper. So it’s probably worth a read if you need a quick introduction to the topic.