search

DarkMatterCore / nxdumptool

Generates XCI/NSP/HFS0/ExeFS/RomFS/Certificate/Ticket dumps from Nintendo Switch gamecards and installed SD/eMMC titles.
GNU General Public License v3.0
1.01k stars 75 forks source link

Padding? #1

Closed mariomadproductions closed 6 years ago

mariomadproductions commented 6 years ago

Does this padding exist on the ROM chip, or is it just added by this program? If the latter, could there be an option for dumping the ROM without the padding?

DarkMatterCore commented 6 years ago

It's added by the application based in gamecard size field from the header. It's gonna be changed to a configurable option in the next release.

mariomadproductions commented 6 years ago

Thanks. Does the padding actually exist on the ROM chip though?

DarkMatterCore commented 6 years ago

It is assumed this padding does exist.

Every cartridge has two different IStorage instances that can be accessed: one with partition ID #0 (which contains the gamecard header, the gamecard certificate, the root HFS0 header, the "update" partition, the "normal" partition and the "logo" partition [this last one only on type 0x02 gamecards]), and one with partition ID #1 (which contains the "secure" partition, along with what I think is incomplete 0xFF padding).

The buffers pointed by both IStorage instances contain data that is decrypted by the gamecard controller (so yeah, it's not a 1:1 dump) and the sum of the sizes from both instances never matches the total gamecard size from the gamecard header (which is expressed in GiB).

This is further supported by the fact that the Valid Data End Address from the gamecard header (at offset 0x118) point to an offset that never matches the sum of the sizes from both instances; it's actually lower. At that very same offset, the padding included by BBB in their XCI dumps starts, but never goes up to a point where it matches the full gamecard size.

So why does the secure partition include any padding at all if isn't needed? I don't know yet, but the Switchbrew page for the gamecard format includes the following statement:

"The entire rest of the Gamecard after the secure partition ends is all FF padding."

So yeah, that's why games are padded up to their full cartridge storage size. As I said before, this is gonna be a configurable option in the next release (which I'm already testing).

DarkMatterCore commented 6 years ago

Fixed in commit 730912a626a329c24e5e70be083725fd6564c251.

mariomadproductions commented 6 years ago

Would having the padding feature on produce a ROM that is identical to a 1:1 dump? Either way, is it feasable to make a "directly read from ROM" 1:1 dump?

DarkMatterCore commented 6 years ago

There's some crypto in place that would need to be performed to truly call the dumps produced by this tool "1:1 dumps". However, since the gamecard controller only returns decrypted buffers, there's no easy way to get the original encrypted data from the cartridge. Even BBB has "indirectly" announced this because their dumps match the ones created with this tool, meaning that they're also decrypted.

The padding feature will be removed in the next release, though. After a deep talk with AnalogMan from GBAtemp, I realized that what we currently think is 0xFF padding in BBB dumps (the same padding data from the IStorage instance with partition ID #1) may not be any padding at all, but actually undumpable/hidden ECC data for the gamecard controller. He noticed a pattern in the padding sizes across many games and even did some math to prove his point. This also means, however, that Nintendo Switch cartridges could possibly be going against convention and actually use storage sizes expressed in Gigabytes (powers of base 10) instead of Gibibytes (powers of base 2).

Historically speaking, having padding as part of a ROM image usually suggests that it is a 1:1 dump. It means that the dumper also took into consideration the unused sectors from the storage chip. A lot of purists disregard any dumps without padding to be 1:1 dumps.