Tutorial A noobNAND's Guide to sysNAND and emuNAND

(Guía en Español)

Introduction

This guide serves as an introduction to what the terms sysNAND and emuNAND mean, what they do, and why they're important. It assumes no previous knowledge or experience of 3DS modding, nor will it include instructions on how to set up emuNAND/unlink NANDs because there are already plenty of great tutorials here about that (however I'll include links to those tutorials wherever appropriate in this guide).

1. What's a NAND?

NAND is a form of flash memory, a way to store information electronically. It stands for NOT AND, although that's not really important here. In the context of Nintendo 3DS, it generally refers to the memory chip inside the 3DS console and the contents stored on it. NAND memory contains all of the system files needed to keep the 3DS running such as the firmware and stock apps (eg. 3DS camera, Mii Plaza). It's kept separate from the SD card, where downloaded games, photos, or extra data is stored. Because of this, a 3DS can run without SD memory, but can't run without NAND.

2. Okay, so what's sysNAND then?

The contents stored on-board the 3DS itself is referred to as sysNAND (system NAND).


As shown in the diagram above, sysNAND is on a chip on the 3DS' internal board, separate to the SD card. The SD card can be removed from the 3DS, but the sysNAND can't. This is the default setup you get when you first receive your 3DS console. When the console starts up, it loads the firmware from sysNAND, then enters the home menu and loads games or other media content from the SD card when needed.

3. What's emuNAND, and what makes it different to sysNAND?

EmuNAND stands for "emulated NAND". EmuNAND is essentially a copy of sysNAND's contents, but stored on a hidden partition on the SD card. You can create an emuNAND partition by using homebrew tools like emuNAND9.


After setting up an emuNAND, you now have the option of loading the 3DS system from either the sysNAND or the emuNAND. The two NANDs act as two separate consoles, but inside one 3DS. It's like having multiple personalities!

4. What does "linked NANDs" mean, and why should I unlink them?

When you first set up an emuNAND, chances are that it's a direct clone of sysNAND. This means that it shares the same Nintendo Network ID account as well as well as other things like theme data, menu icon/folder positions. The trouble is, information can become conflicted between sysNAND and emuNAND (a classic symptom being home menu icons rearranging themselves and eShop downloads becoming re-wrapped again). In order to prevent such conflicts from occurring, the NANDs should be unlinked. This means that one of the NANDs will have to be formatted and set up as new. You can do this with tools like TinyFormat. But before doing any formatting, always remember to create a backup of both NANDs as well as the SD card's contents. You can use emuNAND9 for most backup or restoring tasks.

5. Which NAND should be formatted and which should be used in general?

That's really up to you. Just remember that whichever NAND that's formatted will lose all things like Mii Plaza StreetPass progress and eShop titles (though downloaded games will still be on the SD card, just inaccessible on the formatted NAND). This shouldn't matter much if you properly cloned sysNAND to emuNAND beforehand though, because if you format one NAND, the same information will be preserved on the other. For example, if I have games and everything installed before creating emuNAND and then format my sysNAND, then everything will be reset on sysNAND and it will start up as if it were a new console, but if I switch into emuNAND then all my games, StreetPass characters, and Miis will still be there.

Generally, people format sysNAND and use emuNAND to install games or other homebrew apps on. Why? There are 2 main reasons:

1. It gives you a clean sysNAND to work with. If you installed any homebrew or modified the system in any way, this will be reset.
2. It gives you a fallback in case emuNAND is bricked. If you accidentally install some bad .cias onto emuNAND and cause it to brick, you can easily restore an earlier backup onto the SD card. If however this happens to the sysNAND, restoring won't be so simple. This is due to how the 3DS system boots up.

6. How is the 3DS booting method relevant?

When you power on your 3DS, it will always load the firmware data from sysNAND first, and then it will read information about the home menu, such as themes and icons before entering the home menu.


This means that whatever system files stored on sysNAND must be healthy and undamaged in order for the 3DS to successfully start up. If you've installed something like MenuHax to boot into emuNAND from startup, then the process looks a little more like this:

When the 3DS starts up, it loads the firmware from sysNAND, then when attempting to load theme data for the home menu, it's intercepted by MenuHax which searches and launches boot.3dsx from the root of the SD card. Many setups have boot.3dsx as a CFW that then enters emuNAND (or a boot manager that then leads to the CFW). This also explains why changing themes will temporarily stop MenuHax from working, because the exploit data gets replaced with the new theme data.

The point is, with the Menuhax coldboot method the 3DS will read firmware data from sysNAND first as soon as it's powered on before anything else can run. So if sysNAND were somehow compromised by installing bad .cia files then the 3DS system won't even be able to start up at all. And since recovery mode is part of NAND, a broken sysNAND might mean being unable to enter recovery mode, resulting in a hard-brick. If, on the other hand, the problems occurred on emuNAND, at least the 3DS is capable of booting into sysNAND and from there on, you can work with repairing emuNAND. Going back to diagram 2, we know that emuNAND is removable and sysNAND isn't. So therefore a broken emuNAND can still be extracted and repaired easily since it's on removable media while a badly broken sysNAND can only be fixed with a hardmod, which most 3DS users don't have.

New Update: Arm9loaderhax/Boot9Strap

A recent development in the 3DS homebrew scene is arm9loaderhax/Boot9Strap, which is an exploit that can be run even before sysNAND boots up. This drastically changes how the boot process works:

The exploit is executed as soon as the system powers on, and can run code before sysNAND even starts up. This means that even in the event of sysNAND failure, it's still possible to boot into a recovery utility such as Decrypt9 and attempt to restore the sysNAND. Along with safety features, A9LH and B9S also allow 100% success rate when entering a CFW and boot speeds are similar to stock OFW. There are downsides though, as setting up A9LH takes a lot of time with multiple backups, downgrading to system version 2.1 (small risk of bricking if not careful), and will make it so that the 3DS must have an SD card inserted with an arm9 payload, or it won't boot. B9S however is much easier to install.

Summary

To summarise this rather long post, the 3DS' vital files are stored in NAND. sysNAND lives inside the 3DS' main board while emuNAND lives on the easily accessible SD card. You should unlink NANDs to prevent system conflicts and should always experiment with .cia files on emuNAND since it's easier to recover from a brick. If you have arm9loaderhax though, it's possible to attempt a recovery even if sysNAND has been damaged. I hope this clears up a lot of questions for people who have just joined the 3DS modding community. Good luck!

Glossary