Changes

72 bytes removed ,  00:51, 3 February 2012
m
cleanup
Line 80: Line 80:  
* 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 save image is some unknown 0x10-byte data, this gets updated every-time the save is written.(after generation, 0x100 bytes starting at offset 0x0 is compared with the generated stuff, even though everything after the first 0x10-byte entry is all-zero) This might be AES-CCM MAC over the 0x100-byte DISA/DIFF, but it's unknown for certain.
+
* At offset 0x0 in the image is a 0x10-byte MAC, it might be AES-CCM MAC over the 0x100-byte DISA/DIFF but it's unknown for certain. The 0xe0-bytes following the MAC is normally all-zero and is compared with generated data, it's unknown whether this and the generated data can be non-zero.
    
{| class="wikitable"
 
{| class="wikitable"