serial number (activation code)

[Peter Duniho]

I don't seed the error. The statement is correct in that a built-in MAC
address on *any* device that has one is without question supposed to be
unique.

That's the error right there. It is mostly true that the MAC address is
unique among default, manufacturer-assigned MAC addresses. But beyond
that, no uniqueness is assured.

I can take the MAC address that is assigned to some network device
(whether the default hardware-assigned address or some other address),
and assign that same MAC address to any other network device with a
configurable MAC address that I like. Nothing prevents me from doing so.

The build-in MAC address is assigned in unique way, but that does not in
any way ensure that the MAC address itself is unique. It only ensures
that it's unique among the set of MAC addresses assigned by hardware
manufacturers, which isn't a useful degree of uniqueness.

No ifs ands or buts about it. I do hope that's clear enough. I'm

*not* trying to argue that a very small number of manufacturers allow
you to change the built-in MAC address on a very small number of their
devices/cards; that ability seems to be dwindling tremendously as many
more devices now use MAC addresses.

I'm not clear on what you're trying to say there. If your assertion is
that the ability to override the default MAC address is limited, then
that assertion is wrong. Devices with configurable MAC addresses are
fairly common.

Further, it is codified in the IEEE MAC address standard that these
built-in addresses are unique. That's all I'm saying.

And as I said, even if you assume that the built-in addresses are
unique, that isn't relevant in this context.

Apparently it isn't that difficult to get the built-in MAC address for a
device. One way is on this page:

http://www.nthelp.com/NT6/change_mac_w2k.htm

Just clear the appropriate registry key then use the
Win32_NetworkAdapterConfiguration WMI class to retrieve the device's
built-in MAC address.

I would not call that a "standardized way to get the hardware's default
MAC address".

Not pretty, but it would work. Not that I believe

any of this to be very user-friendly in a license management system,
mind you.

No, and as a matter of fact if I ran into any software that fiddled with
my configured MAC address for any reason without my consent, I would
immediately insist on a refund of whatever I'd paid for such software.

This is, in fact, the underlying basis for everything I've written in
this thread: a copy protection scheme based on the MAC address is a bad
idea. There is no reliable way to obtain a unique MAC address in a
useful way for copy protection.

Pete

 

[G.Doten]

That's the error right there. It is mostly true that the MAC address is
unique among default, manufacturer-assigned MAC addresses. But beyond
that, no uniqueness is assured.

You aren't making sense. The standard for MAC addresses is that any
device given one is given a unique one. That is the standard for each
and every device manufactured. Do we live in a perfect world? Nope. So
manufacturers have screwed up. Look, it is in no way incorrect for me or
anyone else to say that a MAC address is supposed to be unique. They are
and to say otherwise is misleading and wrong.

I can take the MAC address that is assigned to some network device
(whether the default hardware-assigned address or some other address),
and assign that same MAC address to any other network device with a
configurable MAC address that I like. Nothing prevents me from doing so.

That has already clearly been established. I hope you didn't read
anything into what I said as being contrary to what you just reiterated.

The build-in MAC address is assigned in unique way, but that does not in
any way ensure that the MAC address itself is unique. It only ensures
that it's unique among the set of MAC addresses assigned by hardware
manufacturers, which isn't a useful degree of uniqueness.

No, the built-in MAC address is uniquely assigned to a device by a
manufacturer. Did you miss that each manufacturer is assigned a unique
range of numbers they can allocate? What this means is that no two
manufacturers can possibly assign the same MAC address to two or more
devices. Just can't happen.

No ifs ands or buts about it. I do hope that's clear enough. I'm

I'm not clear on what you're trying to say there. If your assertion is
that the ability to override the default MAC address is limited, then
that assertion is wrong. Devices with configurable MAC addresses are
fairly common.

I don't believe you are correct in that assertion. But whatever.

And as I said, even if you assume that the built-in addresses are
unique, that isn't relevant in this context.

Sure it's relevant. Manufacturers follow the IEEE MAC address standard
and that standard dictates uniqueness among all MAC addresses assigned
to each and every device made by a manufacturer. Please quote some
source that makes you think it is otherwise. This isn't an assumption,
it's how the device game is played, plain and simple.

Sure there is, it's called a device driver (for one way). Any
kernel-level code can easily prove a board to read the registers
containing the built-in MAC address. The easiest way to do that (that
I've so far been able to find) is the method I described in my previous
reply (below) which allows you to get at the built-in MAC address quite
easily and without having to write custom kernel-level code.

I would not call that a "standardized way to get the hardware's default
MAC address".

Why not? WMI is very standard. Or is WMI also a standard you don't
believe in like the IEEE MAC address standard?

No, and as a matter of fact if I ran into any software that fiddled with
my configured MAC address for any reason without my consent, I would
immediately insist on a refund of whatever I'd paid for such software.

Makes sense to me. I never did say that using a MAC address for license
enforcement is a good thing. In fact, I said quite the opposite in what
you just quoted.

This is, in fact, the underlying basis for everything I've written in
this thread: a copy protection scheme based on the MAC address is a bad
idea. There is no reliable way to obtain a unique MAC address in a
useful way for copy protection.

I don't think anyone is going to try and say that using the MAC address
from any device is a good way to do license enforcement, except maybe
the OP!

If your point is that standards have from time-to-time been misapplied
or otherwise mis-undertood then that goes pretty much without saying for
many, many standards. It's the nature of the beast. But when push comes
to shove sometimes you have to go by what the standard says and deal
with the bugs on an exception basis. An unfortunate fact, indeed.

 

[Peter Duniho]

You aren't making sense.

You aren't paying attention to what I wrote.

The standard for MAC addresses is that any

device given one is given a unique one.

That is the standard for how manufacturers assign the default MAC
address for a device. That is _not_ the standard for MAC address as
they are used in networks.

[...]

That has already clearly been established. I hope you didn't read
anything into what I said as being contrary to what you just reiterated.

Your implication that the uniqueness of MAC addresses as assigned by
manufacturers is somehow relevant to the MAC address a copy protection
scheme might look at does imply lack of knowledge of users setting MAC
addresses manually. However, thank you for clarifying that you don't
actually believe that.

No, the built-in MAC address is uniquely assigned to a device by a
manufacturer. Did you miss that each manufacturer is assigned a unique
range of numbers they can allocate? What this means is that no two
manufacturers can possibly assign the same MAC address to two or more
devices. Just can't happen.

It is true that "no two manufacturers can possibly assign the same MAC
address to two or more devices" (to the extent that manufacturers don't
screw up...they do, you know).

However, that's entirely irrelevant to the question of whether the MAC
address is unique in the context of a copy protection scheme. The copy
protection scheme does not have the luxury of only seeing the MAC
address that the manufacturer assigned.

Sure it's relevant. Manufacturers follow the IEEE MAC address standard
and that standard dictates uniqueness among all MAC addresses assigned
to each and every device made by a manufacturer. Please quote some
source that makes you think it is otherwise. This isn't an assumption,
it's how the device game is played, plain and simple.

You keep saying the same thing over and over again, even though I have
explained each time why it's not relevant to this context. It doesn't
_matter_ that the manufacturer assigns MAC addresses that are unique
with respect to any other manufacturer-assigned MAC address. Since the
manufacturer isn't the only entity assigning MAC addresses, and since
the other entities (specifically, users of network devices) are not
constrained by the uniqueness protocol that the manufacturers are, the
uniqueness protocol manufacturers follow doesn't matter.

Sure there is, it's called a device driver (for one way).

Do you mean "a device driver" as in, the application uses the public API
that the driver is required to support? If so, then no...that does not
guarantee that you are getting the manufacturer-assigned MAC address.

Do you mean "a device driver" as in, you write a device driver that
queries the hardware directly to get the MAC address? Is so, then
no...that does not qualify as a "standardized way", since you'd have to
have a custom device driver for each network device you intend to support.

Why not? WMI is very standard. Or is WMI also a standard you don't
believe in like the IEEE MAC address standard?

Well, for one, WMI is not providing a specific API to retrieve the MAC
address. The method you posted is essentially a hack, and like all
hacks it is not guaranteed to work in all situations.

The Windows API is a standard. That doesn't mean that any code I
implement using the Windows API is using a "standardized way" to do
something.

[...]

If your point is that standards have from time-to-time been misapplied
or otherwise mis-undertood then that goes pretty much without saying for
many, many standards. It's the nature of the beast. But when push comes
to shove sometimes you have to go by what the standard says and deal
with the bugs on an exception basis. An unfortunate fact, indeed.

No, my point is that from the point of view of an application running on
Windows, the MAC address is not guaranteed to be unique.

Pete

 

[Johnny Jörgensen]

Have a look at this - maybe that's something yoou can use:

http://www.codeproject.com/useritems/FingerPrint.asp

Cheers,
Johnny J.

 

[Johnny Jörgensen]

This is interesting. How would you do that? Do you have sample code?

Cheers,
Johnny J.

 

[G.Doten]

You aren't paying attention to what I wrote.

Sure am; you're just not making sense.

That is the standard for how manufacturers assign the default MAC
address for a device. That is _not_ the standard for MAC address as
they are used in networks.

Of course it is!

[...]

That has already clearly been established. I hope you didn't read
anything into what I said as being contrary to what you just reiterated.

Your implication that the uniqueness of MAC addresses as assigned by
manufacturers is somehow relevant to the MAC address a copy protection
scheme might look at does imply lack of knowledge of users setting MAC
addresses manually. However, thank you for clarifying that you don't
actually believe that.

Never said that; don't put words in my mouth.

It is true that "no two manufacturers can possibly assign the same MAC
address to two or more devices" (to the extent that manufacturers don't
screw up...they do, you know).

Yes, I know. I'm the one that introduced that fact into this thread.

However, that's entirely irrelevant to the question of whether the MAC
address is unique in the context of a copy protection scheme. The copy
protection scheme does not have the luxury of only seeing the MAC
address that the manufacturer assigned.

Sure, a license enforcement scheme can get at the built-in MAC address.
I've already posted a pointer to code that allows this. Is it a good
idea to this in a license enforcement scheme? I don't think so. But that
doesn't mean others haven't used it as a legitimate way to implement a
license enforcement scheme.

You keep saying the same thing over and over again, even though I have
explained each time why it's not relevant to this context. It doesn't
_matter_ that the manufacturer assigns MAC addresses that are unique
with respect to any other manufacturer-assigned MAC address. Since the
manufacturer isn't the only entity assigning MAC addresses, and since
the other entities (specifically, users of network devices) are not
constrained by the uniqueness protocol that the manufacturers are, the
uniqueness protocol manufacturers follow doesn't matter.

I have to keep repeating myself because you don't seem to hear what I'm
saying. Just because you claim something isn't relevant doesn't make it
so. It certainly does matter that a MAC address for a given device is
unique, in *fact* they are globally unique. Yes, barring screw-ups, as I
was the first one to point out. But in practice, that doesn't make the
IEEE MAC address standard any less effective in a license enforcement
scheme.

