96
edits
Changes
this can be worked around as an initial entrypoint but it's not really intended as that. also cleanup on base exploit description - k9l keys aren't really relevant to this hack. standby for known-plaintext description.
| enhanced-arm9loaderhax
| enhanced-arm9loaderhax
| See the 32c3 3ds talk.
| See the 32c3 3ds talk.
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax and it is mandatory to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed as long as one has the proper FIRM xorpads. However, if one doesn't have said FIRM xorpads, a FIRM update could prevent the obtention of useful xorpads to downgrade his FIRM. For that, the updated sections would need to start after the size of the latest vulnerable FIRM. The "hole" would be filled with random data generated on first boot. Thus, as we don't know the decrypted value, we can't generate the relevant xorpad without ARM9 access.
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.
| arm9loaderhax which automatically occurs at hard-boot.
| arm9loaderhax which automatically occurs at hard-boot.
| See arm9loaderhax / description.
| See arm9loaderhax / description.