(Created page with "Historically, 3DS custom firmware required the use of NAND redirection to be safely used, commonly called EmuNAND or RedNAND. Before 2016, there was no method to boot directly into custom firmware. == Differences between EmuNAND and RedNAND == {{Section WIP|notes=When did RedNAND first appear? When did it start to be recommended over EmuNAND? I think this was when Old 2DSes started being produced with 1.8 GiB NANDs but there were issues accessing data past the 1 GiB ma...") |
m (Ihaveahax moved page User:Ihaveahax/3DS:EmuNAND and RedNAND to 3DS:EmuNAND and RedNAND without leaving a redirect) |
(No difference)
| |
Revision as of 10:50, 28 August 2022
Historically, 3DS custom firmware required the use of NAND redirection to be safely used, commonly called EmuNAND or RedNAND. Before 2016, there was no method to boot directly into custom firmware.
Differences between EmuNAND and RedNAND
 | This section is a work in progress. Notes:
When did RedNAND first appear? When did it start to be recommended over EmuNAND? I think this was when Old 2DSes started being produced with 1.8 GiB NANDs but there were issues accessing data past the 1 GiB mark. Check GodMode9 issues. |
EmuNAND first appeared with Gateway-3DS. All NAND reads and writes were redirected to the SD card at the same positions, except for the first block which was placed at the end of the EmuNAND to make space for the MBR header. The disadvantage of this was that consoles with large NAND sizes would require an equally large EmuNAND, with most of the space being unused.
RedNAND is an alternative type of NAND redirection that instead shifts all NAND reads and writes by one block when redirecting to the SD card. The advantage was that the RedNAND would only be as small as needed (~988 MiB for Old 3DS and ~1.2 GiB for New 3DS).
Why it was used in the past
Homebrew could originally only be launched by using an exploit within the 3DS firmware. Notable examples include DS Profile Settings in System Settings (also known as the "MSET exploit"), various game and Internet Browser exploits, and menuhax.
The problem with this setup is that Nintendo can and has fixed these vulnerabilities in updates. Nintendo requires that the console is updated to use the eShop, and newer games would also require newer system versions.
With EmuNAND and RedNAND, this problem could be worked around by instead booting into an alternative NAND that was up to date, while leaving the system on an older, vulnerable firmware.
Reasons why it's no longer recommended
With the advent of permanent boot-time methods such as arm9loaderhax and boot9strap, the use of custom firmware purely on the internal system memory (also known as "SysNAND") became safer to use. The need for NAND redirection declined and soon it was unrecommended for new setups.
- NAND redirection did not protect against bans, because bans were rarely a concern. Nintendo has historically not banned people just for using homebrew/custom firmware online.
- Certain software such as TWiLight-Menu++ does not work at all with EmuNAND or RedNAND.
- Switching SD cards is more difficult with EmuNAND or RedNAND, as it requires formatting the new SD card specifically to support it, then restoring a backup.
- NAND redirection does not protect the internal storage from failing due to use. The amount of writing done to the system's flash memory is relatively very small most of the time. There are currently no reported cases of a 3DS's NAND chip failing due to excessive or long-term use.