Time-limited evaluation period made easy

[Brian Chirgwin]

btw just to clarify - obviously nothing is uncrackable, but if you simply use a static key location then its easy for a cracker to write and distribute a program (or even .reg file) to attack that key, whereas if its dynamic then its a lot harder - the cracker has to debug your program to try and figure out how youre calculating the dynamic names.

Any more questions/comments etc please post to the Programming subforum instead, cheers!

Wayne,

Any licensing or copy protection scheme can be broken. There is no doubt about this.

Dynamic key names add little or no additional protection. While it is true the hacker needs to find where the key name is if dynamic, this can be done in about 2 minutes. Even if it is static, the hacker needs to find the key in the same manner.

Once a dynamic key is found on a system it will be the same dynamic key on the same system. So a hacker could just copy the dynamic key and value as easily as that of a static key.

The same result can be accomplished by using a static key. Just but the dynamic data in the key value plus the date data. There is little difference in:

Keyname: INeverChange
Keyvalue: encrypted(IamDynamicBasedonUserName+expires)

KeyName: IamDynamicBasedonUserName
KeyValue:encrypted(Expires)

In both cases copying the dynamic or static key name and value to a different machine would fail on that machine (Unless the username or what every identifying data is used was the same).

My point is dynamic keys add no value. Doesn't hurt if you do and doesn't hurt if you don't. Just my opinion, but I think key names should be static. Key values should change.

[Wayne Diamond]

Folks, I only posted the demo as an example of how to implement a simple time-restricted evaluation. I made it clear that the demo was as minimal as possible, and provided no security - it is purely about implementing a time restriction, so I don't know why im being hit with so many "you can crack this by doing xxx", as it isn't an anti-cracking demonstration!!! (And besides, show me anything you've ever made and I'll break it too!)

My point is dynamic keys add no value.

Then please allow me to explain to you how you're missing the point ...

If you use static keys, for example HKLM\Software\My Company\My Program\Expiry Date, then all a cracker has to do is distribute a program (or maybe even just a .reg file). The cracker won't even have to look at the executable!

The popular chat program mIRC, for example, can have its evaluation period defeated simply by adjusting the security permissions of its STATICALLY-named key (HKEY_CURRENT_USER\Software\mIRC\LastRun) so that no users have Read permission. You can do this simply with Regedit, and its also quite easy to make such security permission changes programatically (afterall, Regedit does).

However if this key was dynamically named then I couldn't just tell you "go rename this key", because the key would be specific to your computer so I wouldn't know what the key was called.

If you use a dynamic key then they have to attack the executable itself to figure out how the program is calculating the name of the dynamic key(s). Already by this stage you've significantly restricted the number of people who're able to attack your program - the wannabes are no more. Sure the cracker can still use Regmon for example to find out what reg keys are being used, but because they're dynamic those keys are only applicable to his computer. In other words he essentially has to rip your dynamic name generating algorithm out of your program and get it working in his own executable. There is no easy shortcut for him here.

For example, consider I store my dword value in HKLM\Software\37DF129F, where 37DF129F is a hash of something unique to my computer, how are you going to write a program to defeat that, when that value is unique to my computer and based on my own custom algorithm? Basically the only way is by ripping the code out of my program and using it in your own, and if I've included anti-debugging/anti-disassembly tricks then your job will become much slower and harder, possibly taking it out of your reach.

At the end of the day I don't care if you (as in anyone) as an individual cracker are able to get my program running on your computer, because obviously that doesn't really do me as the author any damage, but it is important to try to prevent you as a cracker from creating a patch/crack that can be distributed to others, because obviously then it becomes a much more serious matter when "anyone" can use your crack.

ps. A few nights ago I discovered that Regmon (and Filemon) can easily be bypassed. They work by hooking the SSDT table - important kernel-level registry-related APIs. However, those functions can be copied and called without affecting the original SSDT or any SSDT hooks, therefore bypassing Regmon/Filemon and all other similar API hooking programs that hook into the SSDT. (This isn't just theory - I've put together a working proof of concept). I've done a lot of Googling but haven't seen't any mention of this type of bypass before, so yeah - don't take everything you see from Regmon's display as gospel