NAND Redirection - Revision history

Vappy at 12:06, 14 January 2016

2016-01-14T11:06:21Z

← Older revision		Revision as of 14:06, 14 January 2016
Line 15:		Line 15:
	=== Restrictions on New 3DS ===		=== Restrictions on New 3DS ===

	If the sysNAND of a New 3DS console is below system version 9.6, it is not ~~currently publicly~~ possible to have NAND redirection work with a redirected NAND of any system version since 9.6. This is because the [[AES\|AES engine keyslots]] introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from [[OTP Registers\|OTP data]] upon boot. Since OTP access is blocked via [[CONFIG_Registers#CFG_SYSPROT9\|CFG_SYSPROT9]] shortly after that, it's impossible to perform this keyslot initialization at any later time.		If the sysNAND of a New 3DS console is below system version 9.6, it is not possible to have NAND redirection work with a redirected NAND of any system version since 9.6 without first [[3DS_System_Flaws#arm9loader\|obtaining the relevant keys]]. This is because the [[AES\|AES engine keyslots]] introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from [[OTP Registers\|OTP data]] upon boot. Since OTP access is blocked via [[CONFIG_Registers#CFG_SYSPROT9\|CFG_SYSPROT9]] shortly after that, it's impossible to perform this keyslot initialization at any later time.

Syphurith: Added missing brace to fix the link on this page.

2015-11-05T07:50:31Z

Added missing brace to fix the link on this page.

← Older revision		Revision as of 10:50, 5 November 2015
Line 15:		Line 15:
	=== Restrictions on New 3DS ===		=== Restrictions on New 3DS ===

	If the sysNAND of a New 3DS console is below system version 9.6, it is not currently publicly possible to have NAND redirection work with a redirected NAND of any system version since 9.6. This is because the [[AES\|AES engine keyslots]] introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from [[OTP Registers\|OTP data] upon boot. Since OTP access is blocked via [[CONFIG_Registers#CFG_SYSPROT9\|CFG_SYSPROT9]] shortly after that, it's impossible to perform this keyslot initialization at any later time.		If the sysNAND of a New 3DS console is below system version 9.6, it is not currently publicly possible to have NAND redirection work with a redirected NAND of any system version since 9.6. This is because the [[AES\|AES engine keyslots]] introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from [[OTP Registers\|OTP data]] upon boot. Since OTP access is blocked via [[CONFIG_Registers#CFG_SYSPROT9\|CFG_SYSPROT9]] shortly after that, it's impossible to perform this keyslot initialization at any later time.

WulfyStylez: q:3c

2015-11-04T01:25:05Z

q:3c

← Older revision		Revision as of 04:25, 4 November 2015
Line 15:		Line 15:
	=== Restrictions on New 3DS ===		=== Restrictions on New 3DS ===

	If the sysNAND of a New 3DS console is below system version 9.6, it is ~~impossible~~ to have NAND redirection work with a redirected NAND of any system version since 9.6. This is because the [[AES\|AES engine keyslots]] introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from [[OTP Registers\|OTP data] upon boot. Since OTP access is blocked via [[CONFIG_Registers#CFG_SYSPROT9\|CFG_SYSPROT9]] shortly after that, it's impossible to perform this keyslot initialization at any later time.		If the sysNAND of a New 3DS console is below system version 9.6, it is not currently publicly possible to have NAND redirection work with a redirected NAND of any system version since 9.6. This is because the [[AES\|AES engine keyslots]] introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from [[OTP Registers\|OTP data] upon boot. Since OTP access is blocked via [[CONFIG_Registers#CFG_SYSPROT9\|CFG_SYSPROT9]] shortly after that, it's impossible to perform this keyslot initialization at any later time.

Neobrain at 01:17, 4 November 2015

2015-11-04T00:17:09Z

← Older revision		Revision as of 03:17, 4 November 2015
Line 12:		Line 12:

	Calling the NAND image size N, EmuNAND places bytes [512:N-1] of the NAND image at byte offset 512 on the SD card, and bytes [0:511] at byte offset N. The modified firmware needs to make sure that NAND reads/writes to the first 512 bytes are redirected properly, but leaves all other accesses unmodified.		Calling the NAND image size N, EmuNAND places bytes [512:N-1] of the NAND image at byte offset 512 on the SD card, and bytes [0:511] at byte offset N. The modified firmware needs to make sure that NAND reads/writes to the first 512 bytes are redirected properly, but leaves all other accesses unmodified.

			=== Restrictions on New 3DS ===

			If the sysNAND of a New 3DS console is below system version 9.6, it is impossible to have NAND redirection work with a redirected NAND of any system version since 9.6. This is because the [[AES\|AES engine keyslots]] introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from [[OTP Registers\|OTP data] upon boot. Since OTP access is blocked via [[CONFIG_Registers#CFG_SYSPROT9\|CFG_SYSPROT9]] shortly after that, it's impossible to perform this keyslot initialization at any later time.

Neobrain at 23:46, 3 November 2015

2015-11-03T22:46:23Z

← Older revision		Revision as of 01:46, 4 November 2015
Line 4:		Line 4:

	The SD filesystem, being a FAT32 partition, can be shrinked and relocated easily. As such, it is easy to make room on the SD card for a full NAND image. By not listing the NAND image partition in the SD card's Master Boot Record (the first 512 bytes of data on the device which is responsible for providing information on the contained filesystems), the NAND image does not interfere with regular SD card access. The actual redirection needs to be done through use of a [[FIRM\|firmware]] modification depending on the location of the NAND image on the SD card. Two common approaches for this are known as EmuNAND and RedNAND, albeit these terms are sometimes also used as synonyms for the concept of NAND redirection in general.		The SD filesystem, being a FAT32 partition, can be shrinked and relocated easily. As such, it is easy to make room on the SD card for a full NAND image. By not listing the NAND image partition in the SD card's Master Boot Record (the first 512 bytes of data on the device which is responsible for providing information on the contained filesystems), the NAND image does not interfere with regular SD card access. The actual redirection needs to be done through use of a [[FIRM\|firmware]] modification depending on the location of the NAND image on the SD card. Two common approaches for this are known as EmuNAND and RedNAND, albeit these terms are sometimes also used as synonyms for the concept of NAND redirection in general.

			=== RedNAND ===

			RedNAND places the full NAND image at byte offset 512 on the SD card. The modified firmware hence needs to offset all NAND reads and writes by 512 bytes.

			=== EmuNAND ===

			Calling the NAND image size N, EmuNAND places bytes [512:N-1] of the NAND image at byte offset 512 on the SD card, and bytes [0:511] at byte offset N. The modified firmware needs to make sure that NAND reads/writes to the first 512 bytes are redirected properly, but leaves all other accesses unmodified.

Neobrain: yolo (really, this was in desperate need for documentation, given the complete lack of technical documentation everywhere)

2015-11-03T22:42:48Z

yolo (really, this was in desperate need for documentation, given the complete lack of technical documentation everywhere)

New page

NAND redirection is an umbrella term for methods used to redirect [[Flash_Filesystem|NAND]] reads and writes from the actual system storage (in this context called sysNAND) to the SD card (or technically, any other data source). Among other things, this allows for accessing more recent (in some cases fully updated) system versions (installed on the redirection source) while keeping access to full-control exploits (through the old system installed on sysNAND).

=== General Idea ===

The SD filesystem, being a FAT32 partition, can be shrinked and relocated easily. As such, it is easy to make room on the SD card for a full NAND image. By not listing the NAND image partition in the SD card's Master Boot Record (the first 512 bytes of data on the device which is responsible for providing information on the contained filesystems), the NAND image does not interfere with regular SD card access. The actual redirection needs to be done through use of a [[FIRM|firmware]] modification depending on the location of the NAND image on the SD card. Two common approaches for this are known as EmuNAND and RedNAND, albeit these terms are sometimes also used as synonyms for the concept of NAND redirection in general.