Hi Ray, thanks for the suggestions.
What I had been using was GetVolumeInformation on the C:\ drive and then
mangling the various information returned. The problem turns out to be that
all Dell machines return a zero serial number for the drive, which made my
derived key less than unique.
The problem with using the mac address is that on, um, I forget - XP or W2K,
with one of the newer service packs, if the network cable isn’t plugged in,
the networks aren’t installed sufficiently to be able to obtain the mac
address. There is a workaround of setting a registry key, but this I think
basically disables power management. Which people using laptops seem to not
appreciate for some reason.
Of course, the problem is that my app will be installed with the network
cable attached, so I’ll be able to set up a mac-based key just fine. But
since it is an audio playback app for use in a live theater where you really
need things to happen when you ask and not 30 seconds later, everyone knows
to have auto-update turned off and the network cable unplugged. Poof, no mac
address to validate that key I generated during the install…
Hence my desire to find something reasonably simple that is likely to be
around, even if the cable is unplugged, or the machine has two network cards
and the user never remembers which one he used last time. (Another problem
that I’ve had.) Dongles are just sooo much simpler… 
Now, if I knew a way to reliably find the same mac address every time, even
with the network adapter powered down…
I think I’ll play with the GetVolumeNameForVolumeMountPoint call you mention
and see what sort of results I get from it. Maybe that will be ‘good
enough’.
The target here isn’t to try to stop dedicated hackers from using the
product for free. A dedicated hacker can get around *any* security if they
have an executable copy of the code, even if it is hardware protected. The
idea is to preserve a small revenue stream by making it somewhat difficult
for Joe User to buy one copy of the program for 20 bucks and then put it on
every machine he has, and also give it to all of his friends for free, and
upload it to a ‘free audio toolz’ site for everyone else to download for
free. The idea is to make it so Joe User finds it easier to just shell out
another 20 bucks (or 15 if he registered, and so gets a discount) than to
try to hack the machine or program to get around the protection. Or just
buy a dongle for 30 bucks and use it anywhere without more hassle.
Loren
----- Original Message -----
From: “Ray Trent”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, June 02, 2005 5:30 PM
Subject: Re:[ntdev] Getting the Windows ProductId string from UM
> Well, unless the machine happens to have a TPM, there isn’t really any
> secure way to do this even if you can find such a unique id. But as long
> as true security isn’t the goal…
>
> It’s too bad you don’t like the (lowest of the) MAC address(es) of the
> network adaptor(s) as a unique key. It’s about as good as it gets when
> it comes to widely present non-(easily-)user-changeable globally unique
IDs.
>
> If the disk the software is installed on has a SCSI MMC-3 logical unit
> serial number that’s another good one. ATA volume serial numbers can be
> reasonable too (though not guaranteed to be unique, they’re “pretty”
> unique). Again, like MAC addresses, people can (with sufficient effort)
> change these with AFAIK no ill effects by writing a very simple filter
> driver.
>
> If you’re just looking for a unique id that isn’t particularly secure
> (not sure why that would help), there’s the mount manager’s volume GUID
> for the disk the software is installed on, which can be retrieved with
> GetVolumeNameForVolumeMountPoint.
>
> It’s too bad there exist boot-time defragmenters, or the disk layout of
> your executable (suitably marked as “unmovable” would be pretty
> unique.
>
> The activation key (on XP) or product key won’t work, though, because
> volume licensed Windows (not just MSDN, but most corporate copies)
> aren’t individually activated and all have the same product key. Also,
> you can set the product key with a WMI interface (or probably just
> change it in the registry), and while that might screw up activation on
> XP, it won’t do squat on 2k AFAIK.
>
> Loren Wilton wrote:
> >>If your product really needs dongle protection, then you will have to
> >>resort to a dongle.
> >
> >
> > The higher-end versions need dongle protection, and have a dongle. Much
as
> > both the users and I dislike dongles.
> >
> > The low-end product won’t bear the cost of a dongle in the basic price,
> > although one is available as an extra-cost option to let the program run
on
> > any machine with the dongle plugged in. Without a dongle, the program
> > should only run on some single machine, at least in theory. That is the
> > problem I’m trying to solve at the moment.
> >
> > Now XP & friends have the product activation key. We all know that the
dev
> > keys are reasonably common and may show up on multiple machines. But
I’m
> > not real concerned about that case; people owning copies of MSDN are
> > unlikely to be my customers for this product, in general.
> >
> > In theory, although perhaps not in practice, shrinkwrap XP is supposed
to
> > have a separate activation key for every copy. Is that key stored
someplace
> > on the machine where it is accessible, even in an encrypted form? Seems
> > that might pretty much do what I want, possibly in a corporate
> > mass-distribution case (not that that is a likely target for my
products.)
> >
> > Loren
> >
> >
>
> –
> …/ray..
>
> Please remove “.spamblock” from my email address if you need to contact
> me outside the newsgroup.
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@earthlink.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com