API to collect some unique IDs

Hi all,

Is there any API to collect some unique IDs (such as CPU id, harddisk id,
SKU, etc) from the system w/o running the final software as root?

I've looked into dmidecode.c but it is unable to read /dev/mem without the
root account. Going further, demicode cannot be run even if the user is
added to the kmem group. Is there anyway to get past this? I am using
Ubuntu 7.10

Thanks and best rgds,
Alex

On 2008-02-21 14:39, Alex wrote:
> Hi all,
>
> Is there any API to collect some unique IDs (such as CPU id, harddisk id,
> SKU, etc) from the system w/o running the final software as root?
>
> I've looked into dmidecode.c but it is unable to read /dev/mem without the
> root account. Going further, demicode cannot be run even if the user is
> added to the kmem group. Is there anyway to get past this? I am using
> Ubuntu 7.10
>
> Thanks and best rgds,
> Alex
>
>

Maybe you have something useful in mind, but every time I had heard this
question, it come from someone that just don't get the idea with free or
open software, and will figure out a way to "protect" their software,
and is trying to figure out a way to make a program that refuse to work
when copied, and will be a big problems for the few customers one day
when then replace a machine and you are gone and forgotten.

/bb

Alex schrieb:
>
> Is there any API to collect some unique IDs (such as CPU id, harddisk id,
> SKU, etc) from the system w/o running the final software as root?
>
For which purpose you need such an API? Some licensing scheme?

Note that if a geneneric API for such things existed, it would be easy to
circumvent. Enforcing licenses on a user-controlled machine must be done in
an obscure way so the cracker has to take more effort than the software's
worth.

Kind regards

Jan

On Feb 21, 5:39 am, "Alex" <a...@nospam.nospam> wrote:
> Hi all,
>
> Is there any API to collect some unique IDs (such as CPU id, harddisk id,
> SKU, etc) from the system w/o running the final software as root?
>
> I've looked into dmidecode.c but it is unable to read /dev/mem without the
> root account. Going further, demicode cannot be run even if the user is
> added to the kmem group. Is there anyway to get past this? I am using
> Ubuntu 7.10

Just pick a reasonable file name '/etc/unique_id' and document that a
unique world-readable identifier must be placed there. Don't run
unless there's an ID there. You can create your own randomly on
installation if you like, if it's 160-bits or more, it's sufficiently
likely to be unique as makes no difference.

DS

Alex wrote:
> Hi all,
>
> Is there any API to collect some unique IDs (such as CPU id, harddisk id,
> SKU, etc) from the system w/o running the final software as root?

Well... you could run at root via some kind of roll based mechanism (e.g. sudo).
But barring that, there's a lot of this kind of info populated into /sys...
go exploring.

This little tool I wrote might help with exploring /sys...
http://endlessnow.com/ten/Source/showsysfs-sh.txt

>
> I've looked into dmidecode.c but it is unable to read /dev/mem without the
> root account. Going further, demicode cannot be run even if the user is
> added to the kmem group. Is there anyway to get past this? I am using
> Ubuntu 7.10
>
> Thanks and best rgds,
> Alex
>
>

....snippity...

And examine hal too... lshal

Chris Cox <ccox_nopenotthis@airmail.net> writes:

> Alex wrote:
>> Hi all,
>>
>> Is there any API to collect some unique IDs (such as CPU id,
>> harddisk id, SKU, etc) from the system w/o running the final
>> software as root?
>
> Well... you could run at root via some kind of roll based mechanism
> (e.g. sudo).

And how is that not running as root or rootlike for the duration of the
program which needs root access for the accesses he was mentioning?

> But barring that, there's a lot of this kind of info populated into /sys...
> go exploring.
>
> This little tool I wrote might help with exploring /sys...
> http://endlessnow.com/ten/Source/showsysfs-sh.txt
>
>>
>> I've looked into dmidecode.c but it is unable to read /dev/mem
>> without the root account. Going further, demicode cannot be run
>> even if the user is added to the kmem group. Is there anyway to get
>> past this? I am using Ubuntu 7.10
>>
>> Thanks and best rgds,
>> Alex
>>
>>

--
Murphy was an optimist.

Hadron wrote:
> Chris Cox <ccox_nopenotthis@airmail.net> writes:
>
>> Alex wrote:
>>> Hi all,
>>>
>>> Is there any API to collect some unique IDs (such as CPU id,
>>> harddisk id, SKU, etc) from the system w/o running the final
>>> software as root?
>> Well... you could run at root via some kind of roll based mechanism
>> (e.g. sudo).
>
> And how is that not running as root or rootlike for the duration of the
> program which needs root access for the accesses he was mentioning?

Oddly enough key system processes are running as root on his
box by default (believe it or not).

What was your point? Other than trying to pick a fight?

I was trying to help.. and you were???

Sometimes people don't understand security. They simply
need somebody to help them to better understand how things
work. If you can't run something in a controlled manner
as root.. you've got to simply turn the machine off.

Alex schreef:
> Hi all,
>
> Is there any API to collect some unique IDs (such as CPU id, harddisk id,
> SKU, etc) from the system w/o running the final software as root?
>
> I've looked into dmidecode.c but it is unable to read /dev/mem without the
> root account. Going further, demicode cannot be run even if the user is
> added to the kmem group. Is there anyway to get past this? I am using
> Ubuntu 7.10
>
> Thanks and best rgds,
> Alex
>
>
Not so unique is the result of
$ lspci

But the combination of results is less than common.

Having a look in /etc/fstab for the UUID of the hard disk is more unique
yet it can be spoofed.

Chris Cox <ccox_nopenotthis@airmail.net> writes:

> Hadron wrote:
>> Chris Cox <ccox_nopenotthis@airmail.net> writes:
>>
>>> Alex wrote:
>>>> Hi all,
>>>>
>>>> Is there any API to collect some unique IDs (such as CPU id,
>>>> harddisk id, SKU, etc) from the system w/o running the final
>>>> software as root?
>>> Well... you could run at root via some kind of roll based mechanism
>>> (e.g. sudo).
>>
>> And how is that not running as root or rootlike for the duration of the
>> program which needs root access for the accesses he was mentioning?
>
> Oddly enough key system processes are running as root on his
> box by default (believe it or not).

I know. What is your point? Seriously.

> What was your point? Other than trying to pick a fight?

my point was that running it via sudo is running it as root in most
cases. He wanted a way to access these things NOT as root. No
fight. Just asking why you answered as you did.

>
> I was trying to help.. and you were???

Correcting you.

>
> Sometimes people don't understand security. They simply
> need somebody to help them to better understand how things
> work. If you can't run something in a controlled manner
> as root.. you've got to simply turn the machine off.

WTF are you talking about?