A decent compromise could be to tie it to the hard drive id. Hard drives can
be moved from machine to machine, with the software on them, and one can
always reload the software onto the same hard drive.
Alberto.
-----Original Message-----
From: Norbert Kawulski [mailto:xxxxx@stollmann.de]
Sent: Wednesday, May 02, 2001 10:22 AM
To: NT Developers Interest List
Subject: [ntdev] Re[2]: Unique ID
Lean back to see what will happen to Microsofts way of Registration.
Learn from it.
| Norbert Kawulski | mailto:xxxxx@stollmann.de |
| Stollmann T.P.GmbH, Development | http://www.stollmann.de |
–If it’s ISDN or Bluetooth, make sure it’s driven by Stollmann–
“Two feet on the ground is better than one in the mouth.”
> that. Locks that tie software to a machine are such a pain in the butt.
> If I were emperor I would make this a capital offense 
Hey, I know how
> about that spiffy CPUID Intel came up with? Grrrr…
CPUID is not a solution too because people upgrade CPUs.
Max
You are currently subscribed to ntdev as: xxxxx@stollmann.de
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
On Wednesday, May 02, 2001 11:08 AM ““danp” ” wrote:
>Most of the protection schemes Ive seen in my life where doomed from
start ,
>mainly because the team which implemented them did not made any effort
to
>look at their product from the perspective of an attacker.
You’re right.
>Even using a powerfull dongle might prove inefficient , because you
still
>have to use wisely the features of the dongle, a task which many
developers
>fail to accomplish.
O.K., but if they fail to use wisely well-documented features of the
dongle,
it’s the developers fault (slopiness) and not the protection scheme
itself.
>As for “obscure” approches, security trough obscurity is known not to
>work – is a fact which was proved too many times. Combine
>cryptographic tehniques with traditional approaches, and add a strong
>anti-debugging layer to your product.
Sure. Security must be achieved by stable means: people want guarantees,
not “gizmo techniques” that rely on “obscure” approaches. That’s why I
explicitly said “don’t quote me on this” (as I don’t agree with the
method);
I simply suggested a (sorry, bad) idea. But I know you’re right:
cryptographic
techniques are in the right way. Not so sure about the anti-debugging
layer,
though… 
>As for tracking leaks from customers to the pirate market, I used with
>success watermarking of excutables (…)
Yes, that is another fine technique. Good point there.
Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com
------------------------------------------------------------
«Humour and love are God’s answers
to Human weaknesses»
------------------------------------------------------------
----- Original Message -----
From: “Miguel Monteiro”
To: “NT Developers Interest List”
Sent: Wednesday, May 02, 2001 11:29 AM
Subject: [ntdev] RE: Unique ID
> Hi Bill,
> Intel’s CPUID purpose was to provide a consistent way of identifying
> the processor family and characteristics without relying on devious
> schemes and obscure processor flags…
>
> Now imagine the following scenario:
> -The user does not have a MAC…
> -The spiffy “CPU serial nr ID «feature»” is disabled from BIOS…
>
> Ooops.
>
> Personally I’m not very fond of uniquely IDentifying the equipment:
> users will surely dislike that kind of “feature”. But if you really
> need
> to do that, my tip is to follow an “obscure” approach (don’t quote me
> on this) and use a key made up of a mixture of a few “fixed”
> characteristics (e.g. the CPU characteristics - OK, Bill, now use the
> CPUID… - and some clever hdd and BIOS checksums…). But, as
> I said, it’s highly user-unfriendly and it won’t give you a 100%
> unique ID… Of course, you could always pack your software with
> a hardware dongle… :)))
>
> Miguel Monteiro
> xxxxx@criticalsoftware.com
> www.criticalsoftware.com
> ------------------------------------------------------------
> «Humour and love are God’s answers
> to Human weaknesses»
> ------------------------------------------------------------
>
> On Wednesday, May 02, 2001 1:46 AM, ““Bill M.”
”
> wrote:
> >Bogdan,
> >
> >There is not a serial number in the system that could not be altered
by
> >software before it gets to your app. Worse, there is no serial
number
> that
> >is permanent. What if the user upgrades a hard drive, or network
card
> or
> >motherboard? Now they have to call your company and get permission
to
> use
> >their software again?? If you are using this to protect software
that
> >costs anything under $50,000 US, please don’t torment your customers
> like
> >that. Locks that tie software to a machine are such a pain in the
> butt.
> >If I were emperor I would make this a capital offense Hey, I know
> how
> >about that spiffy CPUID Intel came up with? Grrrr…
> >
> >Bill M.
> >
> >“The opinions expressed by me definitely don’t match those of anyone
I
> have
> >ever worked for, they are uniquely my own!”
> >
> >On 05/01/01, ““Bogdan Coroi” ” wrote:
> >> Hi Pat,
> >>
> >> I looked at the address bellow, but there are some problems:
> >> 1. If one computer does not have a MAC…
> >> 2. #sn from that source code is not the manufacture serial, is just
a
> =
> >> format serial, and it can be changed software by many applications.
> >>
> >> Thank you very much for your help.
> >> Bogdan Coroi
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Miguel Monteiro wrote:
Hi Bill,
Intel’s CPUID purpose was to provide a consistent way of identifying
the processor family and characteristics without relying on devious
schemes and obscure processor flags…
Now imagine the following scenario:
-The user does not have a MAC…
-The spiffy “CPU serial nr ID «feature»” is disabled from BIOS…
Why not uuidgen? Is the function available from the INF file?
Ooops.
Personally I’m not very fond of uniquely IDentifying the equipment:
Agreed!
Cheers
Don Sharp
users will surely dislike that kind of “feature”. But if you *really*
need
to do that, my tip is to follow an “obscure” approach (don’t quote me
on this) and use a key made up of a mixture of a few “fixed”
characteristics (e.g. the CPU characteristics - OK, Bill, now use the
CPUID… - and some clever hdd and BIOS checksums…). But, as
I said, it’s highly user-unfriendly and it won’t give you a 100%
*unique* ID… Of course, you could always pack your software with
a hardware dongle… :)))
«Humour and love are God’s answers
to Human weaknesses»
On Wednesday, May 02, 2001 1:46 AM, ““Bill M.” ”
> wrote:
> >Bogdan,
> >
> >There is not a serial number in the system that could not be altered by
> >software before it gets to your app. Worse, there is no serial number
> that
> >is permanent. What if the user upgrades a hard drive, or network card
> or
> >motherboard? Now they have to call your company and get permission to
> use
> >their software again?? If you are using this to protect software that
> >costs anything under $50,000 US, please don’t torment your customers
> like
> >that. Locks that tie software to a machine are such a pain in the
> butt.
> >If I were emperor I would make this a capital offense Hey, I know
> how
> >about that spiffy CPUID Intel came up with? Grrrr…
> >
> >Bill M.
> >
> >“The opinions expressed by me definitely don’t match those of anyone I
> have
> >ever worked for, they are uniquely my own!”
> >
> >On 05/01/01, ““Bogdan Coroi” ” wrote:
> >> Hi Pat,
> >>
> >> I looked at the address bellow, but there are some problems:
> >> 1. If one computer does not have a MAC…
> >> 2. #sn from that source code is not the manufacture serial, is just a
> =
> >> format serial, and it can be changed software by many applications.
> >>
> >> Thank you very much for your help.
> >> Bogdan Coroi
>
> —
> You are currently subscribed to ntdev as: xxxxx@iee.org
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
On 05/02/01, ““Miguel Monteiro” ” wrote:
> Intel’s CPUID purpose was to provide a consistent way of identifying
> the processor family and characteristics without relying on devious
> schemes and obscure processor flags…
I worked at Intel when this blatently stupid idea came out, and that was
not the scuttle-butt I was getting on the purpose of the ID. They had all
sorts of security people working on this and coming up with all kinds of
security ideas with this thing. The major impetus, and its a valid one,
was to secure processor firmware updates. The initial versions of the PIII
that had this ID feature did not have a way to turn off the feature. It
wasn’t until the hue and cry of the public scared Intel to death, that the
BIOS turn off ability came into play.
I have worked in software for some time now, and all in all I think the
whole security matter is just blown way out of preportion. If you have
software that is high margin, low volume, you might, MIGHT have a reason to
use a dongle. I don’t ever see a reason for mid to high volume software to
use any techniques like this. All it does is piss off the honest people,
and you are going to see your stuff on a WAREZ site in a week no matter
what you do. Most people are honest, and those are the peoples whose money
I am going after. I am not going to get money from the others regardless.
Make it difficult to use illegally, yes, but you will never make it
impossible, so don’t piss off your customer base. Just my $0.02.
Bill M.
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> ----------
From: xxxxx@bsquare.com[SMTP:xxxxx@bsquare.com]
Reply To: NT Developers Interest List
Sent: Wednesday, May 02, 2001 3:00 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Unique ID
Make it difficult to use illegally, yes, but you will never make it
impossible, so don’t piss off your customer base. Just my $0.02.
I can’t agree more. Hope MS is hearing and will refuse the stupid idea with
XP registration. Or did they already?
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Most of the protection schemes I’ve seen were breakable with one instruction
change (jz/jnz to jmp or nops). It is really ridiculous to see something
like this combined with powerfull dongle. You’re right, watermarking is a
good option which doesn’t punish legal users but have limited use for
special software (IDA disassembler is an example). I think trying to protect
software is wasted time. Every protection is breakable and crackers would
enjoy good one, they must be bored with standard things.
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
From: danp[SMTP:danp@jb.rdsor.ro]
Reply To: NT Developers Interest List
Sent: Wednesday, May 02, 2001 12:08 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Unique ID
Most of the protection schemes Ive seen in my life where doomed from start
,
mainly because the team which implemented them did not made any effort to
look at their product
from the perspective of an attacker. Even using a powerfull dongle might
prove inefficient , because you still have to use wisely the features of
the
dongle , a task which many developers fail to accomplish. As for “obscure”
approches , security trough obscurity is
known not to work – is a fact which was proved too many times. Combine
cryptographic tehniques with traditional approaches , and add a strong
anti-debugging layer to your product. As for tracking leaks from customers
to the pirate market , I used with success
watermarking of excutables , i.e there are means to generate for every
customer a unique
executable which would identify him at any time , and if this is clever
implemented , those watermarks are extremly hard to be removed. This will
work if you have a relative small
consumer market for your program.
Best regards , Dan
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Please excuse me for this off-topic message, but since other people on
the list
felt free to comment the subject, I’ll give my opinion too… (and stop
here,
this is not a “me too” thread, I know).
On Wednesday, May 02, 2001 11:00 AM ““Bill M.””
wrote:
>On 05/02/01, ““Miguel Monteiro” ”
wrote:
>> Intel’s CPUID purpose was to provide a consistent way of identifying
>> the processor family and characteristics without relying on devious
>> schemes and obscure processor flags…
>
>I worked at Intel when this blatently stupid idea came out, and that
was
>not the scuttle-butt I was getting on the purpose of the ID.
IF the CPUID purpose was the one I mentioned above, it wouldn’t be
that stupid (by “characteristics” I don’t mean a serial number ID; I
mean
tech specs). But, hey, we know there’s always someone willing to take
advantage of good ideas and turn them into bad things… 
>They had all sorts of security people working on this and coming up
with
>all kinds of security ideas with this thing. The major impetus, and
its a
>valid one, was to secure processor firmware updates.
See what I mean? The “valid” concept you refer was probably an excuse
for other not-so-clear-and-not-so-valid motivations…
>The initial versions of the PIII that had this ID feature did not have
a way
>to turn off the feature. It wasn’t until the hue and cry of the public
scared
>Intel to death, that the BIOS turn off ability came into play.
>
>I have worked in software for some time now, and all in all I think the
>whole security matter is just blown way out of preportion.
I’m aware of it. And maybe the public overreacted (the media helped a
lot),
but in the end the public was right: people felt Intel was not playing a
clear
game. It was kind of someone attaching your suit a tracking device
without
your knowledge: who knows what that could be used for? (There’s a lot
to discuss about this matter, but let’s keep up with the topic here)
>If you have software that is high margin, low volume, you might, MIGHT
>have a reason to use a dongle. I don’t ever see a reason for mid to
high
>volume software to use any techniques like this. All it does is piss
off the
>honest people, and you are going to see your stuff on a WAREZ site in
>a week no matter what you do.
I believe we’re all aware of the warez phenomena. Of course there’s no
such thing as an unbeatable protection scheme; I see protection schemes
just as specific means to achieve specific tasks in particularly
specific
situations. If you’re talking about a mass-distributed software
(M$-like)
you must face the fact that your software is going to be pirated anyway;
the best protection scheme your company could provide is a high-quality
software and high-quality customer/technical assistance; along with
that,
some techniques (watermarks, for e.g.) are very useful and will help
your company to keep track of customers and detect some abuses
(not all, of course, but maybe some important ones).
>Most people are honest, and those are the peoples whose money
>I am going after. I am not going to get money from the others
regardless.
>
>Make it difficult to use illegally, yes, but you will never make it
>impossible, so don’t piss off your customer base. Just my $0.02.
Sure. Just remember to give your customer reasons not to be pissed
with your customer support…
Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com
------------------------------------------------------------
«Humour and love are God’s answers
to Human weaknesses»
------------------------------------------------------------
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com