Hello everyone, this is just a little blog post for all who ask: “Why should I use ARM9LoaderHax instead of MenuHax or <insert other exploit here>?" For anyone else, this may seem like I'm just retreading the same water here so bear that in mind. If you know something I don't and would like me to change my post accordingly, please mention that in a comment or contact me elsewhere about it. (:
So, with that said, let's get into MenuHax.
To explain why this is the case properly, I must try to explain what you are going through each time you boot your 3DS with MenuHax into a Custom Firmware or Gateway, or whatever else.
When you power on your 3DS, it starts all the hardware up, and kicks you into the official SysNAND home menu. When the home menu loads, the code for MenuHax runs, and if it’s in the correct state according to your config, it’ll open whatever you tell it to. If that happens to be a custom firmware, then it’ll have to get access to Kernal9 using some sort of Exploit, for most people, that means Brahma. After, it will patch some stuff on the fly, and then boot the home menu again, but with NAND redirected to your EmuNAND. In most cases this is how it works, this is even the case for the Gateway Flashcart in fact, just with some additional menus, patches and DRM. One big problem with this is; because it requires getting into the Home Menu to boot, playing GBA and DSiware games requires you install them to your SysNAND and patch your SysNAND's TWL and AGB firmwares, as we have no head into the system when it reboots for those firmware modes.
The problem is, exploits, especially ones that use ROP to work, require a relatively consistent memory environment to work consistently, and that is something the 3DS lacks. The 3DS doesn’t clear its RAM when you power it off, so anytime it must reboot, any junk from the last power down remains in memory. Now, for stable access to the system, this isn’t a problem- but for exploits like MenuHax, and those Kernal9 exploits which often abuse a flaw that requires precise timing to execute, this is relatively bad.
It can cause boot failure and in addition, it’s also not very fast or efficient due to all the steps it has to go through to even start up to begin with.
Enter Arm9LoaderHax.
Arm9LoaderHax works by corrupting a specific section of the Firm0/1 that when it’s decrypted, it turns into specific garbage that the 3DS then executes, and that, in the case of the public implementations at least, means *usually initiating the screen and then booting a specially made payload from the SD card, with all this happening before the 3DS even initiates the Arm11 part of the system, essentially, a split second after you press the power button, you have full access to to Kernal9, with no need to rely on any exploits at all.
This means we don’t ever boot into Official SysNAND Home Menu at all anymore. Instead, we install a payload on the SD card for whatever Custom Firmware we want and let that boot up instead, and since you already have both the ability to run unsigned code and access to the Kernal9, there’s no need for anything like Brahma and MenuHax anymore.
Luma3DS CFW is often used with this, because it allows you to chain load other Arm9 Payloads by holding specific buttons on startup- and it has a ton of good CFW features that are always working from the get-go without the need for much configuration, one of them being that it protects the Firm0 and Firm1 partitions of the SysNAND from Nintendo’s Updater, thereby protecting your Arm9LoaderHax installation, and making this hack completely self-sustaining, and in addition, making the need for EmuNAND essentially vanish, as Nintendo’s Updates are no longer any threat to you.
And in the event someone DOES brick their SysNAND in some way; Because we have access to Arm9 at boot, if someone say- broke their home menu in some way, they could have Luma3DS run Decrypt9 at boot and restore a SysNAND backup from before they broke something, which means fairly good brick protection. (Keep in mind, there’s nothing stopping you from using an EmuNAND if you wanted to, it’s just no longer needed.)
Because we no longer need EmuNAND and we get access to the system each and every time it boots without the need to get into the Home Menu first, we can patch those pesky GBA and DSiware mode firmwares on the fly and no longer need to double install games or patch firmware manually. Fixing one of the unfixable problems with the aforementioned MenuHax + CFW setup.
So, let’s review.
MenuHax + CFW:
Arm9LoaderHax + CFW
In closing, Arm9LoaderHax is an objectively better entry point for anyone. Even people that just want to play their games, it’s consistent for everyone and only requires a bit more overhead to set up, but the payoff is a stable, close to stock, seamless experience with your hacked 3DS, that not even Nintendo has any power to put a stop to.
Thanks for reading and I hope you learned something.
Try to keep any comments civil please. Feel free to correct me if I've misunderstood something and if you're actually more knowledgeable than me, I'll fix it, but I think I have a pretty good grasp on this stuff.
So, with that said, let's get into MenuHax.
To explain why this is the case properly, I must try to explain what you are going through each time you boot your 3DS with MenuHax into a Custom Firmware or Gateway, or whatever else.
When you power on your 3DS, it starts all the hardware up, and kicks you into the official SysNAND home menu. When the home menu loads, the code for MenuHax runs, and if it’s in the correct state according to your config, it’ll open whatever you tell it to. If that happens to be a custom firmware, then it’ll have to get access to Kernal9 using some sort of Exploit, for most people, that means Brahma. After, it will patch some stuff on the fly, and then boot the home menu again, but with NAND redirected to your EmuNAND. In most cases this is how it works, this is even the case for the Gateway Flashcart in fact, just with some additional menus, patches and DRM. One big problem with this is; because it requires getting into the Home Menu to boot, playing GBA and DSiware games requires you install them to your SysNAND and patch your SysNAND's TWL and AGB firmwares, as we have no head into the system when it reboots for those firmware modes.
The problem is, exploits, especially ones that use ROP to work, require a relatively consistent memory environment to work consistently, and that is something the 3DS lacks. The 3DS doesn’t clear its RAM when you power it off, so anytime it must reboot, any junk from the last power down remains in memory. Now, for stable access to the system, this isn’t a problem- but for exploits like MenuHax, and those Kernal9 exploits which often abuse a flaw that requires precise timing to execute, this is relatively bad.
It can cause boot failure and in addition, it’s also not very fast or efficient due to all the steps it has to go through to even start up to begin with.
Enter Arm9LoaderHax.
Arm9LoaderHax works by corrupting a specific section of the Firm0/1 that when it’s decrypted, it turns into specific garbage that the 3DS then executes, and that, in the case of the public implementations at least, means *usually initiating the screen and then booting a specially made payload from the SD card, with all this happening before the 3DS even initiates the Arm11 part of the system, essentially, a split second after you press the power button, you have full access to to Kernal9, with no need to rely on any exploits at all.
This means we don’t ever boot into Official SysNAND Home Menu at all anymore. Instead, we install a payload on the SD card for whatever Custom Firmware we want and let that boot up instead, and since you already have both the ability to run unsigned code and access to the Kernal9, there’s no need for anything like Brahma and MenuHax anymore.
Luma3DS CFW is often used with this, because it allows you to chain load other Arm9 Payloads by holding specific buttons on startup- and it has a ton of good CFW features that are always working from the get-go without the need for much configuration, one of them being that it protects the Firm0 and Firm1 partitions of the SysNAND from Nintendo’s Updater, thereby protecting your Arm9LoaderHax installation, and making this hack completely self-sustaining, and in addition, making the need for EmuNAND essentially vanish, as Nintendo’s Updates are no longer any threat to you.
And in the event someone DOES brick their SysNAND in some way; Because we have access to Arm9 at boot, if someone say- broke their home menu in some way, they could have Luma3DS run Decrypt9 at boot and restore a SysNAND backup from before they broke something, which means fairly good brick protection. (Keep in mind, there’s nothing stopping you from using an EmuNAND if you wanted to, it’s just no longer needed.)
Because we no longer need EmuNAND and we get access to the system each and every time it boots without the need to get into the Home Menu first, we can patch those pesky GBA and DSiware mode firmwares on the fly and no longer need to double install games or patch firmware manually. Fixing one of the unfixable problems with the aforementioned MenuHax + CFW setup.
So, let’s review.
MenuHax + CFW:
- Requires booting into the official SysNAND Home Menu causing issues with DS and GBA mode reboots
- Requires the use of an additional exploit to gain access to Kernal9, which is needed for CFW.
- Requires an EmuNAND for proper brick protection (bringing additional issues to getting into DSiware and GBA games)
- Is potentially unstable do to inconsistencies in the contents of ram at boot time
- Because of the above 4 things I said, it takes significantly longer to go from powering on the 3DS to your desired Home Menu.
Arm9LoaderHax + CFW
- Has instant Unsigned Code Execution at boot up
- Has instant Kernal9 access at boot up
- Runs before any Arm11 Code does and is typically used with CFW that protects the part of storage A9LH is installed to, making breaking it incredibly incredibly difficult
- Negates the Need for EmuNAND and getting into the SysNAND Home Menu to work, ridding ourselves of issues related to DS, DSiware and GBA games.
- Because of the above 4 things, it takes about a second or two to go from powering on the 3DS to your desired Home Menu, almost identical to a stock system to the untrained eye.
In closing, Arm9LoaderHax is an objectively better entry point for anyone. Even people that just want to play their games, it’s consistent for everyone and only requires a bit more overhead to set up, but the payoff is a stable, close to stock, seamless experience with your hacked 3DS, that not even Nintendo has any power to put a stop to.
Thanks for reading and I hope you learned something.
Try to keep any comments civil please. Feel free to correct me if I've misunderstood something and if you're actually more knowledgeable than me, I'll fix it, but I think I have a pretty good grasp on this stuff.
