what?
If you've bought, received or otherwise come into possession of a Nintendo 3DS Family console and learned that it may or may not be hacked, or are new to the concept of hacking your console and often find yourself repeating the title of this page and want to learn more, you've come to the right place. Click each section to open or close it.
If your Start and Select buttons are rectangular and along the bottom, you have an "old" console. If they are circular buttons to the right of the screen, you have a "new" console.
If it has a 3D slider on the right of the top screen, it's a 3DS. If it does not, it's a 2DS.
Whether it is an XL doesn't matter a whole lot for hacking purposes.
These details are commonly referred to by shorthand: [old/new | 2/3]ds (XL). I, personally, own an O3DSXL and an N2DSXL. Getting the idea?
Go to System Settings, and in the bottom right corner of the top screen is your software version. This version will determine what hacking methods are available to you, if you are not already hacked.
Turn your console off using the power button, then hold "Select" and turn it back on. Continue to hold Select until you see something. You may see the regular Home menu, or you may see a Luma configuration screen.
If you see a Luma config screen, take note of the version that it displays. You may be asked for it when requesting help. Do not change any of the settings inside it at this stage. Press Start to exit the config screen.
If you see the Home menu, there is a very good chance your console is NOT hacked. Repeat this test again with the SD card taken out of the device.
Speaking of the SD card, its content can give us some clues. If you see any of the following files or folders:
- boot.firm (Luma custom firmware bundle)
- arm9loaderhax.bin (older version Luma bundle)
- boot.bin (probably older version Luma bundle)
- gm9 (support files for godmode9)
- luma (support files and payloads for Luma)
- 3ds (support files and homebrew payloads/apps)
Homebrew, sometimes referred to as "userland access", refers to any of several methods of exploiting the arm11 processor in order to gain some limited control over the userland portion of the system. These days, about the most homebrew can do is manage save files for installed titles, some very weak emulation, and some theming. Steelhax, oothax and freakyhax are examples of exploits used to get Homebrew-only. All these *hax names result in a specific kind of homebrew access. Homebrew access via CFW (Rosalina homebrew) is different, and significantly more powerful.
Custom firmware, or CFW on the other hand, allows total system access, both hardware and software. CFW allows total control over both processors, meaning you can do pretty much whatever you want with it. For a more in depth explanation of CFW, its features, and the way it works, see the "What?" section. Seedminer, frogminer and NTRboot are examples of exploits used to get CFW.
Currently, the most widely used and trusted CFW is Luma, developed in part by AuroraWright. However, CFW is only half the story. CFW is loaded beside the original firmware by a custom bootloader, called boot9strap. boot9strap (or b9s) allows the running of unofficial code and payloads, and gives us access to load CFW beside the original firmware. For more information on the finer points of this, see the "what?" section.
Most developers who develop unofficial applications do so for use on CFW, as CFW is more powerful, readily available (these days) and stable. Homebrew has less system access, and is generally less useful.
Apps
There a few main apps that you will encounter in your journeys with CFW. They are: FBI, godmode9, Anemone3DS, BootNTRSelector, Universal Updater, the Homebrew Launcher and Checkpoint/JKSM.FBI is an important application to have. FBI is an app that can install other applications to your hacked system. Thanks to Luma, it doesn't worry about signature checks. FBI cannot work without CFW and needs to be run once, then installed once: first run via Rosalina homebrew access, and then using that "homebrew FBI" to install the CFW version of FBI.
godmode9 is technically a payload, not an application. Payloads are loaded before any of the other firmware is loaded, and so do not have the arm9 processor telling them what they can and cannot do. godmode9 is a full featured file explorer and manager, and the fact it runs as a payload means it can change anything about any file on your system, up to and including wiping the NAND (do not do this). On a positive note it can also make a backup of your NAND, your console specific encryption data, any cartridge games you have (see my page on piracy), and do things like restore your NAND backup to fix broken things.
Anemone3DS is a theming engine for your console. It can theme your Home Menu, your pre-boot splashes and your background music.
BootNTRSelector is a launcher for something called "NTR CFW". Despite the name, NTR is not actually a CFW. NTR is essentially a very powerful cheat engine that allows you to do things like stream your device to your PC ("New" consoles only) and cheat in games by editing the loaded RAM.
Universal Updater is like a "homebrew app store" for your console. It can install new apps, update apps, and even update/install payloads like Luma3DS and Godmode9.
The Homebrew Launcher is a menu that allows you to launch Homebrew software. Most developers these days develop software for CFW only, not Homebrew, but sometimes something you want will only be available through Homebrew.
Checkpoint is a save manager. It allows you to copy saves from digital and physical games, back them up and re-inject saves back into those games. This means that you can rip the saves off games, edit them and then reinject them. Checkpoint copies these saves in a decrypted format, which means they can be shared between systems very easily.
JKSM does roughly the same thing, but Checkpoint is preferred in most cases. JKSM can be used on a Homebrew-only install, Checkpoint requires CFW. Checkpoint handles a large amount of games that JKSM has issues with, for whatever reason.
Folders and Files
Here's some common folders and files, with a short explanation.Nintendo 3DS: contains your user data such as installed applications, updates and saves, along with other similar information.
3ds: contains homebrew applications and data. NOT the same as "Nintendo 3DS".
gm9: contains support files for godmode9, such as scripts. Also contains data created by godmode9 in the "out" folder, such as nand backups and cartridge dumps.
luma: contains support files for Luma, your custom firmware, such as its configuration details and payloads like godmode9.
DCIM: contains user-created pictures and screenshots.
cias: optional, but recommended folder to organise CIAs you wish to install.
themes: support and data folder for theming engines like Anemone.
private: possibly contains support files for Lenny, an exploit used to get CFW. May also contain other app data, so leave it alone.
boot.firm: Luma firmware file, usually. b9s runs boot.firm when the console boots, so you can change boot.firm to be something like godmode9 if you want, and your console will boot directly to that. (This is not advised under normal circumstances.)
boot.3dsx: homebrew launcher executable.
boot.nds: either b9stool, which is used to install CFW, or TWiLightMenu++ launcher file.
Here is a more in-depth explanation of the hardware, the software, CFW, what it does and how it works when we hack it. Close this if you don't really care about the process of hacking, but in my opinion it's important you understand what you are doing to your device.
Behind Nintendo's doors, the 3DS family are referred to by the codename Citrus, or CTR. CTR devices have two main processors, called "arm9" and "arm11". arm9 is commonly known as the security processor, as it handles most of the console's security measures. arm11 is commonly known as "userland", as it handles almost everything you will do with your console, including games, themes, home menu etc.
Inside your CTR device, there is a little chip called the NAND. The NAND is a bit like the "C:/" drive on your computer. It contains important system files, some very important console-unique data, and the firmware. Firmware is what is used to interface between the hardware, or the physical components, and the software, or the operating system. An important part of the firmware which we care about in specific contains the software which gets loaded to the end user. This part consists of two partitions, or sections: firm0 and firm1, referred to in shorthand as "f0f1". Both of these, in theory, should contain identical copies of the software. f0 is loaded first, and if it's corrupted, f1 is used.
f0f1 is loaded into working memory by a thing called a "bootloader", or bootrom. The "rom" in bootrom stands for read-only memory, which in this case is stored on a kind of media that cannot be rewritten once it is written. The bootloader works along with the arm9 processor to ensure that the code it is trying to run is signed and valid. All code and instructions that are involved in the operating system are "signed", or verified to be authentic, by Nintendo using keys and other such security measures.
What we, as hackers, aim for is compromising the arm9 processor in order to do what we want with it, not what Nintendo says we should want. The contemporary method for this is to exploit some bug, and use that to trick the arm9 processor into letting us install b9s to our f0 partition. boot9strap, aka b9s, is a custom bootloader that allows us to run unsigned code and instructions. The arm9 and arm11 processors generally won't run any unsigned code. b9s allows us to step around this restriction and load unsigned payloads.
This brings us to Luma, the currently biggest and best custom firmware. Luma is an unsigned and unofficial addition to your firmware, which allows for things like region-free play, signature bypasses that allow you to install unofficial applications to your home screen, real-time cheat menus, etc etc etc. Luma runs "alongside" your official firmware/software, which means that on the surface, it doesn't look any different. Luma exists as boot.firm on your SD card's root directory. b9s tells the system to load boot.firm as the firmware every time you boot up your console.
As we have learned, b9s is installed to f0. When a system update or, importantly, a system format occurs, f0f1 are left untouched (thanks to Luma). This means that the only way to get rid of b9s is to deliberately uninstall it, or install something malicious that screws up your f0f1. Essentially, once you have b9s, it tends to stick around.
The CTR's non-hacked firmware is referred to as "native firm", occasionally appearing as "native.firm". Along with native firm, we can also have custom firmware (our Luma). The CTR system also has "TWL_firm", along with some DSi hardware inside the console, which allows us to run "old DS" games with perfect compatibility. Also, "AGB_firm", and the related hardware, does the same thing for Game Boy Advance games. The CTR system also has SAFE_MODE_firm which is a rescue function that allows a system update to be run in order to fix some broken part of the system and the regular system update will not work.
We need to exploit vulnerabilities in order to do what we want with the software. Some very talented people spend a lot of time reverse engineering the firmware and software to find these bugs, and more time coding things designed to exploit them.
A Note About Sighax
Sighax is the reason we have what we have on the 3DS family today. Remember "unsigned code and instructions" from the previous section? Sighax is that unsigned instruction. Some geniuses worked out some vulnerabilities in the way Nintendo signs their data, and brute-forced some information about the arm9 bootrom and the way it loads code. It loads some instructions, loads a Nintendo-signed public key for the firmware payload, loads the payload, checks a hash for the loaded payload against the public key, and if they verify, boots it. The objective of this is to verify if the payload has been altered: the first signature, being a public key, does not change, and the second is created by the payload, and created and checked every time the payload is loaded. If the payload originates from Nintendo, the public key will always match the payload hash, and the payload is safe.
If the payload hash doesn't match the public key result, the bootrom refuses to load. To simplify a very complex process, sighax forces that signature check outside of a "safe zone" and into what's basically an unrestricted area. The reason: with some more code magic, even for unauthorised payloads, the bootloader always accepts the signature check because it's no longer checked as thoroughly.
Slightly simplified: If the payload hash verifies against the public key, the payload is run. Sighax causes the console to generate a signature based on the payload it is given, and then check that signature against itself. Because it matches, it allows us to run external payloads. In other words: magic. actual detailed sighax writeup here, more technical but obviously more accurate than my slapdash explanation
Exploit Methods
One of the best known exploits is Soundhax. Soundhax is currently used to install CFW on consoles on software version 11.3 and below. Soundhax exploits a long chain of vulnerabilities in the Nintendo Sound application, installed by default.
Recently, the 3DS hacking community has been giving itself CPR, so we now have some new tools: Browserhax, unSAFE_MODE and bannerbomb3. By themselves, they're just exploits or glitches, but combined in certain ways, we get easy, free CFW access.
Browserhax
Browserhax was a new implementation of an old exploit, or so it seems. With a bit of work, it's been made to function on both Old and New consoles, across almost every region (sorry CHN). Browserhax can be simplified by the following two words: "oops lol". It's essentially just feeding the Internet Browser some bad data that it doesn't know how to handle (but should), and when it crashes, we interrupt it and run the Homebrew Launcher.unSAFE_MODE
This one's a fun one. Basically, this exploit has existed for quite some time, but nobody ever found it until now. The reason it still exists is because SAFE_MODE's actual firmware hasn't been updated in forever. So, we worked out how to screw with it: put some bad data in the saved internet connections, then bring that bad data up in SAFE_MODE. This bad data can't just be "added" by normal means, so we need an exploit to add it.bannerbomb3
bb3 was a neat little exploit relating to the way the 3DS displayed application banners for DSiWare titles (yes, more DSiWare exploits). bb3 was used as a descendent of Seedminer (see below), whereby we would make a glitchy DSiWare title using our movable.sed, ask the system to read it, and when it read it, it would accidentally dump the DS Internet Connection settings applet onto our SD card. This gives us a valid DSiWare app to feed to a tool like Fredtool.Seedminer
Some time ago, it was discovered that it is possible to obtain the console's encryption key by a somewhat complex reverse-engineering and cryptographic brute-forcing function. All the data on your console, including games and game saves, is encrypted with this key to be specific to your console. This is partially to stop you from sharing or cloning your SD card and giving away your installed content for free. By exploiting a mathematical connection relating to your console's encryption data and the data on the SD card, we can get a working copy of that encryption data. In simpler terms, it is similar to guessing a very complicated password. This exploit has been named Seedminer. Because the console encryption key is used to validate the content of a game or a save, it can be used to trick the console into doing things such as letting us hack it.Japanese Flipnote
While not an exploit in and of itself, this little glitch is relied upon by almost all Seedminer-based methods. A specific Japanese version of DSi Flipnote has a particular kind of save system which allows us to write a bad save, then ask Flipnote to load that bad save. Most apps have protection against this. For some reason, this specific version doesn't.Of note, the only reason Japanese Flipnote really became a big player in getting CFW is because for some (bad) reason, DSi mode apps have access to the entire system firmware memory. Combined with other exploits, we can use this to politely ask DSi mode apps to do things for us, such as install things to places they shouldn't go (read: boot9strap to firmware partitions)
One implementation of "the Seedminer exploit" is Sudokuhax. Sudokuhax functions by injecting bad data into a game save, injecting that game save back into a purchased DSiWare game, launching the game on the system and exploiting a vulnerability in the save data in order to launch a b9s installer. Sounds complicated, doesn't it?
The next, and easier, implementation is Frogminer/Frogtool, which relies on a similar exploit to Sudokuminer, except that it uses the TWL mode Download Play app as its target, instead of a purchased DSiWare game. Frogtool uses userland homebrew access in order to copy the Download Play app and use the encryption key to allow us to change it. Prior to Frogtool, CFW on recent system versions required a purchase.
An even more recent implementation is Fredtool, which is a combination of various exploits: like Frogtool, it uses the encryption data from the console in order to allow arbitrary injection of code, however its target is the DS Internet Connection settings application, which makes it multi-region!
Another *miner exploit, Steelhax relies on "the Seedminer exploit", except the target was a free eShop game. The only catch was that Steelhax only got homebrew access. Steelhax was suggested for stock consoles in order to use Frogtool, as Frogtool requires homebrew access and Steelhax is free and compatible with latest 3DS software.
Pichaxx is another homebrew-only Seedminer based exploit. Works the same way as Steelhax but with a streamlined process.
Wanna know more about Seedminer and the way it works? See here for a detailed presentation from the primary developer of the exploit.
So, we have some exploits. What do we do with them? Well, we chain them together. For the most part, each exploit does one very specific thing. They're only useful when we use them in combination with others. Here's some examples.
Browserhax > unSAFE_MODE
We can use Browserhax to get access to Homebrew, which allows us some control over the system. Once we have that control, we can use Slottool (a Homebrew executable app) to install our bad data for unSAFE_MODE. Once we do that, we can use unSAFE_MODE to install boot9strap.bb3 > unSAFE_MODE
We can use Seedminer to get our movable, and use our movable to make a bad DSiWare app containing our bad data for unSAFE_MODE. Because the app is signed with our encryption key, the system doesn't question what it contains, and we inject our bad wifi data. Once that's done, we can use unSAFE_MODE to install boot9strap.Seedminer > PicHaxx > Frogtool
We can use Seedminer to get our movable, and use that movable to make a bad save for an app (Pokemon Picross). Once we do that, we can force Picross to load the Homebrew Launcher. Once that's done, we can use Frogtool to load Japanese Flipnote with our bad save, and use our bad save to politely ask the console to install boot9strap.Seedminer > PicHaxx > Fredtool
We can use Seedminer to get our movable, and use that movable to make a bad save for an app (Pokemon Picross). Once we do that, we can force Picross to load the Homebrew Launcher. Once that's done, we can use DSiDumper (a Homebrew executable app) to politely ask the console to dump a system DSi app (such as DS Download Play or DS Internet Settings). Once we do that, we can re-wrap our system app to contain Japanese Flipnote using Fredtool. Once we relaunch our system app, it launches Japanese Flipnote with our bad save, and we use our bad save to politely ask the console to install boot9strap.As you can see, all these exploits work in combination with each other to do what we need them to do, though they don't do a lot by themselves. Obviously there are other exploit chains; these are examples.
NTRBoot is a strange one. Thanks to some of the work done to uncover Sighax, we noticed another thing: before attempting to boot, the bootloader checks: if a key combination is being held, AND if the shell is closed (the console is in sleep mode). If both these conditions are true, the bootloader tries to boot from an inserted NTR (old DS) cartridge. Combined with sighax, it allows stupidly easy bootloader access: you can tell the console to boot from the NTR cartridge, and the NTR cartridge tells the bootloader to load a payload (when the cartridge is flashed with b9s, our usual custom bootloader). You can even flash tools like Godmode9 to the cartridge, and boot straight to them via NTRBoot.
We are, at this point, unsure of what NTRBoot was actually intended for. We assume it was some kind of "repair mode" implemented by Nintendo for service purposes, but we'll probably never know. To use NTRboot, you need a compatible flashcart. The NTRboot "exploit" is present on every 3DS Family system currently in the wild and will likely be present on every 3DS Family system to come, because for Nintendo to change the hardware board would be needlessly expensive.
We are approaching the 3DS end of life (EoL), as evidenced by the recent shutdown of the 3DS eShop.
Historically and practically speaking, homebrew developers and console producers/licensors have always been in a 'cat and mouse' game, where the homebrew devs try to make use of exploits to gain more system access, and the console developers try to patch those exploits to stop them.
Every new exploit used by homebrew developers gives more context to console developers as to vulnerabilities to patch - effectively, every new exploit used is 'burned', because using it makes it obvious to console developers how it works and what to patch.
Nintendo's changes in 3DS firmware version 11.17 killed bb3, which was a fairly major exploit and one of the last remaining exploits that did not require an additional purchase and worked on almost all firmware versions. They left a number of exploits open (leading to things like super-skaterhax and kartminer/kartdlphax), but a lot of the contemporary CFW install paths relied on bb3.
super-skaterhax is only applicable to certain firmware/hardware combinations, kartminer/kartdlphax requires a copy of MK7 which not everyone has, and seedminer is in a weird position - bb3 can't be used on 11.17, but firmwares before 11.17 cannot use the friends list to complete the first part of the process.
Anyway, what all this means is the following:
- Seedminer is not relevant any more on 11.17
- New methods exist for 11.17 however they are not applicable across the entire firmware/hardware spectrum
- The game of 'cat and mouse' is drawing to a close: nintendo doesn't want to officially EoL the console in case there are more exploits in the community's pockets, and the community doesn't want to release any big new exploits in case Nintendo patches them before EoL
- ntrboot, which works across the entire FW/HW spectrum, is now a primary method for installing CFW, but requires a flashcart that is flashed with ntrboot. some flashcarts come preflashed, some require flashing via the use of another hacked console
We are in unknown waters here, and it is sort of a mexican standoff. The community and Nintendo are both pointing guns at each other, and nobody wants to shoot first.
eipHax
