Nintendo 3DS Architecture

The history of hacking this console is a long and interesting sequence of events. At first, interests focused on cracking game card readers (in an attempt to replicate the success of the Nintendo DS) and then shifted towards more sophisticated approaches, only involving the operating system.

Main targets

First things first, let's start by describing the two main targets of this system:

• The Game/CTR card reader: This is where physical games are loaded. Historically, the Nintendo DS implemented a weak security mechanism that was eventually cracked and subsequently led to an influx of Flashcards.
• The Operating System: This area is responsible for verifying the authenticity and integrity of every single program before execution (aside from the Boot ROM). Disabling said mechanisms would grant the execution of Homebrew (unauthorised applications) without any restrictions, in theory.

They may look like two independent fronts (similar to the Xbox 360 and Wii U), but in the case of this console, both are intertwined. You'll see it in a bit.

The card reader front

The card reader is the interface between the CPUs and the Gamecards' memory chip. Its only job is to simplify the communication with the use of commands.

Inside the ROM/Flash of CTR Carts, the system will find a block of data in a secured format called NCSD, this will be handled by the operating system, who will be in charge of authenticating, validating and decrypting it.

In conclusion, it seems the OS is solely responsible for the communication with the card reader, so let's move on to the next front.

The Operating System front

Before we continue, if you're not familiar with symmetric and asymmetric encryption systems, I recommend reading previous articles of this series. They will also explain why systems like this rely so much on asymmetric encryption systems (such as RSA and ECDSA).

Dedicated hardware

You'd be right if you suspected that the ARM11 lacks the powerhouse to protect the whole system. Nintendo knew that too, so they took extra care and bundled extra components to compensate:

• The ARM11 cores implement the XN flag and the ARM9 bundles a Memory Protection Unit (MPU), meaning the CPUs won't execute code from any location in memory just because the current program tells it to.
• As said before, the ARM9 acts as a dedicated processor to handle all security-related tasks while the ARM11 MPCore executes the game. Additionally, the ARM9 is exclusively wired to a few hidden cryptographic accelerators:
  • An AES engine that performs AES-128 encryption/decryption without consuming (and exposing) CPU resources. This was inherited from the Nintendo DSi, but can now store up to 64 keys and can operate in numerous block cipher modes, including CTR, CCM, CBC and ECB . Each key slot also features its own key-scrambler, meaning that two arbitrary keys can be used to generate the final AES key. Moreover, the key-scrambler won't allow anyone to read the generated key, only to treat it as a blackbox to encrypt/decrypt data.
  • An RSA engine. By contrast, this performs RSA encryption/decryption using a given RSA public key. This time, it only contains four key slots and there's no key-scrambler . However, it's still a write-only space, meaning no one will be able to read the keys stored there. You'll soon see that this system is filled with RSA-2048 and RSA-4096 signatures, which explains why this component is as crucial as the AES engine.
  • A Pseudo Random Number Generator (PRNG): These are registers that return a different value every time they're read from.
• OTP (one-time programmable) memory that stores console-unique keys, information about the console and CTCert (an ECDSA private key to authenticate with Nintendo's servers). To complicate things further, these keys will be encrypted with an AES-CBC key found in Boot9. Finally, this region includes a flag to disable its access once it's not needed anymore.
• Last but not least, the eMMC memory contains a register called CID (Card Identification) and stores unique information about the eMMC's manufacturing, which will be fed to the AES' key-scrambler for further obfuscation.

To top it off, everything is sealed in an SoC, including the two boot ROMs (Boot9 and Boot11). These are unencrypted, but since they're inaccessible, they don't represent a concern.

Chain of trust

This should come as no surprise considering we've already introduced RSA, AES and the boot ROM as part of the security system. To give you an overview of the Nintendo 3DS' change of trust:

1. ARM9's boot ROM (Boot9) bundles the public key for decrypting and validating the contents of the NAND. The AES engine will be initialised with the keys stored in Boot9. With this, the contents of OTP memory will be accessed.
2. The contents of eMMC are decrypted using Boot9's AES keys combined with the eMMC CID.
3. NAND and CTR cards are formatted using the NCSD format . NCSD stores a header and a collection of up to eight partitions. The NCSD header contains a signature using RSA-2048 and SHA-256, which is quite strong. To decrypt this signature, the system finds its public RSA key in the boot ROM or ITCM memory (the latter was previously decrypted and copied from OTP). The choice depends on where the NCSD block came from (NAND or CTR card).
4. Once the NCSD block is validated, the system accesses each partition. These are structured using the NCCH (Nintendo Content Container Header) format. Independently whether the data was pulled from NAND, the CTR card or the SD card, the NCCH block also contains an RSA-2048 + SHA-256 signature , and its payload is encrypted with AES-128 CTR.
5. Furthermore, installed software is catalogued in the form of Titles (similar to the Wii System). In this case, all titles are signed with either RSA-2048, RSA-4096 or ECDSA; plus SHA256 . The public keys are stored in NATIVE_FIRM.
   • It does surprise me that some signatures are in the form of ECDSA, considering there's no hardware accelerator installed for it.
6. Once the payload is verified and decrypted, the system will find either an executable, library or asset (i.e. manual, icon or banner) that the ARM11 can read.

Please note, this explanation focuses on the main 3DS firmware (NATIVE_FIRM). Yet, TWL_FIRM and AGB_FIRM will also have their share of cryptography implemented.

As time passed by and hackers got the handle on how this console was protected, Nintendo shuffled the chain of trust further to deter the decryption of NCCH data. In some ways, it achieved its purpose, but in others, Nintendo ended up revealing too much. You'll see it in the following sections.

Operating system functions

Once NATIVE_FIRM is up and running, in addition to the aforementioned chain of trust, the following security mechanisms are present:

• User programs only access hardware functions through system calls, authorised at Kernel11's discretion. Depending on the hardware, it will also involve Kernel9.
• From an architecture perspective, ARM11 user programs are completely unaware of the ARM9 and its neighbouring components.
• User applications are sandboxed, meaning they can't access each other's space.
• Last but not least, with the increase in online services, users will require a legitimate game card and an updated firmware to access the new functions. This will deter users who may consider keeping their console on a vulnerable firmware.
• Software downloaded from the eShop also comes with its quirks. In this scenario, the license of a Title is encoded in the form of a Ticket which, again, is signed with RSA-2048 and SHA-256 . Tickets are either linked to a single console ID and the eShop's user account; or made global for any console. Furthermore, Nintendo uses additional RSA certificates in the downloaded Title's metadata to further enlarge the chain of trust .

Flaws

Even though the Nintendo 3DS enjoyed modern protection techniques, such as asymmetric cryptography and lots of hardware at its disposal, there were some fundamental flaws in its implementation. Take a look at the following findings discovered by the hacking community:

• While the XN flag in the ARM11 works without problems, Kernel11 sets up the page table in AXI WRAM (where Kernel11 resides) in a way that it grants Read, Write and Execute permissions to the whole memory block , rendering the capabilities of XN a bit useless (at least for protecting Kernel11).
• Before system version 3.0.0, OTP memory was never hidden , meaning that with the help of any exploit, the OTP keys could be extracted without problem.
• There's no separation between Process9 and Kernel9, as Kernel9 provides a system call that allows Process9 to perform any function with Kernel9 privileges .
• There's no ASLR (Address space layout randomization) implemented , enabling Return-oriented programming (ROP) for exploitation purposes.
• Similarly, there's no protection against system downgrading.
• Once again, this system also comes with a Web browser based on Webkit, which is under constant attack (especially if the fork is old).

This will not only pave the way to the first exploitation attempts, but will also act as a constraint for Nintendo when they try to patch their system.

Defeat

The history of the Nintendo 3DS and Homebrew is a successful one. Tons of video tutorials can attest to that. Yet, the passage exposes very clever discoveries, which evolved from initially requiring proprietary and expensive equipment to just a couple of clicks on your computer.

The DS flashcard era (2011-2013)

Where to begin? Well, from where the Nintendo DSi left it off: Flashcards.

After the release of the Nintendo DSi in 2008, Nintendo incorporated a new element to fight against Flashcards: A whitelist file listing every single licensed card and thereby blocking the 'unauthorised ones' . By no means Flashcard manufacturers ceased their production, they just shipped new variants of their old Flashcards that allowed the user to re-program the cartridge header, enabling the card to identify as a different authorised game whilst Nintendo kept amending the list (through software updates).

This method encompassed the Nintendo 3DS as well, following the same process as the Nintendo DSi. On no account they would get access to the exclusive 3DS hardware, yet this is how Homebrew started in this console.

The 3DS flashcard era (2013-2016)

There wasn't much progress during the first two years of this console (a big achievement for Nintendo!). Yet, things took a turn in August 2013...

The first real 3DS Flashcard

The Gateway3DS package .

Ignoring teasers of '3DS Flashcards' that never appeared . Gateway3DS can be considered the first 3DS Flashcard to reach the stores. The instructions were not as simple as DS counterparts, however. You can sense this by looking at the contents of the box:

• A whitelisted DS Flashcard (known as Blue Gateway) whose only purpose is to run a Nintendo DS ROM crafted by Gateway. As part of the 'installation' process, users were first required to run this 'game' and follow the instructions.
• A Launcher.dat to be placed in the 3DS' SD card.
• A 3DS Flashcard (known as Red Gateway) where the 3DS game is loaded from. Like any other Flashcard, it also features a microSD slot where the 3DS game is stored. The big difference, however, is that the 3DS game image is flashed into the microSD card, meaning that only one 3DS game can be stored at a time.
  • This makes sense, as RSA signatures can't be faked (at least, that's computationally unfeasible). Yet, replicating an exact clone of the game (NCSD block) worked. Forget about Homebrew, for now.

