3DS:EmuNAND and RedNAND - Revision history

Ihaveahax: move translate tags to within the bullet points

2025-08-14T00:05:53Z

move translate tags to within the bullet points

← Older revision		Revision as of 00:05, 14 August 2025
Line 35:		Line 35:
	With the advent of permanent boot-time methods such as [[3DS:arm9loaderhax\|arm9loaderhax]] and [[3DS:boot9strap\|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.		With the advent of permanent boot-time methods such as [[3DS:arm9loaderhax\|arm9loaderhax]] and [[3DS:boot9strap\|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.
	</translate>		</translate>
	<translate><!--T:13--> * 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.</translate>		* <translate><!--T:13--> 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.</translate>
	<translate><!--T:14--> * Certain software such as TWiLight-Menu++ does not work at all with EmuNAND or RedNAND.</translate>		* <translate><!--T:14--> Certain software such as TWiLight-Menu++ does not work at all with EmuNAND or RedNAND.</translate>
	<translate><!--T:15--> * 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.</translate>		* <translate><!--T:15--> 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.</translate>
	<translate><!--T:16--> * 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.</translate>		* <translate><!--T:16--> 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.</translate>

	[[Category:Nintendo 3DS information{{#translation:}}]]		[[Category:Nintendo 3DS information{{#translation:}}]]

Ihaveahax: add {{#translation:}}

2025-08-08T00:08:04Z

add {{#translation:}}

← Older revision		Revision as of 00:08, 8 August 2025
Line 40:		Line 40:
	<translate><!--T:16--> * 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.</translate>		<translate><!--T:16--> * 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.</translate>

	[[Category:Nintendo 3DS information]]		[[Category:Nintendo 3DS information{{#translation:}}]]

Ihaveahax: Marked this version for translation

2025-08-01T04:53:39Z

Marked this version for translation

← Older revision		Revision as of 04:53, 1 August 2025
Line 1:		Line 1:
	<languages/>		<languages/>
	<translate>		<translate>
			<!--T:1-->
	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.		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.

	== Moving EmuNAND/RedNAND to SysNAND ==		== Moving EmuNAND/RedNAND to SysNAND == <!--T:2-->

			<!--T:3-->
	Follow [[3dsguide:move-emunand\|Move EmuNAND on 3DS Hacks Guide]].		Follow [[3dsguide:move-emunand\|Move EmuNAND on 3DS Hacks Guide]].

	== Differences between EmuNAND and RedNAND ==		== Differences between EmuNAND and RedNAND == <!--T:4-->
	</translate>		</translate>
	{{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 mark. [https://github.com/d0k3/GodMode9/issues Check GodMode9 issues.]}}		{{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 mark. [https://github.com/d0k3/GodMode9/issues Check GodMode9 issues.]}}
	<translate>		<translate>
			<!--T:5-->
	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.		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.

			<!--T:6-->
	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).		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 ==		== Why it was used in the past == <!--T:7-->

			<!--T:8-->
	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 [[3DS:menuhax\|menuhax]].		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 [[3DS:menuhax\|menuhax]].

			<!--T:9-->
	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.		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.

			<!--T:10-->
	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.		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 ==		== Reasons why it's no longer recommended == <!--T:11-->

			<!--T:12-->
	With the advent of permanent boot-time methods such as [[3DS:arm9loaderhax\|arm9loaderhax]] and [[3DS:boot9strap\|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.		With the advent of permanent boot-time methods such as [[3DS:arm9loaderhax\|arm9loaderhax]] and [[3DS:boot9strap\|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.
	</translate>		</translate>
	<translate>* 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.</translate>		<translate><!--T:13--> * 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.</translate>
	<translate>* Certain software such as TWiLight-Menu++ does not work at all with EmuNAND or RedNAND.</translate>		<translate><!--T:14--> * Certain software such as TWiLight-Menu++ does not work at all with EmuNAND or RedNAND.</translate>
	<translate>* 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.</translate>		<translate><!--T:15--> * 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.</translate>
	<translate>* 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.</translate>		<translate><!--T:16--> * 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.</translate>

	[[Category:Nintendo 3DS information]]		[[Category:Nintendo 3DS information]]

Ihaveahax: translate tags

2025-08-01T04:52:52Z

translate tags

← Older revision		Revision as of 04:52, 1 August 2025
Line 1:		Line 1:
			<languages/>
			<translate>
	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.		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.

Line 6:		Line 8:

	== Differences between EmuNAND and RedNAND ==		== Differences between EmuNAND and RedNAND ==
			</translate>
	{{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 mark. [https://github.com/d0k3/GodMode9/issues Check GodMode9 issues.]}}		{{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 mark. [https://github.com/d0k3/GodMode9/issues Check GodMode9 issues.]}}
			<translate>
	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.		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.

Line 24:		Line 26:

	With the advent of permanent boot-time methods such as [[3DS:arm9loaderhax\|arm9loaderhax]] and [[3DS:boot9strap\|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.		With the advent of permanent boot-time methods such as [[3DS:arm9loaderhax\|arm9loaderhax]] and [[3DS:boot9strap\|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.
			</translate>
	* 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.		<translate>* 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.</translate>
	* Certain software such as TWiLight-Menu++ does not work at all with EmuNAND or RedNAND.		<translate>* Certain software such as TWiLight-Menu++ does not work at all with EmuNAND or RedNAND.</translate>
	* 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.		<translate>* 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.</translate>
	* 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.		<translate>* 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.</translate>

	[[Category:Nintendo 3DS information]]		[[Category:Nintendo 3DS information]]

Ihaveahax at 00:02, 19 February 2024

2024-02-19T00:02:44Z

← Older revision		Revision as of 00:02, 19 February 2024
Line 1:		Line 1:
	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.		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.

			== Moving EmuNAND/RedNAND to SysNAND ==

			Follow [[3dsguide:move-emunand\|Move EmuNAND on 3DS Hacks Guide]].

	== Differences between EmuNAND and RedNAND ==		== Differences between EmuNAND and RedNAND ==

Ihaveahax: Ihaveahax moved page User:Ihaveahax/3DS:EmuNAND and RedNAND to 3DS:EmuNAND and RedNAND without leaving a redirect

2022-08-28T10:50:17Z

Ihaveahax moved page User:Ihaveahax/3DS:EmuNAND and RedNAND to 3DS:EmuNAND and RedNAND without leaving a redirect

← Older revision	Revision as of 10:50, 28 August 2022
(No difference)

Ihaveahax: 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..."

2022-08-25T06:43:59Z

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..."

New page

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 mark. [https://github.com/d0k3/GodMode9/issues 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 [[3DS:menuhax|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 [[3DS:arm9loaderhax|arm9loaderhax]] and [[3DS:boot9strap|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.

[[Category:Nintendo 3DS information]]