-
-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: More accurate dumps (retrieve comms keydata sector from cartridge) #10
Comments
There's a problem with this. The application currently uses IPC calls to filesystem services in order to retrieve raw data sectors from the gamecard storage. However, a separate gamecard controller from the Switch takes care of decrypting the data on-the-fly, and provides no way of getting the encrypted data, nor a way to retrieve the ECC blocks (any read operation beyond the gamecard storage size results in an IPC error). |
Okay. Hopefully a way will be found in the near-future. |
For the time being, I'm gonna leave this issue open. If new information related to this topic comes to light, I'll make sure to update this issue status. |
@mariomadproductions According to SciresM, it seems there are no ECC blocks at all in Switch gamecards. However, it has been proved that all Switch gamecards hold a 0x200 byte long sector that precedes the gamecard header, which contains communication keydata (title-specific, not gamecard-specific). The data from this sector is used to configure the gamecard <-> ASIC communication encryption.
I will try to implement a way to dump this specific sector. |
@mariomadproductions Support for dumping the initial data region + padding up to 0x1000 bytes has been implemented in the experimental This issue will be kept open until the rewrite is finished. |
Here you (@DarkMatterCore) suggested that the dumps made with this tool aren't 1:1 - they are partially decrypted and are probably missing "ECC data".
Would it be feasible to dump the carts encrypted - and would the resultant ROM dump be decryptable?
Would it also be feasible to dump the "padding" properly (what you think is probably "ECC data") - as I understand it, this data is dumped as "FF" bytes, but this is not an accurate reproduction of the data on the ROM chip.
The text was updated successfully, but these errors were encountered: