HP3000-L Archives

September 2002, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Olav Kappert <[log in to unmask]>
Reply To:
Olav Kappert <[log in to unmask]>
Date:
Fri, 20 Sep 2002 15:10:15 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (65 lines)
Wirt:

My previous PC did not even have a c: as a hard drive.  I had two floppy drives
(one being a:/b: and the other being a 3M Superdisk located at c:).  The hard
drive was located at d: and e:.  How would your protection scheme, check for this
possibility.

Olav Kappert


Wirt Atmar wrote:

> For several different products we're in the process of developing, we need a
> method of uniquely identifying PC's in the same way that we can identify
> HP3000's via the HPSUSAN number for reasons of minimizing piracy.
>
> We originally gave consideration to using the MAC address of the NIC card in
> the PC but two considerations made that option less attractive. One is minor:
> there may be more than one real or pseudo NIC address in the PC and thus
> there is some complexity determining which NIC is primary. However, the
> second was more major: any NIC's MAC address can be changed by the user. The
> "burnt-in" address remains the same after the change. The new aliased
> addressed resides only in the registry, but after some substantial attempts
> at trying to get the API's not to do this, the API's always read the
> registry's MAC address in preference to the actual hardware address. We
> simply don't want to turn off a user's license if they should change the MAC
> address of their PC's NIC for some reason.
>
> Secondly, we have given very serious consideration to reading the BIOS &
> motherboard serial numbers/asset tags/product descriptions, but no Windows
> API exists to this, in part because of the privacy issues that surfaced a few
> years ago. However, surprisingly a scripting mechanism now exists so that any
> remote user can read this information off of your PC. Remote Windows
> management has become more important of late than privacy. While we could
> make this mechanism work, the complexity level to do so is surprisingly high.
>
> Thus, we're now planning on using the serial number of the c:\ drive as the
> unique identifying number of the PC. We can get that information quite easily
> and virtually instantly. Thus my questions are these: does anyone know if a
> disc's S/N can be changed via software methods, or is it truly "burnt-in"?
> This first question is driven by the second: when a single physical disc is
> partitioned, the higher-level partitions (d:/, e:/, etc.) are all assigned
> different serial numbers than that associated with the c:/ drive. The
> partitions have s/n's that are just single-digit increments of one another,
> but they are quite different than the base s/n of the disc. Does anyone have
> any idea about the algorithm associated with those higher disc partitions?
> Clearly, these partitions are being assigned arbitrary s/n's and those s/n's
> are not residing in a read-only memory somewhere in the mechanism of the disc.
>
> The first question, can the base disc s/n be changed?, is the more important
> of the two questions. If someone should re-partition their disc(s), I presume
> that the higher-level s/n's will change, but so long as the base s/n remains
> the same, we're not going to screw the customer up by saying he's no longer a
> customer.
>
> Wirt Atmar
>
> Wirt Atmar
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2