Difference between revisions of "NAND Redirection"
| (3 intermediate revisions by 3 users not shown) | |||
| 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 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. | ||
Latest revision as of 13:06, 14 January 2016
NAND redirection is an umbrella term for methods used to redirect 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[edit]
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 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[edit]
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[edit]
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[edit]
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 obtaining the relevant keys. This is because the AES engine keyslots introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from OTP data upon boot. Since OTP access is blocked via CFG_SYSPROT9 shortly after that, it's impossible to perform this keyslot initialization at any later time.