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

[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] m> wrote in message
news:jr******** *************** *********@4ax.c om...

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*********@gma il.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.*******@worl dnet.att.net.in valid> wrote:

On Wed, 17 Nov 2004 12:17:23 -0600, Lauren Wilson <[e-mail] m>
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.o rg.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*********@gma il.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.net com.com> wrote:

On Wed, 17 Nov 2004 12:17:23 -0600, Lauren Wilson <[e-mail] m>
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.