Refactored rp3 to reuse rp2 signature generation code. Could be merged further as the code is largely the same with seemingly the only differences being to key preparation.
Also changed rp2 to use just the signing key + mcode as parameters as I couldn't find evidence of a 3rd input being used as part of the key in any game, but I did find that I needed to have the last byte in the mcode for generated data to match a real dongle.
Description
rp3 is as documented but some things were not mentioned, so here's the extra details for documentation purposes:
rp3 v1:
Sign keys are stored in plaintext. Only used on Python 2? Couldn't find a source for this variation on PC.
rp3 v2 (GFDM, Jubeat, Gitadora, DDR):
Same as rp3 v1 but the sign keys are stored encoded using key[i] ^ (127 - i). This code can be easily found in any(?) libdevice.dll (GFDM/Gitadora), device.dll (Jubeat) in the device_initialize function for reference.
The reason I separate rp3 v1 and v2 into two separate functions is because the key decoding part of the code is baked in with the sign key preparation. rp3 v2 seems to be the most commonly found variant out of rp2, rp3 v1, and rp3 v2.
Related Issue
How Has This Been Tested?
Booted the affected games to make sure they still worked. Also tested against information from real dongle dumps to make sure it could generate the same payloads for the given parameters.
Checklist
Implemented (unit) test(s) which prove that the introduced changes are working as expected.
Tested with the following games:
IIDX GOLD
Jubeat Ripples
Followed the developer (style) guidelines.
[N/A?] Updated existing doc of or add new doc to README file(s).
[N/A] Updated development documentation.
In GitLab by @33c17f40 on May 11, 2022, 22:19
_Merges rp2_refactor -> master_
## Summary
Refactored rp3 to reuse rp2 signature generation code. Could be merged further as the code is largely the same with seemingly the only differences being to key preparation.
Also changed rp2 to use just the signing key + mcode as parameters as I couldn't find evidence of a 3rd input being used as part of the key in any game, but I did find that I needed to have the last byte in the mcode for generated data to match a real dongle.
## Description
rp3 is as documented but some things were not mentioned, so here's the extra details for documentation purposes:
- rp3 v1:
- Sign keys are stored in plaintext. Only used on Python 2? Couldn't find a source for this variation on PC.
- rp3 v2 (GFDM, Jubeat, Gitadora, DDR):
- Same as rp3 v1 but the sign keys are stored encoded using `key[i] ^ (127 - i)`. This code can be easily found in any(?) libdevice.dll (GFDM/Gitadora), device.dll (Jubeat) in the `device_initialize` function for reference.
```python
>>> print("".join([chr(ord(c) ^ (127 - i)) for i, c in enumerate(",6<14)86")]))
SHAMOSAN
>>> print("".join([chr(ord(c) ^ (127 - i)) for i, c in enumerate(":S<1.)<K")]))
E-AMUSE3
>>> print("".join([chr(ord(c) ^ (127 - i)) for i, c in enumerate("*:223(21")]))
UDONHRKI
```
The reason I separate rp3 v1 and v2 into two separate functions is because the key decoding part of the code is baked in with the sign key preparation. rp3 v2 seems to be the most commonly found variant out of rp2, rp3 v1, and rp3 v2.
## Related Issue
<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
<!--- Please link to the issue here: -->
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Booted the affected games to make sure they still worked. Also tested against information from real dongle dumps to make sure it could generate the same payloads for the given parameters.
## Checklist
<!-- Make sure you covered all items, which apply, of the checklist below. -->
<!-- Strikethrough items that do not apply and provide a brief description why. -->
* [x] Implemented (unit) test(s) which prove that the introduced changes are working as expected.
* Tested with the following games:
* [x] IIDX GOLD
* [x] Jubeat Ripples
* [x] Followed the developer (style) guidelines.
* [N/A?] Updated existing doc of or add new doc to README file(s).
* [N/A] Updated development documentation.
A somewhat familiar checksum. Great to see you and your high quality contribution here.
I am happy to see someone figured this out and improved various hacky bits of my rather old code. Most of the stuff was created with when I worked on IIDX 14 to 17 support or when creating the groundwork for jubeat 1 support. I do appreciate the additional documentation and explanation. That should help future readers to understand these parts better, I hope.
Your refactoring suggestion to merge rp2 and rp3 are also highly welcome if you have the motivation to work on that as well.
A somewhat familiar checksum. Great to see you and your high quality contribution here.
I am happy to see someone figured this out and improved various hacky bits of my rather old code. Most of the stuff was created with when I worked on IIDX 14 to 17 support or when creating the groundwork for jubeat 1 support. I do appreciate the additional documentation and explanation. That should help future readers to understand these parts better, I hope.
Your refactoring suggestion to merge rp2 and rp3 are also highly welcome if you have the motivation to work on that as well.
Your refactoring suggestion to merge rp2 and rp3 are also highly welcome if you have the motivation to work on that as well.
I considered it but I became less confident the longer I compared exact details and dialed it back to something I could justify easier. I'll send over another PR later then to merge the code some more.
In GitLab by @33c17f40 on May 12, 2022, 02:14
>Your refactoring suggestion to merge rp2 and rp3 are also highly welcome if you have the motivation to work on that as well.
I considered it but I became less confident the longer I compared exact details and dialed it back to something I could justify easier. I'll send over another PR later then to merge the code some more.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In GitLab by @33c17f40 on May 11, 2022, 22:19
Merges rp2_refactor -> master
Summary
Refactored rp3 to reuse rp2 signature generation code. Could be merged further as the code is largely the same with seemingly the only differences being to key preparation.
Also changed rp2 to use just the signing key + mcode as parameters as I couldn't find evidence of a 3rd input being used as part of the key in any game, but I did find that I needed to have the last byte in the mcode for generated data to match a real dongle.
Description
rp3 is as documented but some things were not mentioned, so here's the extra details for documentation purposes:
rp3 v1:
rp3 v2 (GFDM, Jubeat, Gitadora, DDR):
key[i] ^ (127 - i). This code can be easily found in any(?) libdevice.dll (GFDM/Gitadora), device.dll (Jubeat) in thedevice_initializefunction for reference.The reason I separate rp3 v1 and v2 into two separate functions is because the key decoding part of the code is baked in with the sign key preparation. rp3 v2 seems to be the most commonly found variant out of rp2, rp3 v1, and rp3 v2.
Related Issue
How Has This Been Tested?
Booted the affected games to make sure they still worked. Also tested against information from real dongle dumps to make sure it could generate the same payloads for the given parameters.
Checklist
A somewhat familiar checksum. Great to see you and your high quality contribution here.
I am happy to see someone figured this out and improved various hacky bits of my rather old code. Most of the stuff was created with when I worked on IIDX 14 to 17 support or when creating the groundwork for jubeat 1 support. I do appreciate the additional documentation and explanation. That should help future readers to understand these parts better, I hope.
Your refactoring suggestion to merge rp2 and rp3 are also highly welcome if you have the motivation to work on that as well.
approved this merge request
In GitLab by @33c17f40 on May 12, 2022, 02:14
I considered it but I became less confident the longer I compared exact details and dialed it back to something I could justify easier. I'll send over another PR later then to merge the code some more.