Difference between revisions of "NAND Redirection"

From 3dbrew
Jump to navigation Jump to search
(yolo (really, this was in desperate need for documentation, given the complete lack of technical documentation everywhere))
 
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.

Revision as of 00:46, 4 November 2015

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

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

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.