Hacking [RELEASE] 3DS Multi EmuNAND Creator

[DarkMatterCore]

Used it and got a new error

Error: FAT16 partition offset (beginning at 0x3fbc0400) collides
with the **first** EmuNAND offset (beginning at sector #1).

This is probably some kind of corruption. Format the EmuNAND
again on your Nintendo 3DS console to fix this.

BTW Im trying to use it on a REDNAND, but it looks like only some people had problems with it while others doesnt.It worked perfectly on a normal emunand.

An override or force function would be awesome, at least for me as messing with the emunand can't brick the console and a lot of people here is trying to do some experiments with this tool. Excellent tool keep improving it.

I performed a few tests with a 2GB SD card and the FAT16 partition also got moved to the offset 0x40000000 after formatting the EmuNAND with the GW Launcher.dat, just like all my other SD cards with greater capacity (and FAT32 partitions). It's a security measure that's been there ever since the program was initially released, to avoid reading/writing an unwanted sector (e.g. completely wiping crucial FAT filesystem sectors).

Did you write a disk image to your current SD card? Because that would sorta explain the problem with the FAT16 partition start sector. god88 did this and that was the reason my program wasn't detecting his SD card as valid, because the GW/MT MBR signature wasn't preserved. I did fix the problem with the logical drives that were not ready, although that was completely unrelated in the end.

I don't really want to add a force option for the reasons mentioned above; I want to keep the program as straightforward as possible. However, I can still help you get a dump of your RedNAND through other means (modified 3ds-triplenand build, 'dd', etc.), though I do recommend you to format the EmuNAND once again after you do this, since the partition start offset **really** should be 0x40000000. Let's just stay on the safe side.

BTW, the same check is performed for both types of NAND, so unless the EmuNAND you're mentioning was stored on a different SD card, it just isn't possible.

According to my experience, most people's problems are related to not running the program with administrative privileges. I have yet to see someone who gets an error code different than 5...

 

[storm75x]

Waiting for a Quadriple Emunand Creator. It's gonna happen, I'm calling it.

 

[DarkMatterCore]

Waiting for a Quadriple Emunand Creator. It's gonna happen, I'm calling it.

With the current code flow, it would take me nothing to add compatibility with a fourth NAND. But we first need a loader capable of booting more than one EmuNAND; right now, just creating a third EmuNAND is pointless, but at least the support is already there.

 

[storm75x]

With the current code flow, it would take me nothing to add compatibility with a fourth NAND. But we first need a loader capable of booting more than one EmuNAND; right now, just creating a third EmuNAND is pointless, but at least the support is already there.

Onwards to 10 emuNANDs. The question is not about why, but why not?

 

[DarkMatterCore]

I have even thought about doing just what Cyan suggested me and change the program name to "3ds-multinand", for real (and add a GUI while I'm at it). I'd still love to see multiple EmuNAND support on rxTools.

 

[DarkMatterCore]

Program updated to v0.7, with some very neat changes:

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.8 will most likely be about implementing a GUI using MinGW, now that I have sorted out most problems and added compatibility with New 3DS.

 

[DarkMatterCore]

Here's a little something called "v0.8 with Win32 API GUI support" I think you may really like...

Spoiler

Support for the command window has been dropped for now, as well as the ability to modify the boot.bin file (this is because TRICK CFW is now able to change the boot sector on the fly).

As always, the first post has been updated. Any feedback is appreciated.

 

[AkiraX3]

Great Tool, Nice Job

 

[PandaMayFire]

This is really cool, didn't know anything like this existed... so if I install a 2nd NAND and turn it into CFW, will I lose all of my game saves and installed content and have to start fresh like a brand new NAND?

 

[DarkMatterCore]

This is really cool, didn't know anything like this existed... so if I install a 2nd NAND and turn it into CFW, will I lose all of my game saves and installed content and have to start fresh like a brand new NAND?

The program has been available for a while now, it's just that until now I didn't have enough time to code a proper GUI, but only to fix bugs. Previous versions were CLI-only.

If you keep the 2nd RedNAND (CFW NAND) linked to your SysNAND, the answer is no, as long as your SysNAND is also 4.X and the games you're referring to are 4.X-compatible. Although I don't recommend it, because you can completely wipe the CIAs installed to the SD card under the CFW if you enter the Data Management menu while using the SysNAND.

 

[Razorbacktrack]

Hi,
I love your program,and I really like the new version,good job!
I have a question for you: what's about boot.bin patching to match the new partition?How does it works now?

 

[DarkMatterCore]

The new TRICK CFW frontend created by nop90 is able to modify the boot.bin sector number on the fly, before booting the RedNAND. It's just way better than having to replace the boot.bin file on the SD card each time you want to boot a diferent RedNAND.

I may re-add this feature in the next version if you still want it, though. But ideally, you're better off using TRICK.

 

[Razorbacktrack]

You're right ,thanks a lot

 

[DarkMatterCore]

Program updated to v0.9. Here's the changelog:

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.

As always, the first post has been updated.

 

[vastrolorde]

is it possible to create a region changed emunand/rxtools and palantine cfw.?? i cant seem to work the pal cfw properly.. bottom screen only hangs at a white screen. already changed to modified boot.bin.

 

[DarkMatterCore]

is it possible to create a region changed emunand/rxtools and palantine cfw.?? i cant seem to work the pal cfw properly.. bottom screen only hangs at a white screen. already changed to modified boot.bin.

You want to region change both NANDs? Normally, you'd only region change one and call it a day, but yes, it is possible. Remember that the CFW is unstable, so just keep trying until it finally loads.

 

[vastrolorde]

No i dont want to region change both NANDS, only the emunand with legit cias. but when i try boot into palantine cfw it always just hangs on white screen. which does not happen when you normally boot palantine. tried a it for 50 times. and still cant boot to palantine cfw while on dualnand with region changed emunand.

btw is there a noob friendly tutorial on how to use your multi nand creator.? i usually the old one. with dos batch files

 

[DarkMatterCore]

No i dont want to region change both NANDS, only the emunand with legit cias. but when i try boot into palantine cfw it always just hangs on white screen. which does not happen when you normally boot palantine. tried a it for 50 times. and still cant boot to palantine cfw while on dualnand with region changed emunand.

btw is there a noob friendly tutorial on how to use your multi nand creator.? i usually the old one. with dos batch files

That's an old version of the program, from back when it still didn't have a graphical interface. There are a few noob friendly tutorials for these new versions, but only in Spanish and Italian. I suppose I can give you a quick crash course:

• Nintendo 3DS Model: I don't really need to explain this, do I?

• NAND Number: determines the NAND number slot to be used when an extraction/injection operation is performed.

• Inject EmuNAND: injects an input NAND dump as an EmuNAND to the selected NAND slot number, making it compatible with Gateway, Gateway clones and rxTools.

• Inject RedNAND: injects an input NAND dump as a RedNAND to the selected NAND slot number, making it compatible with the Palantine CFW.

• Extract NAND: extracts the EmuNAND/RedNAND stored at the selected NAND slot number to an output file.

• Modify boot.bin: modifies the boot sector stored in the boot.bin file from the Palatine CFW, in order to make it able to boot a RedNAND from a different sector. This isn't really needed if you use the TRICK frontend created by nop90.

Regarding your problem, I'm beginning to suspect the NAND dump was written as an EmuNAND rather than as a RedNAND. It would be good if you tried using the "Inject RedNAND" option one more time.

 

[vastrolorde]

That's an old version of the program, from back when it still didn't have a graphical interface. There are a few noob friendly tutorials for these new versions, but only in Spanish and Italian. I suppose I can give you a quick crash course:

• Nintendo 3DS Model: I don't really need to explain this, do I?

• NAND Number: determines the NAND number slot to be used when an extraction/injection operation is performed.

• Inject EmuNAND: injects an input NAND dump as an EmuNAND to the selected NAND slot number, making it compatible with Gateway, Gateway clones and rxTools.

• Inject RedNAND: injects an input NAND dump as a RedNAND to the selected NAND slot number, making it compatible with the Palantine CFW.

• Extract NAND: extracts the EmuNAND/RedNAND stored at the selected NAND slot number to an output file.

• Modify boot.bin: modifies the boot sector stored in the boot.bin file from the Palatine CFW, in order to make it able to boot a RedNAND from a different sector. This isn't really needed if you use the TRICK frontend created by nop90.

Regarding your problem, I'm beginning to suspect the NAND dump was written as an EmuNAND rather than as a RedNAND. It would be good if you tried using the "Inject RedNAND" option one more time.

thank's mate.. what i usually do is click install all legit/region changed cias using palantine copy sd content, extract emunand 1.bat then inject emunand 1.bat and finally run inject rednand 2.bat, restore sd contents, overwrite boot.bin

 

[DarkMatterCore]

thank's mate.. what i usually do is click install all legit/region changed cias using palantine copy sd content, extract emunand 1.bat then inject emunand 1.bat and finally run inject rednand 2.bat, restore sd contents, overwrite boot.bin

Doing a backup of all your SD content after the FAT32 partition has been moved (which is done the first time you perform such steps) is overkill.

I assume you install the CIAs to your second RedNAND, and then extract it to inject it to the first slot as an EmuNAND, right? If so, doing what you're saying will most likely result in nothing, since you're not copying the RedNAND to the slot 1 (please note I haven't seen the comands used in the batch files you mention).