After completing the installation process, users would have to follow these instructions to run any game:

1. Insert the Red Gateway card. Nothing will appear, yet.
2. Open the 3DS settings app and navigate to the DS profile editor screen.
3. For some reason, the 3DS will restart and the flashed 3DS game will show up.
4. After finishing playing a game, returning to the HOME Menu will create a savefile in the 3DS' SD card.

And just like that, users were now able to download 3DS ROMs from the net and run them on their consoles... but how was all of this possible? How did anyone manage to extract decrypted games? What exploits did Gateway3DS employ (or even discover)?

Truth is, there's a lot of hidden functionality within this product. Let's analyse it step by step.

Inside the Gateway3DS

The DS Message editor found on the 3DS settings app. The character limit is solely enforced by the graphical interface.

Sometime in 2012, hacker 'ichfly' discovered interesting behaviour in the Nintendo DS' old profile editor, found on both NATIVE_FIRM and TWL_FIRM. In one of its text fields, you can enter a 'Message' value, which will then be displayed as a greeting on PictoChat rooms . The 3DS' settings app won't allow you to enter more characters than allowed. Yet, nothing prevents a Nintendo DS game from doing so. When that happens, opening the 3DS' System Settings app (called MSET) will crash, and what makes it interesting is that this is caused by stack overflow . Does this remind you of a certain horse name?

Now, the mysterious Launcher.dat by Gateway is a configuration file that the Settings app normally reads. What happened is that Gateway crafted their own Launcher.dat to embed data used for the next stages of their exploit. Curiously enough, Launcher.dat is stored in NAND (not in the SD), so the initial exploit chain also alters where the Settings app loads this from.

If you combine this with a Process9/Kernel9 exploit, you get full execution privileges on this console and can start fiddling with system services. Some hardware like OTP and the boot ROMs will still be out of reach. Yet, this is a significant milestone.

So far so good? Let's now connect this information with Gateway's package:

• The DS/Blue flashcard is just an entry point to install the corrupted DS profile (which will trigger the MSET exploit).
• The 3DS/Red flashcard houses a ProASIC3 FPGA programmed with a firmware (distributed by Gateway). The FPGA and the microSD card are combined to replicate a retail game.
• Launcher.dat is the payload of the MSET exploit. It bundles a Kernel exploit and a collection of system patches. In other words, a Custom Firmware (CFW). A console running Gateway's CFW can extract games or load a 3DS game using the red flashcard. Surprisingly, Gateway also crafted their CFW so it requires the red flashcard inserted to work (a DRM mechanism in a Flashcard, have the tables turned?).

Subsequent anecdotes

All seemed jolly for Gateway until November 2013, when a stream of clones of their card landed. 'R4i Gold 3DS Deluxe' came for some healthy competition, albeit by using some of Gateway's firmware code. In retaliation, Gateway3DS took drastic measures: Subsequent firmware updates of Gateway3DS corrupted the 3DS NAND if a clone was detected. The irony!

