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.
+
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.
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.