Hacking [RELEASE] 3DS Multi EmuNAND Creator

[DarkMatterCore]

After noticing that it is indeed possible to write and use more than one EmuNAND from a single SD card, thanks to the efforts of nop90 at reverse-engineering the Palantine CFW, I decided to write this little tool for Windows in hopes of simplifying the process as much as possible, since I think no one has done it yet.

Basically, it performs the following steps:

• Automatically look for the drive that contains the EmuNAND, by checking all the available storage drives and comparing their MBR string to the one set during the EmuNAND creation on sector #0. All the operations will be performed solely on this drive. Make sure to run the program with administrative privileges.

• Once the SD card is found, check if the NAND dump we're going to work with is valid (either the file [inject] or the SD card EmuNAND/RedNAND [extract]).

• If an injection mode ("Inject EmuNAND", "Inject RedNAND") is selected with either the second, third or fourth NAND and the current FAT32 partition collides with that NAND's offset, the MBR information on the SD card is updated to reflect the new FAT32 partition offset, which gets moved further to the right. Additionally, a quick format operation is performed on the new partition (by calling the Windows "format" tool). Make sure to backup the data present in the FAT32 partition beforehand, since the program won't do it for you!

• Read/write the NAND dump using 64 KiB data chunks.

Additional notes:

• If the FAT32 partition already begins at a valid offset, you can pretty much use this tool to inject a new NAND dump as the first, second, third or fourth EmuNAND, replacing the previous one.

• It isn't necessary to add a 512-bytes dummy header to the NAND dump (e.g., running "drag_emunand_here.bat" on it) before using this program, even though it is compatible with such dumps. If you want to write the input NAND dump as a RedNAND, just click the "Inject RedNAND" button.

Already tested with my own Old 3DS, using two different SD cards (Kingston 4GB, SanDisk 32GB). Feedback is appreciated.

Download latest version (v1.72): https://raw.githubusercontent.com/DarkMatterCore/3ds-multinand/master/3ds-multinand.exe. Feel free to check out the GitHub repo if you wanna take a look at the source code.
________________________________

Official changelog:

v1.72:
* The program now always forces the creation of a new, 4 MiB aligned offset for the FAT partition when injecting a new NAND. This fixes a bug where the first sector from the new FAT partition would have been overwritten with a dummy footer if the generated offset for the partition was already aligned to a 4 MiB boundary. Thanks to Kazuma77 for testing.
* If a new NAND is injected and the size of the previous NAND was greater than the size of the new NAND, the stored NAND dump will be zero padded to match the previous NAND size right after the injection process is finished.
* Now, only the format procedure defaults to the minimum NAND size possible. The rest of the NAND inject operations use the default NAND size layout to avoid problems.

v1.71:
* Updated program manifest to target at more Windows versions.
* Added a proper Windows version check. The program won't run under a Windows version older than XP SP2.
* Fixed a bug where the DRIVE_INFO struct pointer could be freed twice, leading to a crash when trying to refresh the drives lists.
* Simplified the code for checking if the program is running under admin mode.

v1.7:
* Completely revamped the EmuNAND parsing code.
* Added compatibility with multiple NAND layouts in the same SD card. The program is now able to detect, read and write EmuNANDs that don't share the same layout as the first one.
* Every NAND inject operation now defaults to the minimum size possible, including the format procedure. This should fix some compatibility problems with Luma3DS.
* If a new NAND is injected and the size of the previous NAND was greater than the minimum size possible, and if it wasn't stored as a RedNAND, its NCSD header will be wiped from the SD card to avoid problems.

v1.61:
* Fixed a NAND offset miscalculation while parsing EmuNANDs.
* Fixed a regression bug where the NCSD header was always written/read to/from offset "nandsize + 512" instead of the appropiate sector (EmuNAND only).
* Fixed a bug where the calculated NAND size would be zero if a new EmuNAND with a size greater than the current layout was being injected.
* Improved FAT32 format procedure reliability (based on code from Rufus).
* Fixed a crash that occurred when attempting to format a new FAT32 partition (debug build only).
* The program is now licensed under GPLv3.