In October 2013, hacker 'Smealum' published a video showing his own MSET-based implementation that instead booted a copy of NATIVE_FIRM stored in the 3DS' SD . This meant that consoles stuck on system 4.5.0 could boot newer system versions without losing the ability to run exploits. Smealum called this function redNAND (from 'redirected NAND') and, while it wasn't publicly released, Gateway later incorporated this functionality (now referred to as emuNAND) with their CFW released in December 2013 . This became a strong selling point for Gateway3DS.

It's not known what Process9/Kernel9 exploit Gateway employed. Yet, in December 2013, Fierce_Waffle, Xerpi and Megazig reversed engineered and open-sourced Gateway's payload in the form of a tool called '3DS Toolkit' .

In the following years, a second generation of 3DS flashcards will appear in the market. Examples include Stargate, Sky3DS and dozens of clones. This time, they didn't rely on an operating system exploit to work and could load multiple games from their microSD. However, their utility will be entirely based on replicating retail 3DS games (including their signatures), in other words, for solely piracy purposes.

Nintendo acts fast

Having an updatable system software meant Nintendo didn't have to stand there and watch how its system got cracked:

• In March 2013, system update 5.0.0-11 updated the settings app, provisionally fixing the MSET exploit . If you check the timeline, this was before Gateway3DS shipped their card! Hence, it was a prerequisite for users to stay on older versions.
  • It won't be until 2015 when the Gateway team released a notable firmware update. From then on, the flashcard relied on a new Web Browser exploit (called spider exploit, discovered by MathewE) as the entry point. This method lasted until the end of Gateway3DS' lifespan.
• In December 2013, system update 7.0.0-13 fixed the kernel exploits used in combination with MSET and, most importantly, added the RSA module into the chain of trust to decrypt NCCH blocks (where the game data is found) . RSA keys are cleared once Kernel9 finishes loading, meaning existing exploits won't be able to decrypt games that adopted the new 7.0.0 encryption system (unless a vulnerability is used before Kernel9 boots).
• As Gateway3DS' Launcher.dat file contained copyrighted code by Nintendo, the latter company sent Cease & Desist letters to many forums, including GBATemp, which in turn blocked the distribution of those files.

As always, this marked the start of another cat-and-mouse game. Though, to make a long story short, system update 9.3.0 (released in December 2014) finally put an end to Gateway3DS by patching their private Kernel exploit . Since then, Gateway3DS' firmware updates only improved emuNAND support with the latest system versions (for those who didn't update past the breaking update). In 2016, Gateway's last update was released. Meanwhile, Sky3DS enjoyed support until system software 11.0 (released in May 2016) , when Nintendo blacklisted it for good.

I think now it's fair to say that the 3DS flashcard market ended up being too turbulent and unreliable for the average user, compare this to the 'plug & play' experience Nintendo DS flashcard offered. Finally some good news for Nintendo, so far.

The dawn of homebrew (2014)

2014 saw an emergence of homebrew-focused solutions in a circle populated by piracy-oriented developments . Hacking a 3DS still required an old system version, a Gateway3DS card and emuNAND - but that would slowly shift once alternative tools gained traction.

Plutoo, Derrek and Smealum presenting their findings at the 32nd Chaos Communication Congress (2015) , the following paragraphs will explain most of them.

Open-source SDKs

Initial Homebrew appeared in the form of Laucher.dat files, these were produced with the help of devkitARM (a general-purpose toolchain for ARM-based CPUs) and a set of scripts. Fierce Waffle provided 'ROP Loader', a toolkit that included a DS program to install the MSET exploit; and a Launcher.dat that triggered a Kernel11 exploit. It's worth pointing out that there wasn't any tool available, yet, that helped access the 3DS' exclusive hardware.

At the start of 2014, Smealum, with the collaboration of yellows8, ichfly, WinterMute, fincs, mtheall and plutoo, released ctrulib, an open-source C library to facilitate Homebrew development . This is now known as libctru and maintained by the devkitPro group, who have incorporated it into their toolchain.

