As has been pointed out already, these schemes are essentially security by obscurity--i.e. not so good. In practice, the keep honest people honest, but can be circumvented by anyone who cares to spend the time and effort.
The usual approach is to take some unique information (serial number, licensee name and address, etc.), combine it with secret salt value(s) and hash and chop and mash and mix and boil and burn. When you finish you want to wind up with a nice registration code. You need to make up your own ledgerdemain. A good system will provide numbers that are hard to combine to recover the salt value. The secret salt must be stored in the file, so you'll probably want to hide it in your code somehow--do something like use the 8 bit xor sum of line 256 in your perl script rather than my $salt = 'SECRETSALT-WOOT'; .
Textfiles.org has some essays on cracking serial numbers, they may give you some ideas about how other systems work.
If you read the above sources, you'll see that even if you generate ultra-secure codes that cannot be guessed, someone can always decompile your software and reverse engineer your algorithms. If you want maximum achievable security, you'll have to write code that comes out obscured after it has been deparsed, or decompiled (or write obscured assembler). Of course this code can still be decontstructed by a dedicated cracker.
TGI says moo
In reply to Re: Serial Generation and Validation
by TGI
in thread Serial Generation and Validation
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |