Key Generation Knowledge Base / Forum

[CONIGUERO]

It would be pretty useful to know how Windows 98 (and all its editions) verifies its product keys. At first glance, it seems to be a pretty similar system to XP's. 98 seems to be an outlier in the retro Windows scene, as nobody has come up with a generator yet, whereas XP has this one and the versions before 98 use a simple algorithm with many GitHub repos implementing it, some in creative ways.

[Endermanch]

There is a 5-in-1 generator from MSKey for Windows 95, Windows 95 / NT 4 OEM, Windows 98, Windows 98 OEM and Windows 98 Upgrade. Even if I theoretically implemented Windows 98 generation, that would be a job for a different keygen.

[grechnik]

It would be pretty useful to know how Windows 98 (and all its editions) verifies its product keys. At first glance, it seems to be a pretty similar system to XP's. 98 seems to be an outlier in the retro Windows scene, as nobody has come up with a generator yet, whereas XP has this one and the versions before 98 use a simple algorithm with many GitHub repos implementing it, some in creative ways.

The check is exactly the same as in XP, only parameters are different:

p=0xf2f1c54eb7f01ded40c52af55d4994d53d78c425292a91344d6a1d20be292045776ac9ca3d4d2337348e2177304cc3c1
G=(0x541bd6f01e811d44308971a014a08dda42f97d1f2fe0d104946d4c7e3b02583d30f6a2816bd9af6120cc74df0d327b51,
    0xbb6eb8c546c6f1fdc55bef78a28c6b238225f9a79c85dadf5679e251b16775ee1a44fa0fb6f7157e49dfc511b014b208)
pub=(0xd13b9794f20dfe26b8f1029330695244c3762c5f7ca58cc3de6015967384d7c9f6618c27c34ac6def764ae8ee3ec25b9,
    0xc055572b8b15fd56658c0bf146cba480d8e685bcc27a8ac6269fe3b399673682046580c3c4e5e45229262ce86e792574)
order=0xFD5BF182B5E5E9
pri=0x95E1A9256A0149

for Retail keys,

p=0xec224ff2613a9fe1411b51e89634643f79a272402ee146b012a3f71098c7e75df4bf8b3713c4f0ce56691ce56b9b5029
G=(0xb5e1957b19951b5523204a62fd83ab22056f59a13bf8aaaf16ac10b7540f8ea92ba28dbfa68996fa12510c024f912340,
    0xa84fbc02f311b1fd4521773e01821bd047f067c496ad54ce1504315cb88667d69130caa25efb2cb1e479ed50efb40d6b)
pub=(0x26ea9efe57ab6da485225a13ed66533c143f81b7b9528e38c8568bb726a8f0f5607da0e8d85aebf2e1425758b409e811,
    0x1a7c4cebe5f3919e96876a447a813efcd920979e9610d2b2146a04fab1041b31ae65e24efa3e0b0d61622483655716c2)
order=0xE778E33AEE6B3D
pri=0xB9E99B9BB9812E

for OEM keys.

As far as I know, these parameters are the same for all editions except betas. (Upgrade keys differ from normal keys by the lower bit of Product Key.)

[CONIGUERO]

It would be pretty useful to know how Windows 98 (and all its editions) verifies its product keys. At first glance, it seems to be a pretty similar system to XP's. 98 seems to be an outlier in the retro Windows scene, as nobody has come up with a generator yet, whereas XP has this one and the versions before 98 use a simple algorithm with many GitHub repos implementing it, some in creative ways.

The check is exactly the same as in XP, only parameters are different:

p=0xf2f1c54eb7f01ded40c52af55d4994d53d78c425292a91344d6a1d20be292045776ac9ca3d4d2337348e2177304cc3c1
G=(0x541bd6f01e811d44308971a014a08dda42f97d1f2fe0d104946d4c7e3b02583d30f6a2816bd9af6120cc74df0d327b51,
    0xbb6eb8c546c6f1fdc55bef78a28c6b238225f9a79c85dadf5679e251b16775ee1a44fa0fb6f7157e49dfc511b014b208)
pub=(0xd13b9794f20dfe26b8f1029330695244c3762c5f7ca58cc3de6015967384d7c9f6618c27c34ac6def764ae8ee3ec25b9,
    0xc055572b8b15fd56658c0bf146cba480d8e685bcc27a8ac6269fe3b399673682046580c3c4e5e45229262ce86e792574)
order=0xFD5BF182B5E5E9
pri=0x95E1A9256A0149

for Retail keys,

