By entering this site you need to consent to the use of cookies and their functional use according to this privacy policy. Cookies help us to provide the functional services of the website. Kindly read the below message of use and consent to the use.
The following cookies are stored and shared when accessing this website:
- Internal cookies for the MediaWiki site. This is used for user authentication and article modifications.
- Third-party cookies from Google providing services for Google AdSense and Google Analytics
We will never use data collected outside of the above scope.
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 really be completely fixed. More New3DS keys could be generated differently/etc in an updated arm9loader which also fixes arm9loaderhax, but that's about all really.
+
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.
| arm9loaderhax which automatically occurs at hard-boot.
| arm9loaderhax which automatically occurs at hard-boot.