Nintendo's 3DS was supposed to be unhackable. After the Wii and DS were both cracked wide open, Nintendo invested heavily in a layered security architecture for its next-generation handheld... and for a while, it actually held up. Then a developer pointed a 3DS camera at a QR code inside a $5 puzzle game that nobody wanted, and the whole thing started to unravel.

I followed the 3DS hacking scene intensely back then, and looking back, the journey from firmware 4.5 to boot9strap is one of the most entertaining arcs in console hacking history. It started with a bargain bin game and ended with people holding fridge magnets against their consoles to trigger a factory recovery mode that broke the boot ROM wide open. But to understand why any of that mattered, you need to know what Nintendo built in the first place.

The console shipped with two different Arm processors, each with very different jobs. The ARM11 MPCore, a dual-core chip, handled the operating system and applications. The ARM9, meanwhile, ran a single process called Process9, and its entire job was security enforcement: managing cryptographic operations, controlling filesystem access, and handling AES encryption through dedicated hardware that the ARM11 couldn't even touch directly. The two processors communicated through a narrow FIFO interface called PXI, and the ARM9 kept its own RAM entirely walled off from the ARM11. On top of that, the boot chain used RSA-2048 signature verification, and every piece of firmware was validated with SHA-256 hashes before execution.

On paper, you'd need to compromise the ARM11 to get userland access, then somehow escalate to the ARM9 kernel to do anything meaningful, and then somehow get past the boot ROM verification to make it permanent. It was layers on top of layers, but Cubic Ninja was the start of a chain reaction that did all of that.

The first vulnerability was hiding in the DS profile settings

A buffer overflow gave kernel-level code execution

The story really starts in 2012, when people had figured out how to get DS-mode flashcarts working on the 3DS, but before any 3DS-specific flashcarts came out. A security researcher named ichfly was poking around the console's backwards-compatible DS mode, and discovered what ultimately became the first major 3DS exploit. The 3DS had full hardware and software support for Nintendo DS games, which meant it also inherited the DS's profile settings, including a text field where you could enter a nickname and a personal message. These strings later appeared in DS games, and their length was limited only by what the on-screen keyboard would let you type.

Here's the thing: ichfly discovered that if you wrote an extremely long string into those fields through other means, say, using a DS-mode flashcart to directly modify the NVRAM where those settings were stored, the 3DS's System Settings app would try to load that string into a fixed-size buffer without checking the length. This shaped up to be a classic stack buffer overflow, where the name string overflows the region of memory it's assigned, overwriting regions of memory that it's not supposed to.

The string itself became a ROP (Return-Oriented Programming) chain, a sequence of existing code addresses (often referred to as "ROP gadgets") chained together to hijack the execution flow without needing to inject new code. The exploit was particularly clever in how it redirected the system: somewhere in RAM, the system stored a path string "SYS:/Launcher.dat" that pointed to internal firmware. The ROP chain modified the pointer to read "YS:/Launcher.dat" instead, which resolved to the SD card rather than internal storage. The 3DS would then dutifully load and execute whatever Launcher.dat file you'd placed on your SD card, bypassing code execution limitations.

At the time, it seemed others discovered the vulnerability as well, as different groups shared indications that they had also hacked the 3DS. However, everyone was wary of Nintendo, particularly if an exploit enabled piracy, which this one did as it was a full kernel-level takeover of the device. Still, everyone on GBAtemp and similar forums knew that the DS Profile settings were exploitable, and it was just a matter of waiting for someone to build something around it. That someone turned out to be the Gateway team.

Gateway arrived, and then it got messy

Bricked 3DSes and piracy only

Gateway 3DS started shipping in July 2013, and it was the first flashcart for the 3DS. I had deliberately stayed on firmware 4.5, and every firmware update felt like a potential lockout. The MSET exploit only worked on firmware versions up to 4.5, so updating your console was essentially locking yourself out.

As a kid, I tested the early Gateway hardware, and while it worked, it was far from elegant. You needed both a red card (the 3DS flashcart) and a blue card (a DS-mode flashcart to trigger the MSET exploit). The earliest firmware versions for the Gateway 3DS1 could only hold a single game on a microSD card, and the whole experience felt fragile. Gateway released their OMEGA update in early 2014, which added multi-ROM support and emuNAND, a way to create a separate, updatable copy of your system firmware on the SD card so you could play the newest games, on the newest firmware, without touching your vulnerable system firmware.