v1.6:
* Added support for 1.82 GiB N3DS NAND dumps.
* Added proper detection of 2DS NAND dumps.
* The "Format EmuNAND" procedure now defaults to the 'minimum' setup size, using a RedNAND.
* The program now forces the "Remove NAND" button to be enabled if a previous attempt to remove the first EmuNAND failed.
* The MBR is now manually initialized with zeros before creating it using WinAPI instructions (leftover data is kept in sector #0 otherwise).

v1.5:
* Added a checkbox to determine if fixed drives have to be added to the drop-down lists while the program is parsing the currently available storage drives (suggested by piratesephiroth).
* The program now retrieves the extended partition information when parsing the currently available drives in order to get a proper starting offset, instead of manually calculating it based on the MBR information (which may not exist at all).
* Added a "Remove EmuNAND" button, which removes the selected EmuNAND from the SD card. Please bear in mind that this procedure modifies the partition table from the MBR, so backup your data before using it. If an EmuNAND that precedes one or more additional EmuNANDs is removed, these will also get lost. The removal of EmuNAND #1 is equivalent to formatting the SD card without an EmuNAND, e.g. you will gain back all the space consumed by the EmuNAND(s).
* Fixed a bug where the program wouldn't format the FAT32 partition of the selected drive after a previous run of the format procedure failed *but* the partition table was successfully modified.
* The program will now add a valid MBR to sector #0 if it isn't found during the format procedure.

v1.4:
* Autodetection of Old 3DS/New 3DS EmuNANDs for both input/output procedures, which removes the need of manually selecting a 3DS model.
* Added support for additional EmuNAND9 offsets. Every EmuNAND/RedNAND is now created using the 'default' setup size (except if you're creating additional EmuNANDs, in which case the same layout from EmuNAND #1 will be applied).
* The program now shows the capacity of each drive displayed in the drop-down lists. Furthermore, only drives with a capacity greater than 1 GiB will be displayed in the drop-down lists.
* The program now checks if a valid EmuNAND is available at the selected slot before writing the name to the SD card.
* Fixed a bug that made the "Refresh" button also write the EmuNAND name instead of just reading it.
* The FAT32 partition label is now properly written during the format procedure.
* Removed the boot.bin modification feature.
* Fixed some more threading bugs.

v1.3:
* It is now possible to set a custom name to an EmuNAND, which can be displayed by CakesFW in its Multi EmuNAND selection menu.
* The program is now able to format the FAT32 partition without calling the format.exe tool from Windows, using code from fat32format by Ridgecrop.
* Added compatibility with exFAT SD cards. Please have in mind that these cards *will* get formatted to FAT32, if they already aren't.
* Fixed some threading bugs.

v1.2:
* Fixed compatibility with EmuNANDs generated with the EmuNAND9 Tool (different FAT32 starting offset).

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.

v1.0:
* Added the "Format EmuNAND" feature, which allows the users to format an EmuNAND in a new SD card without using a Nintendo 3DS console, as long as a proper NAND dump is given to the program.

v0.9:
* The program now shows a warning if the "Inject EmuNAND" button is clicked and if the input NAND dump was previously patched using the "drag_emunand_here" batch file.
* Reimplemented the boot.bin modification feature. Make sure you set the "NAND Number" option to the RedNAND you want to boot, and then click the "Modify boot.bin" button.
* Minor UI changes.

v0.8:
* Program ported to Win32 API, so now it finally has a proper GUI. It still is written in C and compiled with MinGW. Props to my good ol' friend Xiangua/Nana from a certain Spanish forum, for designing the program icon.
* Buffer size changed from 32 KiB to 64 KiB.

v0.7:
* Program named changed yet again, this time around to "3DS Multi EmuNAND Creator", or "3ds-multinand" for short. Props to Cyan from GBAtemp for the idea (yeah, I'm *that* bad with names).
* Added compatibility with a fourth EmuNAND, because why not? Just use the "-4" parameter.
* The program now checks if the target SD card is write-protected if an input mode is used.
* The program now checks if it is running with administrative privileges. I hope this will keep some people from asking why the program isn't working appropiately...
* Added compatibility with the "3DSCARDNAND" MBR string, since some other 3DS flashcards apparently use it.
* Added compatibility with New 3DS NAND dumps (with multi EmuNAND support). Program usage has been changed again, so please check out the help screen. To make the program use the New 3DS specific offsets, just change argument #1 to "-new". If you just want to keep using the Old 3DS offsets, use "-old" instead. Please bear in mind that the "-cfw" parameter won't do any good while using the "-new" option, since the Palantine CFW isn't compatible with the New 3DS to begin with.

v0.6 (beta 3):
* The program now checks if a logical drive is ready before closing the handle and trying to open its physical drive.

v0.6 (beta 2):
* Fixed compatibility with FAT16 partitions.

v0.6 (beta):
* Name changed from "3ds-dualnand" to "3ds-triplenand".
* The program is now able to write an EmuNAND to the second RedNAND offset in the SD card. Previously, it was hardcoded to only write a RedNAND to this offset, even when using the "-i" parameter.
* Now, the program is able to configure a third EmuNAND/RedNAND by moving the FAT32 partition further to the right, increasing the size of the unallocated space reserved for the NANDs.

v0.5:

* FAT32 format procedure no longer requires any user input.
* Fixed compatibility with RedNANDs (NAND dumps with a 512 bytes long dummy header).
* You can now use the "-cfw" parameter instead of "-i" to write the input NAND dump as a RedNAND (for use with the Palantine CFW).
* Corrected a previous behaviour where EmuNANDs were being written as RedNANDs for "GATEWAYNAND" SD cards (only if the "-1" parameter was used). The NCSD header is now written to the appropiate offset.
* The application now writes a dummy footer after the NAND dump in the SD card during any given input operation, which serves to indicate the right size of the output NAND dump when doing an extraction. This is because the size calculation based in the NCSD header info doesn't always match the right NAND flash capacity.

v0.4:

* Added compatibility with the first EmuNAND. To select an EmuNAND, use either the "-1" (first EmuNAND) or "-2" (second EmuNAND) option, along with the operation parameter (either "-i" or "-o").

v0.3:

* You can now specify an input ("-i") or output ("-o") parameter, to either write or extract the second EmuNAND.

v0.2:

* Added compatibility with SD cards that contain an EmuNAND created by the Gateway Launcher.dat.

v0.1:

* Initial release, only able to write a second EmuNAND to the SD card.

 

[misterb98]

This could be useful for those with a DS flashcart without a gateway. What we really need is a launcher that can launch launchers XD

 

[DarkMatterCore]

This could be useful for those with a DS flashcart without a gateway. What we really need is a launcher that can launch launchers XD

Like me.

Sadly, ROP chain handling is way out of my current abilities. Otherwise, I'd probably do it.

 

[misterb98]

Like me.

Sadly, ROP chain handling is way out of my current abilities. Otherwise, I'd probably do it.

Ya, I don't blame you. From what I have looked at, that looks really hard!

Edit: You could try getting a hex library and check all the partitions for a drive that had MT-CARDNAND or GATEWAYNAND in plaintext at the beginning of the partition. That might be cleaner than relying on launcher.dat for drive detection

 

[DarkMatterCore]

Ya, I don't blame you. From what I have looked at, that looks really hard!

Edit: You could try getting a hex library and check all the partitions for a drive that had MT-CARDNAND or GATEWAYNAND in plaintext at the beginning of the partition. That might be cleaner than relying on launcher.dat for drive detection

That's the "signature" I'm actually checking; look at the code.

My point was that the fact that it exists is because the Launcher.dat sets it during the creation of the EmuNAND. However, right now it only supports MT Card EmuNANDs (since its basically what is used in nop90's tutorial). I'll fix that when I release the new version.

 

[Asia81]

It's possible to use gateway emunand (i have gateway) and a CFW for try my cia in the same sd card ?

 

[misterb98]

That's the "signature" I'm actually checking; look at the code.

My point was that the fact that it exists is because the Launcher.dat sets it during the creation of the EmuNAND. However, right now it only supports MT Card EmuNANDs (since its basically what is used in nop90's tutorial). I'll fix that when I release the new version.

Ah, I misread your post then. You are waaaay ahead of me ^^ Your post makes it looks like it checks for an MD5 or Other checksum of the Launcher.dat file in the filesystem.

 

[gamesquest1]

It's possible to use gateway emunand (i have gateway) and a CFW for try my cia in the same sd card ?

https://www.dropbox.com/s/q8lm6s74o8qpiy2/dualnand.zip?dl=0 think this should work....just edited the MTCARD_NAND to GATEWAYNAND.....simplez XD

(ps untested, but im assuming thats all there is too it )

 

[felystar]

So this is used to have 2 emuNANDs at the same time on a single SD card?

 

[DarkMatterCore]

It's possible to use gateway emunand (i have gateway) and a CFW for try my cia in the same sd card ?

Now you can. Check the first post.

So this is used to have 2 emuNANDs at the same time on a single SD card?

Basically, yes. However, the second EmuNAND is usually used as the RedNAND for the CFW, since currently it is the only loading method that supports custom boot sectors.

 

[henn64]

Sow how do you switch which emunand the GW loader uses?

 

[DarkMatterCore]

Sow how do you switch which emunand the GW loader uses?

You have to use the ROP Multiloader to switch between the "Gateway Launcher.dat 4x" (encrypted GW/MT Launcher.dat) and the "Homebrew MsetForBoss.dat 4x" (decrypted Palantine CFW) ROP chains. But right now, you need to have a DS flashcard. nop90 explains it better in his tutorial.

 

[henn64]

You have to use the ROP Multiloader to switch between the "Gateway Launcher.dat 4x" (encrypted GW/MT Launcher.dat) and the "Homebrew MsetForBoss.dat 4x" (decrypted Palantine CFW) ROP chains. But right now, you need to have a DS flashcard. nop90 explains it better in his tutorial.

I'll check that out, thanks.

 

[DarkMatterCore]

Updated program to v0.3. Now it can also extract the second EmuNAND.

 

[ChrisX930]

We really need something that let us select which EmuNAND we want to start. Something that starts when we going into the DS Profile Exploit and then "Select Launcher".
Like:
SELECT LAUNCHER
- EmuNAND 7.1 (GW_Launcher.dat)
- RedNAND 4.5 (CFW_Launcher.dat)

A Launcher that Launch launcher files... hehe,,,

 

[sergio2195]

Sorry for my ingorance but with this app the players who have a 4.5 CFW and EmuNAND 9.x (without Gateway) can we play .cia's directly in the emuNAND and play games that required 7.x Keys?¿

 

[DarkMatterCore]

No, you're definitely getting the wrong idea. This only serves to store a second EmuNAND in a SD card that already has a formatted Gateway / MT Card EmuNAND. This second EmuNAND can be the RedNAND/CFWNAND, and you can use a modified boot.bin file with the Palantine CFW to boot it.

 

[Asia81]

Can you explain quickly step by step on how to have 2 emunand on the same SD ? (1 GW emunand and 1 CustomFirmware)

?

 

[DarkMatterCore]

Once you format the EmuNAND using the Gateway Launcher.dat, extract it to your PC using EmuNAND Tool, place this program along the extracted NAND dump and a copy of the boot.bin file from the Palantine CFW, and run it using the following command:

3ds-dualnand -i emuNAND.bin boot.bin​

Bear in mind that you have to backup the data in the FAT32 partition beforehand, since it'll get moved to the right (and quick-formatted). Afterwards, you should end up with an "unallocated space" of 2 GiB where the two EmuNANDs are stored, and a smaller FAT32 partition. Finally, move the Palantine CFW files to the SD card (and, while you're at it, the backup of your files you made earlier), but replace the boot.bin with the one modified by the program.

This is of course assuming the GW EmuNAND is on 4.X. If that isn't the case, you will have to generate a 4.X NAND backup from your console (then again, assuming your SysNAND is on 4.X) and use the NAND.BIN file with the program:

3ds-dualnand -i NAND.BIN boot.bin​

 

[phanteon]

buena chamo!