At 10:15 AM 6/9/99 -0700, you wrote:
>
>I still don't see the point of this. Presumably after you've done all
>this magic, you make some decision: did the regcode check out ok or
>not? A cracker just needs to find this bit of logic and make it look
>like the decision came out "ok". Alternatively, he can find the place
>where you start the regcode process and branch around the whole thing.
>Or am I missing something?
Yes. More sophisticated registration checking code uses algorithms the
program itself depends on. If the algorithms are changed, the program
itself doesn't work correctly. You simply check the result (non boolean)
of an function with predetermined inputs. This can make cracking the
program much more difficult.
It's much worse if you have encrypted the code, but this is more difficult
than it seems - if you use private key encryption, the key you used to
encrypt the code must be contained somewhere on the device - you may as
well have not encrypted it at all. The solution to this is to use public
key encyption to encrypt the alogorithm, but this still just adds a very
small amount of complexity - after all, the algorithm must be decrypted in
memory at some stage - it's easy to halt the program and dump the memory.
If you really want to make your program secure, you need to use something
unique about the device you intend to target within the algorithm. If
there was a software readable serial number in the device, you could use
that as your key (dongles work this way)(don't be suprised to see this sort
of application once serialized Pentiums are released). This would require
crackers to modify their actual hardware to get your application to run.
Unfortunately, your clients may have problems if they change their
device... but theoretically, they have a support contract or something.
