Hacking [RELEASE] 3DS Multi EmuNAND Creator

[Ripper00420]

Sadly no, New 3DS is selected.

Try making emunand using old Nand backup with this program, or use Gateway to make fresh one. Then you should be good.

 

[DarkMatterCore]

I'm currently working on a new v1.1 that fixes compatibility with FAT16 partitions (types 0x04 and 0x06), and a few other problems. I haven't released it yet because I haven't sorted out the SD card detection through WinAPI (if anyone knows how to fix this, please tell me).

This is the changelog thus far:

v1.1:
* The MBR string of the available storage drives is now checked before displaying the file input/output dialog when injecting/extracting an EmuNAND/RedNAND.
* Physical disks will now only be added once to the drive list if they have more than one partition.
* Changed the "Format New EmuNAND" and "Update" tags to "Format EmuNAND" and "Refresh", respectively. They were a little confusing.
* Fixed compatibility with FAT16 partitions (types 0x04 and 0x06).
* Fixed compatibility with the GPT partition style when formatting an EmuNAND. Please note the partition style *will* get changed to MBR after the EmuNAND format procedure.

Keep in mind this isn't the final release.

 

[Deathscreton]

My friend can't seem to get the program to recognize his SD card. He used the 1.0 on his friends card and it worked fine. But it won't work on his. He can format it, but after that, the program fails to recognize it when trying to extract (we try to extract to make sure it worked properly).

Same brand cards, same PC, same program. Any idea why this wouldn't work?

 

[Nirmonculus]

Can I use this to transfer my emunand from 32gb msd to 64gb msd? I want to upgrade my capacity. Is there a way my Mii Plaza save will be transfered too? Thanks!

 

[zerox521]

Hi guys, I downgraded my N3DS using SysUpdater from 10.3 to 9.2 and I tried creating the emunand on my 4gb microSD, but I get this error: Couldn't write block #19230 to offset 0x04B1E0000. What should I do?

 

[DarkMatterCore]

My friend can't seem to get the program to recognize his SD card. He used the 1.0 on his friends card and it worked fine. But it won't work on his. He can format it, but after that, the program fails to recognize it when trying to extract (we try to extract to make sure it worked properly).

Same brand cards, same PC, same program. Any idea why this wouldn't work?

The automatic SD card detection currently doesn't work properly if more than one SD card with a compatible MBR flashcard tag is inserted in the computer. For the time being, just make sure you have one SD card inserted at a time.

I plan to have this sorted out in the final v1.1 release.

Can I use this to transfer my emunand from 32gb msd to 64gb msd? I want to upgrade my capacity. Is there a way my Mii Plaza save will be transfered too? Thanks!

Yes, you can use this program for that purpose. Just backup all the data from the FAT partition of your 32GB SD card, extract its EmuNAND, swap cards, format the EmuNAND using the previously extracted NAND dump and finally, copy the backup data to the new FAT partition of your 64 GB SD card.

Hi guys, I downgraded my N3DS using SysUpdater from 10.3 to 9.2 and I tried creating the emunand on my 4gb microSD, but I get this error: Couldn't write block #19230 to offset 0x04B1E0000. What should I do?

Your SD card and/or your SD card reader is/are most likely defective. You should try with a different one.

 

[RaZoR1179]

is there any way to create a emunand of a microSDXC 64gb ?? I always get an error

 

[Pounou]

is there any way to create a emunand of a microSDXC 64gb ?? I always get an error

Try Gateway launcher to format emunand

 

[RaZoR1179]

Try Gateway launcher to format emunand

I finally made it with that, thanks

 

[d0k3]

