Hi, GBATemp. So a lot of you newcomers have been wondering why a 3DS on 11.4 can't be downgraded. Perhaps some of you old members are wondering this too. Well, not after today. This thread attempts to document in a very easy to understand yet very comprehensive way why this feature is not possible. A disclaimer I am not responsible for anything bad that comes out of you reading this thread. If, by gaining this knowledge, your 3DS breaks, you go insane, your hair randomly bursts into flames, or you cause thermonuclear war, and you point at me, I will laugh at you. That being said, if you appreciate this thread, or something good came out of it, leave me a like. Another disclaimer If you do not understand any particular part of this thread, I am doing something wrong. The intent here is for anybody to be able to understand the following material. If there is something you do not understand, please let me know and I will correct it. All right, enough of this stupid disclaimer crap. Let's get to the good stuff. Note: I highly recommend you check out my glossary of 3DS hacking terms before reading this. The Basics The 3DS has two main processors: an arm11 and an arm9. If you don't know what those are, it doesn't really matter. The arm11 handles everything you see: the games that run, the HOME menu, and so on. The arm9's main use is to serve as a backwards compatibility processor: it's what runs DS games. [The arm11 doesn't run games here: this is the one exception to the above rule] However, in 3DS mode, it's reused as a security processor. It handles integrity [making sure the games that run aren't pirated] filesystem calls [reading and writing to the NAND, basically the hard drive of the 3DS] and a lot of other fun things. With this in mind, let's talk about the security of the 3DS. arm11 userland: this is what the games run in. Since games won't *ever* need to read/write to the NAND, install stuff [more on that in a minute] or change security checks, it doesn't have access to them. Things like menuhax, browserhax, and game exploits [like ninjhax, oot3dhax, and so on] are what run here, and so does the Homebrew Launcher. arm11 kernel: this is what handles more sensitive stuff, but is still on the arm11. It has access to anything the arm11 can do, including game installation [with the arm9 making sure the game is valid first], but beyond that it's not really that useful for much (except abusing other functions in specific cases, see "Single System DSiWareHax"). Game exploits [userland] need another exploit in the kernel to break into this and use everything it has access to [things like game installation, so long as the arm9 says the games are OK, which they rarely are, more on that in a bit], since the kernel won't just listen to whatever userland tells it to do*. The one thing it is really useful for is breaking into the arm9: this is what's really interesting in terms of security, as mentioned earlier. We need yet another exploit to break into this, since it won't just listen to what arm11 tells it to do*. Getting an exploit for this is the real meat of 3DS hacking, since it allows for things like CFW, playing backups of your games [oh who am I kidding it means piracy], direct reading/writing to the NAND [useful for very specific things] and decryption of content. Hopefully, now you have a [very] basic idea of the 3DS security. With that in mind, let's talk downgrading. The past [<11.0] Downgrading before 11.0 was pretty simple: it meant an arm11 kernel exploit. Let's talk about what that "arm9 says it's OK" meant from earlier. Legit stuff With an arm11 kernel exploit, game installation is possible. This comes with one major catch- the game must be signed by Nintendo. What does "signed" mean? Well, signatures are little things in a file that say that someone made this, and it has their approval. On the 3DS, signatures are given by Nintendo. With an arm11 kernel exploit, we can install things that are signed by Nintendo. The not fun part here is that for games, the signatures for digital versions [games you install to the SD card, not a cartridge] are console specific. With very few exceptions [they're called "legit CIAs", we'll talk about it in a moment] this means that game installation is not possible with a mere arm11 kernel exploit. Legit CIAs Legit CIA files [the file format for 3DS games] are files that have good signatures for every console. This means that when attempting to install them with an arm11 kernel exploit, the arm9 will approve of it. Now here's the fun part that relates to downgrading- system updates are legit CIAs. Furthermore, the arm9 doesn't check to see if it's an earlier version. [Technically not true, but it's so easy to get around that it's not worth mentioning**] Therefore, to downgrade we perform an arm11 kernel exploit and install the earlier versions of the legit system updates. This reintroduces the last known arm9 exploit to the system, on version 9.2, which we can then use. The present [11.4] arm9 gets in the way Starting on 11.0, this is no longer true. When using an arm11 kernel exploit to install particular titles [system updates] arm9 checks against a list introduced in 11.0 that says what versions of system updates are valid. If the title version is older than 11.4, arm9 tells arm11 to stop installing the title. Due to the way the security system works* the arm11 will obey and stop installing. Downgrading on 11.0-11.3 So all this stuff was introduced on 11.0. But we still downgraded. Let's talk about the various holes that got us there. Hardmod & DSiWareHax These are both methods of dumping/restoring the NAND without an arm9 exploit. Usually, this isn't helpful at all- the NAND is encrypted, and decrypting it would require an arm9 exploit. However, due to the way encryption works, in a nutshell we can derive the main part of the OS [and only the main part of the OS] from an encrypted NAND dump. This was abused by decrypting the main part of the OS [dubbed NATIVE_FIRM], inserting an older version into it, then re-encrypting it and writing it back. By doing this, the version will be on 10.7, and arm9 would no longer use the list. (Note that if this still worked, we would just downgrade to 11.2 so we could use the arm9 exploit there. Technically we would downgrade both NATIVE_FIRM and SAFE_FIRM due to how the exploit works) How did single system DSiWareHax work? On versions 11.0/11.1, a single system downgrade was made possible, with the use of DSiWareHax and Mrrraou's "waithax" implementation of NedWill's "slowhax". How does it work? Usually, installing DSiWareHax would require an arm9 exploit. This is because it needs to write something (a hacked save file) to the NAND. Furthermore, the NAND would need to be decrypted. However, there is a special function, called AM_ImportTwlBackup that can read DSiWare save data, and AM_ExportTwlBackup that can write to it. This is most likely used legitimately for Pokémon Dream Radar and Poké Transporter. (It's actually not???) Because arm11 kernel can access anything the arm11 can do, we use it to write the hacked save. These were patched on 11.3. By having the "sysmodules" (every part of the OS that isn't NATIVE_FIRM) require the latest NFIRM, it's no longer possible to downgrade it. True downgrading On 11.2, an arm9 exploit called "safehax" (details here) was released. With this control, we are able to stop arm9 from using the downgrade check. And with arm9 control, there was no reason to downgrade from 11.2 to 9.2. This was patched on 11.3. However, a bypass was disclosed after 11.4 was released and patched said bypass. Details are also in the above linked thread. The future [what could be done for 11.4] Well, put simply, to downgrade on 11.4, we need an arm9 exploit. Without being able to tell arm9 to not use the list, there's no way to downgrade via normal software. And if we have an arm9 exploit, there would be no reason to downgrade to 11.2 from 11.4. Conclusion I hope this explanation helped you in your understanding of the 3DS, and the particular topic at hand, 11.4 downgrading. Again, if there's anything I missed, or you don't understand, let me know and I'll fix it. Have a nice day *It's a system of permissions. Think of it like this: there's a child, a parent, and a grandparent. The grandparent tells both the parent and the child what to do. The parent tells the child what to do, but not the grandparent, and the child tells neither of them what to do. arm9 is the grandparent, arm11 kernel is the parent, and arm11 userland is the child. The child must trick the parent into doing what he wants, who needs to then trick the grandparent into doing what he wants. **arm9 checks if the title to install is older than a title currently installed, and blocks installation if it is. However, we just uninstall the title before installing the new one. Pretty stupid on Nintendo's part.