91
edits
Changes
mLine 5:
Line 5: − + − How to get around that? It probably means the hash table for the partition, is being hashed to verify the hash table itself, but if you modify just the filler data following the hash table ( same block ) it will not cause "corrupted data" messages on a game cartridge. + + − + +
edit -minor formatting
2. What is the hash-list after all DIFI blobs?
2. What is the hash-list after all DIFI blobs?
3. Re-ordering hashes in the partition table and the blocks of data associated with them (without changing anything) yields a "corrupt data" error.
3. Re-ordering hashes in the partition table and the blocks of data associated with them (without changing anything) yields a "corrupt data" error. How to get around that?
It probably means the hash table for the partition, is being hashed to verify the hash table itself, but if you modify just the filler data following the hash table ( same block ) it will not cause "corrupted data" messages on a game cartridge.
That means the entire 0x1000 block of data, where the hashes are contained, must not be what's hashed, since only editing or re-arranging ( to not invalidate hashes in the list ) anything of the first 0x200 bytes or so, where the hash data is actually generates data corruption errors.
That means the entire 0x1000 block of data, where the hashes are contained, must not be what's hashed, since only editing or re-arranging ( to not invalidate hashes in the list ) anything of the first 0x200 bytes or so, where the hash data is actually generates data corruption errors.
However I cannot locate any hash for either the 0x1000 block or for just the data that is causing the errors if modified ( the first 0x200 bytes ).
However I cannot locate any hash for either the 0x1000 block or for just the data that is causing the errors if modified ( the first 0x200 bytes ).
Comments:
Comments:
1. I noticed the hash list doesnt seem to be in the same order as the blocks of data following it. The first 0x1000 block in the partition might be verified by the 12th hash in the list.
1. I noticed the hash list doesn't seem to be in the same order as the blocks of data following it. The first 0x1000 block in the partition might be verified by the 12th hash in the list.