Question: when you install some kinds of non OSS software, they generate a machine ID. You send this to the maker, they then send you back a registration code which works for that particular machine, and only that machine. Not even that machine, if you make too many changes of hardware.
Is it possible to tweak a different machine so it generates the same machine ID?
This is stuff that comes free with several thousand pounds worth of hardware, does something very simple, like generate a hash index of some sort on a flash card to make some standard format files accessible to the hardware. But for some crazed reason the suppliers of the hardware want to restrict the use of their stuff to one specific machine. I want to know there is a backup solution, should they go bust, or get acquired and suddenly charge exorbitant prices to move the stuff to a different machine.
I am thinking, with considerable sense of humour failure, that one solution might be, install into a VM, then generate the activation for that VM, and then make an archive copy of the VM, so one would always be able to move that VM. I notice that vmware has an option for keeping the machine ID when you move installations. Which is totally ridiculous, but at least you would not have several thousand pounds worth of hardware at the mercy of a whim of some people you have never heard of somewhere in the wilds of Provence. Or their potential purchasers in Kazakhstan!
Can you imagine then, you run Linux in a VM, then you run Wine in that VM, all to be able to be sure of having a moveable solution for your Windows package in case one of your machines explodes or gets stolen! Nuts.
Is there a simpler way by spoofing the machine ID?
Peter
I would of guessed not without knowing the algorithm used to generate the key, time to get your reverse engineering hat on!
Work out what kind of hash/encryption is used first, and then I don't know, use the date+time+MAC_ADDRESS+MoBo_Serial# and see what you come up with etc etc
Its going to be a long winded and almost impossible method of doing it. Instead you might want to try to reverse engineer the software that generates the key, then you can work it out. This is a much more realistic solution.
On Thu, 18 Feb 2010 21:37:25 +0000 James Bensley jwbensley@gmail.com wrote:
I would of guessed not without knowing the algorithm used to generate the key, time to get your reverse engineering hat on!
Work out what kind of hash/encryption is used first, and then I don't know, use the date+time+MAC_ADDRESS+MoBo_Serial# and see what you come up with etc etc
This has got me wondering how many unique ID numbers there are in a machine that could be used in this particular calculation.
Steve.
Steve Fosdick wrote:
On Thu, 18 Feb 2010 21:37:25 +0000 James Bensley jwbensley@gmail.com wrote:
I would of guessed not without knowing the algorithm used to generate the key, time to get your reverse engineering hat on!
Work out what kind of hash/encryption is used first, and then I don't know, use the date+time+MAC_ADDRESS+MoBo_Serial# and see what you come up with etc etc
This has got me wondering how many unique ID numbers there are in a machine that could be used in this particular calculation.
There are various methods available, most of which can be faked or are otherwise not always reliable.
From the top of my head as follows.
CPUID serial, P3 and above. Not trivial to fake afaik but can be disabled in the BIOS of the host.
Volume ID's/UUID's. Trivial to fake, even accidentally when using disk images sometimes. MS themselves offer a free tool to change volume ID's
Ethernet MAC address. dependent on there being a network interface, causes issues if the interface is changed/upgraded, easy to rewrite at a software level, possibly not so easy to rewrite at a hardware level.
Other serialisation, so on Windows you could key against the OS's product key which is available from the registry.
TPM module (if available and enabled in the BIOS)
anyone want to add stuff I have no doubt forgotten ?