A year later, neobrain released nihstro , a PICA200 shader assembler a disassembler, making the job of programming the PICA200 a bit more enjoyable.

To run Homebrew, users had the option to flash a homebrew binary into a microSD, and then use the Gateway3DS to boot it (as their CFW already disabled signature checks) .

Ninjhax chain

The Homebrew Launcher, inspired by the iconic Wii counterpart. Its arrival marked the sophistication of 3DS Homebrew.

The poisoned updates of Gateway left a bitter mark on their users. The time had come to look for nonproprietary alternatives.

Thankfully, people were working on this. During the second half of 2014, a new milestone awaited for the Homebrew community: Smealum published Ninjhax, a package composed of the following components :

1. A crafted QR code to be scanned by 'Cubic Ninja', a game that allows to share user-designed levels using QR codes. This served as a new entry point exploit.
2. GSPWN: A userland vulnerability where the GPU's DMA is used to write over the HOME Menu's heap. Furthermore, the combination with ROP leads to privilege escalation. This resulted in the ability to create & kill processes, SD card access, decrypt & dump titles and override executable data.
   • Other GPUs were also known for intruding into the system's RAM.
3. Homebrew launcher: A new service running under the HOME Menu process thanks to GSPWN. It provides a graphical user interface to load unsigned Homebrew apps (using a new portable .3dsx format) and take over processes. The launcher loads homebrew by opening an official application with enough privileges and then hijacks it with GSPWN, replaces the code with Homebrew code and finally executes it.
   • With its ability to alter user data, the Homebrew launcher can also be used to install alternative entry points as they're discovered (i.e. OotHax, Ironhax and so forth). Thus, reducing its dependency on Cubic Ninja. A notable aftermarket exploit was MenuHax, which exploited a vulnerability in the HOME Menu theme engine and was triggered at boot, making it a permanent solution to launch a payload.
   • If you are curious, the Wii U also experienced similar methodologies as early attempts to run Homebrew.

Notice how Gateway3DS is, for once, out of the equation. Be as it may, the Homebrew Launcher was still under the scope of userland (meaning homebrew apps could only access 64 MB of RAM and had no access to the audio DSP ).

Gaining Kernel11 access

Turns out that before the publication of Ninjhax, in February 2014, yellows8 made a very important discovery: An exploit leading to Kernel11 privileges.

Kernel11 keeps track of the unused memory pages in FCRAM using a structure called memchunk header. This data is stored as a linked list, where each header contains the address of the previous and next header. Well, it so happens memchunk headers are stored in FCRAM, which may be overwritten thanks to other exploits like GSPWN. Consequently, memchunk headers can be modified to grant userland access to AXI WRAM. In doing so, the attacker can eventually modify the Kernel11's page table to grant all FCRAM access to user-space, leading to arbitrary control of Kernel11. This discovery was called memchunkhax.

Nevertheless, Nintendo patched it in December 2014 . However, another hacker by the name of derrek found a race condition where the 'next' pointer of a memchunk header may be replaced with the location of a crafted one. So, when Kernel11 tries to access the crafted memchunk header, it will end up executing arbitrary code with Kernel11 privileges. Ipso facto, memchunkhax2 came into existence.

Thanks to the new privilege escalation, Homebrew software gained complete control of the system up to the ARM9 area... but why stop there?

Most-wanted tools

Considering the availability of Gateway3DS' emuNAND, Ninjhax, CTRLib and the new Kernel exploits, the flood of new software was too great to ignore. To mention a few:

• CtrBootManager by cpasjuste: An extra stage in HomeMenuHax's chain that acts as a boot manager, enabling the selection of various payloads .
  • Shortly after, a new implementation with extended functionality emerged: BootCtr by m45t3r .
• RxTools by Roxas75: A Swiss knife for Gateway3DS users . This was offered as a replacement for Gateway3DS' binaries. Among many things, it includes a CFW called RXMode. This alternative and open-source solution disables signature checks on 3DS binaries, provides emuNAND and removes TWL_FIRM's whitelist checks, to mention a few.
  • Other CFWs will soon make their appearance, like CakesFW, ReiNand and Pasta CFW . These serve different purposes and include their own set of modifications.
