Cloning Window XP Embedded

[Peter Herijgers]

Is it possible to clone a Windows XP embedded Image?

Let's say that one of my customers uses my Windows XP embedded application.
He knows what kind of hardware I am using and makes a clone machine.
The Windows XP embedded Image is stored and installed on a CF card.
Is it possible to clone (copy) the CF card and install the clone on a
hardware identical machine?

Peter.

 

[Slobodan Brcin \(eMVP\)]

Hi Peter,

If you don't make some copy protection he can copy your image even to similar machine and it will still work.

Best regards,
Slobodan
PS:
Cloning image with same hardware is regular usage thing with XPe that many people here practice for creating large quantities of
same device.

 

[Heidi Linda]

Licencing might be an issue to be aware of. IIRC you need to buy a sticker
for each hardware unit you're running a build on.

 

[Philippe Sacx]

Yes you can but you may run into problems if the targets units are part of a
workgroup or a domain.

The reason is that all the target units will have the computer name and the
SID on the master unit. This is a problem as NTFs, XP and the domain server
use these information.

It is straight forward to change the computer names. To change the SIDs you
can use the "New SID" utility from www.Systeminternal.com.
Be aware that Microsoft does not support this type of cloning.
So, if you have it, you may want to use FBReseal.exe. Thats from Microsoft.
More information about XPe cloning on www.msdn.microsoft.com


Phil.

 

[Peter Herijgers]

Any ideas how I can prevent the cloning of a WinXP embedded machine?
One thing I could do is to get every serialnumber of every pice of hardware
and link those serialnumbers in my application.
But this means that I have to build every application over and over again.
I don't mean the XPe image but my application running on XPe.

Peter.

 

[KM]

Peter,

I don't understand why do you need to prevent cloning of your images.
Unless you implement a very complex protection scheme that would include some reliable encryption at the system boot time
(basically, you have to replace NT loader) or some specifics in hardware or BIOS implementation, it is going to be pretty easy to
copy the image offline and hack any application or shell protection in it.
If you, however, want to protect your own IP (your application) then it is a topic for a different NG - security, or etc. There are
many different ways to do the app protection (although none of them gives you absolute assurance).

If you still want to bind yoru app to some serial numbers on the device, first use MAC address if available, and also use registry
or a setting file to store encripted serial numbers. You don't necessarily need to rebuild the app each time. But again, it is just
going to be a protection againt a dump user, no more.

 

[Slobodan Brcin \(eMVP\)]

Konstantin,
I guess that by "prevent cloning" he means "copy protection".

Peter,

Like Konstantin said you can store encrypted numbers that you want in file or registry. This will be no less secure that hardcoding
it in your application.
Unfortunately I have spent great deal of time trying to make same thing.
Since most of our application functionality is stored in drivers itself. I have made protection mechanism there. I'm locking to MAC
addresses and to our hardware (among other things driver is used to drive it).
This is relatively good protection, compared to what most people can even try to do. But unfortunately since I know how this
protection is working it would take me less that a day to bypass it completely.
Trough additional drivers and hardware modification.

So the only thing that really protect your device is how much time is someone ready to spend on removing your protection.