But Gateway had a dark side. In their OMEGA v2.0b2 beta, they implemented anti-tamper code designed to detect whether the Launcher.dat file had been modified. If the check failed, the code would use the eMMC secure command set to lock the console's internal storage after overwriting criticial sections, permanently bricking the system. The stated intent was to discourage clone carts from stealing their software, but there was a critical flaw: the detection was poorly made and triggered on legitimate Gateway users with corrupted SD cards. The community coined the nickname "Brickway," and it was deeply ironic that a company profiting off of a device that was built solely for piracy had been so aggressive in its own anti-piracy measures. Plus, it didn't help that it didn't even work properly as an anti-piracy measure in the first place.

Nintendo patched the MSET exploit in firmware 7.0, and for a lot of people who had already updated, that was it. The door was closed. The scene needed something new, something that didn't depend on hardware accessories or ancient firmware versions, and it took until late 2014 for that something to arrive.

A $5 shovelware puzzle game changed everything

A blockbuster game overnight... for the wrong reasons

On November 20, 2014, a developer named smealum publicly released ninjhax, and it opened the floodgates entirely. The exploit targeted Cubic Ninja, an unremarkable puzzle game by Ubisoft that had launched in 2011 to thoroughly mediocre reviews. It scored a 51 on Metacritic. Critics called it repetitive, shallow, and destined for the bargain bin. Nobody was buying it, and nobody was talking about it.

Smealum, to his credit, was very public about the fact that he didn't want to enable piracy, and stated on multiple occasions that his primary focus was on the creation of homebrew, which would allow people to create their own games and applications that run on the 3DS. He targeted Cubic Ninja as the game had support for scanning QR codes from other people who designed their own levels, and it meant that applications would run at the same level that Cubic Ninja did: that is, at the user-level, not the kernel-level.

Cubic Ninja's level storage format contained sections of variable length, things like object placements and tile data, that were loaded into fixed-length buffers without any length checks. If you crafted a level with oversized sections, you'd overflow the buffer and smash the stack, giving you control over the program counter. You didn't need to hack the save file or modify anything on the SD card, as you'd just point your 3DS camera at a specially crafted QR code, the game would "load" the level, and the malformed data would trigger the overflow.

From there, the exploit used a ROP chain to call gspwn, a technique that abused the GPU's DMA capabilities to write arbitrary data to memory regions the CPU couldn't normally touch. This gave smealum enough of a foothold to download a secondary payload over HTTP, which bootstrapped the Homebrew Launcher. It was the first ever public software-based homebrew exploit for the entire 3DS family. There was no flashcart required, nor any specific firmware needed, at least initially. All you needed was the game in question and a QR code.

The effect on Cubic Ninja's market was both immediate and absurd. A game that had been lying untouched in bargain bins for years suddenly became one of the hottest items overnight. Copies sold out at major retailers within hours, and online prices surged from under $5 to as high as $500. Nintendo even pulled the digital version from the Japanese eShop in a panic, though the physical cartridges were already out there and couldn't be recalled.

It was, genuinely, one of the funniest things I'd ever seen in a hacking scene at the time, and it's still one of the best, to be honest. A piece of shovelware that nobody wanted became essential hardware overnight, all because it had sloppy buffer handling in a feature nobody used.

The exploit floodgates opened

User-generated content became the key

After ninjhax proved that userland exploits in retail games were viable, the community went hunting. What followed was a frenzy as researchers found exploits in game after game, each one named with the now-familiar "-hax" suffix. To top it off, the entry point was almost always the same type of vulnerability: user-generated content features that accepted data without proper length validation. And all of them led to homebrew, not piracy.

OOT3dhax used a modified save file in The Legend of Zelda: Ocarina of Time 3D. Steelhax targeted Steel Diver: Sub Wars, which was free on the eShop, making it one of the more accessible entry points. Freakyhax hit Freakyforms Deluxe. Smilehax came from SmileBASIC. Even Pokemon Super Mystery Dungeon fell to supermysterychunkhax, though that one required an existing homebrew setup to install the modified save.

Ironhax was particularly interesting because IronFall Invasion was a free-to-start eShop download, which meant anyone could get an entry point without spending a cent. Smealum found a save file vulnerability in August 2015, and Nintendo's response was dramatic: they pulled IronFall from the eShop entirely on August 11, before the exploit was even publicly released. The game eventually returned in October with a patched update, but there was a clear cat-and-mouse game taking place. Nintendo was monitoring homebrew forums and preemptively removing games from their own store before they could be exploited publicly.

