Changes

198 bytes added ,  03:32, 22 August 2012
Line 68: Line 68:  
* If the uint32 @ 0x168 into the image in the DISA(the low 8-bits) is non-zero, then first table is is hashed, otherwise the second DIFI table is hashed.  
 
* If the uint32 @ 0x168 into the image in the DISA(the low 8-bits) is non-zero, then first table is is hashed, otherwise the second DIFI table is hashed.  
 
* If the table has more then 1 DIFI then the uint32 @ 0x168 is the offset from the DATA partition to the file base (masked with 0xFFFFFFFE).
 
* If the table has more then 1 DIFI then the uint32 @ 0x168 is the offset from the DATA partition to the file base (masked with 0xFFFFFFFE).
* At offset 0x0 in the image is a 0x10-byte MAC over the 0x100-byte DISA/DIFF, it might be AES-CCM MAC but it's unknown for certain. The following 0xf0-bytes after the MAC normally must be zero, it's unknown whether this can ever be non-zero.
+
* At offset 0x0 in the image is a 0x10-byte AES-CCM MAC over a SHA-256 hash. The 0xf0 bytes following the MAC is always zero. For extdata, this hashes parts of the extdata image file path and other data, including the 0x100-byte DISA/DIFF header. SD/NAND uses the the same [[AES]] engine [[Extdata#Encryption|keyslot]] for this MAC, it's unknown what regular SD/NAND savegames uses but gamecard savegames use a separate keyslot for the MAC.
    
{| class="wikitable"
 
{| class="wikitable"