Homebrew WIP nxdumptool - Nintendo Switch Dump Tool

[Drejj]

So users have to set the pad values?

I didn't see an option for that.
The "0xFF Padding size" is the exact number of bytes of the overdump in my previous post.

 

[DarkMatterCore]

First of all, let me start by explaining myself. I'm gonna quote a comment I made on this issue in the GitHub repository:

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).

__________________________________________________

I dumped my copy of Minecraft (0100D71004694000) this morning, my CRC32 ended up being 753F2AD5 vs 262EC0D2 for the BBB release. Also, on my dump the XCI file size is 2,048.00 MB and the cartridge size is 1,904.00 MB while both the XCI file size and cartridge size is 1,904.00 MB on the BBB release.

Read my previous posts:

Thanks for your help, really! If it isnt't too much to ask, make sure to take a screenshot while you're creating the XCI dump (without cert). You'll need the XCI dump size from that screenshot to perform the CRC32 calculation because BBB dumps are not 0xFF padded.

What I really meant is that the 0xFF padding they have doesn't take up the whole cartridge size (e.g. 7.44 GiB vs 8 GiB for Super Mario Odyssey).

It's expressed in GiB. There's a byte in the gamecard header that indicates the storage size. The dump size is incomplete because the application only dumps the range covered by the two IStorage interfaces available for every gamecard, which are concatenated in the dump process (but their combined size never takes up all that space).

Historically speaking, this is a pretty common thing with ROM images.

You're right. Just make sure you calculate the CRC32 hash over the XCI dump size displayed on that screen and not over the whole file. Worked fine for me using Super Mario Odyssey.

I'll just probably make the additional padding a configurable option.

You can use HxD in Windows to open the XCI dump, select a block from offset 0 with a length = XCI data size from the dump screen, leave the block highlighted and calculate a CRC32 hash over it. It should match the CRC32 hash from the BBB dump.

__________________________________________________

You are padding waaay too much. 301 989 888 bytes on a 4GB image to be exact.

This is what i found out:

https://i.imgur.com/b3enlxu.png
https://i.imgur.com/Kpx7E0f.png

https://i.imgur.com/tnBs4LQ.png

After removing the extra 288MB of padding from my Kirby cart it CRC 100% with Kirby.Star.Allies.NSW-BigBlueBox.

Maybe this will help with Card2 support?
https://github.com/StudentBlake/XCI-Explorer/commit/1b09d6b978ba20458f91455dea5b5796f1b00b26

Read the start of this post. The extra padding is added for a reason. But I'm gonna make this a configurable option, nonetheless.

And nope, that won't help with supporting type 0x02 gamecards (it's a PC program).
__________________________________________________

Cut and then un-cut your file with XCI-Cutter to get a file that (hopefully) matches the Scene release, if Card2 is working! Double check that your cert is not included, as well.

Nope, it's not gonna work like that. The second IStorage instance for any gamecard (using partition ID #1) already includes some unused padding that's not referred to anywhere in the game card dump (which is the padding included in BBB dumps). That's why the XCI data size from the XCI dump screen is needed.
__________________________________________________

So users have to set the pad values?

Nope.

 

[Drejj]

Thanks for the answers. Looks like you took your time to learn how gamecards and their partitions really work. Someone should donate a Mario Tennis card2 to you and i'm sure we have card2 support in the future

 

[cubex]

You can use HxD in Windows to open the XCI dump, select a block from offset 0 with a length = XCI data size from the dump screen, leave the block highlighted and calculate a CRC32 hash over it. It should match the CRC32 hash from the BBB dump.

Sorry, that's my bad, I didn't read the instructions fully beforehand. I did now and the CRC32 on that data ended up being the exact same as the BBB release, 262EC0D2.

 

[DarkMatterCore]

Just updated gcdumptool to v1.0.3! Go check it out in the first post. Also, check the following screenshots, I'm sure you'll like them:

Spoiler

Thanks for the answers. Looks like you took your time to learn how gamecards and their partitions really work. Someone should donate a Mario Tennis card2 to you and i'm sure we have card2 support in the future

I'm confident that, with enough support and testing, we can achieve type 0x02 gamecard compatibility without doing that. hahaha

