How does string obfuscation in obfuscators work?

Question

I want to store a password in my app to encrypt the installation date and store it in some folder and perhaps also in the registry for a 30 day version of my app. I've been googling around a lot and most people suggest to store the installation date encrypted. I know whatever I do can still be cracked but I want it to be just reasonably hard to crack without calling home or stuff like that. I could, for example, have a const string store a password that is encrypted with a password stored in another const string and so on. This would make it a little bit more complicated. But since string obfuscation seems to be such a common task for obfuscators, I want to know if there is a better way to do it in case any of you have any idea how obfuscators usually obfuscate strings in code so I can repeat the procedure.

(I'm not going to purchase an obfuscator. I'm using the free version of dotfuscator which doesn't obfuscate strings and that's fine, but I wouldn't buy the paid version just to obfuscate a single string (in case the paid version obfuscate strings which I don't care).)

(And I still want to do the 30 day trial. I already read a lot about other options like making a free-light version and stuff like that. The 30 days version is the best option in my case.)

Answer 1

You will also need to consider what happens when users delete all your registry keys and reinstall your app to get another 30 days. The "best" option is to generate registration keys that have the date built into them. If they decide to reinstall your application they have to use a valid registration key and the only one they will have is the one with an older date.

Then you have to make sure they don't keep registering for new keys etc.

Anything more than this can be circumvented by decompiling and recompiling your application.

Building in a Date

I do something a little more complicated with identifying features of the users computer. I'll explain a simple way though. Keep in mind if they really wanted to decompile/recompile this won't work, but I'd say it falls under reasonably hard.

• Generate a encryption key for your product.
• Convert it into a byte[] so it isn't a String. (But also remember that "obscurity isn't security", but we aren't really trying to have an end all be all license scheme)
• Take the users full name and concat it to the current date and concat that with the number of days their license is valid. You might end up with 01/10/2011 30 Andrew Finnell as the final string.
• Encrypt that string and convert it to Base64.

This is your new license key. You can just have them cut and paste that into your application when they go to register.

If that key is too hard to manage you do something a little different. Basically you do what I said, but only take the first 16 hex'ed characters. You then store that with their name, date and number of days in the registry. When your application loads up you generate a new key with those stored values (name, date, days, etc) and compare the first 16 characters with whats stored in the registry.

Please keep in mind this is just a simple way to prevent users from sharing or taking advantage of your software. None of these are high security grade techniques and will result in key crackers if they really wanted to.

Answer 2

I agree with the earlier comment stating that anyone who has technical skills and a little bit of free time will defeat any encryption/misdirection scheme you put together if all of the moving parts are local to your application. Obfuscation tools (like Dotfuscator commercial SKU) do all include "string encryption" but this particular transform is considered to be the weakest of the lot (as compared to control flow obfuscation or overload induction renaming). Once a string is mangled, the "decryption" function is injected into the stack prior to the text being popped at runtime - anyone who wants to take the time to trace whatever process you undergo will soon have all of your tricks laid out in front of them (unless some of the tricks are remote). So, you mentioned that you were not trying to make anything bullet proof - just slow people down and deter opportunistic hacks - that being the case, then this type of technique is fine - you will deter "the opportunistic hacker" who will poke around for fun but is easily put-off (but that will be the extent of it).

Lastly, if your app was, by chance, a WP7 app - then the full commercial version of Dotfuscator is available at no charge (and does include string encryption, control flow, etc.) at www.preemptive.com/windowsphone7.html