• Custom HomeMenu Manager (CHMM) by Rinnegatamante: Allows to install HOME Menu themes from the SD card .
• AGB_FIRM Signature patcher by Riku. Loads arbitrary Game Boy Advance ROMs into AGB_FIRM , finally expanding the abandoned catalogue of Nintendo Ambassador games.
• Ftpbrony by mtheall (later known as ftpd): A simple FTP server .
• DevMenu: Not exactly a homebrew app, but a stolen Nintendo-authored app from development units, enabling users to install app packages (in the form of 'CIA' files) into the system, just like the eShop did behind the scenes.
  • Months later, BigBlueMenu was used instead, which also came from Nintendo's development kit.
  • It wasn't until a real open-source solution was brought forward some months after. FBI by Steveice10 became the standard dilemma-free tool for installing CIA files (notice the pun in the names) .

New console, permanent mods (2015)

While homebrew developers were busy fiddling with their system, Nintendo released a new product to the surprise of everyone: The New 3DS.

Apart from the extra hardware (already mentioned throughout this article), a new stage was added to the boot process: arm9loader. With this, Nintendo enhanced their chain of trust by adding new keys, which must be decrypted with the help of a hash of OTP memory (therefore, using console-unique values) . However, arm9loader and the new keys are still stored in NAND, meaning that the contents may be overwritten. This led to one of the most disrupting vulnerabilities of 2015, involving Plutoo, Yellows8 and Delebile.

arm9loaderhax

The first implementation of arm9loader was flawed: the decryption key for the ARM9 system was never removed from the AES engine. So, with the help of additional exploitation, one could reconstruct part of the encryption keys . Consequently, Nintendo quickly tried again with arm9loader v1.1 (found on system update 9.6.0). As luck would have it, this led to a more powerful exploit: Plutoo discovered that the key used to decrypt the ARM9 system was never verified. Hence, arm9Loader will boot NATIVE_FIRM even if the decrypted data is wrong (a.k.a. garbage). Plus, if Firm0 (the first copy of NATIVE_FIRM) fails to boot, Boot9 will try to load Firm1 while the remains of Firm0 stay in the ARM9's RAM.

All in all, if:

• NAND is modified (somehow) so the encrypted Firm0 contains extra crafted code at the end.
• The ARM9 OS key is mangled in a way that the decrypted Firm1 will contain a jump instruction to Firm0's crafted code.

... you got yourself arm9loaderhax, a permanent exploit that provides arbitrary code execution with Kernel9 privileges at boot time!

Since Kernel9 access was now possible, albeit through difficult means, work was put into simplifying the process (i.e. developing an automated installer).

The effects of arm9loaderhax

New discoveries meant new developments. Over the following months, more advanced tools will become part of the 'must have' list of every homebrew user.

To start with, a new CFW to-rule-them-all shipped: Luma3DS . Among many features, Luma3DS provides:

• The removal of signature and region checks.
• A layered filesystem to redirect file operations to the SD card (enabling game modifications).
• Rosalina Menu, an in-game menu overlay where many utilities can be accessed without closing any application.

Initially, Luma3DS was bootstrapped with BootCtr, but that changed once arm9loaderhax became the de-facto hack for any 3DS. Thus, the arm9loaderhax + Luma3DS combination became part of any hacking tutorial.

Along it, other software appeared:

• Godmode9 by d0k3: A next-generation Swiss knife that takes advantage of the permissions granted by ARM9 exploits , enabling the user to read and modify every corner of the console. It can be loaded by arm9loaderhax, Luma3DS or any other compatible hack. Now, the more powerful the exploit, the more functionality is provided. Examples of functionality include a file browser and NAND backup. Plus it's further extended with scripts.
• Anemone3DS by astronautlevel: With a multitude of features, it soon became the app for managing HOME Menu themes .
• nds-bootstrap by Rocket Robz: As the name indicates, it loads Nintendo DS software (ROMs and homebrew) from the SD card . While it's designed to support the three portable consoles (the Nintendo 3DS, DSi and DS, the latter requiring a flashcard), loading it from the 3DS will kickstart TWL_FIRM, meaning there's no emulation at all. It's most commonly used through 'TWLMenu' (now 'TWiLight Menu++'), the front-end of nds-bootstrap.

It's worth mentioning that, at the time of this writing, these are the most popular utilities to install on a hacked 3DS.

