Cd key generated from generated key rules

[cagiva 0]

Hello, I'm preparing a password manager program but i didnt have any security levels (except _encrypting data), in that case, any cdkeys or anything.

After reading this post:

My 2 cents on serial numbers:

Instead of having pre-defined serials and search that long list for a match ... why not use an algorythm and check the serial against that algorythm? If it matches then it's OK and it's a genuine serial - if not, then it's a fake ...

You can create a simple algorythm this way:

example:

-1st character is random (a-g)

- 2nd char is always a number between 6 and 9

- the 3rd character is obtained from 1st character ASCII code +5

- the 4th character is obtained by adding 2nd and 3rd character and dividing the number by 2

- the 5th character is always a number between 0 and 4

... and so on ... you can add as many rules as you want to this algorythm

This way you don't need any serial number database.

I got the idea. Why not to make a cdkey generator from given rules? and what about rules generator?

I've prepared 3 files.

1. Rules generator

2. CDkey generator from generated rules

3. Cdkey tester. There isn't a whole list of cdkeys in file, but only algorythm, which gonna check if the key is valid or not.

1.

global $regula[21]

for $i = 0 to 20 step 1
    $k = chr(random(65,90,1))
    $k2 = chr(random(65,90,1))
    $k3 = chr(random(65,90,1))
    $k4 = chr(random(65,90,1))
    $j = Chr(random(48,57,1))
$f = $k & $k3 & $k4 & $k2 & $j
$regula[$i] = $f
Next

for $j = 1 to 20 step 1
IniWrite(@DesktopDir & "\Rules.txt", "Rules", "Rule"&$j, $regula[$j])
Next

2.

expandcollapse popup

#include <array.au3>
Global $omg[21]

for $j = 1 to 20 step 1
    $omg[$j] = IniRead(@DesktopDir & "\Rules.txt", "Rules", "Rule"&$j, "")
Next

global $s[21]
global $hw[21][6]
Global $rn
$trololo = InputBox("How many CDKeys do you want to generate?","How many CDKeys do you want to generate?")
run("notepad.exe")
sleep(3000)

for $klp = 1 to $trololo step 1
for $hh = 1 to 20 step 1
    $s = StringSplit($omg[$hh], "")
    for $mg = 1 to 5 step 1
        $hw[$hh][$mg] = $s[$mg]
    Next
Next
for $np = 1 to 20 step 1
    $n = $hw[$np][Random(1,5,1)]
    if Mod($np,5)=0 Then
    $rn = $rn & $n & "-"

Else
    $rn = $rn & $n
    EndIf
Next
send($rn)
        send("{BACKSPACE}")
    send("{ENTER}")
$rn = ""
Next


_ArrayDisplay($hw)

3.

$key = InputBox("Hi :D","Please insert CD-Key.")
$11 = StringReplace($key, "-","")
$wtf = StringSplit($11, "")

Global $omg[21]

    for $j = 1 to 20 step 1
    $omg[$j] = IniRead(@DesktopDir & "\Rules.txt", "Rules", "Rule"&$j, "")
Next

for $i =1 to 20 step 1
$k = Stringinstr($omg[$i], $wtf[$i],1)
if $k > 0 Then
Else
    MsgBox(0,"Eroor","CD Key is NOT Valid")
    Exit
EndIf
Next
MsgBox(0,"OK","CD Key is valid")

Hmm you think.. is he crazy? if he upload here his code, he won't use it in any of his programs because anybody could crack it, when they know cdkey rules. yes that's true, but for everybody who gonna run rules generator, they gonna get different rules, so cdkeys will be different too. so everybody can prepare theirs rules and use them in theirs programs. am i right?

one of generated CDKeys:

FNARQ-0KR9U-214HX-3I6DB

discuss, what do you think of that 3 small scripts.

the 3rd script you can use in your programs, to check if the key is valid or not.

Sorry for a poor English language, coz its not my native language and i'm little tired, so please forgive me, my mistakes.

[ivan 1]

You might want to search the forum for similar discussions or ideas you might like to use to complement your security mechanism. You'll eventually find that perfection in this subject is pretty much like the search for the Holy Grail...

Problem #1:

As it sounds your keys are generated on the computer your software is being installed. You grant ease of installation here by issuing a key together with the CD, but there is a major shortcomming. Abc buys your software, makes an IDENTICAL mirror copy of your cd (includes CD serial number, file, directory attributes, including dates, etc). The key issued for that CD will be valid for all identical copies... Once a valid key has been issued on the pirate market, it's pretty much unstoppable.

You might want to revise your procedure by associating the generated key to "unique??" data of the computer where your software is being installed. If you look hard enough you will see that hardware information (use WMI for this) is not totally reliable, so you might want to complement it with somo OS installation data (file date of the io.sys file, the recycler). The discussions get quite interesting. That will require some validation (encrypt/decrypt procedures) on your part and make the issue of distribution much more cumbersome. As to the "uniqueness" of data, it's another very debatable issue. Again, check the forum for discussions.

