Changes

Jump to navigation Jump to search
1,230 bytes removed ,  13:58, 2 January 2018
Nuke the old content
Regular apps can only mount SD extdata using the same extdataID which is stored in the [[NCCH#CXI|CXI]] exheader. Therefore, regular apps which have the exheader extdataID set to zero can't use extdata. This restriction doesn't apply for shared extdata with extdataID high bitmask 0x48000 stored on NAND. System apps with a certain access right can mount arbitrary extdata.
All NAND extdata is shared extdata, while all SD extdata is normal extdata. Thus, normal extdata doesn't exist on NAND, and shared extdata doesn't exist on SD. The extdataID high excluding that bitmask is always zero for shared extdata.
 
=== Encryption ===
The SD extdata are encrypted following [[SD Filesystem|the general SD filesystem encryption rule]]. The NAND extdata images are stored in cleartext.
=== Format ===
Extdata uses dual 'partitions' of IVFC hash trees to store data. The order of data in Extdata is as follows: * AES MAC* DIFF Header* Secondary DIFI Partition descriptor* Primary DIFI Partition descriptor* Secondary Partition IVFC Hash Tree* Primary Partition IVFC Hash Tree* DATA Partition (If applicable) Only one Partition is active at a given time, this is determined by the DIFF header. Normally the 'data' contained in All extdata is stored at level4 of the IVFC hash tree, and hence there are two versions of the 'data' stored in the Extdata image (although only one is 'active'). However if DIFI flags[0[DISA and DIFF|DIFF container files]] is set, this indicates it is a DATA partition and the 'data' is stored outside the IVFC hash tree, at a relative offset defined by the DIFI partition (in follow this case there will be only one version of the 'data' stored in link for the Extdata imagecontainer format description). ==== Chain Of Trust ==== The chain of trust in extdata format description below is as follows: * MAC verifies DIFF Header* DIFF Selects and verifies via Active DIFI partition descriptor* Active DIFI partition descriptor points to for the location of active IVFC tree (and data if applicable), and provides the hash blob to verify Level 1 inner content of the IVFC hash tree* Each IVFC level verifies the next level, until Level 4(data)containers.
=== Filesystem ===
242

edits

Navigation menu