Looking for ways to generate unique ids for a user's PC

[Lauren Wilson]

Does anyone know how the following info is extracted from the user's
computer by a Front Page form?

HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system. If I had a DLL that could allow VBA calls to a
function that would extract the same info from the user's computer, I
could use the info to craft a unique id (or at least a less common id)
for part of the encrypted serial code.

Front Page has a form option that will send the above info back to the
form owner when someone clicks submit. I'd simply like to know if
anyone has or knows of a DLL that will extract the same info or, even
better, hardware ids (hard disks, CD/DVD, Mac Address, etc) from the
user's PC.

Of course there are many PCs out there that can generate the same info
as this because they have the same stuff installed. But this gets the
idea across (I hope).

Thanks large for any advice you folks can offer.

--LW

[Alan Webb]

Lauren,
It's called Systems Management Server, comes from Microsoft, and costs a
bunch. It isn't just a DLL, it's a whole big add-on to Windows NT 4.0
Server and later. When we needed to inventory 300 or so computers for a Y2K
project the cheapest, easiest way we came up with is use some API calls to
the operating system to gather as much as we could from Windows, enhanced
that with a batch file that ported screen dumps of info from built-in DOS
commands like NET to a text file, and just for the sake of due diligence,
used a utility from Compaq that would tell us about the machine as well.
All this got appended to a text file that I then had Word troll through to
pick out the data we wanted and transfer it to a database.
As for generating encrypted serial codes, I'd start with the MAC address of
the NIC. PII and later processors have a processor serial number available
to Windows (though it can be disabled in the CMOS settings of a machine).
Web browsers get this information from Windows, which has a bunch of API's
that will tell you about itself and the machine it is running on. I'd start
there.

"Lauren Wilson" <???@???.???> wrote in message
news:c8********************************@4ax.com...

Does anyone know how the following info is extracted from the user's
computer by a Front Page form?

HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system. If I had a DLL that could allow VBA calls to a
function that would extract the same info from the user's computer, I
could use the info to craft a unique id (or at least a less common id)
for part of the encrypted serial code.

Front Page has a form option that will send the above info back to the
form owner when someone clicks submit. I'd simply like to know if
anyone has or knows of a DLL that will extract the same info or, even
better, hardware ids (hard disks, CD/DVD, Mac Address, etc) from the
user's PC.

Of course there are many PCs out there that can generate the same info
as this because they have the same stuff installed. But this gets the
idea across (I hope).

Thanks large for any advice you folks can offer.

--LW

[Darryl Kerkeslager]

Try this code from Dev Ashish:

http://www.mvps.org/access/api/api0009.htm
Darryl Kerkeslager
"Lauren Wilson" <???@???.???> wrote:

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system.

[Trevor Best]

Lauren Wilson wrote:

Does anyone know how the following info is extracted from the user's
computer by a Front Page form?

HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

In ASP...
Request.ServerVariables("HTTP_USER_AGENT")

--
This sig left intentionally blank

[Lauren Wilson]

On Tue, 16 Nov 2004 08:27:52 -0500, "Darryl Kerkeslager"
<Ke*********@comcast.net> wrote:

Try this code from Dev Ashish:

http://www.mvps.org/access/api/api0009.htm
Darryl Kerkeslager
"Lauren Wilson" <???@???.???> wrote:

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system.

Thanks Darryl. This sounds like a good starting point. However, I
wonder how many users actually change the default computer name? And
what the hell IS the default computer name that Windows sets up
anyway? Do you know?

[Lauren Wilson]

On Tue, 16 Nov 2004 08:27:52 -0500, "Darryl Kerkeslager"
<Ke*********@comcast.net> wrote:

Try this code from Dev Ashish:

http://www.mvps.org/access/api/api0009.htm
Darryl Kerkeslager
"Lauren Wilson" <???@???.???> wrote:

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system.

Also, do you have any idea how I can retrieve the drive id that is
allegedly encoded in the Drive ROM? That id in combination with the
Machine name could produce an (almost) bulletproof unique ID.

[Darryl Kerkeslager]

I use this for my app because the computer name is set by the network admins
to bew unique, and will not be reset. If you are operating in a different
environment - like over the Internet, then this may not be what you need.

When you first set up a computer on XP, you are prompted to enter a new
computer name. Here is the informnation on re-setting the computer name to
identify the comnputer to the network for XP:

http://support.microsoft.com/kb/295017

However, for login, I use the Windows login. Again, I guess it depends on
your environment.

Unfortunately, I'm at the end of my tether with this.
Darryl Kerkeslager
"Lauren Wilson" <???@???.???> wrote in message
news:8u********************************@4ax.com...

On Tue, 16 Nov 2004 08:27:52 -0500, "Darryl Kerkeslager"
<Ke*********@comcast.net> wrote:

Try this code from Dev Ashish:

http://www.mvps.org/access/api/api0009.htm
Darryl Kerkeslager
"Lauren Wilson" <???@???.???> wrote:

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system.

Thanks Darryl. This sounds like a good starting point. However, I
wonder how many users actually change the default computer name? And
what the hell IS the default computer name that Windows sets up
anyway? Do you know?

Also, do you have any idea how I can retrieve the drive id that is
allegedly encoded in the Drive ROM? That id in combination with the
Machine name could produce an (almost) bulletproof unique ID.

[Bolt Upright]

Hi All,

Would a GUID work???

Check the following link...

http://support.microsoft.com/default...b;en-us;176790

Cheers and HTH
"Lauren Wilson" <???@???.???> wrote in message
news:c8********************************@4ax.com...

Does anyone know how the following info is extracted from the user's
computer by a Front Page form?

HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system. If I had a DLL that could allow VBA calls to a
function that would extract the same info from the user's computer, I
could use the info to craft a unique id (or at least a less common id)
for part of the encrypted serial code.

