Valentin Rozescu
April 28th, 2000, 10:21 AM
for a time in this forum we are in the front of question like "how to get hdd s/n?" or "how to get mb s/n"
many people have arguments that this kind of security solution in bad ("if the hdd broke" or "if the user need to move the application on new hdd" etc)
we need a serious abordation of this problem
we need an article very proffessional about this
please put an article about this here on codeguru
suggestion:
tell why is not good to use hardware (mb, hdd) serial numbers
give some sollutions with some exemple
underline the area for research or where is the "perfect" solution
thank you very much
Caliban Darklock
May 1st, 2001, 03:05 AM
> tell why is not good to use hardware (mb, hdd)
> serial numbers
Basic rundown of protection scheme requirements:
- Must be easy to use FOR THE USER
- Must be difficult to break
- Must never accidentally fail
That first one kills many people's attempts. They do something that is easy FOR THE DEVELOPER, but never consider whether it's easy for the *user*. Once a user "registers" the product, he should never have to worry about it again.
Hardware based schemes "accidentally" fail when the user does perfectly innocent things like upgrading his computer. (This is also a frustrating thing to do, and your product then tells the user he can't use it when he's already in a foul temper.) This certainly doesn't make them easy to use; the customer basically *has* to contact you for a new registration code. They're also pretty trivial to break, since most such serial numbers *can* be modified by software.
I am currently experimenting with a solution that uses the standard code keyed to a username. This code contains the encrypted seed values for a pseudorandom number generator, which generates a small array of values used to reconstruct known quantities in "restricted" areas of the program, causing it to behave unpredictably when a code is "faked".
The weak point in the algorithm is a 16-bit value which, if known, can be used to hash the username and decrypt the seed values; these seed values can then be used to generate the same table. While no algorithm is perfect, this strikes me as an unacceptable single point of failure, so I'm trying to come up with a better solution. It is, on the bright side, a considerable nightmare to come up with that 16-bit value. When I'm finished with this package, I'll certainly write an article about it.
----
Caliban Tiresias Darklock
Darklock Communications
"Pain has a face... allow me to show it to you."
-----