Sorry, that's my bad, I didn't read the instructions fully beforehand. I did now and the CRC32 on that data ended up being the exact same as the BBB release, 262EC0D2.

No problem. I'm actually glad it turned out to be fine in the end! Was it a type 0x02 gamecard?

 

[cubex]

No problem. I'm actually glad it turned out to be fine in the end! Was it a type 0x02 gamecard?​

Yep, it is.​

 

[mickthestud]

So a real noob question how do you dump your switch games by connecting your switch with game inside to pc then running the programme

 

[Drejj]

No problem. I'm actually glad it turned out to be fine in the end! Was it a type 0x02 gamecard?

Yep, it is.

Nice! So it's been confirmed to support card2? Great work.
@cubex Do you get correct CRC with v1.0.3 without using XCI-cutter/HxD?
Time to delete WAIN for good

 

[ganons]

Nice! So it's been confirmed to support card2? Great work.
@cubex Do you get correct CRC with v1.0.3 without using XCI-cutter/HxD?
Time to delete WAIN for good

Which version of Wain were you using?

 

[Drejj]

Which version of Wain were you using?

The public one: v0.3. There is nothing WAIN can do that gcdumptool can do better.

 

[ganons]

The public one: v0.3. There is nothing WAIN can do that gcdumptool can do better.

There is a 0.5 version which isn't available to the public anymore

 

[DarkMatterCore]

Yep, it is.​

That's really good to know! If it isn't too much to ask, can you please test the other features from the application?

 

[comput3rus3r]

why can't i see any of the screenshots?

 

[WiiuGold]

why can't i see any of the screenshots?

Me too

 

[Drejj]

Me too

Imgur doesn't allow hotlinking from gbatemp. Open the image in a new tab, then refresh and you should be able see them.

 

[DarkMatterCore]

Weird. Could it be a GBAtemp bug? I'm not sure if I'm the only one, but I've been getting some random 503 and 504 errors in the last few hours.

Here are the links to the latest screenshots:

https://i.imgur.com/jUUIysn.jpg

https://i.imgur.com/cAZMXgO.jpg

https://i.imgur.com/983UJFx.png

 

[cubex]

Nice! So it's been confirmed to support card2? Great work.
@cubex Do you get correct CRC with v1.0.3 without using XCI-cutter/HxD?
Time to delete WAIN for good

Updating now, I'll test and let you know.

edit: Using the new options in 1.0.3 the CRC32 for the dump is 262EC0D2

 

[TheRedRacon79]

Every update since the original build breaks on 1.0 any clue why?

 

[DarkMatterCore]

Updating now, I'll test and let you know.

edit: Using the new options in 1.0.3 the CRC32 for the dump is 262EC0D2

That's really freakin' nice to know. Have you tested the other features? (raw partition dumping, partition data dumping and partition filebrowser)

Manual game card certificate dumping is pretty much confirmed to work up to this point.

Every update since the original build breaks on 1.0 any clue why?

The application currently crashes when it's not being run under CFW (Hekate/Atmosphere, I suppose you're using PegaSwitch or a different entrypoint). It also uses some IPC calls that aren't available in 1.0.0, but that should work fine from 2.0.0 onwards.

I probably won't be able to fix compatibility with 1.0.0 (seriously bro, update to 3.0.0 at least), but missing compatibility with FW > 1.0.0 and < 4.0.0 is a known bug I'm looking into.

 

[TheRedRacon79]

That's really freakin' nice to know. Have you tested the other features? (raw partition dumping, partition data dumping and partition filebrowser)

Manual game card certificate dumping is pretty much confirmed to work up to this point.



The application currently crashes when it's not being run under CFW (Hekate/Atmosphere, I suppose you're using PegaSwitch or a different entrypoint). It also uses some IPC calls that aren't available in 1.0.0, but that should work fine from 2.0.0 onwards.

I probably won't be able to fix compatibility with 1.0.0 (seriously bro, update to 3.0.0 at least), but missing compatibility with FW > 1.0.0 and < 4.0.0 is a known bug I'm looking into.

I'm using cfw always been and 1.0 still has coldboot explaine