Front Page has a form option that will send the above info back to the
form owner when someone clicks submit. I'd simply like to know if
anyone has or knows of a DLL that will extract the same info or, even
better, hardware ids (hard disks, CD/DVD, Mac Address, etc) from the
user's PC.

Of course there are many PCs out there that can generate the same info
as this because they have the same stuff installed. But this gets the
idea across (I hope).

Thanks large for any advice you folks can offer.

--LW

[Lauren Wilson]

Wow Bolt! This just might be the ticket. Dang! I knew about those
GUIDs but I simply overlooked that obvious possibility. Thanks.
On Tue, 16 Nov 2004 18:50:06 -0500, "Bolt Upright"
<Bo*********@BH.com> wrote:

Hi All,

Would a GUID work???

Check the following link...

http://support.microsoft.com/default...b;en-us;176790

Cheers and HTH
"Lauren Wilson" <???@???.???> wrote in message
news:c8********************************@4ax.com.. .

Does anyone know how the following info is extracted from the user's
computer by a Front Page form?

HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system. If I had a DLL that could allow VBA calls to a
function that would extract the same info from the user's computer, I
could use the info to craft a unique id (or at least a less common id)
for part of the encrypted serial code.

Front Page has a form option that will send the above info back to the
form owner when someone clicks submit. I'd simply like to know if
anyone has or knows of a DLL that will extract the same info or, even
better, hardware ids (hard disks, CD/DVD, Mac Address, etc) from the
user's PC.

Of course there are many PCs out there that can generate the same info
as this because they have the same stuff installed. But this gets the
idea across (I hope).

Thanks large for any advice you folks can offer.

--LW

[Lauren Wilson]

OOPS! I spoke too soon! The text of this article, under "MORE
INFORMATION" is quoted as follows:

"The code below can be used to create a GUID in Visual Basic. The code
calls the CoCreateGuid API found in OLE32.DLL on Windows 95, Windows
98, Windows Me, Windows NT and Windows 2000. ..."

Geesh! Windows XP is conspicuously missing! Guess I'll need to dig a
bit deeper. Don't suppose you have something on the XP version do
you? Even if you don't, I thank you for your kind efforts.
On Tue, 16 Nov 2004 18:50:06 -0500, "Bolt Upright"
<Bo*********@BH.com> wrote:

Hi All,

Would a GUID work???

Check the following link...

http://support.microsoft.com/default...b;en-us;176790

Cheers and HTH
"Lauren Wilson" <???@???.???> wrote in message
news:c8********************************@4ax.com.. .

Does anyone know how the following info is extracted from the user's
computer by a Front Page form?

HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system. If I had a DLL that could allow VBA calls to a
function that would extract the same info from the user's computer, I
could use the info to craft a unique id (or at least a less common id)
for part of the encrypted serial code.

Front Page has a form option that will send the above info back to the
form owner when someone clicks submit. I'd simply like to know if
anyone has or knows of a DLL that will extract the same info or, even
better, hardware ids (hard disks, CD/DVD, Mac Address, etc) from the
user's PC.

Of course there are many PCs out there that can generate the same info
as this because they have the same stuff installed. But this gets the
idea across (I hope).

Thanks large for any advice you folks can offer.

--LW

[Bolt Upright]

I do have OLE32.DLL on my system (XP Pro SP2). I didn't specifically copy
that DLL or anything it's just there. I had this working in Access (O97)
under Win98 but I don't think I ever tested it under XP.

Well at least you may have another angle.

Many Cheers

"Lauren Wilson" <[e-mail]> wrote in message
news:jr********************************@4ax.com...

OOPS! I spoke too soon! The text of this article, under "MORE
INFORMATION" is quoted as follows:

"The code below can be used to create a GUID in Visual Basic. The code
calls the CoCreateGuid API found in OLE32.DLL on Windows 95, Windows
98, Windows Me, Windows NT and Windows 2000. ..."

Geesh! Windows XP is conspicuously missing! Guess I'll need to dig a
bit deeper. Don't suppose you have something on the XP version do
you? Even if you don't, I thank you for your kind efforts.
On Tue, 16 Nov 2004 18:50:06 -0500, "Bolt Upright"
<Bo*********@BH.com> wrote:

Hi All,

Would a GUID work???

Check the following link...

http://support.microsoft.com/default...b;en-us;176790

Cheers and HTH
"Lauren Wilson" <???@???.???> wrote in message
news:c8********************************@4ax.com. ..

Does anyone know how the following info is extracted from the user's
computer by a Front Page form?

HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system. If I had a DLL that could allow VBA calls to a
function that would extract the same info from the user's computer, I
could use the info to craft a unique id (or at least a less common id)
for part of the encrypted serial code.

Front Page has a form option that will send the above info back to the
form owner when someone clicks submit. I'd simply like to know if
anyone has or knows of a DLL that will extract the same info or, even
better, hardware ids (hard disks, CD/DVD, Mac Address, etc) from the
user's PC.

Of course there are many PCs out there that can generate the same info
as this because they have the same stuff installed. But this gets the
idea across (I hope).

Thanks large for any advice you folks can offer.

--LW

[Thug Passion]

> Does anyone know how the following info is extracted from the user's

computer by a Front Page form?
HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0
Sure. It's not extracted from the user's computer, but from the
browser. It comes across in a cookie, query string, or hidden form
field, as part of the request to the server. That's not splitting
hairs. The server gets it from the browers, which gets it from the
OS, but only certain things are available to the browser.
I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system. If I had a DLL that could allow VBA calls to a
function that would extract the same info from the user's computer, I
could use the info to craft a unique id (or at least a less common id)
for part of the encrypted serial code.

Well in that case it doesn't sound like you're talking about http
transfer and asp forms, but some kind of backend code in your system?

Could you explain how this works? I'd like to make sure my personal
firewall stops sh!t like this.

Thanks.

[Lauren Wilson]

