Processor ID

  • Thread starter Thread starter nano2k
  • Start date Start date
N

nano2k

Hi
I need to protect my application in a way. Just a "soft" protection,
not a very strong one.
So, using WMI I get the processor ID and compare it against a key.
Protection works well, until someone (me) decides to clone the system.
After cloning, all cloned systems work with the same key. That is, WMI
returns the same processor id on all workstations.
It seems that Windows "caches" the processor ID in the registry or
somewhere else - I didn't dig it - so that subsequent calls to WMI
returns the result from that location.
It's the only logical answer I could give.

My questions:
- is there a way to get a "phisical" processor ID? If yes, how?
- do you use a different kind of simple protection? If yes, which one?

Thanks.
 
Hi
I need to protect my application in a way. Just a "soft" protection,
not a very strong one.
So, using WMI I get the processor ID and compare it against a key.
Protection works well, until someone (me) decides to clone the system.
After cloning, all cloned systems work with the same key. That is, WMI
returns the same processor id on all workstations.
It seems that Windows "caches" the processor ID in the registry or
somewhere else - I didn't dig it - so that subsequent calls to WMI
returns the result from that location.
It's the only logical answer I could give.

My questions:
- is there a way to get a "phisical" processor ID? If yes, how?
- do you use a different kind of simple protection? If yes, which one?

Thanks.

HD serial imo rather than processor. And make sure there's a painless
way to reinstall it if say the HD needs replacing or the PC is
replaced, I'd say a 30 day grace period or similar to reactivate.
Linky below.

http://www.eggheadcafe.com/articles/20030511.asp
 
Why should I use HDD serial?
The hard disk is the first (maybe second, after memory) thing that is
subject of replacement (damage / upgrade, etc).
The processor is the piece that virtually never changes inside a
system.
Thanks for the link. I already implemented that idea, long ago, and
THAT idea is WRONG. I already explaned what happens when cloning
systems. Both the original system and the cloned system return the
same process id, which is incorrect.
Let's assume you buy an application from me. My app is protected using
the processor id retrieved through WMI.
You buy one license. I install the license to your computer. After
that, you are free to clone your hdd and restore it to as-many-systems-
you-want. And here we are! You payed 1 license, you got N licenses
without the need to ask me extra lincese keys.

Thanks again.


DeveloperX a scris:
 
Why should I use HDD serial?
The hard disk is the first (maybe second, after memory) thing that is
subject of replacement (damage / upgrade, etc).
The processor is the piece that virtually never changes inside a
system.
Thanks for the link. I already implemented that idea, long ago, and
THAT idea is WRONG. I already explaned what happens when cloning
systems. Both the original system and the cloned system return the
same process id, which is incorrect.
Let's assume you buy an application from me. My app is protected using
the processor id retrieved through WMI.
You buy one license. I install the license to your computer. After
that, you are free to clone your hdd and restore it to as-many-systems-
you-want. And here we are! You payed 1 license, you got N licenses
without the need to ask me extra lincese keys.

Thanks again.

DeveloperX a scris:






- Show quoted text -

Yeah that's the point. With VMWare at least you can't change the HD
Serial number (You can change the volume ID, but that's different). Of
course there's nothing to stop them installing it onto the vmware
image after, but I think it has a specific serial so you could always
just check for that and refuse to install.
Saying all that people like virtualisation so preventing them from
installing your product in a vmware environment will probably lose you
some friends/sales and alot of licenses are far more virtualisation
friendly now.

It's a tricky nut to crack, look at the efforts MS have put into
preventing their software from being pilfered.
 
Hi,

| Hi
| I need to protect my application in a way. Just a "soft" protection,
| not a very strong one.
| So, using WMI I get the processor ID and compare it against a key.
| Protection works well, until someone (me) decides to clone the system.
| After cloning, all cloned systems work with the same key. That is, WMI
| returns the same processor id on all workstations.
| It seems that Windows "caches" the processor ID in the registry or
| somewhere else - I didn't dig it - so that subsequent calls to WMI
| returns the result from that location.
| It's the only logical answer I could give.
|
| My questions:
| - is there a way to get a "phisical" processor ID? If yes, how?
| - do you use a different kind of simple protection? If yes, which one?


I think this question will be better answered in a WMI NG. Personally I
would find it very weird that the processor ID is cached. and transported to
the others system.
 
Personally, I've developed software protecting mechanisms in the past and I
what I have done is to compile a set of data from different pieces of the
hardware, as:

a) BIOS information - there is a piece of ROM, which is available for PEEK,
which does not change.
b) Hardware information - there is a set of data on the ROM which can also
be used for that purpose. Normally starts on the segment F000
c) CPU data (speed, etc)
d) HD information, normally serial info
e) video card information: normally starts at segment C000 or C800,
depending on the card type

Besides, today Windows protection mechanisms are groing. You could use data
from the registry for that.

You can compile a set of bulk data and compare against the same data you
would gather from the machine

I hope it helps.
 
Back
Top