|
|||
If Microsoft did this correctly, it's not going to happen. What happens is that XP examines your hardware and from that generates a fingerprint (as described here) and that gets sent to Microsoft either by direct internet connection or by you reading a long string of digits to someone over the phone. At Microsoft that number is logged, and it also gets enciphered. The output of the cipher is then given back to you and gets stored in your registry. Each time you boot your computer, XP regenerates the fingerprint, and also deciphers the key in the registry, and compares the two. If they match "close enough" then it will let you run. Otherwise it forces you to register again. But they're using an asymmetric cipher, also known as a "public key cipher". Presumably they're using RSA; the number of bits involved is small enough so that RSA's inefficiency is unimportant. The whole point of an asymmetric cipher is that knowing the public key doesn't help you to find the private key. This article proposes creating a whole series of fingerprint/validation-key pairs and from that figuring out how they're created. That won't help you if indeed they're using RSA. Anyway, he's working too hard; if he really wanted to find out what was going on then the way to do it would be to find the code which interpreted the activation key from the registry and reverse engineer that. Then you could get the public key, and see how many bits it is. If it is a thousand bits (and it's likely to be more) then you can forget about cracking it. So what other alternatives are there? One would be to actually replace the module in XP which does the validation, to make it simply say "We're validated" unconditionally. The problem with that is that Win2K (and presumably XP) have integrity checks built in now. DLLs and other system code files have checksums and other validation mechanisms and they're checked before being used. This was put in place to protect against trojans and also to prevent so-called "DLL hell", and what happens is that if a bad (i.e. altered) file is found then you're prompted for your install disk or other access to a valid file) and the bad one gets replaced with a good one. So secondarily it would be necessary to figure out how those integrity checks work so that you could make your bogus validation module look correct. At that point you're well beyond the scope of effort that I think a typical cracker is willing to expend. (discuss) |