Do you mean "a device driver" as in, the application uses the public API
that the driver is required to support? If so, then no...that does not
guarantee that you are getting the manufacturer-assigned MAC address.

Do you mean "a device driver" as in, you write a device driver that
queries the hardware directly to get the MAC address? Is so, then
no...that does not qualify as a "standardized way", since you'd have to
have a custom device driver for each network device you intend to support.

A device driver can quite easily read the built-in MAC address from a
device. Higher level software standardizes the interface supplied so
that software, like that I've already posted pointers to, can read the
built-in MAC address. But this is really getting OT.

Well, for one, WMI is not providing a specific API to retrieve the MAC
address. The method you posted is essentially a hack, and like all
hacks it is not guaranteed to work in all situations.

Whatever. It still works.

The Windows API is a standard. That doesn't mean that any code I
implement using the Windows API is using a "standardized way" to do
something.

This doesn't make any sense at all!

[...]

If your point is that standards have from time-to-time been misapplied
or otherwise mis-undertood then that goes pretty much without saying
for many, many standards. It's the nature of the beast. But when push
comes to shove sometimes you have to go by what the standard says and
deal with the bugs on an exception basis. An unfortunate fact, indeed.

No, my point is that from the point of view of an application running on
Windows, the MAC address is not guaranteed to be unique.

True. But the built-in MAC address is globally unique and if desired
could be used in a license enforcement scheme. I still wouldn't
recommend it could be used but that doesn't change the facts of the
built-in MAC addresses' uniqueness.

Are we having fun yet?

 

[Peter Duniho]

G.Doten wrote:
[...]

True. But the built-in MAC address is globally unique and if desired
could be used in a license enforcement scheme. I still wouldn't
recommend it could be used but that doesn't change the facts of the
built-in MAC addresses' uniqueness.

So many words, so little new thoughts in the thread.

Perhaps a very simple example will clarify the problem for you:

On one of my computers, I generally run Windows XP in a VM. In that
instance of Windows there is only the virtualized network adapter, and
this virtualized network adapter _only_ has whatever MAC address I
assign it.

This is just an example. There are numbers of other ways that a network
device's MAC address may not be unique, but the important thing to
remember here is that there are a lot of things that can act as a
network adapter, having a MAC address, and which are not actually a
device manufactured in a way that causes the device to have a uniquely
assigned MAC address. They always have user-assigned MAC addresses
(either implicitly or explicitly), and there is no "low-level hardware
device MAC address" to obtain via a hack or other mechanism.

Furthermore, because of this class of network device, even those that
are manufactured with a uniquely assigned MAC address cannot be
guaranteed to actually have a unique MAC address, because the same MAC
address assigned to the hardware at the time of manufacture could be
used with one of the network devices not assigned a MAC address at the
time of manufacture, rendering the MAC address non-unique even though it
was theoretically selected in a unique manner at the time of manufacture.

There are plenty of other problems with the assertions you made in your
reply, but the fact is there's no need to address them at all. The
above is incontrovertible and invalidates any potential the MAC address
has as a unique identifier.

I presume that the software in question here requires network access to
operate correctly. But if not, there's another hole in the equation: if
the application does not itself ordinarily need a network adapter,
requiring that one be present simply so that the copy protection can
work is absurd.

Are we having fun yet?

Sorry...was this about your entertainment? My goal was simply to
discredit the incorrect idea that a program can rely on the MAC address
as a unique identifier in a reliable way. I do this not because it's
fun, but simply because it needs to be done.

Pete

 

[G.Doten]

G.Doten wrote:
[...]

True. But the built-in MAC address is globally unique and if desired
could be used in a license enforcement scheme. I still wouldn't
recommend it could be used but that doesn't change the facts of the
built-in MAC addresses' uniqueness.

So many words, so little new thoughts in the thread.

I have to keep repeating myself because you don't seem to understand
those words.

Perhaps a very simple example will clarify the problem for you:

I know what the issue is, but thanks anyway.

On one of my computers, I generally run Windows XP in a VM. In that
instance of Windows there is only the virtualized network adapter, and
this virtualized network adapter _only_ has whatever MAC address I
assign it.

So? Has nothing to do with the IEEE MAC addressing standard that *all*
manufacturers follow when creating a device.

This is just an example. There are numbers of other ways that a network
device's MAC address may not be unique, but the important thing to
remember here is that there are a lot of things that can act as a
network adapter, having a MAC address, and which are not actually a
device manufactured in a way that causes the device to have a uniquely
assigned MAC address. They always have user-assigned MAC addresses
(either implicitly or explicitly), and there is no "low-level hardware
device MAC address" to obtain via a hack or other mechanism.

I was the one who originally pointed out things such as radios using
MACs, etc. So many words, so little new content in this thread.

Furthermore, because of this class of network device, even those that
are manufactured with a uniquely assigned MAC address cannot be
guaranteed to actually have a unique MAC address, because the same MAC
address assigned to the hardware at the time of manufacture could be
used with one of the network devices not assigned a MAC address at the
time of manufacture, rendering the MAC address non-unique even though it
was theoretically selected in a unique manner at the time of manufacture.

Has nothing to do with IEEE MAC addressing standard for devices. How
many times are you going to repeat yourself?

There are plenty of other problems with the assertions you made in your
reply, but the fact is there's no need to address them at all. The
above is incontrovertible and invalidates any potential the MAC address
has as a unique identifier.

Incontrovertible? My, we really do think highly of ourself don't we?