Anyhow if you make Win32 application only. Someone could decide either to bypass your protection by modifying the application
binaries. Or if you choose to use MAC or other hardware info then simple filter drivers could fake those values :-(

Quote from Konstanin: "But again, it is just going to be a protection against a dump user, no more."
The more time you spend creating your protection the more ways how it can be removed will reveal to you by it self.

Best regards,
Slobodan

 

[Simon Wilton]

Protecting the whole XPe image is a bit tricky, but protecting your
application might be sufficient. If some-one copies your hardware and uses a
hacked version of your XPe image to run their application in their product
its less of a problem than some-one copying your whole product (I guess that
the MS perspective is a little different given that the OS image is their
product - albeit tailored by you).

You could us a fairly simple scheme that keeps a hash value derived from
some unique attribute of your hardware in the registry (or an INI file). The
MAC address would do or the media serial number (google for DiskID) - not
the volume serial number which can be hacked very easily. This is only
written to the registry by using a feature in your application known only to
your organisation (perhaps a web service on a private server or a TCP
session if you don't have a UI to enter the info). This happens as part of
manufacture. You application has the knowledge to derive the hash embedded
in it, and can compare the value in the registry with that calculated from
the hardware attribute. That should do for a casual hacker who could see the
registry read, but have no real idea how to derive the correct hash value
for the hardware. You need to be a bit defensive to prevent the application
being patched to make the test pass regardless of the data. There is plenty
of info around on how to approach that.

You could use a commercial product like CrypKey or FlexLM. This is built
into your application and requires that the folder containing the
application is writable when the application is unlocked.

If your aplication includes a custom shell, putting the protection there
make the image all but useless.

Its also worth doing a risk assessment to decide how much profit you could
lose, against the cost of building the defences.

HTH

Simon

 

[KM]

Frankly, I've learnt that one of good ways to protect device is in locking down the hardware - not providing an easy way to open the
box, using on board CFs, etc. Again, that would not be an ultimate solution but for a software guy (who usually play around the OS
and does the cracking/hacking) it may be a solid wall that hard to break through.

 

[Peter Herijgers]

You see, we are just using of the shelf hardware. The only thing that is
comming from us is the software (our app and the XP image).
We just use an of the shelf CF which is placed in an PCMCIA slot. So every
one can buy this.
I can find a reason why my customer wants to clone the system, the price of
the system.
Buying the hardware himself and copy the CF is a very cheap solution for him
to get more systems.
There is no way for us to develop our own hardware with onboard CF/ROM.

But what if my customer clones the system. Are we responsible for this?
He has only one licence of XPe? By cloning the system he gets more systems
for the price of one licence of XPe.

Peter.

 

[KM]

Peter,

You see, we are just using of the shelf hardware. The only thing that is
comming from us is the software (our app and the XP image).
We just use an of the shelf CF which is placed in an PCMCIA slot. So every
one can buy this.
I can find a reason why my customer wants to clone the system, the price of
the system.
Buying the hardware himself and copy the CF is a very cheap solution for him
to get more systems.
There is no way for us to develop our own hardware with onboard CF/ROM.

But what if my customer clones the system. Are we responsible for this?
He has only one licence of XPe? By cloning the system he gets more systems
for the price of one licence of XPe.

I am a developer and cannot read Legal stuff clearly but I think you are
protected by US law when you distribute XPe images. If you signed specific
QEM argreements with MS.
Read some more info here:
http://www.bsquare.com/licenses/resourcecenter/faqs.asp
And on the OEM Secure site: http://microsoft.embeddedoem.com.

KM

 

[Slobodan Brcin \(eMVP\)]

Hi Peter,

In your case where you do not supply your hardware, you will have to either rely completely on Legal copyright protections.
Or you will make some phone/net activation mechanism like that Win XP Pro uses.

Best regards,
Slobodan

 

[Peter Herijgers]

Well we also supply the hardware otherwise we may not use XPe.
XPe may only be sold as a complite system.
We only develop the software and use standard hardware.

Peter.

 

[Slobodan Brcin \(eMVP\)]

Hi Peter,

You will need to provide customer with EULA, that prevent them from copying image and other legal stuff.
If you want to protect your image from piracy then you will have to include some form of software lock protection.

You should certainly check this topic with MS legal department but I think that you are not responsible if your customer multiply
your image.

Best regards,
Slobodan

 

[Gereon]

These are all good ideas. In my experience, here's a few more:
If you do implement some copy protection, obfuscate when it is run and how
it fails. Since you are providing them the whole software package, you
have a lot of power to hide checks in hard to track places, and do things no
software for a regular PC would dare to do. Stuff it in a kernel driver,
tagged on to a timer somewhere. Have it check rarely and randomly. Nothing
worse than a system that runs for a week, then locks up. Force it to
bluescreen with a message that's obvious to you that the copy protection
went off, but to them will just seem like the product crashed. Chances are,
they'll report it to you as a bug, and then you'll know.