On 16 Nov 2004 20:47:34 -0800, Th*********@gmail.com (Thug Passion)
wrote:

Does anyone know how the following info is extracted from the user's
computer by a Front Page form?
HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

Sure. It's not extracted from the user's computer, but from the
browser. It comes across in a cookie, query string, or hidden form
field, as part of the request to the server. That's not splitting
hairs. The server gets it from the browers, which gets it from the
OS, but only certain things are available to the browser.

I only ask because I believe I could use the same info as part of a
scheme to generate a unique (or at least less common) serialized id
code for the user's computer as part of a software locking and
activation system. If I had a DLL that could allow VBA calls to a
function that would extract the same info from the user's computer, I
could use the info to craft a unique id (or at least a less common id)
for part of the encrypted serial code.

Well in that case it doesn't sound like you're talking about http
transfer and asp forms, but some kind of backend code in your system?

Could you explain how this works? I'd like to make sure my personal
firewall stops sh!t like this.

Thanks.

Thanks for your comments . I understand your concern. However in the
case I describe, it would purely be a function of a LOCAL program the
user has installed (an Access application). The ONLY reason I want to
do this is so I can generate a serial id code that is UNIQUE to the
user's PC. That code would then be used to generate an activation
code that would unlock the application (take it out of trial mode)
ONLY on the PC that generated the serialization code. As it now
stands, every serial code my app generates is the same on all machines
-- a risky approach. The user should not care that a unique code is
being generated for this purpose UNLESS he/she has perfidious
intentions -- which is precisely why we must worry about this in what
the world has become.

[Thug Passion]

> Thanks for your comments . I understand your concern. However in the