Then there was browserhax, which moved beyond game cartridges entirely. yellows8 released a series of webkit-based exploits targeting the 3DS's built-in web browser in September 2015. These were heap-based attacks against the browser's rendering engine, and they came in several variants for different firmware versions. One, called sliderhax, was triggered by touching the scrollbar at a precise position after the page fully loaded. Another triggered automatically while the page was loading. The browser exploits were unreliable, as webkit exploits often are, but they were free and required zero additional software.

Menuhax went even further. Also by yellows8, it exploited how the Home Menu loaded custom theme data from the SD card. When the Home Menu decompressed theme data, it allocated a buffer with a fixed 0x150000-byte output section followed by a 0x150000-byte input section. The decompression routine had an input size parameter but no output size check at all, so a specially crafted theme file could overflow the output buffer, overwrite the compressed input data, and corrupt the heap memory chunk headers that followed. When the system tried to free that corrupted memory, it would crash in a controllable way, giving you code execution. This meant you could trigger homebrew every time the console booted, just from a modified theme file on the SD card.

The sheer volume of exploitable games and system features made it nearly impossible for Nintendo to fully lock things down. You could patch the browser, but you couldn't retroactively fix every cartridge ever manufactured. You could pull games from the eShop, but people already had them installed. It was a constant back-and-forth, and Nintendo had clearly lost at that point.

Going deeper than userland

ARM9 was the final frontier

All of those exploits, as impressive as they were, only gave you userland access on the ARM11 processor. You could run homebrew apps, but you were operating in the same sandbox as a normal game. The real security enforcer was still the ARM9, sitting behind its walled-off RAM, controlling the cryptographic keys and filesystem permissions. Getting ARM9 access was the holy grail, because it meant you could decrypt and modify the system firmware itself.

In December 2015, at the 32nd Chaos Communication Congress (32C3), smealum, derrek, and plutoo presented their work on ARM9 kernel exploits, and things got a lot more serious after that.

The breakthrough that followed, ARM9LoaderHax, was clever in how it abused the 3DS's boot process. The New 3DS had an extra encryption layer: before the actual ARM9 firmware could run, an intermediary piece of code called arm9loader would decrypt it using keys stored in NAND. Those keys were themselves encrypted using data derived from the console's OTP, a one-time programmable memory region that gets locked out after boot. The idea was that each console would have unique keys, making it impossible to use one console's firmware on another, and this was implemented identically on the original 3DS as well.

But arm9loader had a critical flaw: the NAND keysector was encrypted with AES in ECB mode, meaning individual blocks could be rearranged without breaking the encryption. On top of that, Nintendo never verified one of the stored keys against a known value. By writing manipulated key data to NAND, researchers could cause arm9loader to decrypt the ARM9 firmware into attacker-controlled code... executing it automatically before the real firmware ever launched.

That changed everything. Instead of loading homebrew through a game every time you powered on your 3DS, you could now have persistent custom firmware. Luma3DS, which was becoming the community's custom firmware of choice, could patch the system on the fly, disable signature checks, and give you full control over both processors.

The community had gone from "scan a QR code in a bad puzzle game" to "we own the boot chain" in just over a year. That's a wild escalation, and it happened because each exploit built on the last, with researchers sharing knowledge and building tools collaboratively.

Soundhax made it free for everyone

No more downloads

I should talk about soundhax, because it deserves its own recognition for how clean it was. Released by nedwill at 33C3 in December 2016, soundhax exploited a heap overflow in the Nintendo 3DS Sound app, the built-in music player that every single 3DS ships with.

The vulnerability was in how the app parsed MP4 atom tags, specifically the Unicode string handling for song names. When 3DS Sound loaded an .m4a file, it would allocate a 256-byte heap buffer to hold the song's name, which is the maximum size the MP4 spec allows. Reasonable enough. But because Unicode strings contain null bytes, the app couldn't use a standard strncpy function to copy the name. Instead, it used a raw memcpy with the user-provided size field from the MP4 metadata, which could be arbitrarily large. So you'd craft an .m4a file with a song name that claimed to be, say, 4,096 bytes long, and the app would dutifully copy all of that data onto the 256-byte heap buffer, overflowing into the adjacent heap chunk.

From there, nedwill's exploit overwrote the malloc header of the next heap chunk. When that chunk was later freed, the heap's linked-list unlinking operation performed an arbitrary write, which nedwill used to redirect execution. The next malloc call would return the stack address as the "heap" location, letting him write ROP chain data directly onto the stack. It was a textbook heap exploitation chain, and it worked beautifully.