Nice! I assume this can be used the same way as EmuNAND Tool, too? Don't know if you know, but there's a compatibility issue with my EmuNAND9 and EmuNAND Tool (EmuNAND Tool won't accept EmuNANDs that use small, but correct NAND sizes). Hope yours doesn't have that. In that case I'll recommend it to anyone complaining about those incompatibilities.

 

[DarkMatterCore]

Nice! I assume this can be used the same way as EmuNAND Tool, too? Don't know if you know, but there's a compatibility issue with my EmuNAND9 and EmuNAND Tool (EmuNAND Tool won't accept EmuNANDs that use small, but correct NAND sizes). Hope yours doesn't have that. In that case I'll recommend it to anyone complaining about those incompatibilities.

If it's the same size of the NAND dumps created by your Decrypt9WIP, then it works fine. I have already tested it.

 

[d0k3]

If it's the same size of the NAND dumps created by your Decrypt9WIP, then it works fine. I have already tested it.

Decrypt9WIP and EmuNAND9 use the actual NAND flash chip size as size of the dump (this also makes sure the dump contains all the data that is actually on there). I'm sure you already know, but there are different NAND chip sizes, f.e. for N3DS there are 1.2GB and 1.8GB chips (I think, the 1.8GB one is more common). Also see here. I think everything should be fine as long as you just check the minimum sizes (aka, the actually used part of NAND memory) and allow anything above. The minimum sizes are 0x4D800000 (for N3DS) and 0x3AF00000 (for O3DS). You can't check console type anyways, though .

And, thanks a ton for including the source code!

 

[DarkMatterCore]

Decrypt9WIP and EmuNAND9 use the actual NAND flash chip size as size of the dump (this also makes sure the dump contains all the data that is actually on there). I'm sure you already know, but there are different NAND chip sizes, f.e. for N3DS there are 1.2GB and 1.8GB chips (I think, the 1.8GB one is more common). Also see here. I think everything should be fine as long as you just check the minimum sizes (aka, the actually used part of NAND memory) and allow anything above. The minimum sizes are 0x4D800000 (for N3DS) and 0x3AF00000 (for O3DS). You can't check console type anyways, though .

And, thanks a ton for including the source code!

Yeah, I'm fully aware of that fact. How does the Gateway Launcher determine the NAND flash chip capacity, then? The size values are hardcoded in my program, actually, but a dummy footer is written to the sector next to the NAND dump after it has been injected. It is used to determine the actual size of the NAND dump, for verification purposes in the extraction process (specially helpful if its a RedNAND).

No problemo, btw.

 

[d0k3]

I think everything should be fine as long as you just check the minimum sizes (aka, the actually used part of NAND memory) and allow anything above. The minimum sizes are 0x4D800000 (for N3DS) and 0x3AF00000 (for O3DS).

I have to take that back... using minimum sizes is not okay. I forgot that the NCSD header in EmuNAND is after the end of the true NAND chip size. Oh well. But I guess you knew already anyways.

Yeah, I'm fully aware of that fact. How does the Gateway Launcher determine the NAND flash chip capacity, then? The size values are hardcoded in my program, actually, but a dummy footer is written to the sector next to the NAND dump after it has been injected. It is used to determine the actual size of the NAND dump, for verification purposes in the extraction process (specially helpful if its a RedNAND).

No problemo, btw.

GW should use the the same method. As I wrote above, the NCSD header is after the end of the NAND chip size (if the size is 1.8GB, it is at offset 1.8GB, f.e.). And GW gets that right, every time.

 

[DarkMatterCore]

I have to take that back... using minimum sizes is not okay. I forgot that the NCSD header in EmuNAND is after the end of the true NAND chip size. Oh well. But I guess you knew already anyways.


GW should use the the same method. As I wrote above, the NCSD header is after the end of the NAND chip size (if the size is 1.8GB, it is at offset 1.8GB, f.e.). And GW gets that right, every time.

Yes, I know that. But as long as the proper size values remain hardcoded in the application, there should be nothing to worry about. The current algorithm starts writing the input NAND dump from offset 0x200 at sector #1 and when it finishes, it adds the NCSD header, then writes the dummy footer.

RedNANDs are different, though. The dummy footer is required because the input NAND dump is written as-is to the SD card right after sector #0, so no NCSD header is available at the end.

 

[Meorge]

Noice

 

[DarkMatterCore]

v1.1 released. Here's the changelog:

v1.1:
* A new EmuNAND SD Card drop-down list has been added, which is automatically populated with drives that have a compatible flashcard string in their MBR. This allows the user to select a specific drive for the input/output operations if more than one SD card with a valid flashcard string is available, instead of letting the program select the first one it finds.
* Physical disks will now only be added once to the drive lists if they have more than one logical partition.
* Changed the "Format New EmuNAND" and "Update" tags to "Format EmuNAND" and "Refresh", respectively. They were a little confusing.
* Fixed compatibility with FAT16 partitions (types 0x04 and 0x06).
* Fixed compatibility with the GPT partition style when formatting an EmuNAND. Please note the partition style *will* get changed to MBR after the EmuNAND format procedure.

You can get the download link in the first post.

 

[Twilight Seeker]

I keep getting this error when trying to extract/inject a new 3DS emuNAND:

It's a 9.5 emuNAND that was originally formatted with EmuNAND9 - the rest of the card should be FAT32. The emuNAND seems to work perfectly fine under RXTools. I had the New 3DS option selected while trying to extract/inject. The application seems to run in admin mode by default, so that's probably not the issue.

Edit: I should probably mention that it doesn't give an option to format at all - it just shows "No valid drives available".

 

[DarkMatterCore]

It seems like EmuNAND9 doesn't set the FAT32 starting sector to the same offsets used by the Gateway Launcher. I'll have to fix that.

Bear in mind that the Format EmuNAND drop-down list will only display drives that *do not* have a valid flashcard string in their MBR, or so to say, SD cards with no EmuNAND at all.

 

[Twilight Seeker]

Awesome - tested it by extracting an emuNAND and re-injecting it, and it didn't seem to break anything. Thanks!