serial number (activation code)

[Jassim Rahma]

I want to create a unique serial number (activation code) which must be used
on one PC. The only way I thought of is to generate a serial number from the
PC's MAC address and i want to know how can I do that?

[Peter Duniho]

Since a MAC address is not necessarily unique, I am not convinced that
your approach is going to work.

Also, keep in mind that existing implementations of "activation codes"
(such as Microsoft's Product Activation for Windows and Office products)
cause a lot more inconvenience to paid users of their products than they
do to software pirates. In fact, they only inconvenience paid users;
the pirates have, by definition, gotten around the activation feature
and so don't ever run into any trouble with it.

So if your goal is to defend against piracy, an activation code isn't
really a very nice thing to do to your paid users.

The key point here is that anything that could be a barrier to a
software pirate can also potentially be a barrier to your paid users.
And for a software pirate, they only have to break your barrier once,
and then it is no longer an inconvenience for _any_ person who has
pirated your software, while your paid users, since they are not using a
hacked version of your software in which the barrier has been removed,
will continue to have problems with your barrier.

Of course, the same thing can be said of most copy protection schemes.

It is much better to provide your users with non-barrier incentives to
licensing your software legally. For example, offering excellent
product support to paid users, and not charging ridiculous prices for
your software (to name a couple of things many software publishers get
wrong).

Pete

[G.Doten]

Peter Duniho wrote:
> Jassim Rahma wrote:
>> I want to create a unique serial number (activation code) which must
>> be used on one PC. The only way I thought of is to generate a serial
>> number from the PC's MAC address and i want to know how can I do that?
>
> Since a MAC address is not necessarily unique, I am not convinced that
> your approach is going to work.

All MAC addresses had better be unique; they are designed to be, anyhow.
But what you probably mean is which MAC address should be used? Probably
most PC's only have one NIC but a lot have more than one so there's two
or more MAC addresses right there. Other devices like Bluetooth radios
also can—and usually do—have MAC addresses, like in the case of a
Bluetooth Personal Area Network.

So Jassim, if you go the MAC address route, you have to first decide
which one you want to use. Not an easy problem to solve.

--
-glenn-

[Bob Johnson]

Well, if you *must* protect your investment - even at the soft expenses
described by Mr. Duniho - then you might want to go with a real licensing
system:

http://www.desaware.com/products/licensingsystem/index.aspx

Protecting your code is something that is incremental - you can only raise
the bar for would-be crooks. It can be easily argued that you must do ALL of
a bunch of things or NONE of them; as doing only a subset would only
increase your expense, tick off paying customers, and really not raise the
bar as high as possible.

IN the spirit of going "all out"... in addition to the serious licensing
system at the link above, you would need to obfuscate your code. There are a
few other things as well....

- "HTH"

"Jassim Rahma" <jra...@hotmail.com> wrote in message
news:u7fT6fU0...@TK2MSFTNGP04.phx.gbl...

[Bob Johnson]

The core issue here is "how do we _define_" a given PC? You must do that
before you can proceed to _identify_ any PC. Going off of a NIC is just one
way to do it.

The licensing system at the following link lets you change the very
definition of a given computer to suite your needs. Do you want to define it
as simply one of the installed NICs? Great - you can do that. How about
going off of the HD. Great. How about both plus CPU - no problem (IIRC).

http://www.desaware.com/products/licensingsystem/index.aspx

HTH

"G.Doten" <gdo...@gmail.com> wrote in message
news:%23qKe$5U0HH...@TK2MSFTNGP02.phx.gbl...

> Peter Duniho wrote:
>> Jassim Rahma wrote:
>>> I want to create a unique serial number (activation code) which must be
>>> used on one PC. The only way I thought of is to generate a serial number
>>> from the PC's MAC address and i want to know how can I do that?
>>
>> Since a MAC address is not necessarily unique, I am not convinced that
>> your approach is going to work.
>
> All MAC addresses had better be unique; they are designed to be, anyhow.
> But what you probably mean is which MAC address should be used? Probably
> most PC's only have one NIC but a lot have more than one so there's two or
> more MAC addresses right there. Other devices like Bluetooth radios also

> can預nd usually do揺ave MAC addresses, like in the case of a Bluetooth

[Jassim Rahma]

but when say MAC i thought that's a PC (physical PC) not any other
componant?

"G.Doten" <gdo...@gmail.com> wrote in message
news:%23qKe$5U0HH...@TK2MSFTNGP02.phx.gbl...

[G.Doten]

Jassim Rahma wrote:
>
> but when say MAC i thought that's a PC (physical PC) not any other
> componant?
>
>
>
>
> "G.Doten" <gdo...@gmail.com> wrote in message
>>

>> So Jassim, if you go the MAC address route, you have to first decide
>> which one you want to use. Not an easy problem to solve.
>>
>> --
>> -glenn-
>

No, MAC is a unique number assigned to things like Network Interface
Cards and similar devices. Each manufacturer of such cards is assigned a
unique range of MAC addresses that they can burn into the actual
hardware. A PC can have no NIC cards or one or more. Plus, like I said
previously, not just NIC cards use MAC addresses, and a PC can have any
number of such non-NIC devices.

So a MAC address does not uniquely identify a PC or anything like that.
In fact, as stated, some PCs won't have any devices that use a MAC
address and therefore won't have any MAC addresses you could use for
license enforcement.

You'll need to pick some other way to uniquely identify a PC. And if you
come up with something, please post it here. :-)

--
-glenn-

[Jon Skeet [C# MVP]]

G.Doten <gdo...@gmail.com> wrote:
> All MAC addresses had better be unique; they are designed to be, anyhow.

IIRC, a MAC addrses has to be unique within a subnet in order for
routing to work - beyond that it's all down to the IP address.

Some network cards allow you to specify the MAC address yourself
(again, IIRC), which completely kills any claim of uniqueness.

--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Bromberg [C# MVP]]

a "unique serial number" is only part of the equation. As other comments have
indicated, I'd be extremely reluctant to use only the MAC address since it's
common for NICs to be switched out. Not only that but utilities like
"etherchange" can actually change the reported MAC address at will.
Maybe if you could be more specific about exactly what is the goal of your
proposed licensing scheme, you can get better help.

Virtually ANY licensing scheme can be broken by a determined cracker. I
repeat: ANY.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
bogMetaFinder: http://www.blogmetafinder.com

[G.Doten]

Jon Skeet [C# MVP] wrote:
> G.Doten <gdo...@gmail.com> wrote:
>> All MAC addresses had better be unique; they are designed to be, anyhow.
>
> IIRC, a MAC addrses has to be unique within a subnet in order for
> routing to work - beyond that it's all down to the IP address.
>
> Some network cards allow you to specify the MAC address yourself
> (again, IIRC), which completely kills any claim of uniqueness.
>

Yes, you can override the value of the MAC address burned into any of
the devices that the networking layer will then use (it's just software,
after all; there's nothing to force the software to use the address
burned-in to the device). But all the addresses burned-in to such a
device had better be unique, and you can easily get that number, again,
using software, to use in a licensing scheme (or whatever) if you want to.

If a MAC address burned-into one of these devices isn't unique, then the
device manufacturer screwed up. Each manufacturer is assigned a unique
number by the IEEE that goes into the first 24-bits of a MAC address,
and the manufacturer assigns the remaining 24-bits as they see fit, so
long as they never reuse a number.

If bit 41 of a MAC address is 0 then it is the address burned-in to the
device; if it is 1 then the address has been changed by a network admin.
Although why a network admin would do this I've never fully understood.
The only thing that pops to mind is that a device manufacturer screwed
up and duplicated a MAC address and some unlucky sole ended up with two
devices having the same MAC address on their local subnet, in which case
they can override the number (pretty much only for some manufacturer's
NICs though).

The fact that manufacturer's may indeed screw up assigning these
addresses, that's yet another good reason not to use them in some
licensing scheme which attempts to uniquely identify a PC.

--
-glenn-

[Peter Duniho]

G.Doten wrote:
> All MAC addresses had better be unique; they are designed to be, anyhow.

Hardware MAC addresses are intended to be as unique as possible. But
there is no requirement that they be unique, and since you can
arbitrarily set the MAC address on most network devices, they easily can
be non-unique.

As long as a MAC address doesn't show up twice on the same network
segment, it's not even a problem for them to be non-unique.

> But what you probably mean is which MAC address should be used?

Nope. That's not at all what I mean. But it's a good point to bring up
as well.

Probably
> most PC's only have one NIC but a lot have more than one so there's two
> or more MAC addresses right there. Other devices like Bluetooth radios
> also can—and usually do—have MAC addresses, like in the case of a
> Bluetooth Personal Area Network.

I am currently using a computer that has four MAC addresses: Bluetooth,
Firewire, wireless, and wired Ethernet. To further complicate matters,
I sometimes run a VM with Windows XP in it, and that VM's network
adapter has its own MAC address, as do other virtual network adapters
based on the Bluetooth and Firewire hardware.

> So Jassim, if you go the MAC address route, you have to first decide
> which one you want to use. Not an easy problem to solve.

As an example of the issues I brought up in my previous post, consider
the scenario where someone is using software on a computer that also has
a VM installation. I see no legitimate reason to prevent that person
from running the given software either within the VM or under the
non-virtual instance, but if the MAC addresses aren't the same under
both OS instances (and they very well might not be, especially if the VM
is configured to have the network adapter on the same network segment as
the non-VM instance), the software will insist on being "activated" on
one or the other, but not both.

I have, in fact, had this exact problem with Office 2007 and their
incredibly annoying Product Activation "feature" (I do use that term
loosely).

Pete

[Peter Duniho]

Jassim Rahma wrote:
>
> but when say MAC i thought that's a PC (physical PC) not any other
> componant?

The MAC address is associated with network adapters. You'll generally
have one unique MAC address per network adapter, and lots of different
devices on a given computer can look like a network adapter (as has been
mentioned), including those that actually _are_ network adapters.

The MAC address is definitely not "one-per-PC".

Pete

[Peter Duniho]

G.Doten wrote:
> Yes, you can override the value of the MAC address burned into any of
> the devices that the networking layer will then use (it's just software,
> after all; there's nothing to force the software to use the address
> burned-in to the device). But all the addresses burned-in to such a
> device had better be unique, and you can easily get that number, again,
> using software, to use in a licensing scheme (or whatever) if you want to.

And the user can just as easily reconfigure a given PC's MAC address to
match that used to license the software.

Pete

[ajk]

assuming you are running under windows you could just leech on the
windows product key and use that as base for creating your unique
serial number.

[G.Doten]

Well, no, they can't. Not unless they hack the OS, that is. I wouldn't
say that's very easy...

--
-glenn-

[G.Doten]

Peter Duniho wrote:
> G.Doten wrote:
>> All MAC addresses had better be unique; they are designed to be, anyhow.
>
> Hardware MAC addresses are intended to be as unique as possible. But
> there is no requirement that they be unique, and since you can
> arbitrarily set the MAC address on most network devices, they easily can
> be non-unique.

Yes they are required to be unique, although a given manufacturer may
screw up, they each have an assigned range of values they are allowed to
use. Think of a MAC address like a GUID; both are supposed to be
globally unique. Or think of it as an IP address where the network
portion of the address is handed out to specific organizations so they
will in theory be unique. They too don't have to be unique but you
probably don't want more than one instance of the same IP address being
used on your network. (Though the IP address analogy isn't 100% since
there are so-called private IP addresses in the 10, 192.168, etc.,
network ranges, but you get the idea.)

>
> As long as a MAC address doesn't show up twice on the same network
> segment, it's not even a problem for them to be non-unique.

Agreed. But they are designed to be globally unique because a
manufacturer of a device has no idea what network a given device will be
used on.

>> Probably
>> most PC's only have one NIC but a lot have more than one so there's
>> two or more MAC addresses right there. Other devices like Bluetooth
>> radios also can—and usually do—have MAC addresses, like in the case of
>> a Bluetooth Personal Area Network.
>
> I am currently using a computer that has four MAC addresses: Bluetooth,
> Firewire, wireless, and wired Ethernet. To further complicate matters,
> I sometimes run a VM with Windows XP in it, and that VM's network
> adapter has its own MAC address, as do other virtual network adapters
> based on the Bluetooth and Firewire hardware.

Exactly my point, which is why a PC does not have a single MAC address
that Jassim thought they did. Maybe use the CPU ID? Ha ha ha.

--
-glenn-

[Jesse Houwing]

You'd have to write very specific code (as ins specific to that device)
to extract the original MAC address if it's overridden in the driver.
All Intel, 3COM and BroadCom NIC's I've used so far have an option to
easily, from the driver, override the MAC address.

I've seen software being hacked before relying on the MAC address. The
hack was done in a pretty simple fashion. They put an altered version of
the windows dll that can read the mac address in the executables
directory. That dll always returns the same address, so the keygen
would've been pretty easy from that moment on.

The only way you can truly get am identifying piece of information from
a PC is when they have a TPM installed (Trusted Platform Module). Most
consumer PC's dont' have this, but it's becoming more common in business
workstations.

Jesse

[G.Doten]

I stand corrected; good point. I was assuming that the driver would
always return the burnt-in MAC address when asked for it via a system
call (as opposed to asking for the currently active MAC address).

--
-glenn-

[Peter Duniho]

G.Doten wrote:
>> As long as a MAC address doesn't show up twice on the same network
>> segment, it's not even a problem for them to be non-unique.
>
> Agreed. But they are designed to be globally unique because a
> manufacturer of a device has no idea what network a given device will be
> used on.

I think you understand the error in the above statement already, but
just to make sure it's clear:

While the hardware's default MAC address should always be globally
unique, this is not the MAC address that is necessarily being used.
Even if hardware MAC addresses were guaranteed to be unique (and because
of mistakes by manufacturers, this is not even always the case), that's
not relevant to the discussion here, because there's no standardized way
for arbitrary software to get the hardware's default MAC address, and
the MAC address being used could be set to whatever the user wants.

Pete

[G.Doten]

Peter Duniho wrote:
> G.Doten wrote:
>>> As long as a MAC address doesn't show up twice on the same network
>>> segment, it's not even a problem for them to be non-unique.
>>
>> Agreed. But they are designed to be globally unique because a
>> manufacturer of a device has no idea what network a given device will
>> be used on.
>
> I think you understand the error in the above statement already

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. 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.

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

> , but
> just to make sure it's clear:
>
> While the hardware's default MAC address should always be globally
> unique, this is not the MAC address that is necessarily being used. Even
> if hardware MAC addresses were guaranteed to be unique (and because of
> mistakes by manufacturers, this is not even always the case), that's not
> relevant to the discussion here, because there's no standardized way for
> arbitrary software to get the hardware's default MAC address, and the
> MAC address being used could be set to whatever the user wants.
>
> Pete

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. 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.

--
-glenn-

[Peter Duniho]

G.Doten wrote:
> 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.

>> there's no
>> standardized way for arbitrary software to get the hardware's default
>> MAC address, and the MAC address being used could be set to whatever
>> the user wants.
>>
>> Pete
>
> 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]

Peter Duniho wrote:
> G.Doten wrote:
>> 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.

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
>> *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.
>

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

>> 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.

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.

>
>>> there's no standardized way for arbitrary software to get the
>>> hardware's default MAC address, and the MAC address being used could
>>> be set to whatever the user wants.

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.

>>>
>>> Pete
>>
>> 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".

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

>
>> 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.

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.

--
-glenn-

[Peter Duniho]

G.Doten wrote:
>> 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.

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.

[...]

>> 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.

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.

>> 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.

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.

>>> 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.
>
> 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.

>>>> there's no standardized way for arbitrary software to get the
>>>> hardware's default MAC address, and the MAC address being used could
>>>> be set to whatever the user wants.
>
> 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.

>>> 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".
>
> 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.

"Jassim Rahma" <jra...@hotmail.com> wrote in message
news:u7fT6fU0...@TK2MSFTNGP04.phx.gbl...

[Johnny Jörgensen]

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

Cheers,
Johnny J.

"ajk" <a...@workmail.com> wrote in message
news:al2oa3pagelolpu6b...@4ax.com...

[G.Doten]

Peter Duniho wrote:
> G.Doten wrote:
>>> 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.
>
> You aren't paying attention to what I wrote.

Sure am; you're just not making sense.

>
>> 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.

Of course it is!

>
> [...]
>>> 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.
>
> 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.

>
>>> 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.
>
> 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.

>
>>>> 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.
>>
>> 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.

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.

>
>>>>> there's no standardized way for arbitrary software to get the
>>>>> hardware's default MAC address, and the MAC address being used
>>>>> could be set to whatever the user wants.
>>
>> 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.

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.

>
>>>> 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".
>>
>> 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.

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? :-)

--
-glenn-

[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]

Peter Duniho wrote:
> 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.

>
>> 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.

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.

--
-glenn-

[Peter Duniho]

G.Doten wrote:
> 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]

Peter Duniho wrote:
> G.Doten wrote:
>> 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.

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.

--
-glenn-

[Jon Skeet [C# MVP]]

G.Doten <gdo...@gmail.com> wrote:

<snip>

> 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]

Jon Skeet [C# MVP] wrote:

> G.Doten <gdo...@gmail.com> wrote:
>
> <snip>
>
>> 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.

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.

--
-glenn-

[Jon Skeet [C# MVP]]

G.Doten <gdo...@gmail.com> wrote:
> >> 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.
>
> 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.

<snip>

> > 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.

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.

<snip>

> 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.

<snip>

> 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]

Jon Skeet [C# MVP] wrote:

> G.Doten <gdo...@gmail.com> wrote:
>>>> 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.
>> 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".

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?

>>> 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.
>
> 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.

>
>> 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.

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.

>> 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.

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

>> 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.

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."

>> 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).
>

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!

--
-glenn-

[Jon Skeet [C# MVP]]

G.Doten <gdo...@gmail.com> wrote:
> > 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.

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.

> > 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?

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

> > 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.

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.

> >> 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.
>
> 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.

> >> 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.
>
> 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".

> >> 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.
>
> 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.

> >> 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).
>
> 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?

"Johnny Jörgensen" <jo...@altcom.se> wrote in message
news:%23VtJH%23n0HH...@TK2MSFTNGP03.phx.gbl...

[G.Doten]

Jon Skeet [C# MVP] wrote:

> G.Doten <gdo...@gmail.com> wrote:
>>> 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.
>
> 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!

>>> 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?
>
> 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.

>>> 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.
>
> 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 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.
>> 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.

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.

>> 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.

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.

>
>>>> 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.
>> 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".

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'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.
>> 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.

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.

>>>> 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).
>> 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).

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.

>
>> 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.
>

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...

--
-glenn-

[G.Doten]

Jassim Rahma wrote:
> 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.

--
-glenn-

[Jon Skeet [C# MVP]]

G.Doten <gdo...@gmail.com> wrote:

<snip>

> >> 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.
>
> 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.

> >> 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.
>
> 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.

> > 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.

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.

> > Please don't start name-calling. It's not useful at all.
>
> 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.

> > 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.

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.

> >> 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.
>
> 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]

Jon Skeet [C# MVP] wrote:
> G.Doten <gdo...@gmail.com> wrote:

>>>> 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.
>> 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.

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.

>> 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.

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

>> <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.

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.

>> 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.

Yes, I do. I may easily be wrong.

>>>> 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.
>> 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.

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

networks." Wrong.

>> 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.

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

>> 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.

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

>>> 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.
>
> 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.

>>> Please don't start name-calling. It's not useful at all.
>> 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 sheepishly agree with that.

>> 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?

Maybe.

>> 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.

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.

>> 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.

True.

>>> 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.
>
> 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.

>>>> 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.
>> 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.

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.

>> Should they? Hey, it's their software...
>
> 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.

--
-glenn-

[Jon Skeet [C# MVP]]

G.Doten <gdo...@gmail.com> wrote:
> > 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 really don't think so. I think the "mostly" is to cover vendor
mistakes.

> >> 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.
>
> But there is that denial, and of the standard itself. Venture what you'd
> like; it's a free Internet!

Again, I see no such denial. I think we'll have to agree to disagree
about this.

> >> 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.
>
> 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.

There's a difference between working round a problem and believing that
such a problem doesn't (or can't) exist.

> > 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 *reported* address can be set by the user, therefore it shouldn't
be trusted. I thought *that* bit was agreed on...

> >> 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.
>
> Yes, I do. I may easily be wrong.

Do you really think that resetting a customer's networking settings is
realistic as a viable way to do things? People kick up a fair amount of
fuss about installers requiring a reboot - but resetting network
settings is a whole different league, IMO.

> >> 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.
>
> "That is _not_ the standard for MAC address as they are used in
> networks." Wrong.

He's making the distinction between MAC addresses which are used in
real life and the MAC addresses which are built into the hardware. I
think that's a very valid distinction to make, given that users can
change the MAC addresses that are used. What's controversial about
that?

> >> 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.
>
> We disagree on the meaning of non-negligible, I think.

Possibly.

> >> 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.
>
> No, I think that would work fine. Supposedly it does, anyway.

If any installer tries to screw around with my network settings, it
certainly doesn't count as "working fine" in my view.

> > 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.

Just because it's used doesn't mean it works though. ROT-13 can be
*used* as an "encryption" mechanism, but it doesn't *work* as an
encryption mechanism. It's not a viable, feasible, workable encryption
scheme. If a product shipped using it, that wouldn't make it any more
secure as a scheme.

<snip>

> >> 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.
>
> 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.

I think it depends on the amount of difficulty involved in cracking it.
If it takes 5 minutes without having to install any extra drivers etc,
that's pretty unworkable in my view - and that's what I suspect the
case is for most if not all such licensing schemes, unless they commit
the cardinal sin of tampering with my network settings. At that point
they may be more secure, but I suspect not 100%. The cost is too high
though, IMO.

Now, as with most holes, I suspect that it's not the case that
companies deem such a hole as acceptable so much as that they don't
understand the hole to start with.

> > 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.

There are pros and cons. At least there isn't usually too much pain for
legitimate owners, however - no network settings tampering, for example
;)

> > 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.

I would be interested to see what those companies would say if a
5-minute zero-expertise (beyond reading a web page) crack were to be
presented to them. Of course, without trying out one of these products
(and knowing a valid licence key for a given MAC address) it's hard to
show that - but I have strong suspicions that their products aren't as
safe as they expect them to be. When a risk is accepted unknowingly it
shouldn't count as making the scheme involved "workable" IMO.

> >> Should they? Hey, it's their software...
> >
> > True.
>
> Which is why they can define how bullet-proof or not bullet-proof their
> licensing scheme is.

Only if they understand the weaknesses of such a scheme.

> You make an excellent proxy for Peter, BTW.

I just got fed up with the situation where I couldn't see that much
disagreement on what you actually believed, just on the words being
used.

[G.Doten]

Jon Skeet [C# MVP] wrote:

> G.Doten <gdo...@gmail.com> wrote:
>>> 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 really don't think so. I think the "mostly" is to cover vendor
> mistakes.

I don't, but that's OK.

>>>> 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.
>> But there is that denial, and of the standard itself. Venture what you'd
>> like; it's a free Internet!
>
> Again, I see no such denial. I think we'll have to agree to disagree
> about this.

Makes sense to me. Plus, I don't want to repost everything he wrote.

>>>> 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.
>> 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.
>
> There's a difference between working round a problem and believing that
> such a problem doesn't (or can't) exist.

That's true.

>>> 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 *reported* address can be set by the user, therefore it shouldn't
> be trusted. I thought *that* bit was agreed on...

I meant the reported built-in MAC, not the potentially change addresses
allowed by some NICs.

>>>> 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.
>> Yes, I do. I may easily be wrong.
>
> Do you really think that resetting a customer's networking settings is
> realistic as a viable way to do things? People kick up a fair amount of
> fuss about installers requiring a reboot - but resetting network
> settings is a whole different league, IMO.

I think it is rather simple to get at the built-in MAC address for any
device that has them, without reconfiguring a system. Assuming, of
course, that what you pointed out isn't the case (i.e., that the
built-in MAC is always available and can't be hidden or otherwise wiped
out by firmware or whatever).

>>>> 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.
>> "That is _not_ the standard for MAC address as they are used in
>> networks." Wrong.
>
> He's making the distinction between MAC addresses which are used in
> real life and the MAC addresses which are built into the hardware. I
> think that's a very valid distinction to make, given that users can
> change the MAC addresses that are used. What's controversial about
> that?

Because it *is* the standard for MAC addresses as they are used in a
network.

>>>> 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.
>> No, I think that would work fine. Supposedly it does, anyway.
>
> If any installer tries to screw around with my network settings, it
> certainly doesn't count as "working fine" in my view.

Won't argue with that.

>>> 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.
>
> Just because it's used doesn't mean it works though. ROT-13 can be
> *used* as an "encryption" mechanism, but it doesn't *work* as an
> encryption mechanism. It's not a viable, feasible, workable encryption
> scheme. If a product shipped using it, that wouldn't make it any more
> secure as a scheme.

But it does work, in this case. Does it necessarily fit your definition
of what a licensing scheme should achieve? Maybe not. But that's not the
point. The fact is products do use it, whether you want them to or not.

>>>> 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.
>> 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.
>
> I think it depends on the amount of difficulty involved in cracking it.
> If it takes 5 minutes without having to install any extra drivers etc,
> that's pretty unworkable in my view - and that's what I suspect the
> case is for most if not all such licensing schemes, unless they commit
> the cardinal sin of tampering with my network settings. At that point
> they may be more secure, but I suspect not 100%. The cost is too high
> though, IMO.

You're going places that are way out the scope of this conversation. I
don't disagree with anything you just said in that paragraph.

> Now, as with most holes, I suspect that it's not the case that
> companies deem such a hole as acceptable so much as that they don't
> understand the hole to start with.

Oh, I think you'd be surprised at the trade-offs a company is willing to
make. I agree those trade-offs aren't always great, but sometimes it is
the cost of doing business.

>>> 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.
>
> There are pros and cons. At least there isn't usually too much pain for
> legitimate owners, however - no network settings tampering, for example
> ;)

I wouldn't bet the farm on that. I'll bet that even some of the one-time
validation schemes dick around with net settings. And I bet they don't
even tell you! Not that I suspect it is prevalent or anything like that,
just that it wouldn't surprise me in the least.

>>> 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.
>
> I would be interested to see what those companies would say if a
> 5-minute zero-expertise (beyond reading a web page) crack were to be
> presented to them. Of course, without trying out one of these products
> (and knowing a valid licence key for a given MAC address) it's hard to
> show that - but I have strong suspicions that their products aren't as
> safe as they expect them to be. When a risk is accepted unknowingly it
> shouldn't count as making the scheme involved "workable" IMO.

I think most would say, "oh well." Enforcing licensing is one of those
trade-off things where you decide how secure to make it and/or how
effective to make and/or etc. compared to how much money and/or time you
are willing to invest in it. Management will take some pretty strange
short-cuts sometime. But then we're now just talking about licensing
schemes and I think that in 9 out of 10 cases a "pretty good" solution
is just fine. Just try to keep out as many software pirates for as
little investment as possible and go with that. It doesn't need to be
bullet proof. Of course how much is invested depends on the vendor, what
they are willing to invest, and other factors like that.

>>>> Should they? Hey, it's their software...
>>> True.
>> Which is why they can define how bullet-proof or not bullet-proof their
>> licensing scheme is.
>
> Only if they understand the weaknesses of such a scheme.

Yep!

>> You make an excellent proxy for Peter, BTW.
>
> I just got fed up with the situation where I couldn't see that much
> disagreement on what you actually believed, just on the words being
> used.

And since you seem to be playing his defender, I admit that I got
entirely fed up with his condescending all the time. Especially when
someone gets to their point where their argument is "well clearly you
don't understand so I certainly can't explain it to you." It bugs the
shit out of me--almost as much as name-calling (though you have to admit
"the mighty" isn't necessarily derogatory :-). But I suppose they are
techniques we all use one time or another, whether we are aware of it or
not. I think a lot of people have a hard time stepping back and seeing
how condescending they can sound, especially in a forum like this. I
know I have been guilty of it in the past!

I don't think I've ever seen you so, ah, passionate about any other
thread in this forum before. You took the "Peter proxy" like a
gentleman. I was just joking around, and it just popped in my head while
writing that sentence and couldn't resist it. If we can't play around in
these forums, and they have to stay stodgy and "just the facts," well
who the hell wants that?

--
-glenn-

[Peter Duniho]

It is unfortunate that Jon allowed himself to be dragged down the same
rat-hole that I myself permitted myself to be dragged down. He has my
sympathy.

As I already mentioned, I see little point in any further effort on my
part in this thread. However, you've crossed a line by leveling false
accusations at me, and those I must correct:

G.Doten wrote:
[...]

>>> 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 really don't think so. I think the "mostly" is to cover vendor
>> mistakes.
>
> I don't, but that's OK.

Jon's interpretation is exactly correct.

Frankly, I am at a loss to understand how you can justify the opposite
interpretation. I believe I have made exactly clear the exceptions I
feel exist, but at worst I have left some sort of ambiguity. I
definitely have not written anything that should lead you to an absolute
conclusion opposite of my intent.

It is telling that when presented with such an ambiguity (such as it may
be), you choose to infer a meaning that you feel is incorrect, rather
than offering the benefit of the doubt. This tendency to attribute the
worst to someone else is made even more clear here (from a previous post):

> 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.

The only person in this thread who has made any sort of personal attack
or engaged in name-calling is you. For you to claim that I have
"certainly used worse" on you is wrong, factually and ethically.

I grant that your name-calling has been mild as Usenet goes, but you
certainly have not shied from it and in fact you appear to relish in
creating a personal confrontation as part of the discussion rather than
just sticking to the facts. But you are alone in this thread with
respect to that sort of behavior, and I don't appreciate you falsely
claiming that you are not, especially when I am the target of that false
accusation.

Pete

[Jon Skeet [C# MVP]]

G.Doten <gdo...@gmail.com> wrote:

<snip>

> > Do you really think that resetting a customer's networking settings is
> > realistic as a viable way to do things? People kick up a fair amount of
> > fuss about installers requiring a reboot - but resetting network
> > settings is a whole different league, IMO.
>
> I think it is rather simple to get at the built-in MAC address for any
> device that has them, without reconfiguring a system. Assuming, of
> course, that what you pointed out isn't the case (i.e., that the
> built-in MAC is always available and can't be hidden or otherwise wiped
> out by firmware or whatever).

How? The web page you've used before as evidence of how feasible it is
certainly doesn't do it without reconfiguring the system.

At this point it would be worth breaking into code if possible - it
would be nice to have something to try to fool, if you see what I mean.

> > He's making the distinction between MAC addresses which are used in
> > real life and the MAC addresses which are built into the hardware. I
> > think that's a very valid distinction to make, given that users can
> > change the MAC addresses that are used. What's controversial about
> > that?
>
> Because it *is* the standard for MAC addresses as they are used in a
> network.

VMs appear on networks all the time. They aren't assigned unique MAC
addresses by hardware vendors, so don't follow the same standard of
uniqueness.

> > Just because it's used doesn't mean it works though. ROT-13 can be
> > *used* as an "encryption" mechanism, but it doesn't *work* as an
> > encryption mechanism. It's not a viable, feasible, workable encryption
> > scheme. If a product shipped using it, that wouldn't make it any more
> > secure as a scheme.
>
> But it does work, in this case. Does it necessarily fit your definition
> of what a licensing scheme should achieve? Maybe not. But that's not the
> point.

If it doesn't achieve what any sensible licensing scheme should
achieve, it doesn't count as working in my view.

> The fact is products do use it, whether you want them to or not.

I've never argued against that. There are products which do all kinds
of stupid things.

<snip>

> >> You make an excellent proxy for Peter, BTW.
> >
> > I just got fed up with the situation where I couldn't see that much
> > disagreement on what you actually believed, just on the words being
> > used.
>
> And since you seem to be playing his defender, I admit that I got
> entirely fed up with his condescending all the time.

Condescension such as:

<quote>

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.

</quote>

?

> Especially when someone gets to their point where their argument is
> "well clearly you don't understand so I certainly can't explain it to
> you."

Sounds quite similar to:

<quote.

It bugs the
> shit out of me--almost as much as name-calling (though you have to admit
> "the mighty" isn't necessarily derogatory :-). But I suppose they are
> techniques we all use one time or another, whether we are aware of it or
> not. I think a lot of people have a hard time stepping back and seeing
> how condescending they can sound, especially in a forum like this. I
> know I have been guilty of it in the past!
>
> I don't think I've ever seen you so, ah, passionate about any other
> thread in this forum before. You took the "Peter proxy" like a
> gentleman. I was just joking around, and it just popped in my head while
> writing that sentence and couldn't resist it. If we can't play around in
> these forums, and they have to stay stodgy and "just the facts," well
> who the hell wants that?
>
>

--

[G.Doten]

Peter Duniho wrote:
> It is unfortunate that Jon allowed himself to be dragged down the same
> rat-hole that I myself permitted myself to be dragged down. He has my
> sympathy.
>
> As I already mentioned, I see little point in any further effort on my
> part in this thread. However, you've crossed a line by leveling false
> accusations at me, and those I must correct:

And he's back! I knew you couldn't stay away! I missed you! (Laugh, damn
it.)

And why do you think I'm been holding my ground in this thread? Do you
think I enjoy being contradicted by you over-and-over again, especially
when my sense tells me you understand what I am saying perfectly well?
False accusations are indeed not fun.

>>>> 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 really don't think so. I think the "mostly" is to cover vendor
>>> mistakes.
>>
>> I don't, but that's OK.
>
> Jon's interpretation is exactly correct.
>
> Frankly, I am at a loss to understand how you can justify the opposite
> interpretation.

Did it ever occur to you that you may not have chosen the best words to
precisely describe what you were trying to say? "Interpretation" in this
case is a perfect word. Jon perhaps interpreted what you said one way, I
perhaps interpreted it another; if you are at a loss to understand how
that can happen, well, it's the nature of language. English is not like
C#. My having said "I don't" does not in any way imply or otherwise
justify someone reading into that that I take the opposite stance to
what I was commenting to; it leaves things wide open for interpretation.
As does Jon's "I really don't *think* so" statement. There's no 1s and
0s in English, unfortunately.

For example, if you had said "It is true that the MAC address is unique
among default, manufacturer-assigned (aka built-in) MAC addresses." Then
I, for one, would have understood perfectly what you said. But you
didn't say that, and you said the opposite for a reason, at least my
interpretation leads me to believe you intentionally obfuscated what you
said. Did you intend to? I can say that having experienced your defense
mechanism so much these past few days that my interpretation is that you
did. If you can't see how someone can come to that conclusion, then I'm
sorry, I don't know how else to explain it.

> I believe I have made exactly clear the exceptions I
> feel exist, but at worst I have left some sort of ambiguity.

You believe the facts you have stated to be true, as do I. But the
nature of language unfortunately always leaves room for ambiguity.

> I
> definitely have not written anything that should lead you to an absolute
> conclusion opposite of my intent.

I can't know your intent except by what you have written. Clearly, I
disagree with some of the stuff you've written. Where I agree I've
stated that explicitly. How you can twist my intent I do not understand
either.

> It is telling that when presented with such an ambiguity (such as it may
> be), you choose to infer a meaning that you feel is incorrect, rather
> than offering the benefit of the doubt.

That's exactly what you have been doing with me, well put. Until you got
to the point of "oh he's in his own world, I'm 'done'."

> This tendency to attribute the
> worst to someone else is made even more clear here (from a previous post):

Now you are generalizing, and have no facts for such a generalization.
I've posted in this forum many hundreds of times. I challenge you to
post sufficient examples to generalize that I condescend.

>> 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.
>
> The only person in this thread who has made any sort of personal attack
> or engaged in name-calling is you. For you to claim that I have
> "certainly used worse" on you is wrong, factually and ethically.

First of all, "the mighty" is hardly something to be concerned about. If
that bothers you, you need to grow a thicker skin. Factually and
ethically, that's rich. But if you want to deny what you've written,
feel free. Name-calling is not always explicit, being condescending to a
person is, I would say, a far worse form of name-calling. *Especially*
compared to the term "the mighty."

Is this thread now going to be the condemning and the defense of the
term "the mighty?" It is used quite positively in these circumstances:

- The Mighty Organ - http://www.themightyorgan.com/
- The Mighty Sparrow - http://www.mightysparrow.com/
- The Mighty Geek - http://www.themightygeek.com/

Why did you jump to the conclusion that I was using it for name-calling
in a negative sense? (Other than I admitted to it after the fact.) Feel
free to call me The Mighty Glenn. I like the sound of that.

> I grant that your name-calling has been mild as Usenet goes, but you
> certainly have not shied from it and in fact you appear to relish in
> creating a personal confrontation as part of the discussion rather than
> just sticking to the facts.

Now that's calling the kettle black. Your attitude in many of your posts
leads one to believe you relish in such behavior.

> But you are alone in this thread with
> respect to that sort of behavior, and I don't appreciate you falsely
> claiming that you are not, especially when I am the target of that false
> accusation.

If "the mighty" is name-calling, then your writings invite you to be
tarred-and-feathered from the forum. You see, from where I sit and read,
you have this attitude of superiority to practically everyone in this
forum, whether you intend your writing to come across like that or not.
Could I be misreading that? Admittedly, certainly yes, but I'm not the
only one. Do I think you do not contribute useful posts? Nope. Do I
think you are a bad person? Probably not.

But please, try some humor. It makes the day much more pleasant, and
this is C# nonsense after all, and way to unimportant to get yourself
all worked up over.

Yes, I am having fun. At this point in my career I'm in this industry
far more for the interaction with other people in it and how the
interpret, react, implement, and otherwise play with the bits-n-bytes of
the technology. This discourse, at least for me, has been tremendously
insightful. Not only on the nature of yourself, Jon, and some others,
but on the nature of myself and how the technology points that have been
raised have been discussed. Have fun coding, and always be open to
discussing, even if you don't believe you see the other person's point
of view. It's the best part of the game!

--
-glenn-

[Arne Vajhøj]

G.Doten wrote:
>> 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)

> 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 would guess that most ethernet address checking code just checks
the ethernet address being used.

And that can be set by software for many/most cards.

Arne

[Arne Vajhøj]

Oh and BTW then I think licenses tied to some specific hardware
is a horrible idea.

A real nightmare for sysadm's.

Arne