p=0xec224ff2613a9fe1411b51e89634643f79a272402ee146b012a3f71098c7e75df4bf8b3713c4f0ce56691ce56b9b5029
G=(0xb5e1957b19951b5523204a62fd83ab22056f59a13bf8aaaf16ac10b7540f8ea92ba28dbfa68996fa12510c024f912340,
    0xa84fbc02f311b1fd4521773e01821bd047f067c496ad54ce1504315cb88667d69130caa25efb2cb1e479ed50efb40d6b)
pub=(0x26ea9efe57ab6da485225a13ed66533c143f81b7b9528e38c8568bb726a8f0f5607da0e8d85aebf2e1425758b409e811,
    0x1a7c4cebe5f3919e96876a447a813efcd920979e9610d2b2146a04fab1041b31ae65e24efa3e0b0d61622483655716c2)
order=0xE778E33AEE6B3D
pri=0xB9E99B9BB9812E

for OEM keys.

As far as I know, these parameters are the same for all editions except betas. (Upgrade keys differ from normal keys by the lower bit of Product Key.)

Woah, that's amazing! Thank you!

Also, how did you calculate pri? Or did you just extract it from MSKey4in1?

[grechnik]

Or did you just extract it from MSKey4in1?

No. MSKey4in1 knows nothing about Win98, and mskey.exe from the second comment just prints some hardcoded keys for Win98 (and some of them are not even valid, using '1' or 'A').

In fact, I have implemented and run Pollard's rho for these points and curve, but I don't want to share the code.

[Endermanch]

Or did you just extract it from MSKey4in1?

No. MSKey4in1 knows nothing about Win98, and mskey.exe from the second comment just prints some hardcoded keys for Win98 (and some of them are not even valid, using '1' or 'A').

In fact, I have implemented and run Pollard's rho for these points and curve, but I don't want to share the code.

I don't remember getting any garbage keys from the mskey.exe I sent.

Why would you not want to share the code? It would be helpful, especially that you seem to know what you're talking about.

[Endermanch]

It would be pretty useful to know how Windows 98 (and all its editions) verifies its product keys. At first glance, it seems to be a pretty similar system to XP's. 98 seems to be an outlier in the retro Windows scene, as nobody has come up with a generator yet, whereas XP has this one and the versions before 98 use a simple algorithm with many GitHub repos implementing it, some in creative ways.

The check is exactly the same as in XP, only parameters are different:

p=0xf2f1c54eb7f01ded40c52af55d4994d53d78c425292a91344d6a1d20be292045776ac9ca3d4d2337348e2177304cc3c1
G=(0x541bd6f01e811d44308971a014a08dda42f97d1f2fe0d104946d4c7e3b02583d30f6a2816bd9af6120cc74df0d327b51,
    0xbb6eb8c546c6f1fdc55bef78a28c6b238225f9a79c85dadf5679e251b16775ee1a44fa0fb6f7157e49dfc511b014b208)
pub=(0xd13b9794f20dfe26b8f1029330695244c3762c5f7ca58cc3de6015967384d7c9f6618c27c34ac6def764ae8ee3ec25b9,
    0xc055572b8b15fd56658c0bf146cba480d8e685bcc27a8ac6269fe3b399673682046580c3c4e5e45229262ce86e792574)
order=0xFD5BF182B5E5E9
pri=0x95E1A9256A0149

for Retail keys,

p=0xec224ff2613a9fe1411b51e89634643f79a272402ee146b012a3f71098c7e75df4bf8b3713c4f0ce56691ce56b9b5029
G=(0xb5e1957b19951b5523204a62fd83ab22056f59a13bf8aaaf16ac10b7540f8ea92ba28dbfa68996fa12510c024f912340,
    0xa84fbc02f311b1fd4521773e01821bd047f067c496ad54ce1504315cb88667d69130caa25efb2cb1e479ed50efb40d6b)
pub=(0x26ea9efe57ab6da485225a13ed66533c143f81b7b9528e38c8568bb726a8f0f5607da0e8d85aebf2e1425758b409e811,
    0x1a7c4cebe5f3919e96876a447a813efcd920979e9610d2b2146a04fab1041b31ae65e24efa3e0b0d61622483655716c2)
order=0xE778E33AEE6B3D
pri=0xB9E99B9BB9812E

for OEM keys.

As far as I know, these parameters are the same for all editions except betas. (Upgrade keys differ from normal keys by the lower bit of Product Key.)

Acquiring the private key and the order of the curve isn't sufficient but necessary to the generation process. Surely, though, the generation algorithm itself is different.

Besides, I don't expect the Raw Product Key format to be the same either in Windows 98.

Addressing the OP's question, you clearly must have extracted the pubkey from the pIDgen.dll, which you also should have the code for.

