This explanation is here for one reason: Most people who hack their 3DS using [URL='https://3ds.guide']3ds.guide[/URL] don't know what they are doing. We have ended up with just a big black magic box that's supposed to do all of our work for us, even when we are working in a system so complicated that even to make small modifications you will need to know a lot about its inner workings.
To quote [URL='https://yifan.lu']yifan.lu[/URL]:
[quote]writing mods for the 3DS is extremely difficult and usually requires an in depth knowledge of the system even to make simple modifications.[/quote]
I've seen countless posts here, in chatrooms, on reddit, and on many other forums where people blindly follow the instructions for installing the popular B9S/Luma combo on their 3DS, only to finish the guide, and just stare at their monitor thinking "Wow, I have no idea what I just did, but hey, it works, so, let's keep it".
You also have people who are genuinely curious as to how they hacked their 3DS, or [URL='http://gbatemp.net/threads/why-the-3ds-cant-be-downgraded-on-11-4-for-dummies-a-simple-explanation-for-the-rest-of-us.441373/']why the 3DS can't be downgraded anymore[/URL] (Thanks @Swiftloke !), or why they need 3 different hacks in order to install a CFW, and, the ever popular question of "what is boot9strap and sighax?".
I believe that people [B]SHOULD[/B] know what they are doing, since it only benefits them in the end. There is no noob-friendly total complete package that explains everything fundamental about the 3DS, and I believe that simply pointing everyone to [URL='https://yifan.lu/2016/04/06/the-3ds-cryptosystem/']a lot[/URL] [URL='https://youtu.be/CzVZgdkzBn8?t=16m26s']of[/URL] [URL='https://youtu.be/8C5cn_Qj0G8?t=20m8s']dev[/URL]-[URL='https://sciresm.github.io/33-and-a-half-c3/']speak[/URL] [URL='https://www.3dbrew.org/wiki/Main_Page']that[/URL] [URL='https://yifan.lu/2015/01/10/reversing-gateway-ultra-first-stage-part-1/']they[/URL] [URL='https://yifan.lu/2015/01/12/reversing-gateway-ultra-first-stage-part-2/']cannot[/URL] [URL='https://yifan.lu/2015/01/17/reversing-gateway-ultra-stage-3-owning-arm9-kernel/']understand[/URL], is not the correct way to educate people and encourage them to learn more.
For example, have a look at these two pictures:

Here's how the 3DS looks behind the scenes:

[CENTER][IMG]https://image.prntscr.com/image/xo7aTa5pTgmeRq1WoTWfEA.png[/IMG][/CENTER]

And here's how complicated the 3DS security has gotten over the years:

[CENTER][IMG]https://yifan.lu/images/2016/04/96Encryption-2.png[/IMG][/CENTER]


So, without further ado, let's get right to it.

[h]
[CENTER][SIZE=6][B]3DS HARDWARE & SOFTWARE[/B][/SIZE][/CENTER]
[/h]

[SIZE=4][B]Hardware[/B][/SIZE]
Okay, to begin, let's talk about the hardware. The 3DS has two processors, one is the ARM11, and the other is the ARM9. Now, to be technically correct, there is also an ARM7 for better backwards compatibility with GBA and NDS games, but we're not going to go into too much detail because this isn't a thread about NDS-Bootstrap Loader[sup]1[/sup], or AGB_FIRM[sup]2[/sup]
The ARM11 is the more powerful processor, and it is what handles running the actual 3DS games. So, whatever you see, the home menu, the web browser, games, all run on that processor.
The ARM9 is used heavily when you play a DS game on the 3DS using the DS backwards compatibility mode (Called TWL_FIRM[sup]3[/sup]). However, in 3DS mode, the ARM9 is reused as a security processor.
The 3DS also has RAM (because it is essentially a computer), and it is split into 3 parts: RAM that is only for the ARM9 processor, RAM that is shared between the two processors, and RAM that is for the ARM11 but can be accessed by the ARM9 if needed.

