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.
AppsThere a few main apps that you will encounter in your journeys with CFW. They are: FBI, godmode9, Anemone3DS, BootNTRSelector, Luma 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.
Luma Updater is a simple application that connects to the internet to check for, download and install updates to Luma, your CFW. Sometimes you will need to update the updater.
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 FilesHere'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.
steelhax: contains support files for Steelhax/Steelminer. Not needed once Finalizing Setup has been completed.
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.
movable.sed: your console's unique encryption data. You should have a backup of this file somewhere, but once you've installed CFW, it doesn't have to be on the SD.
484E4441.bin: a clean version of your DS Download Play. Once you've been through Finalizing Setup and restored the clean version, this file isn't necessary.
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
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, 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.
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 implementation is Frogminer, 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. Frogminer 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 Frogminer, CFW on recent system versions required a purchase.
An even more recent implementation is Fredminer, which is a combination of various exploits: like Frogminer, 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, Steelminer relies on "the Seedminer exploit", except the target was a free eShop game. The only catch was that Steelminer only got homebrew access. Steelminer is suggested for stock consoles in order to use Frogminer, as Frogminer requires homebrew access and Steelminer is free and compatible with latest 3DS software.
Wanna know more about Seedminer and the way it works? See here for a detailed presentation from the primary developer of the exploit.
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.