Jump to content
  • Advertisement
Sign in to follow this  
granat

Key generator

This topic is 5216 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I need to create a keygenerator where you can specify some options (data) and a company name. This results in a Registration key (licensekey). This key together with the company name can restore the settings at a later time (in a program). In this program a customer(company) must enter the key which is given to them along with their company name. If they enter a wrong company name the key will not be accepted. If the key is altered it will not work. This means that the generated key must be able to verify the company name and contain info about settings (data). The company name is to be displayed in the title bar of the program so that they do not distribute their key to others. I don't know where to start. Can anyone point me in the right direction? I'm using c# and .NET

Share this post


Link to post
Share on other sites
Advertisement
The easiest way is to take the data and then XOR over it the company name again. If you then XOR over that your "master key", you'd end up with a key of some description.
Unfortunaltely, this doens't give a readable string - it'd end up being a string of random-looking ASCII. At this point you could convert it to a HEX string. For example;
Data = 1234567890ABCDEFGHIJ
Company = Good Corp

You'd XOR them; repeating the shorter one

1234567890ABCDEFGHIJ
Good CorpGood CorpGo
--------------------
hjdsa76h873ghjasd82g

I don't know what the XOR'd version would look like; but it would be a mess [grin] Let's say it's that string underneath (in reality it would be garbled ASCII). Now we apply the master key:

hjdsa76h873ghjasd82g
masterkeymasterkeyma
--------------------
ghjk321413ghjk321gy3

Even more garbled ASCII - now just convert each character into it's HEX value, so you'd get something like:

ghjk321413ghjk321gy3
--------------------
BN3214B4C1A0F23F023CF0E9C1D100024BC34CB3

Voila, there's your key!
You could split it into groups of 5 characters for legibilty.
Now, to revert to the original data, just convert back to ASCII, XOR with the master key, XOR that with the company details and you've got your data back!

[Edited by - benryves on September 3, 2004 6:10:54 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by granat
Where did that master key come from ?


You [grin]
If you're trying to make keys uncrackable, then it's a good idea to lay as much extra crap on top of the original.
XOR is entirely reversable; it's very simple and no doubt very easy to crack anyway, but it's the best I know of.
You make up the master key to add more protection. Of course, you could also switch every two characters, so ABCDEF would become BADCFE as well.

Share this post


Link to post
Share on other sites
I suggest standard encryption, like maybe using the AES algorithm. First, use SHA to generate a hash from the company name. Next, put the settings in a simple binary buffer and append a simple CRC32 checksum of the company name and also a checksum of the settings data (including the other checksum). Then, encrypt this buffer using the hash generated from the name. Next, use MIME64 to convert the binary buffer to something readable. You might want to change the encoding scheme to eliminate simmilar-looking characters if it will be typed in, so maybe replace zero, one, and lowercase 'el'(or uppercase i) with other characters. If it will just be copies from an email to the program, then you don't need to worry about the letter replacement.

MIME64 is much better than converting it to hex, because it gives 6 bits of information per character instead of only 4, which means MIME codes will be 2/3 of the length of the hex version, and only 4/3 the length of the binary version instead of double like hex would be.

Since you can find easily implementable source for things like AES and SHA, there really isn't any reason to use XOR encryption unless this is just a proof of concept or somesuch. Of course, just doing this won't make it secure because somebody could take apart your program and figure out what it does, then just decrypt the settings themselves and then encrypt them with a new company name or something like that, but it would be slightly more difficult than if you used XOR.

Share this post


Link to post
Share on other sites
A simple xor isn't cryptographically secure nor is that character switching method.
Use standard encryption AES, RSA and SHS for each purpose, .NET has some libs for that look'em up at msdn.

Share this post


Link to post
Share on other sites
Quote:
Original post by White Rabbit
A simple xor isn't cryptographically secure nor is that character switching method.
Use standard encryption AES, RSA and SHS for each purpose, .NET has some libs for that look'em up at msdn.


No; I know it isn't, but it's nice and easy to implement and your average Joe Bloggs will probably not be able to work it out.

Share this post


Link to post
Share on other sites
One of the common problems with using XOR is that people don't notice that XOR'ing a plaintext with a whole bunch of keys is really the same thing as using a single key. Plaintext^k1^k2^k3^k4^k5 may seem safe, since it's hard to guess k1, k2, k3, k4, and k5. But say K=(k1^k2^k3^k4^k5)? Now I just need to guess K; the values that it's made up of are irrelevant. Next order of business, if you really are considering using XOR, *never* use a key that's anything less than random. That's because it works both ways. While foo^bar might equal @m8, with foo as the plaintext and bar as the key, not only is there the normal decryption method of @m8^bar=foo, but you can also get the key by @m8^foo=bar. Furthermore, repeating keys verbatim is unsafe. "Some random plaintext"^"foofoofoofoofoofoofoo" is how that's normally done, but say I, as an attacker, can have some influence on the plaintext, like in a chat program? by knowing only that the word "random" is part of that plaintext, I can try XOR'ing it in with various offsets, and I'll eventually find something that goes (jarbled text is simulated, as I'm not actually calculating this out) "5,w9?foofootg|\!9db @2". When I see that repeating "foofoo", I've got the key. Even if you use a key that's longer than the known piece of the plaintext, if it's a non-random key like "The quick brown fox jumped over the lazy dog", when I decrypt via my known piece, and I find in the middle of jarbled text, "ox jumped over t", I'll know where to go from there. A simple solution to keep it random and not repeat, is let n = some random number. XOR the first 16 bytes to MD5(n), the next to MD5(n+1), etc. It's still breakable though, and while it might now suffice for both Joe Bloggs and Johnny Justlearningmywayaroundencryption, it won't work on everyone. Use a real encryption function: TEA (the Tiny Encryption Algorithm) is fast and small, and public domain source code is easy to find. I'd recommend hashing whatever you get at the end with an algorithm like MD5 or SHA-1, to keep the keylength the same size. MD5(TEA(Plaintext,Your key)) is getting much safer. XOR it to MD5(TEA(Your key,Plaintext)) if you want even more. If you're really worried, keep a database where each user has a different version of your key. That way, even if one breaks it, they don't all get it. Or heck, you can use a public key encryption system, where the key is dependant on your server as well, not just the client. That'll help fend off keygens. Of course, you don't need to do all this. But it should give you some idea of the weaknesses of XOR, and what other choices you have.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Unfortuantely, your average Joe Bloggs does not need to work it out. Joe merely downloads a crack or key generator that someone else has written.

Ambrosia Software on software keys (good points here):
http://www.ambrosiasw.com/webboard/Forum14/HTML/000052.html

I think the big thing here is the key having an expiry date.

Share this post


Link to post
Share on other sites
From our recent experience (well... I guess "current" is better :) : the way you generate your key do not matter, unless you are sure that the key verification is hard to crack. We've done several experiments here with cracking our own code. What we've done so far :

a) neat, MD5 based, key generation
b) async key verification
c) useless unsafe code (to fool up th cracker)
d) async random errors (from bad execution to software crash) when we detect cheaters.

Finally, to crack the stuff, we simply found the code which was used to generate the comparison key, and filled the comparison key with something known. :|

It hurts. A 30 min cracking to destroy 4 days of work.

But we won't stop here :) Next point : detecting exe patching, and silently do Very Bad Things. Hope this one will be hard to catch :)

BTW, there are tools here that really helps crackers. Using them, they can get a lot of symbol references (MFC, STL, Win32 API) that will help them locating your protection code. One thing we'll also try next week to defeat this tools : creating some of the protection code at run time, as well as some important code, using softwire.

HTH,

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!