The user experience was almost comically simple. You'd place a crafted .m4a file on your SD card, open 3DS Sound, and play a song whose title showed up as an ASCII emoji and "nedwill 2016." That was literally it, and it was free, worked fully offline, and was compatible with every firmware version from 1.0 through 11.3.

Before soundhax, every primary exploit required either a specific game cartridge or the browser, which Nintendo could update. Soundhax used a built-in system app that existed on every 3DS ever made. Combined with the ARM9 exploits that were already available, soundhax became the recommended entry point for years. It opened the door to 3DS hacking for everyone, in a way that nothing before it had managed.

The magnet, the key combo, and the bootrom

Nintendo had lost

In May 2017, the final piece fell into place, and it was the most permanent one of all. SciresM released boot9strap, which exploited a vulnerability in the 3DS's boot ROM itself: the very first code that runs when the console powers on, burned into the silicon at the factory and impossible to update. SciresM, if the name sounds familiar, was also the maintainer of Atmosphere on the Nintendo Switch before stepping back early this year.

To understand how this worked, you need to know about a recovery feature that Nintendo built into every 3DS. It was meant for the factory: when assembling new units with blank NAND storage, technicians needed a way to load firmware onto the console for the first time. So Nintendo's Boot9 code included a check at the very start of the boot sequence. If the console's clamshell is closed (the 3DS thinks it's in sleep mode) and the buttons Start, Select, and X are all held during power-on, Boot9 will skip NAND entirely and attempt to boot from a signed firmware image on an inserted DS cartridge. Nintendo used this to flash fresh consoles on the assembly line, and it doubled as a recovery mode for bricked units.

The sighax vulnerability, discovered by derrek, broke the "signed" part of that equation. He found a flaw in Boot9's RSA signature verification that made it possible to forge signatures the bootrom would accept as valid. The details are technical, but the short version is that Boot9's implementation of RSA PKCS#1 v1.5 didn't properly implement ASN.1 signature parsing; it didn't check field boundaries, it accepted the wrong PKCS#1 block type, and it didn't require correct padding. All of this allowed a crafted signature to pass verification despite not being generated by Nintendo's private key.

Combined with ntrboot, the community had a universal installation method. You'd flash boot9strap onto a compatible DS flashcart, insert it into the 3DS, and then trigger the factory recovery mode. On clamshell models (the 3DS, 3DS XL, New 3DS, New 3DS XL) you needed to hold a small magnet against the console near the A/B/X/Y buttons to trick the Hall effect sensor into thinking the lid was closed, because you obviously couldn't press the key combo with the lid physically shut. The old 2DS, being a slate design, had a physical sleep switch instead, which made it easier.

It looked absurd, in fairness. You'd see people holding a fridge magnet against their 3DS while pressing three buttons and the power button at the same time, with a $5 flashcart poking out of the cartridge slot. But it worked on every single unit ever manufactured, on any firmware version, regardless of what patches Nintendo had applied.

This was the endgame of 3DS hacking, and signalled the entire system had been blown open. Boot9strap operates at the lowest possible level, before any software-based protections can kick in. Nintendo couldn't patch it because the boot ROM is, by design, read-only after manufacturing. No firmware update could touch it. Every 3DS ever made, from the original 2011 launch model to the final New 2DS XL, was permanently and irrevocably hackable.

The 3DS is fully defeated, and that's a good thing

You can do whatever you want with your hardware

Looking back, Nintendo did build a good security system for the 3DS. Dual processors with strict privilege separation, a hardware root of trust, layered encryption, RSA signature verification at every stage of the boot chain... it held for longer than the Wii or DS ever did. But the chain of exploits that brought it down, from a DS profile text field overflow, through a $5 puzzle game's QR reader, past a parade of shovelware save file hacks, through the ARM9 kernel via a firmware decryption flaw, all the way down to the boot ROM's broken RSA implementation, tells you something about what happens when a determined community decides to pick a lock. Each exploit opened the door just a little wider, and the next researcher walked through it to find the next flaw deeper in the stack.

Today, every 3DS ever made can run custom firmware. The current guide walks you through the process in under an hour, using free exploits like super-skaterhax or MSET9 that don't require any additional hardware at all. Luma3DS, the community's custom firmware of choice, is still actively maintained despite the console's official end of life and the closure of Nintendo's online services.

I'm glad the 3DS was cracked open. It means my 3DS will keep working even though Nintendo's servers are gone for good, running software the community maintains because they genuinely care about the hardware. That's what mattered more to me above all else, and being able to use the hardware for whatever I want, even as an Xbox controller on my PC, is amazing.