- Local time
- Today, 18:38
- Joined
- Sep 12, 2006
- Messages
- 15,953
Here's a general idea for securing a database.
You need
an encryption/decryption technique
a utility to change an encrypted byte string into a (longer) hex string (for presentation purposes)
a MD5 (say) one-way hashing algorithm
a utility to get a "secret" from your machine - say the HDD number
all of these things are available for download.
First - you need to put this into an mde/accde, as obvioulsy it's no good if users can see your code.
Now you need some "secret" you want to protect. Say you want an expiry date for your aplication. You also may want to read something unique to the machine - maybe the HDD code.
put the date and HDD code together into a string - you could interleave or process these in any way you want
Now, encrypt this again using your encryption technique. A simple xor system may be sufficient, although there are more complex methods.
Turn the resultant string into a Hex String - it's better to get printable chars than strange non-printable chars.
In order to do this all remotely, your client/installation presents this string to you.
now take a MD5 hash of the HEX string
take a few characters from selected positions in the MD5 hash, and insert them into your hex string to make a longer HEX string
this is the license key you issue to your users, which does not now need to be hidden from users - they need to see this one
encrypt it all again, if you want, and turn it into another Hex string.
send this string back to your users
--------
so - to use the licence key
-decrypt the licence key, if you encrypted it again
- take out the MD5 characters you inserted into the string in the first place, and store them in a variable
- this leaves you with the original encrypted string, and the characters you just stripped out. Now do a MD5 of the encrypted string, and make sure it gives you the same check characters. If it doesn't reject the string
The likelihood of someone working out which characters you added to the string from the MD5 hash to produce the final string are negligible, I would think, but if you obfuscated further by re-encrypting the entire string, it becomes pretty random.
- this now leaves you with the original encrypted stuff, which you can reverse to recover the original license date, and machine HDD, which you test to make sure the license date has not expired, and the HDD is correct.
----
the main thing here is the MD5 hash. MD5's are one way functions. Knowing the final MD5 hash does not help you recover the original string that produced it. There are databases to test MD5's - which is why you need to start with a pretty random string in the first place.
If you just took an MD5 of a date, I suspect the databases would have this stored in their records.
HDD's are not unique, but are random enough for your database to not automatically be able to be run on any other random machine - but there are other secrets you could lift off your machine, if you want something else. HDD is quicker to get at than some things though.
This whole validation process is very fast, and produces no noticeable delay.
-----
obviously your database has to include all the code necessary to reverse all these processes - so reverse engineering code could identify all the steps you took to encrypt everything. The only way round this I suppose is to require an active online connection - to do some of this checking away from the client's machine, but I suspect this would be taking it all too far.
I hope this helps.
You need
an encryption/decryption technique
a utility to change an encrypted byte string into a (longer) hex string (for presentation purposes)
a MD5 (say) one-way hashing algorithm
a utility to get a "secret" from your machine - say the HDD number
all of these things are available for download.
First - you need to put this into an mde/accde, as obvioulsy it's no good if users can see your code.
Now you need some "secret" you want to protect. Say you want an expiry date for your aplication. You also may want to read something unique to the machine - maybe the HDD code.
put the date and HDD code together into a string - you could interleave or process these in any way you want
Now, encrypt this again using your encryption technique. A simple xor system may be sufficient, although there are more complex methods.
Turn the resultant string into a Hex String - it's better to get printable chars than strange non-printable chars.
In order to do this all remotely, your client/installation presents this string to you.
now take a MD5 hash of the HEX string
take a few characters from selected positions in the MD5 hash, and insert them into your hex string to make a longer HEX string
this is the license key you issue to your users, which does not now need to be hidden from users - they need to see this one
encrypt it all again, if you want, and turn it into another Hex string.
send this string back to your users
--------
so - to use the licence key
-decrypt the licence key, if you encrypted it again
- take out the MD5 characters you inserted into the string in the first place, and store them in a variable
- this leaves you with the original encrypted string, and the characters you just stripped out. Now do a MD5 of the encrypted string, and make sure it gives you the same check characters. If it doesn't reject the string
The likelihood of someone working out which characters you added to the string from the MD5 hash to produce the final string are negligible, I would think, but if you obfuscated further by re-encrypting the entire string, it becomes pretty random.
- this now leaves you with the original encrypted stuff, which you can reverse to recover the original license date, and machine HDD, which you test to make sure the license date has not expired, and the HDD is correct.
----
the main thing here is the MD5 hash. MD5's are one way functions. Knowing the final MD5 hash does not help you recover the original string that produced it. There are databases to test MD5's - which is why you need to start with a pretty random string in the first place.
If you just took an MD5 of a date, I suspect the databases would have this stored in their records.
HDD's are not unique, but are random enough for your database to not automatically be able to be run on any other random machine - but there are other secrets you could lift off your machine, if you want something else. HDD is quicker to get at than some things though.
This whole validation process is very fast, and produces no noticeable delay.
-----
obviously your database has to include all the code necessary to reverse all these processes - so reverse engineering code could identify all the steps you took to encrypt everything. The only way round this I suppose is to require an active online connection - to do some of this checking away from the client's machine, but I suspect this would be taking it all too far.
I hope this helps.