May 14th, 2003, 09:46 AM
Here's a little puzzler for those of you with a puzzling mind ...
I'm writing a licence manager / key generator to protect a piece of software (an add-in for the NT IIS Admin service). The user will have to re-licence periodically and will be asked for the server IP that their system runs on and will be given a new licence.
But why are you posting this?
I want to be fairly sure that the users won't be able to figure out how to make their own codes once they have several licences to compare. If anyone can figure it out this one I'll post this version of the code and rewrite it (sorry - I can't post it if I use it - I'm being paid for this one ) and we'll try again
What will the user know?
Say the users IP was 188.8.131.52. They would get the following licences/expiry dates:
Expires 01/04/2003: 3EAC281-3F9B7CE-3F91CB9-4088350
Expires 01/06/2003: 3EAC281-3F9B7D2-3F91CB9-4088350
Expires 01/01/2004: 3EAC282-3F9B7CF-3F91CB9-4088350
Expires 01/06/2004: 3EAC281-3F9B7D2-3F91CB9-4088351
Create a code with a new expiry data.
Create a code with a new IP address
\"I may not agree with what you say, but I will defend to the death your right to say it.\"
Sir Winston Churchill.
May 14th, 2003, 10:24 AM
Why not make a string consisting of
secretword:ip address:expiry date in some format
and md5 hash it (or hash with another algorithm)? Then the client does the same computation to check if it produces the right result?
Of course you might need the expiry date sent plaintext too, but that's ok you can just append it or something.
The codes are going to be long, but if you're worried, use a hashing algorithm that produces shorter codes. 32-bit CRC should do fairly nicely (although clearly less good than md5)
May 14th, 2003, 11:25 AM
Here's a suggestion. Why use some self composed algortihm for this kind of tasks when there are so many standarized encryption methods that would do exactly the same, only much better. I would have come up with a concrete suggestion - but I can't think of anything right now.
It's a cliché, but "security through obscurity" usually isn't good enough....
May 14th, 2003, 02:24 PM
As with most cases anyone attempting to circumvent your security will take the easiest route. I wouldnt bother trying to break your alg. by hand, one would only need a copy of your software and SoftIce to find your code validation routine. One could extract it from there or NOP the check. Unless of course you have a way to prevent this.
May 14th, 2003, 04:18 PM
Here is a quick try at Challenge 1 just because I had a little bit of spare time. I want you to check it and tell me if it works out. Right now I'm just playing with a few values, and am just wondering what the results are. I still am messing with the original IP, and I don't think I'll have the time to figure the part where the IP value is different. So far I think I have found the part of the key that holds the month and year, but I haven't had any time (or the ability) to verify what values will work in those areas.
Here are a couple of assumptions I am making:
1) The key is made by changing the order of the IP & Date after they have undergone some sort of change, or were made by the keygenerator. The result was then converted to HEX.
2) Your dates are in the order "dd/mm/yyyy". Thus 01/06/2003 would be the first day of June, 2003.
3) The key does not contain a value to check weither or not the key was altered. Like a built-in checksum for the key.
Here are a few quick jabs at Challenge 1 below...
Expires 01/06/2005: 3EAC281-3F9B7D2-3F91CB9-4088352
or Expires 01/06/2005: 3EAC282-3F9B7D2-3F91CB9-4088351
Expires 01/04/2004: 3EAC281-3F9B7CE-3F91CB9-4088350
Please tell me if any of those were valid. So far I have essentially changed only one value of the key (except my 'or Expires...') to get those. I don't know if the client (the customer's server) will do any checking on the validity of the code by using some sort of a checksum to check for a change. The checksum-value could be embedded into the key, and could provide more difficulty in generating new keys until the client figures out there is a checksum, and decides to change your plug-in/program to not verify the checksum, or care about the result.
My main goal here is to tell you what I have come up with to go against your algorithm (so far). Implementation of stuff is always a big issue, because many good things have been used incorrectly, and had...bad...results. My guess is that it would be very difficult to write a program with even a simple licence/key manager/generator. But, I am trying to focus on the keys generated themselves, and things that I have seen in them. I just want to know if the keys I made can be used, as that is my only goal for now... If I can't meet that goal, then it just means that I might need to consider going into more math classes for my junior high school year...