Apart from the actual chips that are soldered on your 3DS motherboard that do the processing, we also have the power cycle of the 3DS, or more specifically, the bootROMs for each of the two processors.
Since the bootROMs are embedded in the actual die of the CPU, I will put this explanation here, in hardware.
"But Jason, what is a bootROM?" Good question. So, whenever you turn on your 3DS, your 3DS doesn't simply turn on. Instead, this happens:
[CODE]Power button --> ARM9 BootROM initialized --> Run some code --> Lockout the BootROM permanently (Until the next cold restart) --> Arm9loader --> Load the console-specific keys stored in the OTP region --> Lockout the OTP region permanently (Until the next cold restart) --> Load the Firmware (The actual "OS" of the 3DS)[/CODE]
What does all this mean?
Well, the bootROM is a very small portion of the processor in which some code is located, such that it is the very first thing that is initialized whenever you press the power button. In this case, the ARM9 bootROM is initialized first, and then the ARM11 is initialized later (of course by its own bootROM), but keep in mind that the ARM9 sends the command for the ARM11 to power on, not the power button.
As you may or may not know, ROM stands for [U]Read Only Memory (R.O.M.)[/U]. This means that whatever code is in that area, it is there for good, and cannot be modified by a firmware update, the only way is through a new hardware revision. The good thing about such a system is that it ensures that it is unhackable, since you cannot write your own hack to that region. The bad thing though, is that if you slip up and make a mistake and leave it in that unwritable area, you cannot fix it, and spoiler alert, Nintendo did slip up and leave an exploit for us in the bootROM.

Apart from the bootROM, you may have also read about the OTP region. The 3DS has hardware that is specifically made for encryption and decryption of various things. In this case, the OTP region is a keyslot[sup]4[/sup] where the console specific-keys are located. These console-specific keys are important for decrypting many things on your 3DS, for example decrypting the NAND, which is why they are loaded in the first place.
Lastly, you may have noticed that there is a "bootROM lockout" and "OTP lockout". What these mean is that, after the system accesses whatever it needs to access from those regions, it locks them out permanently until the next cold restart[sup]8[/sup]. This is because there is very sensitive information in there (Things like various keys and the source code[sup]9[/sup], which we can search for exploits), and Nintendo didn't want people to mess around in that area.

There are a few more things implemented in the hardware that might interest us, like the [URL='https://en.wikipedia.org/wiki/Advanced_Encryption_Standard']AES[/URL] and the [URL='https://en.wikipedia.org/wiki/Public-key_cryptography']RSA[/URL] engine (really important for signatures!), but apart from that, we don't really need to know more in order to understand how the 3DS security is actually breached.

[SIZE=4][B]Implementation & Software[/B][/SIZE]
So now that we know what's under the hood, let's see how it's all connected and programmed.
As you know, the ARM9 is used as a security processor. Specifically, whenever you try to run a game, encrypt or decrypt something, install anything with DevMenu or FBI, the ARM9 makes sure that whatever you are trying to do is legit. Also important to note is that the ARM9 is the processor that actually reads and writes to the NAND (Essentially the hard drive of your 3DS). Now, all those capabilities have to be called from somewhere, we need to tell the system to execute those capabilities somehow (we call these capabilities "functions"), and the ARM11 does that. To be exact, the ARM11 kernel.
Here's a diagram of how the the tree of privileges[sup]5[/sup] is implemented:

