Is there any way to crack/decrypt the WinXP CONSUMER activation system to generate Activation IDs?

for OEM-SLP 1.0 (xp - 2003) activation all you need is the Vendor String. you can use any OEM-SLP product key with any Vendor bios string.
for OEM-SLP 2.x (vista onwards) activation you need to use .bin file + xrm-ms file plus correct product key

 

That's the reply to a different question

We aren't discussing here how to activate a generic windows.

What I need to know or, to put it better, what would be nice to know is, if you have a first hand info about the XPM activation using the way you suggested.

Not that I don't trust you, but

your "AFAIK" is exactly opposite to @Carlos Detweiller's "AFAIK", and also, like I said, my failing memory is somewhat tickling.

I used (like more than a decade ago) the .bin way surely for a reason. Maybe VBOX of the time didn't work or something.

Maybe there was a side effect or whatever, but for sure there was something (which maybe isn't a thing anymore, in vbox 5/6/7/...)

 

yes maybe carlos is correct if using Windows XP Mode in another virtual machine environment (VirtualBox).

 

Check the dedicated VirtualBox release topic. They had to patch the vboxdd2.dll file with the Windows_Virtual_XP_randomnumberhere string every new release. In the linked post is explained that the string is both too long and expected to be in a certain memory location, so the usual strings method doesn't work like it does for HP or Dell.
Of course, I don't know if that's still the case for modern VB releases, thus the AFAIK (I'm using 5.2.45).

 

Hey, another question if you don't mind.

How did you defeat the obfuscation in liclib.dll and related binaries to extract the parameters? Currently trying to extend this to MS Plus! ME and Office 2003

 

Anyway I just checked the my original .bin file and it's from sept 2011, so that non intrusive method was known *at least* from that date.

But here on MDL looks like it took two years before someone noticed

 

It turns out that the bitfields in https://forums.mydigitallife.net/th...rate-activation-ids.80133/page-2#post-1640340 are a bit incorrect and the correct unpacking is:

Code:

pid1 = productid & ((1 << 17) - 1)
pid2 = (productid >> 17) & ((1 << 10) - 1)
pid3 = (productid >> 27) & ((1 << 24) - 1)
version = (productid >> 51) & 15
pid4 = productid >> 55

assert version == (9 if len(iid) == 17 else 10)

It does not matter for SP1+ IIDs, but for pre-SP1 the code only works if media product code (the first 5-digit part of product id) is odd. (Russian XP RTM Home is 55681, Professional is 55683, so my testing has not catched this.)

If you want to get pre-SP1 confirmation IDs for even product codes, patch the byte at offset 0x1906 in xp_activate32.exe from 01 to 00.

 

With the help of d45h, we got Confirmation ID generation working for Microsoft Plus! Digital Media Edition and Office XP.

I can't seem to post any links or pictures, but I have a SageMath notebook that generates correct confirmation IDs, and we will be implementing this into WindowsXPKg soon™.

 

So you're smart enough to turn the encryption inside-out, but not to write h**p:// , instead of http:// ?

 

Online activation (still works, just update your root certs) accepts keys generated by WindowsXPKg.

 

Like I said in a previous post, I really believe microsoft have "disabled" the activation checking for these old o/s's. I think their server just accepts all product keys now.

 

I'd be curious to know if they kept the "same formula" for the Vista phone activation or if they figured that somebody probably already broke it back then.

 

No, that one is cryptographically good.

 

“cryptographically good” meaning hasn’t been broken/cracked yet or is such a heavy computational task that todays PCs don’t have the computing power?

 

To be precise, it requires calculating discrete logarithms in a 128-bit group.

 

It is not so difficult. You can try maybe with the number field sieve algorithm or parallel version of Pollard's rho algorithm

 

Care to elaborate?

 

What kind of group? A group formed by elliptic curve points? A group formed with multiplicative groups?

 

That does not really matter for generic methods.

If you can collect several valid pairs of installation-confirmation codes, then you have a choice.
Without any pairs, the only choice is GF(p^6). And before you think about specific methods (NFS and such), keep in mind that their performance is determined by the size of the entire field, not the subgroup, and the field is 793-bit (p is 133-bit).
With one valid pair, there is an alternative - elliptic curve over GF(p^3). Impractical, since a single group operation in this setup is more costly than in the previous setup (afaik).
With 33 valid pairs, there is another alternative - elliptic curve over GF(p) (p is still the same, 133-bit).
More pairs won't improve anything.