Line 37:
Line 37:
0000000: 4e41 4e44 424f 4f54 494e 464f fd00 2714 NANDBOOTINFO..'.
0000000: 4e41 4e44 424f 4f54 494e 464f fd00 2714 NANDBOOTINFO..'.
0000010: 0035 0000 1020 0000 1000 0001 0000 0000 .5... ..........
0000010: 0035 0000 1020 0000 1000 0001 0000 0000 .5... ..........
−
=== File structure ===
+
{| class="wikitable"
{| class="wikitable"
|-
|-
Line 83:
Line 83:
|-
|-
| 0x15
| 0x15
−
| 0x16
−
| 2
−
| 0
−
| unknown
−
|-
−
| 0x17
| 0x18
| 0x18
−
| 2
+
| 4
| 0x1000
| 0x1000
| uid
| uid
Line 104:
Line 98:
| 4
| 4
| 0
| 0
−
| unknown
+
| x3 (unknown, but see below)
+
|-
+
|}
+
+
=== HMAC info ===
+
The filesystem data and metadata clusters are "signed" with an HMAC to prevent tampering. The HMAC key is a 20-byte key stored in OTP, but each cluster is also seeded with a non-standard "salt". This 0x40-byte piece of data is generated in memory and then fed into the HMAC algorithm, and then the unencrypted contents of a cluster is fed through the HMAC algorithm. Two copies of the resulting 20-byte HMAC value is stored in the spare / OOB area of the cluster, in the 7th and 8th pages within that cluster.
+
+
Salt format for file data:
+
+
{| class="wikitable"
+
|-
+
! Start
+
! End
+
! Length
+
! Description
+
|-
+
| 0x00
+
| 0x03
+
| 4
+
| uid
+
|-
+
| 0x04
+
| 0x0f
+
| 0x0b
+
| filename
+
|-
+
| 0x10
+
| 0x13
+
| 0x04
+
| index (which cluster in the chain this is; for the first cluster, this will be 0, for the second cluster, 1, etc)
+
|-
+
| 0x14
+
| 0x17
+
| 0x04
+
| fst_pos (index into FST)
+
|-
+
| 0x18
+
| 0x1b
+
| 0x04
+
| x3 (unknown field above)
+
|-
+
| 0x1c
+
| 0x3f
+
| 0x24
+
| padding (all zero)
+
|-
+
|}
+
+
Salt format for metadata:
+
{| class="wikitable"
+
|-
+
! Start
+
! End
+
! Length
+
! Description
+
|-
+
| 0x00
+
| 0x11
+
| 0x12
+
| padding (all zero)
+
|-
+
| 0x12
+
| 0x13
+
| 2
+
| cluster (starting cluster number of this metadata block, e.g. 0x7F00)
+
|-
+
| 0x14
+
| 0x3f
+
| 0x2b
+
| padding (all zero)
|-
|-
|}
|}