case I describe, it would purely be a function of a LOCAL program the
user has installed (an Access application). The ONLY reason I want to
Well, just so it's clear, my concern is that I spent $1,600 on a
computer, believe I own it, and don't like it to go talking to
mysterious servers without me knowing about it. ( A temp installed
some kind of Napster p2p thing on one of our workstations - and was
let go over it - which put all kinds of malware on the machine.
Collecting all kinds of data and sending it out.

It sounds like that's not what you're trying to do. If your customers
know about this then it's a different story.

Still, I'd appreciate if you wanted to send me an email on how this is
going to work, so I can make sure my security systems will stop it.
Your software can refuse to run when it can't reach your server, but I
have to control what goes across my network.
do this is so I can generate a serial id code that is UNIQUE to the
user's PC. That code would then be used to generate an activation
code that would unlock the application (take it out of trial mode)
You definately need unique for what you're trying to do, but does it
have to be unique and tied to the machine?
ONLY on the PC that generated the serialization code. As it now
So what happens if someone buys your software, and then upgrades their
computer? Wouldn't it be better - more equitable, and maybe easier -
to put a unique number in the product you distribute? Put a 30 byte
ID into a hidden system table, or a custom property somewhere in the
database, and then let that ID be activated only once by your server?
-- a risky approach. The user should not care that a unique code is
being generated for this purpose UNLESS he/she has perfidious
intentions -- which is precisely why we must worry about this in what
the world has become.

You'd be surprised at all the perfectly innocent reasons a user would
object to (a) their machine talking to somebody's server, (b) trusting
that you're only sending an ID number, and (c) "invasion of privacy"
and other concerns that aren't really an issue, except in the big,
abstract picture.

[Trevor Best]

Chuck Grimsby wrote:

<sarcasm>
Oh, sure... People *never* upgrade computers... Nor do they ever
change roles... Nah... Never happens...
</sarcasm>
I have about 15-25 licences for WinXP excluding the ones shipped with
laptops I have WinXP installed on about 4 PCs, I have no activations
left. I wouldn't mind activation so much if it were possible to
de-activate for a planned upgrade.
Think really, really, *REALLY* carefully about what you are doing.
Remember that although the program may be yours, the *DATA* never is.
Locking people out of their data is a sure way to find yourself in
court, or in a worse case scenario, behind bars! It's already
happened, do you want to be next?

Oh, and before someone suggests it, the courts don't care about "trial
mode". The data is *NEVER* yours. Period.

TBH if the data is in a back-end db then it's acessible, they have what
they own, their data. The means to present it in an effective way was
never theirs, it was the copyright/IPR owner's.

--
This sig left intentionally blank

[Lauren Wilson]

On Wed, 17 Nov 2004 23:14:46 GMT, Chuck Grimsby
<c.*******@worldnet.att.net.invalid> wrote:

On Wed, 17 Nov 2004 12:17:23 -0600, Lauren Wilson <[e-mail]>
wrote:

Thanks for your comments . I understand your concern. However in the
case I describe, it would purely be a function of a LOCAL program the
user has installed (an Access application). The ONLY reason I want to
do this is so I can generate a serial id code that is UNIQUE to the
user's PC. That code would then be used to generate an activation
code that would unlock the application (take it out of trial mode)
ONLY on the PC that generated the serialization code. As it now
stands, every serial code my app generates is the same on all machines
-- a risky approach. The user should not care that a unique code is
being generated for this purpose UNLESS he/she has perfidious
intentions -- which is precisely why we must worry about this in what
the world has become.
<sarcasm>
Oh, sure... People *never* upgrade computers... Nor do they ever
change roles... Nah... Never happens...
</sarcasm>

We've already encountered this situation many times. We simply give
them a new unlock code for the MDE front end.
Think really, really, *REALLY* carefully about what you are doing.
Believe me, we have.
Remember that although the program may be yours, the *DATA* never is.
Locking people out of their data is a sure way to find yourself in
court, or in a worse case scenario, behind bars! It's already
happened, do you want to be next?
The data is NEVER locked. It all resides in an UNLOCKED back end data
base. They ALWAYS have access to it (assuming the have Access
installed)
Oh, and before someone suggests it, the courts don't care about "trial
mode". The data is *NEVER* yours. Period.
Agreed. See above.
If you want to go through with this, and I'm not saying you shouldn't
or can't, just make sure you have a support plan in place. And
remember that "no one in the 70's and 80's thought that their program
would still be in use in the year 2000." Just a slight
miscalculation....

This one is going on five years and shows no sign of ending any time
soon.

Thanks for your insight.

[Lauren Wilson]

On Thu, 18 Nov 2004 08:24:02 +0000, Trevor Best <no****@besty.org.uk>
wrote:

Chuck Grimsby wrote:

<sarcasm>
Oh, sure... People *never* upgrade computers... Nor do they ever
change roles... Nah... Never happens...
</sarcasm>

I have about 15-25 licences for WinXP excluding the ones shipped with
laptops I have WinXP installed on about 4 PCs, I have no activations
left. I wouldn't mind activation so much if it were possible to
de-activate for a planned upgrade.

A license transfer procedure is what we're implementing right now.
That will save us the trouble of re-activating it on a new or
drastically modified machine.

Think really, really, *REALLY* carefully about what you are doing.
Remember that although the program may be yours, the *DATA* never is.
Locking people out of their data is a sure way to find yourself in
court, or in a worse case scenario, behind bars! It's already
happened, do you want to be next?

Oh, and before someone suggests it, the courts don't care about "trial
mode". The data is *NEVER* yours. Period.

TBH if the data is in a back-end db then it's acessible, they have what
they own, their data. The means to present it in an effective way was
never theirs, it was the copyright/IPR owner's.

Exactly.

[Lauren Wilson]

On 17 Nov 2004 18:46:43 -0800, Th*********@gmail.com (Thug Passion)
wrote:

Thanks for your comments . I understand your concern. However in the
case I describe, it would purely be a function of a LOCAL program the
user has installed (an Access application). The ONLY reason I want to
Well, just so it's clear, my concern is that I spent $1,600 on a
computer, believe I own it, and don't like it to go talking to
mysterious servers without me knowing about it.

I completely agree. The user should NEVER be in the dark about when
and for how long their PC is communicating with ANY other machine or
server.
( A temp installed some kind of Napster p2p thing on one of our workstations - and was
let go over it - which put all kinds of malware on the machine.
Collecting all kinds of data and sending it out.
And we all know what happened to Napster.
It sounds like that's not what you're trying to do. If your customers
know about this then it's a different story.

Still, I'd appreciate if you wanted to send me an email on how this is
going to work, so I can make sure my security systems will stop it.
Your software can refuse to run when it can't reach your server, but I
have to control what goes across my network.
We don't use server based activation. It's ALL done locally and by
email for retrieving an activation code that the user manually pastes
into the activation form after copying it from an email.

do this is so I can generate a serial id code that is UNIQUE to the
user's PC. That code would then be used to generate an activation
code that would unlock the application (take it out of trial mode)

You definately need unique for what you're trying to do, but does it
have to be unique and tied to the machine?

Well yes it does because our license is for ONE PC, unless they
purchase the multi-user LAN upgrade. Stand alone copies 2 - ? are
also available a fraction of the full price for each additional copy.

ONLY on the PC that generated the serialization code. As it now

So what happens if someone buys your software, and then upgrades their
computer?

They get a new unlock code for the new/upgraded PC. This happens all
the time.
Wouldn't it be better - more equitable, and maybe easier -
to put a unique number in the product you distribute?
I have often wondered about how I could implement such a procedure.
The program would need to generate and store its own unique ID as soon
as it is installed. I just have not yet figured out how the
incorporate that approach into the locking system. I do NOT want to
distribute more than one version of the program -- for obvious
reasons.
Put a 30 byte ID into a hidden system table, or a custom property somewhere in the
database, and then let that ID be activated only once by your server?

Hmmm. This idea has possibilities. Thanks.

-- a risky approach. The user should not care that a unique code is
being generated for this purpose UNLESS he/she has perfidious
intentions -- which is precisely why we must worry about this in what
the world has become.

You'd be surprised at all the perfectly innocent reasons a user would
object to (a) their machine talking to somebody's server, (b) trusting
that you're only sending an ID number, and (c) "invasion of privacy"
and other concerns that aren't really an issue, except in the big,
abstract picture.

Correct. That's why we don't use server dependent activation.

[Lauren Wilson]

On Thu, 18 Nov 2004 06:25:19 GMT, Dennis Lee Bieber
<wl*****@ix.netcom.com> wrote:

On Wed, 17 Nov 2004 12:17:23 -0600, Lauren Wilson <[e-mail]>
declaimed the following in comp.databases.ms-access:

Thanks for your comments . I understand your concern. However in the
case I describe, it would purely be a function of a LOCAL program the
user has installed (an Access application). The ONLY reason I want to
do this is so I can generate a serial id code that is UNIQUE to the
user's PC. That code would then be used to generate an activation
code that would unlock the application (take it out of trial mode)
ONLY on the PC that generated the serialization code. As it now
stands, every serial code my app generates is the same on all machines
-- a risky approach. The user should not care that a unique code is
being generated for this purpose UNLESS he/she has perfidious
intentions -- which is precisely why we must worry about this in what
the world has become.
Well, theoretically, the MAC address of a NIC is unique...

Yes there is a way to do that but it would be blown away if the user
had to replace his NIC. Also, many users don't HAVE a NIC and have no
need for one.
I think there is some way to obtain that.

Otherwise you are trying to duplicate what WinXP itself does --
using a mix of processor ID, monitor type, drive IDs, etc... and shuts
down if too many of these identifiers have changed..

I would LOVE to have some code that would retrieve the drive ID from
the drive's ROM. Do you have any?

[Forrest]

> I would LOVE to have some code that would retrieve the drive ID from

the drive's ROM. Do you have any?

For what you want to do, you really need something better than Access.

How does your activation work? How does your program know whether
it's legit or not, whether it should run? If you're using Access/VBA,
I'm guessing you've got a key stored in a db table, and a function
that calculates a new key and compares them?

You can hold the shift key when you load an Access database and bypass
any startup code. You probably know that, and built your copy
protection in deeper than when the app is started. With some tools
like a good object browser and spy++ you can get at the return value
of a function when it runs. MDE code is sort of "half-compiled."

If you're that concerned about building a secure copy protection
system, I wouldn't trust it to an Access app.

[Pieter Linden]

> I would LOVE to have some code that would retrieve the drive ID from

the drive's ROM. Do you have any?

Just wondering, but did you check with Randy Birch at vbnet? Maybe this article...
http://vbnet.mvps.org/

" Obtaining Disk Drive Information using WMI"

[Lauren Wilson]

Thanks Forrest. At your convenience, please see imbedded
comments/questions below.

On 18 Nov 2004 20:31:49 -0800, Va************@gmail.com (Forrest)
wrote:

I would LOVE to have some code that would retrieve the drive ID from
the drive's ROM. Do you have any?
For what you want to do, you really need something better than Access.

How does your activation work? How does your program know whether
it's legit or not, whether it should run? If you're using Access/VBA,
I'm guessing you've got a key stored in a db table, and a function
that calculates a new key and compares them?

Nope. It's all done by encrypted DLLs. I dare not reveal much more
detail than that in a public forum.
You can hold the shift key when you load an Access database and bypass
any startup code.
We thwart that action by setting the "AllowBypassKey" property to
false before compiling the MDE. It seems to work just fine -- for
about 5 years so far. But that could change overnight due to the
never ending supply of looters spawned by the human world.
You probably know that, and built your copy protection in deeper than when the app is started.
With some tools like a good object browser and spy++ you can get at the return value
of a function when it runs. MDE code is sort of "half-compiled."
Yes. However, anyone who is that determined, will probably get it
anyway, short of 1024 encryption. That's so incredibly rare that it
won't make us or break us (I THINK!). In any case, part of our
product is world class support -- which ONLY happens for properly
registered users. IOW -- our customers don't just by a program, they
buy US. It's actually a SERVICE that happens to be implemented
through a piece of software. Thus, getting an illegal copy of the
program would not be too useful to legitimate users. That does not
keep us from trying to make it more secure anyway. After all,
intellectual property Rights are the foundation for ALL other Rights.
If you're that concerned about building a secure copy protection
system, I wouldn't trust it to an Access app.

I'm sure this is good advice. Since this IS an Access forum, I
assumed this was the place where I would see the most possible good
advice about that product. Thus far, that has been my experience.
This is an AWESOME group. I wish I had more time to contribute more
than I do.

Despite the power of Access, we STILL look for better options. For
about two years we've agonized over what might be a more secure, but
equally flexible platform to move to. ALL of the platforms have
various strengths and weaknesses. If you have advice on a good
alternate platform choice, I'm all ears.

It's really hard to imagine moving to a platform that is more rapidly
adaptable to dynamic business realities than Access. Access forms
alone make it one of the most powerful programming environments I've
been exposed to in 25 years as an IT specialist. I might be mistaken,
but my impression is that C++, VisualC, VB.Net, et.al, are NOT as
flexible as Access VBA and Access forms combined with an imbedded
database engine. We routinely respond to good improvement ideas from
users within DAYS instead of months or years. We are able to do that
because of the Access environment.

If you know of another, equally robust but more secure programming
platform to use, please say so. Even after 25 years in IT, hardly a
day passes when I fail to learn something new and exciting that we can
do with Access. Of course, we're always willing to be persuaded
otherwise.

In the mean time, I strongly believe that if I could latch onto some
code that would retrieve the user's local hardware id, or even a GUID
procedure for XP, we could dramatically improve the security we
already have. Please correct me if I am wrong. Earlier in this
thread, someone pointed me to a GUID generator that works with all MS
OS's EXCEPT XP. About 98% of our users are on XP.

Thanks for your contribution Forrest (love your name).

--LW

[Lauren Wilson]

On 18 Nov 2004 21:04:39 -0800, pi********@hotmail.com (Pieter Linden)
wrote:

I would LOVE to have some code that would retrieve the drive ID from
the drive's ROM. Do you have any?

Just wondering, but did you check with Randy Birch at vbnet? Maybe this article...
http://vbnet.mvps.org/

" Obtaining Disk Drive Information using WMI"

Thanks a LOT Pieter. I looked at the site. It's very cool.
Unfortunately, I'm not sure how adaptable VB.Net code is for a VBA
environment. I do believe that retrieving the user's "Smart IDE"
serial number would be very useful for my purpose. Do you know how
much trouble it is to adapt VB.net code for VBA? Also, I'm not a
hardware person. How common is "Smart IDE" on PCs that are no older
than four years?

[Bolt Upright]

Hi,

Here's another idea...

Define a table to contain:
an autonumber field set to replication id
a text field

Adding and data to the text field will create a replication id (GUID) in
the autonumber field. Perhaps you can use this???

Cheers Again
"Lauren Wilson" <[e-mail]> wrote in message
news:pt********************************@4ax.com...

Thanks Forrest. At your convenience, please see imbedded
comments/questions below.

On 18 Nov 2004 20:31:49 -0800, Va************@gmail.com (Forrest)
wrote:

I would LOVE to have some code that would retrieve the drive ID from
the drive's ROM. Do you have any?

For what you want to do, you really need something better than Access.

How does your activation work? How does your program know whether
it's legit or not, whether it should run? If you're using Access/VBA,
I'm guessing you've got a key stored in a db table, and a function
that calculates a new key and compares them?

Nope. It's all done by encrypted DLLs. I dare not reveal much more
detail than that in a public forum.

You can hold the shift key when you load an Access database and bypass
any startup code.

We thwart that action by setting the "AllowBypassKey" property to
false before compiling the MDE. It seems to work just fine -- for
about 5 years so far. But that could change overnight due to the
never ending supply of looters spawned by the human world.

You probably know that, and built your copy protection in deeper than when
the app is started.
With some tools like a good object browser and spy++ you can get at the
return value
of a function when it runs. MDE code is sort of "half-compiled."

Yes. However, anyone who is that determined, will probably get it
anyway, short of 1024 encryption. That's so incredibly rare that it
won't make us or break us (I THINK!). In any case, part of our
product is world class support -- which ONLY happens for properly
registered users. IOW -- our customers don't just by a program, they
buy US. It's actually a SERVICE that happens to be implemented
through a piece of software. Thus, getting an illegal copy of the
program would not be too useful to legitimate users. That does not
keep us from trying to make it more secure anyway. After all,
intellectual property Rights are the foundation for ALL other Rights.

If you're that concerned about building a secure copy protection
system, I wouldn't trust it to an Access app.

I'm sure this is good advice. Since this IS an Access forum, I
assumed this was the place where I would see the most possible good
advice about that product. Thus far, that has been my experience.
This is an AWESOME group. I wish I had more time to contribute more
than I do.

Despite the power of Access, we STILL look for better options. For
about two years we've agonized over what might be a more secure, but
equally flexible platform to move to. ALL of the platforms have
various strengths and weaknesses. If you have advice on a good
alternate platform choice, I'm all ears.

It's really hard to imagine moving to a platform that is more rapidly
adaptable to dynamic business realities than Access. Access forms
alone make it one of the most powerful programming environments I've
been exposed to in 25 years as an IT specialist. I might be mistaken,
but my impression is that C++, VisualC, VB.Net, et.al, are NOT as
flexible as Access VBA and Access forms combined with an imbedded
database engine. We routinely respond to good improvement ideas from
users within DAYS instead of months or years. We are able to do that
because of the Access environment.

If you know of another, equally robust but more secure programming
platform to use, please say so. Even after 25 years in IT, hardly a
day passes when I fail to learn something new and exciting that we can
do with Access. Of course, we're always willing to be persuaded
otherwise.

In the mean time, I strongly believe that if I could latch onto some
code that would retrieve the user's local hardware id, or even a GUID
procedure for XP, we could dramatically improve the security we
already have. Please correct me if I am wrong. Earlier in this
thread, someone pointed me to a GUID generator that works with all MS
OS's EXCEPT XP. About 98% of our users are on XP.

Thanks for your contribution Forrest (love your name).

--LW

[VRWC]

What an awesome idea Bolt! I'm embarrassed that >>> I <<< did not
think of it. I probably did not think of it because I have NEVER had
occasion to use the replication features of Access.

So, you are saying that a replication id is functionally equal to a
GUID -- correct?
On Fri, 19 Nov 2004 16:11:01 -0500, "Bolt Upright"
<Bo*********@BH.com> wrote:

Hi,

Here's another idea...

Define a table to contain:
an autonumber field set to replication id
a text field

Adding and data to the text field will create a replication id (GUID) in
the autonumber field. Perhaps you can use this???

Cheers Again
"Lauren Wilson" <[e-mail]> wrote in message
news:pt********************************@4ax.com.. .

Thanks Forrest. At your convenience, please see imbedded
comments/questions below.

On 18 Nov 2004 20:31:49 -0800, Va************@gmail.com (Forrest)
wrote:

I would LOVE to have some code that would retrieve the drive ID from
the drive's ROM. Do you have any?

For what you want to do, you really need something better than Access.

How does your activation work? How does your program know whether
it's legit or not, whether it should run? If you're using Access/VBA,
I'm guessing you've got a key stored in a db table, and a function
that calculates a new key and compares them?

Nope. It's all done by encrypted DLLs. I dare not reveal much more
detail than that in a public forum.

You can hold the shift key when you load an Access database and bypass
any startup code.

We thwart that action by setting the "AllowBypassKey" property to
false before compiling the MDE. It seems to work just fine -- for
about 5 years so far. But that could change overnight due to the
never ending supply of looters spawned by the human world.

You probably know that, and built your copy protection in deeper than when
the app is started.
With some tools like a good object browser and spy++ you can get at the
return value
of a function when it runs. MDE code is sort of "half-compiled."

Yes. However, anyone who is that determined, will probably get it
anyway, short of 1024 encryption. That's so incredibly rare that it
won't make us or break us (I THINK!). In any case, part of our
product is world class support -- which ONLY happens for properly
registered users. IOW -- our customers don't just by a program, they
buy US. It's actually a SERVICE that happens to be implemented
through a piece of software. Thus, getting an illegal copy of the
program would not be too useful to legitimate users. That does not
keep us from trying to make it more secure anyway. After all,
intellectual property Rights are the foundation for ALL other Rights.

If you're that concerned about building a secure copy protection
system, I wouldn't trust it to an Access app.

I'm sure this is good advice. Since this IS an Access forum, I
assumed this was the place where I would see the most possible good
advice about that product. Thus far, that has been my experience.
This is an AWESOME group. I wish I had more time to contribute more
than I do.

Despite the power of Access, we STILL look for better options. For
about two years we've agonized over what might be a more secure, but
equally flexible platform to move to. ALL of the platforms have
various strengths and weaknesses. If you have advice on a good
alternate platform choice, I'm all ears.

It's really hard to imagine moving to a platform that is more rapidly
adaptable to dynamic business realities than Access. Access forms
alone make it one of the most powerful programming environments I've
been exposed to in 25 years as an IT specialist. I might be mistaken,
but my impression is that C++, VisualC, VB.Net, et.al, are NOT as
flexible as Access VBA and Access forms combined with an imbedded
database engine. We routinely respond to good improvement ideas from
users within DAYS instead of months or years. We are able to do that
because of the Access environment.

If you know of another, equally robust but more secure programming
platform to use, please say so. Even after 25 years in IT, hardly a
day passes when I fail to learn something new and exciting that we can
do with Access. Of course, we're always willing to be persuaded
otherwise.

In the mean time, I strongly believe that if I could latch onto some
code that would retrieve the user's local hardware id, or even a GUID
procedure for XP, we could dramatically improve the security we
already have. Please correct me if I am wrong. Earlier in this
thread, someone pointed me to a GUID generator that works with all MS
OS's EXCEPT XP. About 98% of our users are on XP.

Thanks for your contribution Forrest (love your name).

--LW

[Lauren Wilson]

========
What an awesome idea Bolt! I'm embarrassed that >>> I <<< did not
think of it. I probably did not think of it because I have NEVER had
occasion to use the replication features of Access.

So, you are saying that a replication id is functionally equal to a
GUID -- correct?
On Fri, 19 Nov 2004 16:11:01 -0500, "Bolt Upright"
<Bo*********@BH.com> wrote:

Hi,

Here's another idea...

Define a table to contain:
an autonumber field set to replication id
a text field

Adding and data to the text field will create a replication id (GUID) in
the autonumber field. Perhaps you can use this???

Cheers Again
"Lauren Wilson" <[e-mail]> wrote in message
news:pt********************************@4ax.com.. .

Thanks Forrest. At your convenience, please see imbedded
comments/questions below.

On 18 Nov 2004 20:31:49 -0800, Va************@gmail.com (Forrest)
wrote:

I would LOVE to have some code that would retrieve the drive ID from
the drive's ROM. Do you have any?

For what you want to do, you really need something better than Access.

How does your activation work? How does your program know whether
it's legit or not, whether it should run? If you're using Access/VBA,
I'm guessing you've got a key stored in a db table, and a function
that calculates a new key and compares them?

Nope. It's all done by encrypted DLLs. I dare not reveal much more
detail than that in a public forum.

You can hold the shift key when you load an Access database and bypass
any startup code.

We thwart that action by setting the "AllowBypassKey" property to
false before compiling the MDE. It seems to work just fine -- for
about 5 years so far. But that could change overnight due to the
never ending supply of looters spawned by the human world.

You probably know that, and built your copy protection in deeper than when
the app is started.
With some tools like a good object browser and spy++ you can get at the
return value
of a function when it runs. MDE code is sort of "half-compiled."

Yes. However, anyone who is that determined, will probably get it
anyway, short of 1024 encryption. That's so incredibly rare that it
won't make us or break us (I THINK!). In any case, part of our
product is world class support -- which ONLY happens for properly
registered users. IOW -- our customers don't just by a program, they
buy US. It's actually a SERVICE that happens to be implemented
through a piece of software. Thus, getting an illegal copy of the
program would not be too useful to legitimate users. That does not
keep us from trying to make it more secure anyway. After all,
intellectual property Rights are the foundation for ALL other Rights.

If you're that concerned about building a secure copy protection
system, I wouldn't trust it to an Access app.

I'm sure this is good advice. Since this IS an Access forum, I
assumed this was the place where I would see the most possible good
advice about that product. Thus far, that has been my experience.
This is an AWESOME group. I wish I had more time to contribute more
than I do.

Despite the power of Access, we STILL look for better options. For
about two years we've agonized over what might be a more secure, but
equally flexible platform to move to. ALL of the platforms have
various strengths and weaknesses. If you have advice on a good
alternate platform choice, I'm all ears.

It's really hard to imagine moving to a platform that is more rapidly
adaptable to dynamic business realities than Access. Access forms
alone make it one of the most powerful programming environments I've
been exposed to in 25 years as an IT specialist. I might be mistaken,
but my impression is that C++, VisualC, VB.Net, et.al, are NOT as
flexible as Access VBA and Access forms combined with an imbedded
database engine. We routinely respond to good improvement ideas from
users within DAYS instead of months or years. We are able to do that
because of the Access environment.

If you know of another, equally robust but more secure programming
platform to use, please say so. Even after 25 years in IT, hardly a
day passes when I fail to learn something new and exciting that we can
do with Access. Of course, we're always willing to be persuaded
otherwise.

In the mean time, I strongly believe that if I could latch onto some
code that would retrieve the user's local hardware id, or even a GUID
procedure for XP, we could dramatically improve the security we
already have. Please correct me if I am wrong. Earlier in this
thread, someone pointed me to a GUID generator that works with all MS
OS's EXCEPT XP. About 98% of our users are on XP.

Thanks for your contribution Forrest (love your name).

--LW

[Bolt Upright]

Hi,

According to the Help they are the same thing. I have never used the
replication stuff either. I think I was looking at a 'random' auto number in
A2K a couple of years ago and remembered the possibility of different
options.

Have Fun!
"Lauren Wilson" <[e-mail]> wrote in message
news:9e********************************@4ax.com...

========
What an awesome idea Bolt! I'm embarrassed that >>> I <<< did not
think of it. I probably did not think of it because I have NEVER had
occasion to use the replication features of Access.

So, you are saying that a replication id is functionally equal to a
GUID -- correct?
On Fri, 19 Nov 2004 16:11:01 -0500, "Bolt Upright"
<Bo*********@BH.com> wrote:

Hi,

Here's another idea...

Define a table to contain:
an autonumber field set to replication id
a text field

Adding and data to the text field will create a replication id (GUID) in
the autonumber field. Perhaps you can use this???

Cheers Again
"Lauren Wilson" <[e-mail]> wrote in message
news:pt********************************@4ax.com. ..

Thanks Forrest. At your convenience, please see imbedded
comments/questions below.

On 18 Nov 2004 20:31:49 -0800, Va************@gmail.com (Forrest)
wrote:

> I would LOVE to have some code that would retrieve the drive ID from
> the drive's ROM. Do you have any?

For what you want to do, you really need something better than Access.

How does your activation work? How does your program know whether
it's legit or not, whether it should run? If you're using Access/VBA,
I'm guessing you've got a key stored in a db table, and a function
that calculates a new key and compares them?

Nope. It's all done by encrypted DLLs. I dare not reveal much more
detail than that in a public forum.

You can hold the shift key when you load an Access database and bypass
any startup code.

We thwart that action by setting the "AllowBypassKey" property to
false before compiling the MDE. It seems to work just fine -- for
about 5 years so far. But that could change overnight due to the
never ending supply of looters spawned by the human world.

You probably know that, and built your copy protection in deeper than
when
the app is started.
With some tools like a good object browser and spy++ you can get at the
return value
of a function when it runs. MDE code is sort of "half-compiled."

Yes. However, anyone who is that determined, will probably get it
anyway, short of 1024 encryption. That's so incredibly rare that it
won't make us or break us (I THINK!). In any case, part of our
product is world class support -- which ONLY happens for properly
registered users. IOW -- our customers don't just by a program, they
buy US. It's actually a SERVICE that happens to be implemented
through a piece of software. Thus, getting an illegal copy of the
program would not be too useful to legitimate users. That does not
keep us from trying to make it more secure anyway. After all,
intellectual property Rights are the foundation for ALL other Rights.

If you're that concerned about building a secure copy protection
system, I wouldn't trust it to an Access app.

I'm sure this is good advice. Since this IS an Access forum, I
assumed this was the place where I would see the most possible good
advice about that product. Thus far, that has been my experience.
This is an AWESOME group. I wish I had more time to contribute more
than I do.

Despite the power of Access, we STILL look for better options. For
about two years we've agonized over what might be a more secure, but
equally flexible platform to move to. ALL of the platforms have
various strengths and weaknesses. If you have advice on a good
alternate platform choice, I'm all ears.

It's really hard to imagine moving to a platform that is more rapidly
adaptable to dynamic business realities than Access. Access forms
alone make it one of the most powerful programming environments I've
been exposed to in 25 years as an IT specialist. I might be mistaken,
but my impression is that C++, VisualC, VB.Net, et.al, are NOT as
flexible as Access VBA and Access forms combined with an imbedded
database engine. We routinely respond to good improvement ideas from
users within DAYS instead of months or years. We are able to do that
because of the Access environment.

If you know of another, equally robust but more secure programming
platform to use, please say so. Even after 25 years in IT, hardly a
day passes when I fail to learn something new and exciting that we can
do with Access. Of course, we're always willing to be persuaded
otherwise.

In the mean time, I strongly believe that if I could latch onto some
code that would retrieve the user's local hardware id, or even a GUID
procedure for XP, we could dramatically improve the security we
already have. Please correct me if I am wrong. Earlier in this
thread, someone pointed me to a GUID generator that works with all MS
OS's EXCEPT XP. About 98% of our users are on XP.

Thanks for your contribution Forrest (love your name).

--LW

[Pieter Linden]

Lauren Wilson <[e-mail]> wrote in message news:<q8********************************@4ax.com>. ..

On 18 Nov 2004 21:04:39 -0800, pi********@hotmail.com (Pieter Linden)
wrote:

I would LOVE to have some code that would retrieve the drive ID from
the drive's ROM. Do you have any?

Just wondering, but did you check with Randy Birch at vbnet? Maybe this article...
http://vbnet.mvps.org/

" Obtaining Disk Drive Information using WMI"

Thanks a LOT Pieter. I looked at the site. It's very cool.
Unfortunately, I'm not sure how adaptable VB.Net code is for a VBA
environment. I do believe that retrieving the user's "Smart IDE"
serial number would be very useful for my purpose. Do you know how
much trouble it is to adapt VB.net code for VBA? Also, I'm not a
hardware person. How common is "Smart IDE" on PCs that are no older
than four years?

Umm... I beg your pardon? there isn't a *single* line of .NET code
there. Not a one. Absolutely *everything* is VB6 or lower. He even
says so. His website has been around since before VisualBasic.Net or
any of the other dot-NET technologies...

[Lauren Wilson]

On 19 Nov 2004 18:24:24 -0800, pi********@hotmail.com (Pieter Linden)
wrote:

Lauren Wilson <[e-mail]> wrote in message news:<q8********************************@4ax.com>. ..

On 18 Nov 2004 21:04:39 -0800, pi********@hotmail.com (Pieter Linden)
wrote:

>> I would LOVE to have some code that would retrieve the drive ID from
>> the drive's ROM. Do you have any?
>
>Just wondering, but did you check with Randy Birch at vbnet? Maybe this article...
>http://vbnet.mvps.org/
>
>" Obtaining Disk Drive Information using WMI"

Thanks a LOT Pieter. I looked at the site. It's very cool.
Unfortunately, I'm not sure how adaptable VB.Net code is for a VBA
environment. I do believe that retrieving the user's "Smart IDE"
serial number would be very useful for my purpose. Do you know how
much trouble it is to adapt VB.net code for VBA? Also, I'm not a
hardware person. How common is "Smart IDE" on PCs that are no older
than four years?

Umm... I beg your pardon? there isn't a *single* line of .NET code
there. Not a one. Absolutely *everything* is VB6 or lower. He even
says so. His website has been around since before VisualBasic.Net or
any of the other dot-NET technologies...

OOPS! Sorry. I misinterpreted all those "VBnet" labels. Thanks.

[David Schofield]

Hi
Note this doesn't work for SCSI drives (which in principle may not
have a hardware serial number). also not for older drives. Because of
increased security, some of the ways of generating unique ids are no
longer so useful, eg BIOS signatures. There are cases reported where
batches of PCs have been delivered with the same hardware IDs.

On a different branch of this mega-thread: there is more than one way
to make a GUID, the Access ones I have looked at were not uing the
time element. When people complained that GUIDs identified their NIC,
a revised format was also offered. The 1996 spec for guids is
explained here:
http://kruithof.xs4all.nl/guid-uuid-info.html
David