A typical procedure at this stage is:

On first run, generate the unique encrypted string. Instruct the user to purchase your product and submit this generated key. Once you confirm the purchase, you decrypt the key and issue an activation key using another algorithm. There are some variations on this, but it's a matter of personal choice.

Problem #2:

Algorithms can and are cracked, so the stronger the generated key the stronger your overall security. Bear in mind that memory and processing capabilities are quite powerful, so you should consider stronger encryptions.

Problem #3:

Even with the procedure suggested in #1, you will need to store data somewhere, registry, file, wherever... That data can be erased...

Problem #4:

Cracking... This is a decompile, recompile issue. At some point your program will evaluate conditions whether it's a valid copy or not. Suppose this is done by a function you call _ValidateProgram(), so

If Not _ValidateProgram() Then Exit
; do whatever

If your cracker changes your validation procedure to

Func _ValidateProgram()
  Return True
Endfunc

The security system has collapsed. To solve this, your validation procedure has to be linked to some critical process of the program.

A strong security system has to address all these issues, and probably more. I have done my fair share of work on this. but unfortunately, I have not been authorized to disclose any code, so the best I can do is just point you out in the right direction.

IVAN

[jvanegmond 307]

ivan, each security approach has its own problems because as you said: It is much like searching for the Holy Grail. That said, CD-keys have their purpose as a first line of defense. cagiva's script does a decent job that is similar to how games are protected (part of their protection is CD-key). There are problems of course, but problems #2, #3 and #4 fall outside of the scope of the problem that CD-keys can solve: There is no workaround when you stick to the CD-key idea. The solution you're describing in #1 is simply a form of offline-authentication.

cagiva, your script actually does a decent job. The biggest problem at the moment is that you have to supply a Rules.txt (plaintext ftw) set of CD-keys with your application. Although the name Rules.txt may not inspire everyone to click on it, there is a good probability that at least a group of people will and then share that knowledge. To tackle this problem you have to write a code-generator that will come up with the rules and the code that generates and checks the rules for validity.

A simple example of this is a regular expression. I can create a rule like: [0-5][6-9][A-E][F-G]. A CD-key generator script will pick random values that fit the regexp, and finally the CD-key validity code is the regexp itself. Eventually, you'll want to create more and more complex CD-keys and regular expressions will definitely not be enough.

[ivan 1]

ivan, each security approach has its own problems because as you said: It is much like searching for the Holy Grail. That said, CD-keys have their purpose as a first line of defense. cagiva's script does a decent job that is similar to how games are protected (part of their protection is CD-key). There are problems of course, but problems #2, #3 and #4 fall outside of the scope of the problem that CD-keys can solve: There is no workaround when you stick to the CD-key idea. The solution you're describing in #1 is simply a form of offline-authentication.

cagiva, your script actually does a decent job. The biggest problem at the moment is that you have to supply a Rules.txt (plaintext ftw) set of CD-keys with your application. Although the name Rules.txt may not inspire everyone to click on it, there is a good probability that at least a group of people will and then share that knowledge. To tackle this problem you have to write a code-generator that will come up with the rules and the code that generates and checks the rules for validity.

A simple example of this is a regular expression. I can create a rule like: [0-5][6-9][A-E][F-G]. A CD-key generator script will pick random values that fit the regexp, and finally the CD-key validity code is the regexp itself. Eventually, you'll want to create more and more complex CD-keys and regular expressions will definitely not be enough.

@Manadar:

I did take a look at the 3 scripts provided and my comments were attempting to tackle the larger issue of security which is the whole purpose of such scripts. I did not have any intentions of providing destructive criticism, rather than that, I believe I politely and respectfully made a contructive list of issues a security script has to handle. While working on a solution for a language teaching application for a customer, it took me a lot of trial/error write, re-write several scripts, and my desire was to share some of the experiences I came accross, and to be honest, I'm not totally satisfied with my solutions either.

It's actually a shame 3 1/2" Floppies have falen out of use. My earliest work on this dates about 8 years, and the best solution I could come up with was to distribute a floppy with minimal physical dammage together with the CD. The location of the damaged clusters was hard coded on the software, so verifying the legitimacy of the CD was related to a non logical but a physical key. I dropped this also years ago for several reasons, not to mention that using damaged hardware wasn't particularly the best idea, but also verifying that the physical damage on the floppy existed and it was not a mirror copy of the damaged disk was time consuming. I must admit, I had lots of fun doing it though.

@Cagiva:

My intention was to be helpful and if I have offended you, please accept my sincere apologies.

Regards,

Ivan

Edited February 21, 2011 by ivan