Open mariomadproductions opened 6 years ago
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.
typedef struct {
u8 key_source[0x10];
u8 encrypted_title_key[0x10];
u8 mac[0x10];
u8 nonce[0xC];
u8 reserved_1[0x1C4];
} InitialDataRegion;
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 rewrite
branch. It has already been confirmed to work properly by some other users.
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.