I presume that the software in question here requires network access to
operate correctly. But if not, there's another hole in the equation: if
the application does not itself ordinarily need a network adapter,
requiring that one be present simply so that the copy protection can
work is absurd.

Stating the obvious.

Sorry...was this about your entertainment? My goal was simply to
discredit the incorrect idea that a program can rely on the MAC address
as a unique identifier in a reliable way. I do this not because it's
fun, but simply because it needs to be done.

Of course it's about my fun, otherwise I wouldn't be participating in
this forum! Think I'd be doing this if it wasn't? You keep repeating
yourself, and that makes me chuckle. You seem to relish in attempting to
put people down just for the hell of it and to *always* have the last
word, even though everyone already understands the issues and solutions.

The questions is: are *you* having fun? If not, I feel sorry for you!

One more time for those in the back: a built-in (implies a physical
device, don't you know) MAC address (they always follow the IEEE MAC
addressing standard) can certainly be used as a unique number. Is this
the best thing to do for a licensing enforcement scheme, probably not,
as you, I, and others have pointed out ad nauseum here.

 

[Peter Duniho]

I have to keep repeating myself because you don't seem to understand
those words.

I understand the words you write just fine. Your problem is that the
words you write aren't relevant to the question at hand.

However, your insistence on the matter seems intractable, and I have no
doubt that there is no one else left who is confused about the matter.
The points have been made as clear as they can be, and at this point I
see no need to wander around in circles repeating myself just because
you seem happy to do so as well.

So yes, you feel free to continue to entertain yourself however you
like. Your claim that a MAC address is reliably unique has been
sufficiently discredited, whether you like it or not, and so my work
here is done.

Thanks,
Pete

 

[G.Doten]

I understand the words you write just fine. Your problem is that the
words you write aren't relevant to the question at hand.

Of course they are. You just can't understand how they are relevant. I'm
happy to help you and keep repeating myself, though I'll vary the words
each time with a hope that some combination of such will get through to you.

However, your insistence on the matter seems intractable, and I have no
doubt that there is no one else left who is confused about the matter.
The points have been made as clear as they can be, and at this point I
see no need to wander around in circles repeating myself just because
you seem happy to do so as well.

There ya go, now you're learning! (Though it begs the question why you
have been going in circles this long.) Just as you are insistent on your
viewpoint, so am I with mine.

So yes, you feel free to continue to entertain yourself however you
like. Your claim that a MAC address is reliably unique has been
sufficiently discredited, whether you like it or not, and so my work
here is done.

Nice job, ya got there, zippy; I wouldn't want to have that job. I think
that if a poll could somehow be taken it would be your credibility that
has been discredited. For the record, what I like or don't like has
nothing to do with you or this discussion.

It is not a claim that the built-in MAC address assigned by
manufacturers of devices are unique, it's a fact in the IEEE MAC address
standard. You just keep telling yourself otherwise.

Now we're having fun.

 

[Jon Skeet [C# MVP]]

It is not a claim that the built-in MAC address assigned by
manufacturers of devices are unique, it's a fact in the IEEE MAC address
standard. You just keep telling yourself otherwise.

I don't think anyone's been disputing that, barring mistakes which
everyone acknowledges are possible. It's this bit that I believe Peter
disagrees with (and so do I):

<quote>
But the built-in MAC address is globally unique and if desired
could be used in a license enforcement scheme.
</quote>

The latter part is what I believe to be infeasible.

1) The web page you cited before regarding getting back the original
MAC address assumes that it can't be altered at the firmware level; I
believe that some network cards really let you set it pretty much as
deep as you want, in a way that will resist a generic way of retrieving
the factory config. (i.e. the device drivers would see the changed MAC
address - a device-specific factory reset might restore it, but that's
all)

2) Any licence enforcement scheme built on the MAC address would:

a) Potentially hack the user's registry, quite possibly breaking all
their network settings
b) Be ineffective on VMs
c) Prohibit changing network adapters
d) Be ineffective against network cards allowing MAC address changes
that device drivers can't detect

That makes such a licence scheme not only sub-optimal, but effectively
infeasible in my view.

 

[G.Doten]

I don't think anyone's been disputing that, barring mistakes which
everyone acknowledges are possible.

Peter has sure been disputing it. He just doesn't get it.

It's this bit that I believe Peter
disagrees with (and so do I):

<quote>
But the built-in MAC address is globally unique and if desired
could be used in a license enforcement scheme.
</quote>

The latter part is what I believe to be infeasible.

1) The web page you cited before regarding getting back the original
MAC address assumes that it can't be altered at the firmware level; I
believe that some network cards really let you set it pretty much as
deep as you want, in a way that will resist a generic way of retrieving
the factory config. (i.e. the device drivers would see the changed MAC
address - a device-specific factory reset might restore it, but that's
all)

2) Any licence enforcement scheme built on the MAC address would:

a) Potentially hack the user's registry, quite possibly breaking all
their network settings
b) Be ineffective on VMs
c) Prohibit changing network adapters
d) Be ineffective against network cards allowing MAC address changes
that device drivers can't detect

That makes such a licence scheme not only sub-optimal, but effectively
infeasible in my view.

Interesting points, Jon. Although I wonder if anyone can confirm #1
definitively. I have been assuming (from experience) that the built-in
MAC address is always accessible at least by kernel-level code. But I
will be the first to admit I don't know this to be a fact for all
devices. I'm happy to take your word on it.

I fully agree with #2. I have been a proponent of NOT using the MAC
addresses for licensing enforcement all along (I think I even started
this thread off with something like "OP, exactly which MAC address do
you wish to choose" meaning it ain't so simple as originally asked--then
Peter went all mental on me).

However, I've dealt with software that uses the MAC address (and not
necessarily the built-in one) in just this way. It's not a perfect
solution, but it is workable and companies have used it for these
purposes. Your 2c and 2d are not absolutes. The software I've used in
the dim past simply required you to reacquire a license key if you
changed your MAC address (whether physically or otherwise). Companies
have done far stranger things in their quest to enforce their licensing.
Doesn't mean I like it, agree with it, or would propose it as a solution
these days. Then again, I don't think license enforcement should go
beyond having a piece of paper (or PDF-type document) that says you
purchased the software under such-and-such terms. This phoning in to the
mother-ship stuff I think has very similar pitfalls as simply using a
MAC address does.

 

[Jon Skeet [C# MVP]]

Peter has sure been disputing it. He just doesn't get it.

Could you point out where he's disputed that very narrow part? He wrote
that there's no requirement for them to be unique, which I took to mean
"in order for networking to work".

Peter later wrote:

<quote>
While the hardware's default MAC address should always be globally
unique, this is not the MAC address that is necessarily being used.
</quote>

which goes along with the rest of how I read his posts.

Interesting points, Jon. Although I wonder if anyone can confirm #1
definitively. I have been assuming (from experience) that the built-in
MAC address is always accessible at least by kernel-level code. But I
will be the first to admit I don't know this to be a fact for all
devices. I'm happy to take your word on it.

Even if it's accessible by kernel level code, that's a level of
difficulty which is beyond what I'd say is reasonable, especially if it
needs to alter your network configuration in order to get there.

I fully agree with #2.

And that, I believe is what Peter has been trying to get at. It's a
really, really bad way of finding a unique number to use - sometimes it
won't even work, and other times it's incredibly inconvenient to the
user.

However, I've dealt with software that uses the MAC address (and not
necessarily the built-in one) in just this way.

Yup - and there is software you can download which is specifically to
get round it. Just because some company does something doesn't make it
feasible in a *useful* sense.

It's not a perfect solution, but it is workable and companies have
used it for these purposes.

I think it depends on what you deem "workable". In an age where VMs are
becoming ever more popular, I wouldn't count it as being workable.

Then again, I don't think license enforcement should go
beyond having a piece of paper (or PDF-type document) that says you
purchased the software under such-and-such terms. This phoning in to the
mother-ship stuff I think has very similar pitfalls as simply using a
MAC address does.

I don't personally mind a one-time validation. I don't think such
things are usually secure, of course, but I don't mind it from a
convenience point of view - especially if the delivery mechanism is the
internet to start with (so the vendor can assume network connectivity).

 

[G.Doten]

Could you point out where he's disputed that very narrow part? He wrote
that there's no requirement for them to be unique, which I took to mean
"in order for networking to work".

That's just one small bit of what he has written. However...

I don't believe he's said that because he has admitted that on an IP
segment, MACs with the same address won't work. Which means "networking
won't work." Hopefully no one at this point would dispute that.

Peter later wrote:

<quote>
While the hardware's default MAC address should always be globally
unique, this is not the MAC address that is necessarily being used.
</quote>

And I've not disputed that. Do you think that I have?

Even if it's accessible by kernel level code, that's a level of
difficulty which is beyond what I'd say is reasonable, especially if it
needs to alter your network configuration in order to get there.

Agreed. But it *is* possible. Desirable? No. Easy? No. I never said it
would be a reasonable technique, just a possible technique. I've seen
licensing schemes use far more difficult techniques, especially in the
pre-Internet-everywhere days.

And that, I believe is what Peter has been trying to get at. It's a
really, really bad way of finding a unique number to use - sometimes it
won't even work, and other times it's incredibly inconvenient to the
user.

Oh I know he's said that; and I've agreed each and every time.

What I don't fathom is his insistence that the things I've said are not
true. Especially the one about the IEEE MAC addressing standard.
Although I think he finally came around in his last couple of posts.
From "there's no such standard for built-in MACs" to "yeah there is but
they can be overridden." I think he knows damn well what I'm saying.

Yup - and there is software you can download which is specifically to
get round it. Just because some company does something doesn't make it
feasible in a *useful* sense.

But it is a technique that has been used, which pretty much makes it
feasible. For the 100th time: desirable? No!

I think it depends on what you deem "workable". In an age where VMs are
becoming ever more popular, I wouldn't count it as being workable.

I mean it in the sense that it has been used over and over as a license
enforcement technique. Should it have been, and should it be a technique
used now? Nope, not if it were my call. Just like I've been saying all
along. Yet Peter the mighty will tell you I "just don't get it."

I don't personally mind a one-time validation. I don't think such
things are usually secure, of course, but I don't mind it from a
convenience point of view - especially if the delivery mechanism is the
internet to start with (so the vendor can assume network connectivity).

Activation really sucks, IMO, almost to the point that I'd argue that
now *there's* a licensing scheme that is unworkable. Especially the
hardware hash technique that I understand Microsoft's product activation
to use (though I really don't know the details there). That technique is
fraught with problems, yet, just like with a scheme that utilizes a MAC
address, can be made workable. Again, desirable? No!

 

[Jon Skeet [C# MVP]]

That's just one small bit of what he has written. However...

I don't believe he's said that because he has admitted that on an IP
segment, MACs with the same address won't work. Which means "networking
won't work." Hopefully no one at this point would dispute that.

Indeed. There's a big difference between "unique on an IP segment" and
"globally unique" however. In particular, if someone wanted to pirate
some software to run behind their firewall and knew the MAC address of
someone who had a legit copy running behind *their* firewall, there's
no network requirement for those two machines to have different MAC
addresses.

And I've not disputed that. Do you think that I have?

No - I just think it runs counter to your argument that *Peter* has
been arguing against the uniqueness of vendor-assigned MAC addresses.

Agreed. But it *is* possible. Desirable? No. Easy? No. I never said it
would be a reasonable technique, just a possible technique. I've seen
licensing schemes use far more difficult techniques, especially in the
pre-Internet-everywhere days.

But these days *aren't* pre-Internet. What might have been usefully
feasible before isn't necessarily so now.

Put it this way: is a licence scheme which requires the licencee to
remember (without writing down) a 32 digit number, entered every time
they start the software, "feasible"? It's possible in the strictest
technical sense - but not feasible in any useful sense.

Oh I know he's said that; and I've agreed each and every time.

What I don't fathom is his insistence that the things I've said are not
true. Especially the one about the IEEE MAC addressing standard.

I still haven't seen where he said that isn't true - which is why I
asked for a specific quote.

Although I think he finally came around in his last couple of posts.
From "there's no such standard for built-in MACs" to "yeah there is but
they can be overridden." I think he knows damn well what I'm saying.

Where did he say there's no standard for built-in MACs? He's repeatedly
acknowledged that - but stated (and I agree with him) that that's
completely different from the MAC addresses which are *used* being
unique and standardised.

But it is a technique that has been used, which pretty much makes it
feasible. For the 100th time: desirable? No!

I think we disagree about the meaning of "feasible".

I mean it in the sense that it has been used over and over as a license
enforcement technique. Should it have been, and should it be a technique
used now? Nope, not if it were my call. Just like I've been saying all
along. Yet Peter the mighty will tell you I "just don't get it."

Please don't start name-calling. It's not useful at all.

Activation really sucks, IMO, almost to the point that I'd argue that
now *there's* a licensing scheme that is unworkable.

Why, out of interest? It certainly works pretty well in all the
situations I've used it in. Admittedly I've never tried to hack round
it, and I don't know how secure it is in that sense (it'll vary
depending on scheme, certainly).

Especially the
hardware hash technique that I understand Microsoft's product activation
to use (though I really don't know the details there). That technique is
fraught with problems, yet, just like with a scheme that utilizes a MAC
address, can be made workable. Again, desirable? No!

Again we disagree on the meaning of "workable", I believe.

 

[Jassim Rahma]

but what if the user changed one of his hardware components?

 

[G.Doten]

Indeed. There's a big difference between "unique on an IP segment" and
"globally unique" however. In particular, if someone wanted to pirate
some software to run behind their firewall and knew the MAC address of
someone who had a legit copy running behind *their* firewall, there's
no network requirement for those two machines to have different MAC
addresses.

Right, and Peter (and I think others) have already pointed this out. No
argument here!

No - I just think it runs counter to your argument that *Peter* has
been arguing against the uniqueness of vendor-assigned MAC addresses.

Well, um, he has. Just read back.

But these days *aren't* pre-Internet. What might have been usefully
feasible before isn't necessarily so now.

No argument here!

Put it this way: is a licence scheme which requires the licencee to
remember (without writing down) a 32 digit number, entered every time
they start the software, "feasible"? It's possible in the strictest
technical sense - but not feasible in any useful sense.

I certainly wouldn't ship a product that had that requirement.

I still haven't seen where he said that isn't true - which is why I
asked for a specific quote.

Fine. Let me quote.

<quote>
Me: The statement is correct in that a built-in MAC address on *any*
device that has one is without question supposed to be unique.

Peter: That's the error right there. It is mostly true that the MAC
address is unique among default, manufacturer-assigned MAC addresses.
But beyond that, no uniqueness is assured.
</quote>

This is where he started his random contradicting. He knows damn well
what I am saying, but must make me sound like I am stating some sort of
"error" when I say that. The built-in MAC address is without question
supposed to be unique. There is no error in that statement. Peter then
continues to sing that same song inferring that I can't read English.

<quote>
me: Further, it is codified in the IEEE MAC address standard that these
built-in addresses are unique. That's all I'm saying.

Peter: And as I said, even if you assume that the built-in addresses are
unique, that isn't relevant in this context.
</quote>

It's not an assumption! I've had to repeat that a number of times. And
he keeps refuting it.

And from the same reply:

<quote>
Peter: This is, in fact, the underlying basis for everything I've
written in this thread: a copy protection scheme based on the MAC
address is a bad idea. There is no reliable way to obtain a unique MAC
address in a useful way for copy protection.
</quote>

He knows damn well that everyone--including myself--agree that using a
MAC address for this purpose is a bad idea.

Where did he say there's no standard for built-in MACs? He's repeatedly
acknowledged that - but stated (and I agree with him) that that's
completely different from the MAC addresses which are *used* being
unique and standardised.

Well, here's just one:

<quote>
Peter: That is the standard for how manufacturers assign the default MAC
address for a device. That is _not_ the standard for MAC address as
they are used in networks.
</quote>

Finally coming around to agreeing there is a standard, and it that it
does dictate that built-in MAC addresses be unique ('It is true that "no
two manufacturers can possibly assign the same MAC address to two or
more devices" (to the extent that manufacturers don't screw up...they
do, you know)'), he then tries to say the standard is not used in
real-life networks.

Then it pretty much devolves into device drivers, and things like "WMI
does not provide a specific API to retrieve a MAC address" (it does, and
in a very standard way), and this beauty: 'The Windows API is a
standard. That doesn't mean that any code I implement using the Windows
API is using a "standardized way" to do something.' That's just precious.

I think we disagree about the meaning of "feasible".

Could be; it's not like it has a technical definition or anything. Would
you not agree that a technique that is used by a shipping product is
indeed feasible? If not, then we are indeed using different definitions
for the word.

Please don't start name-calling. It's not useful at all.

I didn't realize I called you a name, Jon. I think "the mighty" can fend
for himself, as far as I've seen. He's certainly used worse on me (not
that I care). However, you're right, name-calling is not useful at all.

Regardless, using a MAC address is not only workable (using the normal
definition of the word), it is and has been done.

Why, out of interest? It certainly works pretty well in all the
situations I've used it in. Admittedly I've never tried to hack round
it, and I don't know how secure it is in that sense (it'll vary
depending on scheme, certainly).

I've had systems (programs, I mean) become disabled at critical times
because I've changed hardware. Yes, there are work-arounds of calling a
telephone number (at least for the software I've used), but it's a pain
in the patuty when you are under a deadline. Personally I just don't
think I should have to prove I am legally using a piece of software
every time I run it. But this is getting way OT, and admittedly this is
just a personal opinion of mine.

Again we disagree on the meaning of "workable", I believe.

Perhaps. But I hope you are not disagreeing that software has and does
ship that uses MAC addresses for their licensing scheme. Should they?
Hey, it's their software...

 

[G.Doten]

but what if the user changed one of his hardware components?

You mean like the PC itself? (Just kidding!)

If they change their mobo, or CPU, or whatever, and you are using a ID
of some sort from any of those hardware components then the easiest
thing is to just regenerate a new license key for them.

Microsoft apparently uses some sort of hardware hash out of a bunch of
the IDs in a system, which allows the license key to still work when
certain pieces of hardware are added or changed or removed. People here
may know details of that method. You probably won't find all the details
on the net because I assume that MS keeps how that works a pretty good
secret.

 

[Jon Skeet [C# MVP]]

Fine. Let me quote.

<quote>
Me: The statement is correct in that a built-in MAC address on *any*
device that has one is without question supposed to be unique.

Peter: That's the error right there. It is mostly true that the MAC
address is unique among default, manufacturer-assigned MAC addresses.
But beyond that, no uniqueness is assured.
</quote>

Well, there's a difference between "MAC addresses are designed to be
globally unique" and "default, hardware-assigned MAC addresses are
designed to be unique". I *suspect* that's what Peter was getting at,
given the rest of the post.

This is where he started his random contradicting. He knows damn well
what I am saying, but must make me sound like I am stating some sort of
"error" when I say that. The built-in MAC address is without question
supposed to be unique. There is no error in that statement. Peter then
continues to sing that same song inferring that I can't read English.

I'd venture to suggest that you're the one implying that he's denying
that manufacturers are meant to assign unique addresses, despite there
being no such denial.

<quote>
me: Further, it is codified in the IEEE MAC address standard that these
built-in addresses are unique. That's all I'm saying.

Peter: And as I said, even if you assume that the built-in addresses are
unique, that isn't relevant in this context.
</quote>

It's not an assumption! I've had to repeat that a number of times. And
he keeps refuting it.

It's an assumption that they *are* unique - i.e. that everyone follows
the standard without any errors creeping in. We've all agreed that
manufacturers *can* make errors, therefore it would be foolish to
believe that all the built-in addresses genuinely are unique.

Peter's wider point in that quote was that you still couldn't trust the
*reported* MAC address anyway though.

And from the same reply:

<quote>
Peter: This is, in fact, the underlying basis for everything I've
written in this thread: a copy protection scheme based on the MAC
address is a bad idea. There is no reliable way to obtain a unique MAC
address in a useful way for copy protection.
</quote>

He knows damn well that everyone--including myself--agree that using a
MAC address for this purpose is a bad idea.

The difference being that you believe (as far as I can tell) it's
always realistic to retrieve a built-in MAC address reliably.

Well, here's just one:

<quote>
Peter: That is the standard for how manufacturers assign the default MAC
address for a device. That is _not_ the standard for MAC address as
they are used in networks.
</quote>

I don't see where that says that he says there's no standard for built-
in MACs.

Finally coming around to agreeing there is a standard, and it that it
does dictate that built-in MAC addresses be unique ('It is true that "no
two manufacturers can possibly assign the same MAC address to two or
more devices" (to the extent that manufacturers don't screw up...they
do, you know)'), he then tries to say the standard is not used in
real-life networks.

And indeed it's not, because in real networks MAC addresses *are*
assigned - often enough to make it non-negligible, IMO.

Then it pretty much devolves into device drivers, and things like "WMI
does not provide a specific API to retrieve a MAC address" (it does, and
in a very standard way), and this beauty: 'The Windows API is a
standard. That doesn't mean that any code I implement using the Windows
API is using a "standardized way" to do something.' That's just precious.

Well, using the instructions you were suggesting, WMI isn't providing
an API to get at the original, built-in MAC address. Part of the
process you were suggesting is "just" clearing registry keys - a
critical part of system configuration. *That* certainly isn't a
"standardized way to get at the hardware's default MAC address". The
WMI part isn't the big problem - it's the preceding step.

Could be; it's not like it has a technical definition or anything. Would
you not agree that a technique that is used by a shipping product is
indeed feasible? If not, then we are indeed using different definitions
for the word.

It depends on whether that scheme actually *works*. I could ship a
"licensing scheme" that relied on an invalid user not creating a file
called licence.txt - I wouldn't say that's feasible as a real licensing
scheme.

I didn't realize I called you a name, Jon.

I never claimed that you did. I just don't like it when newsgroup posts
involve slanging matches whoever's involved.

I think "the mighty" can fend for himself, as far as I've seen. He's
certainly used worse on me (not that I care). However, you're right,
name-calling is not useful at all.

Does that mean you'll stop doing it?

Regardless, using a MAC address is not only workable (using the normal
definition of the word)

We certainly haven't agreed on that. "Workable" presumably means that
something "works" doesn't it? For a copy protection scheme to work, it
must detect when someone fakes their MAC addresses. I don't have enough
experience of such products to know whether they manage that - but I
suspect they don't.

it is and has been done.

Products have certainly been shipped using it. Are they genuinely
protected by the licensing scheme? That's a different matter.

I've had systems (programs, I mean) become disabled at critical times
because I've changed hardware. Yes, there are work-arounds of calling a
telephone number (at least for the software I've used), but it's a pain
in the patuty when you are under a deadline. Personally I just don't
think I should have to prove I am legally using a piece of software
every time I run it. But this is getting way OT, and admittedly this is
just a personal opinion of mine.

Hang on a sec - I specifically spoke about one-time validation. Not
"every time I run it" validation, nor validation which dies when
hardware is changed. I certainly don't like either of those.

Perhaps. But I hope you are not disagreeing that software has and does
ship that uses MAC addresses for their licensing scheme.

No. I just dispute whether it's reasonable to call that licensing
scheme "workable" if it doesn't provide any real protection.

Should they? Hey, it's their software...

True.

 

[G.Doten]

Well, there's a difference between "MAC addresses are designed to be
globally unique" and "default, hardware-assigned MAC addresses are
designed to be unique". I *suspect* that's what Peter was getting at,
given the rest of the post.

I don't. He clearly says "It is mostly true that the MAC address is
unique among default, manufacturer-assigned MAC addresses." Insisting on
"mostly true" when he knows darn well it is true. He's splitting hairs
here just to argue with me.

I'd venture to suggest that you're the one implying that he's denying
that manufacturers are meant to assign unique addresses, despite there
being no such denial.

But there is that denial, and of the standard itself. Venture what you'd
like; it's a free Internet!

It's an assumption that they *are* unique - i.e. that everyone follows
the standard without any errors creeping in. We've all agreed that
manufacturers *can* make errors, therefore it would be foolish to
believe that all the built-in addresses genuinely are unique.

No, it wouldn't. That's like saying it would be foolish to follow the
standard when dealing with these addresses. There must be many standards
that are misapplied, yet what they say can still be used. If a problem
with a particular implementation is encountered it can be worked-around,
especially in this specific case of built-in MAC addresses.

Peter's wider point in that quote was that you still couldn't trust the
*reported* MAC address anyway though.

Sure you can! You're losing me.

The difference being that you believe (as far as I can tell) it's
always realistic to retrieve a built-in MAC address reliably.

Yes, I do. I may easily be wrong.

I don't see where that says that he says there's no standard for built-
in MACs.

"That is _not_ the standard for MAC address as they are used in
networks." Wrong.

And indeed it's not, because in real networks MAC addresses *are*
assigned - often enough to make it non-negligible, IMO.

We disagree on the meaning of non-negligible, I think.

Well, using the instructions you were suggesting, WMI isn't providing
an API to get at the original, built-in MAC address. Part of the
process you were suggesting is "just" clearing registry keys - a
critical part of system configuration. *That* certainly isn't a
"standardized way to get at the hardware's default MAC address". The
WMI part isn't the big problem - it's the preceding step.

No, I think that would work fine. Supposedly it does, anyway.

It depends on whether that scheme actually *works*. I could ship a
"licensing scheme" that relied on an invalid user not creating a file
called licence.txt - I wouldn't say that's feasible as a real licensing
scheme.

Yes, it works; it is used by products.

I never claimed that you did. I just don't like it when newsgroup posts
involve slanging matches whoever's involved.

I sheepishly agree with that.

Does that mean you'll stop doing it?
Maybe.


We certainly haven't agreed on that. "Workable" presumably means that
something "works" doesn't it? For a copy protection scheme to work, it
must detect when someone fakes their MAC addresses. I don't have enough
experience of such products to know whether they manage that - but I
suspect they don't.

That's your definition of licensing scheme (and isn't a bad one).
Because a product ships with a "MAC address licensing scheme" that may
(or may not) let MAC addresses be spoofed does not mean it isn't a
legitimate licensing scheme. I would say that there is no licensing
scheme that is 100% accurate nor 100% secure. A product company may
decide that this hole may be perfectly acceptable for their needs.

This is what makes such a licensing scheme workable.

Products have certainly been shipped using it. Are they genuinely
protected by the licensing scheme? That's a different matter.
True.


Hang on a sec - I specifically spoke about one-time validation. Not
"every time I run it" validation, nor validation which dies when
hardware is changed. I certainly don't like either of those.

Well, we agree on that. I don't like any of those schemes either,
including the one-time validation ones. All of them are relatively easy
to crack.

No. I just dispute whether it's reasonable to call that licensing
scheme "workable" if it doesn't provide any real protection.

I don't see how it can be denied that it is a workable technique, but
whatever. I never claimed, nor would I ever claim, it is a perfect
solution. But I would say it is perfectly acceptable for the needs of
some companies.

True.

Which is why they can define how bullet-proof or not bullet-proof their
licensing scheme is.

You make an excellent proxy for Peter, BTW.