[CENTER][IMG]https://image.prntscr.com/image/RGQ9j5QMQ_uSvozWRfrTfg.png[/IMG][/CENTER]
At the top we have the ARM9[sup]6[/sup] After that is the ARM11 kernel and the ARM11 itself.
Whatever application you run, be it games or anything else, run in the ARM11 userland (Userland, as in, that's where the user resides). ARM11 kernel (Sometimes abbreviated to K11, as in, KERNEL11) is what has full rights over the entire ARM11 processor, and that includes the userland. The ARM11 is also what handles the actual installation process, granted the ARM9 authorizes it first (It does so by checking the signature[sup]7[/sup]), so, if a signature is checked to be legit, the installation/runtime is approved by the ARM9.

[h]
[CENTER][SIZE=6][B]HACKING THE 3DS - GETTING NAND ACCESS[/B][/SIZE][/CENTER]
[/h]

Now we get to the real meat of the story. So what exactly are we trying to do when we mean "I'm going to hack my 3DS"? What do the hackers mean when they say "Breaching the 3DS security"?
What I need to say right now is that our end goal when trying to hack a 3DS is getting access to read/write functionalities on the NAND. What we are trying to do is, install Boot9Strap (I'll get to what it is later, for now, treat it as the files we need to copy over to the NAND so that we install the hack), and it requires the ability to read/write to the NAND. You know how when you try to install an application in windows using a .exe installer? That requires writing and reading to the hard drive. And same for the 3DS. When we need to install something, we need to access to the 3DS' storage, the NAND[sup]10[/sup].
In order to get NAND access, we need to take control of the ARM9, and as you already know, the ARM9 is the security processor, which means it has plenty of security features.
So, let's step back a bit and look at the bigger picture. We are trying to hack our 3DS, and we need to get NAND access to install Boot9Strap. We need to get ARM9 access in order to get access to the NAND, therefore, our goal is to hack the ARM9. But how do we hack the ARM9?

I will now explain, from start to finish, how Soundhax works, which I believe is the most popular hacking method.

First of all, Soundhax is just the userland exploit. You can't really do much in userland, if your end goal is to install unsigned software. Our end goal is ARM9 access. And good news, there is an ARM9 exploit, it's called safehax!
Safehax  is actually an old exploit from 2013 brought back from the dead by noticing the slip ups that Nintendo made.
The old exploit, called firmlaunchax, took advantage of the fact that during bootup the ARM9 would write some data to the RAM shared between the ARM11 and the ARM9, and it wouldn't expect the ARM11 to do anything to that portion of RAM. We of course abused this and, with the ARM11 kernel access we had, we would write whatever we wanted to that portion of RAM, and the ARM9 would execute it and we got ARM9 access.
The way in which we brought this exploit back after Nintendo patched it is by abusing the fact that Nintendo doesn't really update the 3DS properly. You see, the 3DS' firmware is split into 3 parts, those are NATIVE_FIRM, TWL_FIRM and AGB_FIRM.
Whenever you play a DS/DSi game, TWL_FIRM is loaded. Whenever you play a GBA game, AGB_FIRM is loaded. Whenever you are doing anything else, NATIVE_FIRM is loaded.
The important thing here is that the 3DS has a special mode, called SAFE_MODE_FIRM, in which you can boot into. And this mode almost [B]never[/B] gets updated[sup]12[/sup], so it should have very old exploits. And that is exactly the case. The catch though, is that you need ARM11 kernel access.
Therefore, if we can somehow get ARM11 kernel access, we can reboot into this SAFE_MODE_FIRM, and have access to old code, and exploit it! And that is what we do[sup]11[/sup].

So now we just learned that safehax requires K11 access, and we are in luck, because there is an exploit that can get us from userland to K11, it's called UDSPloit.
UDSPloit works by this and that and 4 classes etc

And now the last step we need to achieve is to get a userland exploit, which is easy, we got soundhax for that. Now, I won't get too technical about this, but the general idea is that we achieve a buffer overflow with .M4A format.

One last thing to say here is that the exploits are actually executed backwards, we first get userland, then we get K11, then we get ARM9. This is how it's done in 3ds.guide as well, it first instructs you to execute soundhax, then through the homebrew launcher you can execute udsploit, then we execute safehax.

[h]
[CENTER][B][SIZE=6]WHY THE 3DS NEEDS TO BE HACKED EVERY RESTART - THE NEED FOR BOOT9STRAP[/SIZE][/B][/CENTER]
[/h]

So now that we have taken over the ARM9 and we can execute whatever code we want there, we essentially can do whatever we want with the 3DS.
Here's the issue though, every time we reboot the 3DS, all of our work gets erased (because RAM gets deleted on shutdown[sup]13[/sup]), so every time we shutdown and boot up the 3DS, we need to go through this process again of soundhax-->udsploit-->safehax, and it can get a bit annoying.
This is how Gateway[sup]14[/sup] was back in the day. Every time you shutdown your 3DS, you had to execute the old DS Profile exploit[sup]15[/sup], and it would get annoying sometimes.
But why can't we make it so that the 3DS get hacked on bootup?
Let's get back to the bootROM we talked about earlier. See, the bootROM is programmed to only load genuine firmwares (Firmware = Operating System of the 3DS), so even if we got ARM9 access, all that we can do is simply patch whatever we already have, what is already loaded by the 3DS. We cannot load whatever firmware we want, because the bootROM will refuse to load it as it is not signed by Nintendo, and even if we have ARM9 access, we cannot do anything to change the fact that the bootROM will only load genuine firmwares, as it is read only.

What the 3DS hacking scene was trying to do is find a way to load unauthorized firmwares right from bootup, and it took us until [URL='https://twitter.com/derrekr6?lang=en']Derrek[/URL] announced at [URL='https://youtu.be/8C5cn_Qj0G8?t=54m7s']33c3[/URL] this thing called sighax, which allows us to sign our own firmwares, essentially allowing us to load whatever we want in the 3DS without ever needing to go through the hacking process. If we never had Boot9Strap (or A9LH[sup]16[/sup] for that matter), every time you would want to run a game you would have to run the 3 hacks in a row and go through a lot of time in order to get unauthorized code execution.

So now, the big question in everyone's mind is "What is Boot9Strap?". Everyone refers to it as the hack you need to install, but, what does that even mean?
Well to explain it entirely, we need to go through some computer science and cryptography first.

[h]
[CENTER][B][SIZE=6]A CRASH COURSE ON DIGITAL SIGNATURES - RSA PADDING AND LENGTH FIELDS[/SIZE][/B][/CENTER]
[/h]

[SIZE=4][B]The basics[/B][/SIZE]
[URL='https://en.wikipedia.org/wiki/RSA_(cryptosystem)']RSA[/URL] Stands for Rivest Shamir Adleman (The three people that invented it). It is an asymmetric cryptographic algorithmm, which means that we can encrypt something with a public key, but only encrypt it with a private key, or the other way around, we can encrypt something with a private key, and decrypt it with the public key.
The public key and the private key are mathematically connected. The reason why you cannot retrieve the private key from the public key, is because you would need to factor a very large ([URL='https://en.wikipedia.org/wiki/RSA_numbers#RSA-2048']617+ digits long![/URL]) number into two prime numbers (See [URL='https://en.wikipedia.org/wiki/Fundamental_theorem_of_arithmetic']Fundamental theorem of arithmetic[/URL]), something which is very difficult to do with traditional computers, and the only way we can achieve such a feat in a reasonable amount of time is by using quantum computers.

[CENTER][MEDIA=youtube]GSIDS_lvRv4[/MEDIA][/CENTER]

A hashing algorithm is basically a function, in which you give it some data, and it spits out some gibberish. The reason why this is useful is because:
[LIST=1]
[*]If you enter the same thing in this function, you will always get the same gibberish
[*]No two inputs give the same gibberish
[*]You cannot reverse the output to get the input, it is impossible
[/LIST]
The algorithm which we use for hashing is SHA-2, the 256 bit version of SHA-2 to be exact.

[CENTER][MEDIA=youtube]DMtFhACPnTY[/MEDIA][/CENTER]

[B]The simple way of signing[/B]
If you want to sign something, the following things are done:
[LIST=1]
[*]First, you take the piece of data and hash it (So that if you have a huge piece of data you want to sign, you can just hash it and get a unique hash which is essentially the same as the piece of of data, and you don't have to mess with the piece of data)
[*]Then, you take your private key and encrypt that hash
[*]The encrypted hash is now the [B]signature[/B]
[*]You send to the recipient the signature (the encrypted hash), the piece of data and your public key
[*]He hashes the message
[*]The recipient decrypts the signature with your public key and gets the decrypted hash
[/LIST]
If the hash he produced from your message matches the encrypted hash you sent him (which he decrypted using your public key), we are 100% sure that the piece of data was signed by you, because only [B]you [/B]have the secret key.
If someone wants to forge a signature, he [B]must [/B]obtain your private key in some way shape or form, and use it to encrypt the hash of whatever he wants to send. There is no other way to forge your signatures, unless... you don't implement the RSA algorithm properly.























[sup]1[/sup] NDS-Boostrap is essentially a piece of software that allows you to run DS games on your 3DS, straight from the SD card of your 3DS, without a DS flashcart. You can read more [URL='https://gbatemp.net/threads/nds-bootstrap-loader-run-commercial-nds-backups-from-an-sd-card.454323/']here[/URL] and [URL='https://gbatemp.net/threads/twloader-ctr-mode-nds-app.448375/']here.[/URL] NDS-Bootstrap Loader is the actual software, while TWLoader is the interface that runs that code.
[sup]2[/sup] Basically, whenever your 3DS is going to play a GBA game, it doesn't run an emulator that's been designed by Nintendo, it loads AGB_FIRM, which, you can think of it as a virtualbox simulator, where you allocate some resources and then you run a piece of software in that simulated space, and that is what AGB_FIRM does.
[sup]3[/sup] As explained in the above note, TWL_FIRM works very similarly to AGB_FIRM, with the whole idea of a simulator.
[sup]4[/sup] A keyslot is an area in hardware that is (i will finish this later)........
[sup]5[/sup] So, imagine a family tree: You have a grandfather, a father, and a son. The grandfather tells everyone what to do, both the father and the son. The parent tells only the son what to do, but not the grandfather, and the son can only listen, he doesn't have a say in anything. That is how a tree of privileges works. The ARM9 can tell everyone what to do, the ARM11 kernel can only tell the ARM11 userland, and the ARM11 userland can only control itself, he doesn't have a say in what happens to the ARM11 kernel and the ARM9.
[sup]6[/sup] Technically there is an ARM9 kernel, then the ARM9 userland. But because if you are in just the ARM9 userland you can do everything that the ARM9 kernel does, we combine them into one. It's one exception to the privilege rule
[sup]7[/sup] If you want a nice bite-sized explanation on digital signatures, watch [URL='https://www.youtube.com/watch?v=bBC-nXj3Ng4&feature=youtu.be&t=3m29s']this video[/URL] from 3:29 to 6:36
[sup]8[/sup] When you have a computer, and you click "Shut down" in windows, it shut downs to a cold state, meaning that it doesn't use any power. So when we say cold shutdown, we aren't referring to a sleep mode, or hibernation, or a "soft restart" (In the 3DS hacking sense) where it shuts down some programs, then relaunches some others. No, we mean absolutely shutting down the 3DS by holding its power button until all the screens and LEDs are turned off, and it is "cold"
[sup]9[/sup] Technically it is just a dump of whatever assembly code was in the bootROM, not the actual source code from which the assembly was derived.
[sup]10[/sup] Technically, in order to install a Legit CIA you only need ARM11 kernel access, since you can ask the ARM9 to install the Legit CIA for you from just the ARM11 kernel, and the ARM9 will gladly do it since it's a Legit CIA and its signature is accepted by the ARM9
[sup]11[/sup] Yes I know about the patch they tried to implement, but it failed miserably, that's why I'm not bringing it up. [URL='https://gbatemp.net/threads/safehax-for-11-3-released.467265/']Read here[/URL].
[sup]12[/sup] The reason SAFE_MODE_FIRM never gets updated is because it is the safe mode of the 3DS. You know how Windows has its own safe mode, which you can boot into incase something goes horribly wrong? Logically you don't want to mess with this safe mode because it is there for emergencies, and you want to make sure it is always there. Same thing with the 3DS, you don't really want to update SAFE_MODE_FIRM because you want it always there in perfect working condition, and that is why it has old code that we can abuse.
[sup]13[/sup] To be correct about this, the 3DS' RAM doesn't get fully erased on shutdown. There's a huge bug that makes it so not all RAM is cleared on restart, so some memory still contains some data after a restart.
[sup]14[/sup] Gateway was a company which produced the first ever 3DS flashcart which could play 3DS backups. The fact that it was a flashcart did not mean that you didn't have to hack the 3DS. In fact, you had to do much of the same work that today's hacks do, because the backups that you loaded on the flashcart (As .3DS files) weren't signed and you had to patch out the signature checks, and therefore you needed to hack the ARM9.
[sup]15[/sup] The DS Profile Exploit (Which was only on version 4.0-4.5, and recently made to work with 6.0) was an old exploit, and pretty much the first exploit ever in the 3DS hacking scene that allowed us to takeover the ARM9.
[sup]16[/sup] A9LH (Which stands for Arm9Loaderhax) is an old hack, that was similar to Boot9Strap, it allowed us to load into the 3DS our own firmwares, but in a method very different to Boot9Strap's. I will not go into details as it is now history.
[sup]17[/sup]
[sup]18[/sup]
[sup]19[/sup]
[sup]20[/sup]
[sup]21[/sup]
[sup]22[/sup]
[sup]23[/sup]
[sup]24[/sup]
[sup]25[/sup]