The Golden Age (2016-2017)

While a universal and powerful solution, installing arm9loaderhax was still considered a complicated and dangerous activity. Not only does this require dumping the console's OTP memory beforehand (using other exploits), but neglecting any step could potentially turn a working Nintendo 3DS into a rock.

But fear not as new developments were in the works (a mighty effort considering Nintendo was still battling to protect their console).

naehrwert, nedwill and derrek presenting a new set of findings at the 33nd Chaos Communication Congress (December 2016) .

At the 33C3 conference, derrek unveiled two major discoveries , which led to subsequent milestones.

Extracting Boot9

For some reason, the contents of ARM9's RAM are not cleared upon reset. Thus, Derrek discovered that, with the use of external hardware, he could override the exception vectors from ARM9's RAM (previously copied from Boot9) with arbitrary code. Then, reset the system, glitch it at very precise timing (also using external hardware) to trigger an exception and hope for the ARM9 to have executed the new code. This will have included something like 'Copy all contents of Boot9 to X location in RAM'.

Lo and behold, this did work. With this, Derrek and others managed to analyse the contents of the Boot9 ROM, allowing new vulnerabilities to be found.

Sighax

One vulnerability from Boot9 was Sighax , a flaw in Boot9's RSA-2048 signature verification. RSA signatures of type 'PKCS #1 v1.5' (adopted by this system) contain an area called padding to prevent being reversed. Additionally, they store an SHA-256 hash encoded with a model called 'ASN.1', this guarantees the authenticity of the data being decrypted.

Now, the respective parser found in Boot9 lacks several protections, including bounds checking. In the end, this allowed Derrek to produce a crafted RSA signature (through brute-forcing) that will always succeed on any data. In doing so, the entirety of the chain of trust was nullified.

For the curious, I recommend reading a comprehensive post in GBATemp describing the theory more calmly .

With this, one would now be allowed to craft a firmware for the ARM9 core, sign it with a crafted RSA signature, install it on NAND and Boot9 will 'just run it'. The question now is, how can the average user do this using an unmodified console?

Boot9strap

