Hello. I'm a newbie who is just getting into all this Windows activation stuff, and I read that Windows uses a public/private key scheme with a Schnorr signature algorithm. Question is, since the WPA system for XP is pretty dated, and they haven't changed the algorithms for XP ever since, is there any known crack or way to generate the activation ID (that you have to type in the "Activate by phone" window) based on the unique Installation ID generated for every PC?
As long as you can hide the private key there would be no need to change the algo. PGP for instance is secure until today and is also 'dated'...
Ok, understood. HOWEVER, I found a really nice method to activate Windows XP that doesn't requiere any software or search for new keys. Basically, some guy cracked the private key used to sign the hash of the product key, and made a keygen for WinXP and Server 2003 keys. The neat part is that since the key is generated by YOU and only YOU, Microsoft won't blacklist it since it's never published online! Thus allowing activation, either via phone or internet (if you have SP3) I can't post links here due to not having 5 posts or more, but if anyone wants, search in google "Windows XP schnorr reddit" and a result should come up from the r/reverseengineering subreddit.
There are XPKey and XPKey_OEM tools out there for years, where you could brute-force keys that passed the local validity check. However, these keys mean Jack Schitt to MS; they know what keys were issued by them, all others will fail validation.
Yes, but the idea here is not to generate keys, but to replicate what microsoft does when generating a Confirmation ID based on the Unique Installation ID generated on the activation window. That's what I'm asking if it's possible.
If it was possible, you would certainly have heard about it here. To my knowledge, that process is unbroken to that day. Even if it was broken in the past, MS would have just updated it and deprecated the whole old one. Nothing gained, permanently. OEM:SLP 1.0 and Volume licensing are the way to go. Especially the first is as permanent as you can get (if the OEM string in the BIOS remains the same, you can change all the hardware you want).
I am not sure the tools to generate the phone-activation keys were ever leaked, however there's plenty of keys that can be validated against windows update for XP still as of today (if that's what you were worried about). Good luck, though!
0x014, BYTE[0x04]: length of the elliptic curve parameters in DWORDS (for 2003 the each parameter (p, B(x,y), K(x,y) are 16 DWORDS long, for xp they are 12 DWORDS long) 0x018, BYTE[0x04]: length in bits of the resultant product id's Hash (for 2003 it's 31bits or 0x1F, for xp it's 28bits or 0x1C) 0x01C, BYTE[0x04]: length in bits of the resultant product id's Signature (for 2003 it's 62bits or 0x3E, for xp it's 55bits or 0x37) 0x020, BYTE[0x04]: unknown. xp does not have this data 0x024, BYTE[0x04]: unknown. xp does not have this data
Thank you, @pottzman! That explains some more of the BINK structure. I think that 2003 and XP may indeed also be using some different setup of the decoded data. I haven't had much time to look into the depths of XP yet. The fields for 0x014, 0x018 and 0x01C also match up with what I'm observing for a Windows 98 pidgen.dll BINK resource, so perhaps XP really didn't do anything novel there, and 2003 is the vast outlier. I know that for regular XP, the part from which the product ID (channel ID and the serial number) are derived is in the front, i.e. the first bits of the decoded array. For 2003, I can't seem to make out any matching bit pattern in the decoded key yet.
I believe for 2003 the first 12bits (little endian) are the OS Family (ie VLK XXXXX-640-XXXXXXX-XXXXX) so the 640 part. after you calculate the product key into big binary number take the first 12bits (little endian) 010100000000 and Right Shift by 1 (divide by 2) to get PID.
New discovery: What I previously marked as "version" is more likely to be an offset to where the curve parameters begin (in words), relative to the first word after the BINK ID. XP has value 7, 7*4 == 0x1c, 0x004 (skip BINK ID) + 0x1c == 0x20, which points to p. 2003 has value 9, 9*4 == 0x24, 0x004 (skip BINK ID) + 0x24 == 0x28, which points to p.
Why would you bother generating activation IDs when you can just use a hacked pidgen.dll (allows you to use any key you want) and a hacked winlogon.exe ? You can just replace the original files on your iso with the hacked ones and forget about keys and activation.
theres the latest version of wpakill from early 2006 that does everything for you, its just a dll that hooks on to something and wont touch system files, you dont need to modify system files when you have a dll hooker that does the job for you. its still here on thepiratebay and its called Windows XP Activation Crack and it had 19 seeders. it works both for xp pro and home, dont know about x64 xp pro, might've already had a working crack since wpakill has a 64bit version of the dll.
i've just tested it days ago and it works fine but kinda like s**t sometimes, i suggest you use wpakill 2.3.0 instead of this "dll hooker", because windows product activation is not completely gone as it claims especially when you use it and then boot to safe mode with networking, you will have wpa whining at you to boot normally so it can "activate" and then it resets the value in oobetimer, temporary fix for this is just to reregister the dll with this command "rundll32 antiwpa.dll, DllRegisterServer" so that it puts the value back to what it was. but anything else? it works just fine, theres no wpakill 2.3.0 for 64bit and ia64 versions of xp though, :/ if you have xp 32bit, you should use wpakill 2.3.0 from may 2009 instead because it works completely fine, and is much more recent than the latest version of wpakill which is from late 2006. i know that perhaps any or some of you despise antiwpa because it modifies system files but it clearly does the job and it works perfectly fine, it only modifies 1 file and that is just winlogon.exe, whats wrong with it??? it also deletes winlogon.exe in dllcache but you can get that back if you just get a fresh copy of xp of the version you have installed and do sfc /scannow and it will come back again.
Quick check into the licdll mess: The decryption key mentioned by Licenturion/Fully Licensed in their XPdec tool for the SHA-1-based custom Feistel cipher could be confirmed present in XP RC1, but is missing from the XP SP3 licdll.dll. More than likely, not only has the key changed, but the algorithm has also changed because XP SP3 has more digits in the installation ID than XP RC1 did. As for the feasibility of breaking this... A confirmation ID looks roughly something like this: 138803-083396-259204-843822-309523-580033-357353-657735. The last digits of each are a checksum for each block of digits to guard against typos. This leaves a number 1388008339259208438230952580033573565773, which amounts to about 131 bits of information that can be stored in the confirmation ID. Assuming Microsoft re-used the same signature system for the activation system as they did for the product keys (Schnorr signatures with b-bit hash and a 2b-bit scalar), this would amount to a 43-bit hash and a 88-bit scalar; perhaps even a bit higher since the first digit in decimal for the test number is a 1 rather than a 9 (which would give a 133-bit number rather than a 131-bit number). Breaking an elliptic curve with a point of 88-bit order would be out of the question on commodity hardware and would require some non-trivial dedicated hardware out of the reach of non-state actors. If my assumption holds true, the the regular/retail activation system cannot be broken to generate confirmation IDs.