Closed tastymeatball closed 2 years ago
Coming back the other day, now I see what this is doing. pycryptodome also installs itself under "Crypto" with its officially recommended instruction, so this is looking at two places for the same package pycryptodome. If that's the rational, I think this is fine. Am I understanding this correctly?
If that's the case, I recommend reordering this to try importing from Cryptodome
first. We know that Cryptodome
is definitely the pycryptodome package, while the Crypto
one could be a mess.
I don't know for sure but I guess the Crypto namespace is the new one and the Cryptodome is the old namespace and is kept in the pycryptodomex package for compatibility reseaons https://pypi.org/project/pycryptodome/ https://pypi.org/project/pycryptodomex/ I at least can't see any differences between these two packages except pycryptodome operates under Crypto and pycryptodomex operates under Cryptodome
Edit: Totally forgot to mention. I already tested it with the pycryptodome package (pycryptodomex is and was never installed on this machine) and it successfully decrypted and extracted all my StreetPass Mii Plaza files
Edit2: Answer probably lies here: https://github.com/Legrandin/pycryptodome/blob/master/README.rst Pycryptodome just replaces the old PyCrypto package while pycryptodomex uses a complete new namespace so it doesn't interfere with the old PyCrypto package.
If you really want to change the ordering of Crypto and Cryptodome you should also change this in sd_decrypt.py.
I also would suggest that you add somewhere in the readme that either the library/package pycryptodome or pycryptodomex must be installed.
Yeah, I plan to make the change to sd_decrypt.py and readme after merging this one. The current readme says
This extracts encrypted save data of Pokemon Sun from SD card to folder output/pokemon-sun-save. Some requirement and notes of this command ... An additional library Cryptodome is needed.
And the current order in sd_decrypt.py is in its way because it attempt to detect the old unmaintained Crypto package first, and then detect the optionally required Cryptodome package. It is technically true as some other commands work with the old unmaintained Crypto package, but I agree this is confusing. I'll update it such that Cryptodome is always required to make it simpler to understand.
There was a specific reason that I didn't include support for Crypto package. I specifically mentioned this in readme
However, I can't recall the exact reason. Maybe CMAC verification in Crypto was unsupported/broken at that time.
Could you provide a manual test that exercises this code path using Crypto package? Reading an encrypted SD card save that doesn't output "Error: CMAC mismatch" should be enough