The year is 2017. Most know about the existence of Sighax but only a handful can apply it, all because the new method requires a crafted RSA signature and writing access to the NAND, none of which is easy to come by (and let's not forget Nintendo was still clamping down hard on userland exploits through system updates). Luckily, Sighax was in the process of being democratised.

Even though Derrek's announcement didn't include a suitable RSA signature or a copy of Boot9 (due to copyright reasons, I'm guessing), that didn't stop hackers SciresM and Myria from finding alternative resources that would enable them to craft an RSA signature.

In summary, they discovered that system versions before 1.0.0 shared similar flaws to those previously exposed with Sighax and, thanks to this, they were able to begin brute-forcing RSA signatures. The result was a success, a match was eventually found with the help of plenty of Nvidia GPUs .

Now that they could craft an alternative firmware that Boot9 would accept, they needed to find a way to redirect Boot9 to their payload. The challenge was to redirect execution before Boot9 hides its Boot ROM. To tackle this, the duo found a route through the ARM9's exception handlers. The ARM9 can't override these, but the NDMA can - and the CPU can command the NDMA to do so.

All in all, the team were able to use the NDMA to fill the exception handlers with a jump to arbitrary code, and then instruct the ARM9 to copy to NULL, resulting in an exception that would execute the payload with unrestricted access. In the end, this was packaged in a solution called boot9strap and served as an alternative bootloader that could either load a payload from the SD card or continue to boot normally. Consequently, Godmode9 added new options to backup OTP and the Boot ROMs.

And so, boot9strap quickly displaced arm9loaderhax as the de facto solution for loading arbitrary code with maximum privileges.

Ntrboot

Some DS Flashcards sold after the discovery of ntrboot came with a switch to enable a '3DS mode' (see the top corner of the photo), this enables trigger ntrboot.

At this point, there was only one question left: How could users install boot9strap?

Well, the team didn't stop there. By taking a look at their recent Boot ROM dumps, they found an interesting routine: During boot, Boot9 will query if a specific key combination is pressed and the lid is closed. If so, Boot9 will redirect execution to the inserted Nintendo DS card (with full privileges).

Thus, ntrboot came to fruition: Flash a sighax-signed payload into a Nintendo DS flashcard, use a magnet to simulate a closed shell and press the required key combination. Instant Boot9 privileges.

If this wasn't enough, Nintendo couldn't fix any of these vulnerabilities through software updates, as they're hardwired into the Boot ROM. A possible solution would've been to ship new hardware revisions, yet, none ever appeared.

The remaining years (2018-present)

Now that the homebrew community has achieved its magnum opus, the remaining years of the Nintendo 3DS will only see the streamlining of hacking methods, all of which share the same objective: Install boot9strap.

As the methodologies used to hack a 3DS drastically evolve, sometimes too quickly for new users, community-maintained websites like 3ds.hacks.guide currently holds a reputation as the most reliable and updated set of tutorials.

By this point in time, there were many exploits in the wild: 'SoundHax', 'Safehax', 'Browserhax'... too many to mention here. For the curious, 3DBrew provides a comprehensive list .

To give you an idea of how elegant exploitation became by 2023, let me show you a common method users relied on and didn't require extra hardware. This process was called 'seedminer + BannerBomb3' and combined the following vulnerabilities, the majority of them authored by zoogie:

1. seedminer: User data installed in the 3DS' SD card is encrypted using AES-128-CTR. Its key is constructed from other keys found in a file called movable.sed (console-unique, stored in NAND). Well, it was discovered that this file can be re-constructed by using the console's Friend Code, subdirectory names in the SD card (generated by the console) and short-term brute-forcing. Once extracted, the keys allowed to tamper with DSiWare data in the SD card.
2. BannerBomb3: An exploit that overflows the stack of the Settings app while it tries to parse the banner of an installed DSiWare title . Combined with seedminer, this serves as an entry-level exploit with Kernel11 privileges.
3. Now, how to take advantage of BannerBomb3 (i.e. which payload to use) depended on the tutorial the user was following at the time. For simplicity purposes, there were two routes:

The Safe Mode route

This route consisted of exploiting SAFE_FIRM and was described in earlier tutorials:

1. unSAFE_MODE: Users can boot into Safe Mode by pressing a combination of buttons during the console's boot, the alternative firmware then enables the user to perform a system update, which is useful for repairing the console. Well, zoogie discovered that the proxy settings can be overflowed . Hence, providing userland execution within Safe Mode.
2. safehax: a port of 'firmlaunch-hax' to work under SAFE_FIRM. Nintendo originally patched it with system update 9.5.0 released in February 2015 . Yet, SAFE_FIRM is an immutable replica of the factory firmware, and thus it features old exploits NATIVE_FIRM once enjoyed.
   1. firmlaunch-hax: When the firmware is booting, the ARM9 stores the firmware's header in FCRAM for verifying and then parsing. With the help of a race condition, execution can take control of the ARM9, so the boot9strap installer can be launched. Nintendo fixed this by keeping the header in ARM9 RAM instead, although this stayed unpatched on SAFE_FIRM.

The HOME Menu route

Sometime later, a new route was proposed by new tutorials. This exploited the HOME Menu with a new Menuhax-style hack:

1. menuhax67: The screen brightness configuration value can be overflown , leading to userland control from the HOME Menu.
2. nimdsphax: An modern exploit chain combining 'ctr-httpwn', 'nimhax' and 'dsp pwn' .
   1. ctr-httpwn by yellows8: The HTTP service used for network connections can be controlled by overriding its heap memory (using the old GPU DMA exploit) .
   2. nimhax by luigoalma: Uses ctr-httpwn to escalate and take over the services that control the user file system, console configuration and application management .
   3. dsp pwn by luigoalma: Uses nimhax to take control of the DSP, which in turn uses the GPU's DMA to override the Kernel9 memory space. Thus, obtaining ARM9 privileges.

Post-2023 and conclusions

Be as it may, at the time of this writing, Nintendo hasn't quite surrendered to the cat-and-mouse game. In May 2023, system update 11.17.0 patched BannerBomb3, nullifying one of the last entry points that didn't require additional materials . This means users will now need to either obtain a legitimate 3DS game (which can then be exploited), an ntrboot-compatible DS flashcard; or wait for a WebKit exploit (there's one only left for the New 3DS browser ).