6,264
edits
Changes
→arm9loader
For keyslots 0x16, 0x19-0x1F it uses a new key for keyslot 0x11, but the actual algorithm has not been changed. This time the keyslot 0x11 seed is loaded from (nand_sector96+0x10) instead of (nand_sector96+0). They also changed the initialization vector for the 0x19-0x1F key-generation to a new hardcoded key.
For keyslots 0x16, 0x19-0x1F it uses a new key for keyslot 0x11, but the actual algorithm has not been changed. This time the keyslot 0x11 seed is loaded from (nand_sector96+0x10) instead of (nand_sector96+0). They also changed the initialization vector for the 0x19-0x1F key-generation to a new hardcoded key.
Since we don't know the decrypted value at (nand_sector96+0x10), we don't know the new key for keyslot 0x11, and we cannot generate keys for the updated keyslots 0x16, 0x19-0x1F. Thus they plugged their hole and we can no longer decrypt arm9-binary without a new arm9 code-execution exploit or nandmodding.
Since we don't know the decrypted value at (nand_sector96+0x10), we don't know the new key for keyslot 0x11, and we cannot generate keys for the updated keyslots 0x16, 0x19-0x1F. Thus they plugged their hole and we can no longer decrypt arm9-binary without an arm9 code-execution exploit compatible with 9.6.0-X or <tricks where some of these *require* nand-modding>.
On panic, arm9loader now clears keyslots 0x15, 0x16, 0x18, 0x19, 0x19-0x1F. Previous versions only cleared 0-7, 0x15, 0x16.
On panic, arm9loader now clears keyslots 0x15, 0x16, 0x18, 0x19, 0x19-0x1F. Previous versions only cleared 0-7, 0x15, 0x16.