That would be excellent learning material!

[grechnik]

I don't remember getting any garbage keys from the mskey.exe I sent.

well, mskey.exe has 47 keys in "Windows 98 OEM" group and maybe five of them are not valid win98 keys, and "Full"/"Upgrade" groups are much smaller and fully correct, so it does take some luck (misfortune?) to get one

Besides, I don't expect the Raw Product Key format to be the same either in Windows 98.

Yet, it is literally the same except that different behaviour for ChannelID has only appeared in XP, so one does not need to worry about setting a "correct" BBB (in terms of README.md). Even the BINK resources have the same format, except that pidgen.dll was 16-bit back then, so finding the blob in the file is different - but once one finds the blob, its structure is the same (already with 32-bit fields).

Rewind to 1995. Windows 95 has just been released, product keys have no cryptographic protection, and that is sort of bad. Elliptic-curve cryptography is either a thing from frontiers of science or some lunatic math depending on your point of view. Given a problem of protecting product keys that should nevertheless be reasonably short, Microsoft Research develops a cryptographic scheme that we all know. For 1995, it makes some sense.

Fast-forward three years. Windows 98 incorporates the new scheme of cryptographically-signed product keys. Nobody cares because everyone just uses the same key. MS takes it as a sign that the scheme is good; everything else (Office/WinME/Win2k) uses the same scheme, only concrete numbers are changed (a key from win98 shouldn't be valid for win2k).

Fast-forward another three years. XP introduces WPA, nobody wants to share keys anymore (okay, that is not exactly true, but it is true enough to make a pressure to find alternate ways; and "Devil's Own" VL key was banned after all), so people actually try to make keygens. Moore's law is good, ECC slowly expands its usage and becomes better known. The scheme is still cryptographically secure in the sense that nobody knows better-than-generic-blackbox-attacks, but suddenly it turns out that the parameters are just too small, and the generic attacks are within the reach, and even in two different ways. (One way is what this repository does: blackbox discrete logarithm for n-bit groups uses O(2^(n/2)) operations, it is not too much for n=55. Another way uses the fact that the check field is 28-bit, so a random key with a correct ChannelId has probability 2^(-28) to pass the check; just keep checking random keys until one of them passes, that requires 2^28 checks per key on average - I think computers from 2001 could do that in maybe several hours per key.)

MS has noticed the keygens, but it is hard to totally redesign a cryptographic scheme on a short notice. For 2003 Server (and XP64 which is essentially 2003 Server with repainted wallpapers), they raised parameters as much as they could (and also introduced 10-bit server-auth field at expense of ChannelId that is encoded in more complicated way), which may have stopped keygenners for some time, but not forever.

In Vista, the product keys are finally checked in entirely different way, it marks the end of this story. (I have not seen any discussion on how Vista does this.) (And in Win8, MS has entirely dropped client-side crypto checks for product keys, leaving only 10-bit CRC to prevent typos and hoping for server-side checks during activation.) But before that, everything used one of two variations (XP vs 2003Server) of the same scheme where the only things that differ are concrete numbers to plug in.

[CONIGUERO]

I don't remember getting any garbage keys from the mskey.exe I sent.

well, mskey.exe has 47 keys in "Windows 98 OEM" group and maybe five of them are not valid win98 keys, and "Full"/"Upgrade" groups are much smaller and fully correct, so it does take some luck (misfortune?) to get one

Besides, I don't expect the Raw Product Key format to be the same either in Windows 98.

Yet, it is literally the same except that different behaviour for ChannelID has only appeared in XP, so one does not need to worry about setting a "correct" BBB (in terms of README.md). Even the BINK resources have the same format, except that pidgen.dll was 16-bit back then, so finding the blob in the file is different - but once one finds the blob, its structure is the same (already with 32-bit fields).

Rewind to 1995. Windows 95 has just been released, product keys have no cryptographic protection, and that is sort of bad. Elliptic-curve cryptography is either a thing from frontiers of science or some lunatic math depending on your point of view. Given a problem of protecting product keys that should nevertheless be reasonably short, Microsoft Research develops a cryptographic scheme that we all know. For 1995, it makes some sense.

Fast-forward three years. Windows 98 incorporates the new scheme of cryptographically-signed product keys. Nobody cares because everyone just uses the same key. MS takes it as a sign that the scheme is good; everything else (Office/WinME/Win2k) uses the same scheme, only concrete numbers are changed (a key from win98 shouldn't be valid for win2k).

Fast-forward another three years. XP introduces WPA, nobody wants to share keys anymore (okay, that is not exactly true, but it is true enough to make a pressure to find alternate ways; and "Devil's Own" VL key was banned after all), so people actually try to make keygens. Moore's law is good, ECC slowly expands its usage and becomes better known. The scheme is still cryptographically secure in the sense that nobody knows better-than-generic-blackbox-attacks, but suddenly it turns out that the parameters are just too small, and the generic attacks are within the reach, and even in two different ways. (One way is what this repository does: blackbox discrete logarithm for n-bit groups uses O(2^(n/2)) operations, it is not too much for n=55. Another way uses the fact that the check field is 28-bit, so a random key with a correct ChannelId has probability 2^(-28) to pass the check; just keep checking random keys until one of them passes, that requires 2^28 checks per key on average - I think computers from 2001 could do that in maybe several hours per key.)

MS has noticed the keygens, but it is hard to totally redesign a cryptographic scheme on a short notice. For 2003 Server (and XP64 which is essentially 2003 Server with repainted wallpapers), they raised parameters as much as they could (and also introduced 10-bit server-auth field at expense of ChannelId that is encoded in more complicated way), which may have stopped keygenners for some time, but not forever.

In Vista, the product keys are finally checked in entirely different way, it marks the end of this story. (I have not seen any discussion on how Vista does this.) (And in Win8, MS has entirely dropped client-side crypto checks for product keys, leaving only 10-bit CRC to prevent typos and hoping for server-side checks during activation.) But before that, everything used one of two variations (XP vs 2003Server) of the same scheme where the only things that differ are concrete numbers to plug in.

That's a nice bit of history and explanation, I appreciate the in-depth look.

However, why couldn't you want to release the code so that we can all generate keys for all editions? It would greatly improve the field and preservation ease, not having to rely on keys posted all over the place and having everything documented and easily accessible is always a plus.

[Endermanch]

I don't remember getting any garbage keys from the mskey.exe I sent.

well, mskey.exe has 47 keys in "Windows 98 OEM" group and maybe five of them are not valid win98 keys, and "Full"/"Upgrade" groups are much smaller and fully correct, so it does take some luck (misfortune?) to get one

Besides, I don't expect the Raw Product Key format to be the same either in Windows 98.

Yet, it is literally the same except that different behaviour for ChannelID has only appeared in XP, so one does not need to worry about setting a "correct" BBB (in terms of README.md). Even the BINK resources have the same format, except that pidgen.dll was 16-bit back then, so finding the blob in the file is different - but once one finds the blob, its structure is the same (already with 32-bit fields).

Rewind to 1995. Windows 95 has just been released, product keys have no cryptographic protection, and that is sort of bad. Elliptic-curve cryptography is either a thing from frontiers of science or some lunatic math depending on your point of view. Given a problem of protecting product keys that should nevertheless be reasonably short, Microsoft Research develops a cryptographic scheme that we all know. For 1995, it makes some sense.

Fast-forward three years. Windows 98 incorporates the new scheme of cryptographically-signed product keys. Nobody cares because everyone just uses the same key. MS takes it as a sign that the scheme is good; everything else (Office/WinME/Win2k) uses the same scheme, only concrete numbers are changed (a key from win98 shouldn't be valid for win2k).

Fast-forward another three years. XP introduces WPA, nobody wants to share keys anymore (okay, that is not exactly true, but it is true enough to make a pressure to find alternate ways; and "Devil's Own" VL key was banned after all), so people actually try to make keygens. Moore's law is good, ECC slowly expands its usage and becomes better known. The scheme is still cryptographically secure in the sense that nobody knows better-than-generic-blackbox-attacks, but suddenly it turns out that the parameters are just too small, and the generic attacks are within the reach, and even in two different ways. (One way is what this repository does: blackbox discrete logarithm for n-bit groups uses O(2^(n/2)) operations, it is not too much for n=55. Another way uses the fact that the check field is 28-bit, so a random key with a correct ChannelId has probability 2^(-28) to pass the check; just keep checking random keys until one of them passes, that requires 2^28 checks per key on average - I think computers from 2001 could do that in maybe several hours per key.)

MS has noticed the keygens, but it is hard to totally redesign a cryptographic scheme on a short notice. For 2003 Server (and XP64 which is essentially 2003 Server with repainted wallpapers), they raised parameters as much as they could (and also introduced 10-bit server-auth field at expense of ChannelId that is encoded in more complicated way), which may have stopped keygenners for some time, but not forever.

Could you elaborate on the server-auth (prefix) field and how it's related to the ChannelID? What exactly do you mean by more complicated encoding? I searched enough, but I couldn't find the Product ID <-> Raw Product Key relation for Server 2003, so it's still kind of a mystery. You very likely know much more.

But most importantly, Server 2003 seems to be oblivious to the prefix (that server-auth field). I tested the code with that field generated with RNG and it works about half of the times, given the high bits are set.

At first, I thought it was a SHA prefix, but if it actually serves a real purpose other than being salt, it might explain why the generation fails sometimes.

In Vista, the product keys are finally checked in entirely different way, it marks the end of this story. (I have not seen any discussion on how Vista does this.) (And in Win8, MS has entirely dropped client-side crypto checks for product keys, leaving only 10-bit CRC to prevent typos and hoping for server-side checks during activation.) But before that, everything used one of two variations (XP vs 2003Server) of the same scheme where the only things that differ are concrete numbers to plug in.

Vista abandoned the initial activation mechanism, it uses SLP 2.0 exclusively, which is rather easy to crack. People moved on from using keygens to instead emulating ACPI SLIC tables to trick Windows into thinking its activated.

//

Are there any papers/resources you could suggest on this particular topic, asides from the known MSKey 4-in-1 ReadMe? The code would MARGINALLY help too. You don't have to share it, but if you did it really would help everyone with understanding how to approach this task. Any help is appreciated!

[grechnik]

But most importantly, Server 2003 seems to be oblivious to the prefix (that server-auth field).

That's the point. The client never checks this field. That field exists so that MS servers (mainly activation servers, maybe update center servers) can distinguish between a true key and a generated one: if there is no code in the OS, then nobody can reverse-engineer how the field is checked, so any keygen can not do better than a random guess.

On the other hand, if you don't care about MS servers, this field doesn't matter at all.

XP keys don't have this field. In the initial release of XP, activation servers happily proceeded with anything that the OS itself accepted. First keygens have shown the weakness. Then, MS presumably has built a database of MS-generated keys - maybe only new ones starting from some moment? - and made activation servers contact this database; this closed the weakness, but presumably MS wasn't too happy - maybe maintaining such a database is a pain? - and decided to implement other measures.

and it works about half of the times

You don't check the return value of BN_sqrt_mod. Half of numbers modulo a prime are not squares, so BN_sqrt_mod fails about half of the times, you should just restart with a different seed if BN_sqrt_mod returns NULL.

What exactly do you mean by more complicated encoding?

Patent US7512232: https://patents.google.com/patent/US7512232B2/en . XP keys have bitfields 1+30+28+55 for UpgradeOnly+SerialNumber+r+s, where SerialNumber is later split as ChannelId*1000000+CCCCCC, and r,s form a ECC signature. 2k3 keys have larger ECC signature and additional server-auth field, but the same length, so MS had to get creative with SerialNumber field; 2k3 bitfields are 1+10+31+62+10 for UpgradeOnly+ChannelId+r+s+ServerAuth, and the CCCCCC part is encoded inside r,s. For the details, see the patent or https://github.com/Endermanch/XPKeygen/blob/main/server.cpp in this repository.

[Endermanch]

and it works about half of the times

You don't check the return value of BN_sqrt_mod. Half of numbers modulo a prime are not squares, so BN_sqrt_mod fails about half of the times, you should just restart with a different seed if BN_sqrt_mod returns NULL.

That's what MSKey 4-in-1 stated, and that's exactly why I rerun the generator function if it returns an invalid point. Thanks for clarifying! I'm rather new to cryptography, so my intuition failed me when I thought squares should appear more often than not.

What exactly do you mean by more complicated encoding?

Patent US7512232: https://patents.google.com/patent/US7512232B2/en . XP keys have bitfields 1+30+28+55 for UpgradeOnly+SerialNumber+r+s, where SerialNumber is later split as ChannelId*1000000+CCCCCC, and r,s form a ECC signature. 2k3 keys have larger ECC signature and additional server-auth field, but the same length, so MS had to get creative with SerialNumber field; 2k3 bitfields are 1+10+31+62+10 for UpgradeOnly+ChannelId+r+s+ServerAuth, and the CCCCCC part is encoded inside r,s. For the details, see the patent or https://github.com/Endermanch/XPKeygen/blob/main/server.cpp in this repository.

I guess I just didn't get what you meant by "encoding".

A rather credible source I found today explained everything. It makes much, much more sense now.

MSKey 4in1 Readme is just completely wrong. But that's what I assumed anyway.
Thank you for explaining everything in detail. Not too happy though - I'll have to completely rewrite my Readme on the subject. Haha

The final thing I don't entirely understand is how the signature scalar cap affects the discrete logarithm computation time despite the 512-bit curve parameters. It's relatively tangent to key generation, but it might help if you do know that as well.