Re: Keying an installation to a single machine
- From: "MikeD" <nobody@xxxxxxxxxxx>
- Date: Tue, 14 Feb 2006 20:28:01 -0500
"Dan Hoskin" <danhoskin@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:thrIf.2366$_D5.197787@xxxxxxxxxxxxxxxxxxxxxxxx
Using the computer name sounds like a better idea. I am not looking for a
iron-clad security method, just somewhat of a deterrent. I didn't realize
that a re-format would change the drive serial number.
No, still not any better. <g>
In fact, it might be worse. The computer name can easily be changed. If the
computer is part of a network, its name is not likely to get changed because
that would mean changing a lot more network config settings, etc. But for a
typical home computer, not a good solution either IMO. For example, if Ken
and I wanted to pirate your program and I've got it unlocked (legally) for
my PC, all I'd have to do is tell Ken to change his computer's name to the
same as mine (and figure out where/how your program is storing this
information; it has to be somewhere, perhaps a file, perhaps the Registry).
Sure, it'd provide simple protection, but probably any
slightly-above-average user could crack it.
But maybe that's all you want or need. There are many things to consider.
For example: Is your program only going to be appealing to casual users who
probably aren't too computer-savy (like a home video database program would
be)? Do you think your program could so immensely popular (sure, we all hope
for that, but be realistic about it) that others might try to crack it so
they can profit by selling the "crack"? Bottom line is that no software
protection is foolproof. If foolproof protection existed, there'd be no such
thing as software piracy. The best you can do is make it reasonably
difficult and only you can determine how difficult it needs to be.
For whatever it's worth, here's a brief synopsis of what I do:
I get Windows' ProductID from the Registry. A portion of the ProductID
always remains constant for that copy of Windows, even if Windows gets
re-installed, so that's the only part of it that I use. The app also creates
a value that identifies the app (this is an algorithm based on the app's
name, but for obvious reasons I'm not going to say more about that <g>).
These 2 values are then "combined" (another algorithm) to create a single
value. This value is unique for the app AND that particular copy of Windows
(the "app value" is necessary so that a license code can't be used with
multiple products). This "combined value" is then saved, encrypted, to the
Registry. Each time the program is run, it reads this value (if it exists)
from the Registry, unencrypts it, and compares it to the generated value. If
they match, the program's unlocked. If they don't match, but the Registry
*has* the value (because it only gets written to the Registry when the user
unlocks the program by typing in a license code), the user did some
tampering (and I show a polite, but firm, message stating it *appears* the
user was playing around with things he/she shouldn't be playing around with
<g>). If the Registry doesn't have this value at all, the user hasn't yet
unlocked the program.
I do get a tad more complicated with it than that (for example, I also save
the date the program was first run [not the date it got installed because
you never know if maybe somebody else installed it but the *user* doesn't
actually run it for days or even a couple weeks later]). But, that's the
nuts and bolts of it. The good thing is that the PC can be upgraded with
whatever hardware, and even re-install Windows, and the same license code
will still work. The only real caveat is if Windows gets upgraded (or
downgraded) to another version. Then, a new license code is required. Of
course, another caveat is if that copy of Windows itself is pirated. That's
less of a problem as Windows' piracy protection gets better. IOW, the better
MS protects Windows from piracy, the better my software, automatically, gets
protected. And then there is always the chance that MS will change where the
ProductID is stored in the Registry. That would create problems, but I do
have a fail-safe built in just for that possibility.
By no means is this foolproof. Somebody could crack it if they wanted to.
But, it's fairly simple to implement (it's actually all wrapped in a class
module so all I need to do is add that class module, set a few properties,
and call one method), has no major drawbacks that I'm aware of, and I think
provides fairly decent protection while keeping "user annoyance" to a
minimum (no user has ever complained about needing a new license code after
they've upgraded Windows).
--
Mike
Microsoft MVP Visual Basic
.
- Follow-Ups:
- References:
- Re: Keying an installation to a single machine
- From: Ken Halter
- Re: Keying an installation to a single machine
- From: Richard B
- Re: Keying an installation to a single machine
- From: Dan Hoskin
- Re: Keying an installation to a single machine
- Prev by Date: Re: Multiline tooltips
- Next by Date: Re: Keying an installation to a single machine
- Previous by thread: Re: Keying an installation to a single machine
- Next by thread: Re: Keying an installation to a single machine
- Index(es):
Relevant Pages
|
