Subj : Reg methods
To   : Scott Adams
From : Eddy L O Jansson
Date : Wed Oct 03 2001 03:16 pm

 ELOJ> keymaker with source and read the included documentation for an
 ELOJ> example. (The idea is to _not_ use all keybits in all versions)

SA>         I've not heard of nero where can it be found?

 Nero is a CD-writing software, but I meant CDRWin which is another
 such software. Google can help you out. If you download the keymaker
 for version 3.8+ there will be a 'notes.txt' or you can read the text
 from within the program itself.

 As I said, the idea is to devote portions of the keyspace to checksums
 that you calculate on your end, but don't check in every version. That
 way you can knock out keymakers by introducing the checks in new
 versions, gradually.

 Say you create a key which looks like this

 a4c9a13d3-0100010101
 | serial | parities |

 Now, for the first version of your software you only check that the
 serial is valid (being a hash/function of the name/company/whatever of
 the customer). I've rendered the section called 'parities' as bits to make
 it a little clearer. Okay, the parities are all deterministic and
 functions of other parts of the key or other available data (more hashed
 fields). Say you write your own keymaker so that the first parity-bit is
 set if the 21:st bit of the serial is set.

 Now someone have your software, and decides to write a keygen for it.
 They will reverse-engineer the serial and know how is generated. They
 won't however be able to generate the parities, because the version of
 the software that they have don't do anything with them.

 The smartest move by the cracker now, as (s)he discovers that the
 program will allow any bits in that part of the key, is to generate
 those bits randomly and document this somewhere. The keymaker will
 now work for this the first released version of your program.

 However, you soon discover the keygen and analyze it. You determine that
 the paritites are generated randomly (they might not be, analyzis can
 be meaningful to learn how to best knock the keymaker out). Now, for
 your next version you simply add in the code to check one of the
 parities, say, you begin checking that first bit truly IS in parity
 with the 21:st bit of the serial. If they are not, you know that the
 key is fake. You've just knocked out 50% of the false keys.

 You can extrapolate more advanced schemes from there. For instance,
 you might not want to outright declare "this key is invalid" is so
 found, it's much better to do sneaky thinkgs like adding in a failure
 rate, degrade performance or other little things that will be annoying.

 For instance, if the software is supposed to run in batchmode, make it
 so that there is a one in a thousand chance of the program simply pausing
 to wait for a key. That'd be sure to annoy someone, somewhere.

 Of course, now that the new version is out the crackers can update
 _their_ keymaker, so it's really just an armsrace throughout keyspace :-)

 How effective this can be is only limited to how good you are designing
 your keymaker. Don't forget to key your hashes so that someone with a
 valid key cannot easily deduce the meaning of hashed fields in it that
 you are meaning to 'activate' later on. Etc, etc, bla, bla...

 /%/)+Eddy (srm_dfr@hotmail.com)

---
 * Origin:  (2:203/233)

.