x64 key generation?

[pottzman]

What is wrong with x64 key generation? I have no issues with x64.

[Endermanch]

Hello pottzman! We're working in a team with Neo and Coni now. We've figured out that the private keys I've reversed are in fact correct, the only problem with them is that they aren't VLK. They're used to generate Retail and OEM keys and neither of them work with the image I'm testing it on. Note that I extracted the pidgen from that exact volume image.

I find it extremely weird, and for now this is the main issue with x64 key generation.

[pottzman]

If the pidgen cane from a VLK image of windows then it shouldn't have BINK resources for Retail or OEM in it.

[CONIGUERO]

If the pidgen cane from a VLK image of windows then it shouldn't have BINK resources for Retail or OEM in it.

The problem is that the VLK builds seem to have 2 BINKs in their pidgen DLLs.

We also know the second BINK resource is hardcoded to be OEM

We're stuck trying to figure out what this mysterious second VLK bink might be.

[pottzman]

For VLK builds I don’t think the second BINK is used for anything.

[WitherOrNot]

According to dpcdll.dll, the second bink (id 0x65) isn't used for anything relevant. You can confirm this with DPCDLL-Viewer, the only entries matching BINKs in pidgen are those for BINK 0x64.

For reference, I tested with en_win_xp_pro_x64_vl.iso

[CONIGUERO]

Got it. Glad to have that out of the way.

As for x64, everything after server 2003 uses a new signature algorithm. We have yet to figure out entirely and implement it. We do have the keys.

[WitherOrNot]

I implemented an algorithm that generated a working key.

Please try with en_win_xp_pro_x64_vl.iso: R7KWY-RBF3F-R6C8P-RBK36-26YRY

Have not tested confirmation ID yet. Am dumb, I forgot VLK doesn't do conf IDs

[WitherOrNot]

R7KWY-RBF3F-R6C8P-RBK36-26YRY

I will test with en_windows_xp_professional_x64.iso and share results.

[CONIGUERO]

R7KWY-RBF3F-R6C8P-RBK36-26YRY

I will test with en_windows_xp_professional_x64.iso and share results.

Confirmed working and the PID shown on system properties is the same!

[WitherOrNot]

x64 Retail: FDP9B-YDR92-PXP7H-9FY2Q-YFKJ6

[CONIGUERO]

x64 Retail: FDP9B-YDR92-PXP7H-9FY2Q-YFKJ6

Delightful! Can you aubmit a PR with the changes?

[WitherOrNot]

I had a look at the code. It seems there is no change in algo from server 2k3, just different os_family constants, keys, and curve params.

# x64 VLK - 652
# x64 Retail - 306

I will see if I can implement something for this tomorrow. In the meantime, it would be good if DPCDLL.DLL was used to create a table of these constants, as that file is where I found them. I proposed this in UMSKT/UMSKT#15.

[Neo-Desktop]

@WitherOrNot I think going forward I'll add something similar to that structure you proposed to keys.json