endermanch
/
XPKeygen
1
0
Fork 0
Code Issues 11 Pull Requests 1 Packages Projects Releases 8 Wiki Activity

x64 key generation? #12

New Issue
Open
opened 2023-06-03 10:31:33 +03:00 by pottzman · 13 comments
pottzman commented 2023-06-03 10:31:33 +03:00 (Migrated from github.com)
Copy Link

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

What is wrong with x64 key generation? I have no issues with x64.
Endermanch commented 2023-06-03 14:30:41 +03:00 (Migrated from github.com)
Copy Link

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.

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 commented 2023-06-03 18:18:01 +03:00 (Migrated from github.com)
Copy Link

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

If the pidgen cane from a VLK image of windows then it shouldn't have BINK resources for Retail or OEM in it.
CONIGUERO commented 2023-06-04 02:31:34 +03:00 (Migrated from github.com)
Copy Link

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.

> 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](https://github.com/Endermanch/XPKeygen/blob/1e106268a932382ad712629797d7a853e1b48164/pidgen/pidgen.rc#L29) in their pidgen DLLs. We also know the second BINK resource is [hardcoded to be OEM](https://github.com/Endermanch/XPKeygen/blob/1e106268a932382ad712629797d7a853e1b48164/pidgen/pidgen.cpp#L457) We're stuck trying to figure out what this mysterious second VLK bink might be.
pottzman commented 2023-06-04 04:32:45 +03:00 (Migrated from github.com)
Copy Link

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

For VLK builds I don’t think the second BINK is used for anything.
WitherOrNot commented 2023-06-04 07:08:22 +03:00 (Migrated from github.com)
Copy Link

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

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 commented 2023-06-04 08:19:21 +03:00 (Migrated from github.com)
Copy Link

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.

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 commented 2023-06-04 08:20:46 +03:00 (Migrated from github.com)
Copy Link

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

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 commented 2023-06-04 08:41:28 +03:00 (Migrated from github.com)
Copy Link

R7KWY-RBF3F-R6C8P-RBK36-26YRY

image

I will test with en_windows_xp_professional_x64.iso and share results.

> R7KWY-RBF3F-R6C8P-RBK36-26YRY ![image](https://github.com/Endermanch/XPKeygen/assets/26913821/53947624-1d54-41f2-8b5f-501c1ee9baa1) I will test with en_windows_xp_professional_x64.iso and share results.
CONIGUERO commented 2023-06-04 08:49:43 +03:00 (Migrated from github.com)
Copy Link

R7KWY-RBF3F-R6C8P-RBK36-26YRY

image

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!

> > R7KWY-RBF3F-R6C8P-RBK36-26YRY > > ![image](https://user-images.githubusercontent.com/26913821/243155098-53947624-1d54-41f2-8b5f-501c1ee9baa1.png) > > 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 commented 2023-06-04 09:10:34 +03:00 (Migrated from github.com)
Copy Link

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

image

x64 Retail: `FDP9B-YDR92-PXP7H-9FY2Q-YFKJ6` ![image](https://github.com/Endermanch/XPKeygen/assets/26913821/bbeeb396-c4fd-4326-bbf3-4873e57052db)
CONIGUERO commented 2023-06-04 09:18:35 +03:00 (Migrated from github.com)
Copy Link

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

image

Delightful! Can you aubmit a PR with the changes?

> x64 Retail: `FDP9B-YDR92-PXP7H-9FY2Q-YFKJ6` > > ![image](https://user-images.githubusercontent.com/26913821/243156606-bbeeb396-c4fd-4326-bbf3-4873e57052db.png) Delightful! Can you aubmit a PR with the changes?
WitherOrNot commented 2023-06-04 09:20:53 +03:00 (Migrated from github.com)
Copy Link

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 Neo-Desktop/WindowsXPKg#15.

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 Neo-Desktop/WindowsXPKg#15.
Neo-Desktop commented 2023-06-04 09:39:34 +03:00 (Migrated from github.com)
Copy Link

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

@WitherOrNot I think going forward I'll add something similar to that structure you proposed to `keys.json`
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
drazisil/patch-1
v2.7
v2.5
v2.3
v2.2
v2.1
v2.0
v1.2
v1.1
Labels
Clear labels   
bug

Something isn't working

  
documentation

Improvements or additions to documentation

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
invalid

This doesn't seem right

  
question

Further information is requested

  
wontfix

This will not be worked on

No Label
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: endermanch/XPKeygen#12
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?