[CENTER][SIZE=6][B]INTRODUCTION TO 3DS HACKING[/B]
[B]"What the fuck am I doing when I follow 3ds.guide?"[/B][/SIZE][/CENTER]


The goal here is simple: To explain how the 3DS works behind the scenes.
Most people who hack their 3DS using [URL='https://3ds.guide']3ds.guide[/URL] don't know what they are doing. We unfortunately have ended up with 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://twitter.com/yifanlu']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".
I believe that people should 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.

When you are finished reading this guide, you will have a basic understanding of how we actually hack the 3DS, and hopefully I will have answered a lot of questions that may be in your minds.
There are nearly zero pre-requisites needed for this guide, since I have tried to explain everything either through parenthesis or through foot-notes. However, if you have a decent amount of computer knowledge you would be many steps ahead.
The people who fall into this category are the people who can install Arch linux without issues on their computer. What I mean to say is that if you have questions in your mind along the lines of "What is FAT32?" or "What does 'cutoff' mean when someone says that a processor can only access a certain part of RAM?" or "What is a service?" or "What's a function in a program?" you aren't in this category. But this isn't bad! It just means that you may have to re-read some parts of the guide a few times to get the point I'm trying to make.

Also, if there is some part of the guide that doesn't make sense, then [B]I am doing something wrong.[/B] Let me know and I'll look into fixing it up.

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

[CENTER][h][B][SIZE=6]3DS HARDWARE AND SOFTWARE[/SIZE][/B][/h][/CENTER]
[B][SIZE=4]Hardware[/SIZE][/B]
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 a lot of different areas (FCRAM, AXI WRAM, ITCM, SoC memory, etc.), but it boils down to 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.

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 OTP region is a region in the SoC[sup]4[/sup] where the console-specific data is located at. From this console-specific data, you can generate keys which are going to be console-specific. These console-specific keys are important for decrypting many things on your 3DS, for example decrypting the NAND.
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 which are integrated in the ARM9 die (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, BigBlueMenu 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). The 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 of CIAs, 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.

[CENTER][h][B][SIZE=6]HACKING THE 3DS - GETTING ARM9 ACCESS[/SIZE][/B][/h][/CENTER]
Now we get to the real meat of the story. So what exactly are we trying to do when we say "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[sup]10[/sup], we need to access to the 3DS' storage, the NAND.
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 is one of the most popular ways of hacking 3DSes (I explain NTRBoot later on...)

First of all, Soundhax is just the userland exploit. You can't really do much in userland, if your end goal is to install boot9strap. Our end goal is to get ARM9 access. And good news, there is an ARM9 exploit, it's called safehax!

Safehax is actually an old exploit from 2013.
The old exploit, called firmlaunch-hax, took advantage of the fact that during a FIRM launch, 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 without noticing that that region of RAM was overwritten with a hack payload. And we got our ARM9 code execution.
But what is a FIRM launch? To understand this, you first have to understand how the 3DS firmware is split up.
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 through GBA Virtual Console, AGB_FIRM is loaded. Whenever you are doing anything else, NATIVE_FIRM is loaded.
A FIRM launch is essentially changing from one FIRM to another (e.g. you go from NATIVE_FIRM to TWL_FIRM), and during a FIRM launch, the ARM9 is vulnerable to firmlaunch-hax.
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].
For a more detailed explanation, refer to [URL='https://gbatemp.net/threads/how-does-the-11-2-arm9-exploit-work-for-dummies.457645/']Swiftloke's safehax explanation.[/URL]

So now we just learned that safehax requires K11 access, and we are in luck, because there is an exploit that can give us K11, it's called [U]udsploit[/U].
udsploit works by a curious hardware flaw of the 3DS.
The 3DS' GPU has access to a certain part of RAM (because a graphics card needs memory). However, the GPU is wired up to much more more memory than it should be wired up to. It is connected to the entire 3DS' memory in fact.
When you have a userland exploit, you have entire access to the GPU (because games use the GPU to draw graphics on the screen), and with access to the GPU, you can "render" (really we are copying not rendering) data to the GPU's RAM, which in this case, is also main memory. Once you copy over data to the main memory with the GPU, the ARM11 kernel will get this code and it will run it, because it stills thinks it's running whatever piece of software it was running before. This exploit of getting the GPU to render to the main memory is called GSPWN (From the system module [URL='https://www.3dbrew.org/wiki/GSP_Services']GSP[/URL])
For example, if you had a copy of Ocarina of Time 3D, and you used the userland exploit in that, the 3DS wouldn't know that you are in the homebrew launcher, it would still think that you are playing OoT. And if the 3DS gets a request from the GPU to "render" something, it will obey since it thinks it's running an innocent OoT game[sup]19[/sup].

If you are in the homebrew launcher, this means that you were able to get userland code execution. In order to elevate from userland to K11 you will have to use the GSPWN exploit.
However, the GSPWN exploit was sort of fixed with a special register. The GSPWN exploit is essentially a hardware exploit (since if you wire up the GPU to the RAM then it is an unfixable exploit), [B]BUT[/B], you [I]can[/I] program the 3DS so that it only allows a certain part of memory to be used by the GPU. It is set by [URL='https://www.3dbrew.org/wiki/CONFIG11_Registers#CFG11_GPUPROT']a special register in a configuration[/URL], and you cannot change this register from userland.
There is way of configuring this register though. The 3DS' WiFi module has access to this register, and by using our userland access to use the WiFi module, we could reset this config register and then the GPU would have entire access to the memory. Once we have entire access to the memory, we can do whatever we want with the ARM11 kernel and write whatever code we want to the memory so that it gets executed by the ARM11 kernel. And this exactly is the reason why you need to have the WiFi enabled, it's so that you can set this register that allows you to do the GSPWN exploit!

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 header 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.

[CENTER][h][B][SIZE=6]WHY THE 3DS NEEDS TO BE HACKED ON EVERY RESTART - THE NEED FOR A COLD BOOT EXPLOIT[/SIZE][/B][/h][/CENTER]
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. We can patch out signature checking, we can do custom modifications to the system, essentially what most people want out of a CFW.
Here's the issue though, every time we reboot the 3DS, all of our work gets erased (because RAM gets cleared 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] or rxTools 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 unsigned game you would have to run the 3 hacks in a row and go through a lot of time in order to get 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 explain how digital signatures actually work.

[CENTER][h][B][SIZE=6]RSA DIGITAL SIGNATURES[/SIZE][/B][/h][/CENTER]
[B][SIZE=4]The basics[/SIZE][/B]
[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 algorithm, which means that we can encrypt something with a public key, but only decrypt it with a private key, or the other way around, we can encrypt something with a private key, and only 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:
[ul]
[li]If you enter the same thing in this function, you will always get the same gibberish[/li]
[li]No two inputs give the same gibberish[/li]
[li]You cannot reverse the output to get the input, it is impossible[/li]
[/ul]
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:
[ul]
[li]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)[/li]
[li]Then, you take your private key and encrypt that hash[/li]
[li]The encrypted hash is now the [B]signature[/B][/li]
[li]You send to the recipient the signature (the encrypted hash), the piece of data, and your public key[/li]
[li]Once the recipient receives your letter, he  hashes the message[/li]
[li]The recipient decrypts the signature with your public key and gets the decrypted hash[/li]
[/ul]
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, [B]or[/B] he can also try to brute force a perfect signature which when decrypted using the public key will give a desired hash. There is no other way to forge your signature, unless... you don't implement the RSA algorithm properly.

See, when a computer program goes and reads a signature, it actually reads this:

[CENTER][IMG]https://image.prntscr.com/image/RXgXCwlNQHeQ2-55nD3r4g.png[/IMG][/CENTER]
That above, is an actual RSA signature. We generate it by taking the piece of data we want to sign (In this case, the 3DS' NAND header), hashing it, and encrypting it.
You may notice however, all these "ffffffff" that are taking up the majority of the space here. These "fffffff" are called [B]padding, [/B]and the reason why we use padding is quite simple.

[spoiler="What is padding?"]
See, in the end, a signature is just a number. In order to encrypt something, we do the following exponential operation:

[CENTER][IMG]https://image.prntscr.com/image/CQoczPqYRJGsQNhc16sc1A.png[/IMG][/CENTER]
Where [B]c [/B]is the data you want to encrypt, [B]d [/B]is the private key and [B]n[/B] is the public key (the product of the two primes)
If you remember, there is this following property of exponentials:
[CENTER][IMG]https://image.prntscr.com/image/vCwGCbOOQ6W3xnyg3tWHiA.png[/IMG][/CENTER]
From these 2 facts, we can create our own encrypted messages without knowing the private key. For example, if you have an encrypted message [B]A[/B]:

[CENTER][IMG]https://image.prntscr.com/image/sHf3FZGvQjO9s8enfc16kw.png[/IMG][/CENTER]
And also, another encrypted message [B]B[/B]:
[CENTER][IMG]https://image.prntscr.com/image/yc5K0yJATyqjTDXtj7-uyA.png[/IMG][/CENTER]
Then you can find what [B]AB[/B] is equal to:

[CENTER][IMG]https://image.prntscr.com/image/AFjomIX2Q4CkBRdBK741Bw.png[/IMG][/CENTER]
And be sure that [B]AB [/B]will be regarded as a legitimately encrypted message, since the match checks out.

This is a big problem for our signature! What can we do?
Well, we... could add some gibberish in the signature, making it so that the signatures can't be fabricated with the math trick above. And this exactly, is called [B]padding[/B].
We add some gibberish (in this case, the "fffffff"s sprinkled in), and this bypasses the big problem we had. Problem solved!

[/spoiler]

Now, you don't need to know the nitty-gritty details about all of this, but in order to understand the ingenious trick behind sighax (I'll get to what it is in a bit), you need to understand a few basic things.
First of all, the signature is read from left to right, top to bottom. We have a pointer that is similar to the pointer you get when you type something on a computer
[CENTER]
[IMG]http://blob:http://imgur.com/f01a6b4c-153c-4348-bac1-e5c30ceae7f1[/IMG] [IMG]https://media.giphy.com/media/3ohhwgsIzf8B0AtusE/giphy.gif[/IMG][/CENTER]
Now this cursor, goes, from left to right, top to bottom as I have said. For example, here is the signature block I posted being parsed:

[CENTER][IMG]https://media.giphy.com/media/3oKGzneYJiY0KUCvVC/giphy.gif[/IMG][/CENTER]


What happens here, is the parser [sup]17[/sup] reads every single byte (a byte in this context meaning a pair of characters, so we start with the [B]00[/B] and we continue on to [B]01 [/B]and [B]ff[/B] etc.) one by one[sup]18[/sup]. And as the parser goes along, it reads every single byte and checks it to see if it is a correct one or not (Don't worry, I'll explain in a bit)


[CENTER][h][B][SIZE=6]SIGHAX EXPLAINED[/SIZE][/B][/h][/CENTER]

So what is sighax? Good question!
Sighax is a bootROM exploit that allows us to sign our own firmwares. But how does this exploit work? How is it even possible? Aren't signatures encrypted with the private key and decrypted with the public key?
Well, we're going to go through this step by step, so stick to me and it will make sense.

[SIZE=6][B]How a signature is parsed:[/B][/SIZE]

Let's start by looking at the signature with which the NAND is signed:

[CENTER][IMG]https://image.prntscr.com/image/RXgXCwlNQHeQ2-55nD3r4g.png[/IMG][/CENTER]
Whenever you turn on the 3DS, the bootROM has to make sure that the signature is indeed legit. It does this by parsing the signature byte by byte.
First of all, it reads this [B]00[/B] at the start. This declares that we are about to start a signature.
After that, it finds this [B]01[/B] value. This value, called [B]padding type[/B], declares whether padding will exist in this signature or not, [B]01 [/B]meaning "Padding will follow" and [B]02 [/B]meaning "Padding will not follow".
If you read the math spoiler above, you would know that this should always be set to [B]01, [/B]since this increases the security of signatures dramatically. But... Nintendo, for whatever reason, decided to allow us to just use the [B]02 [/B]value if we want, and the bootROM has no objections to that.

Already we have a major problem! You should never allow people to write signatures without padding, as you can brute force signatures [B]a LOT [/B]easier!
We don't know why Nintendo did this, but the fact of the matter is this: You can disable padding in signatures.
Now, OK, this is... very big indeed. But still, a signature is a signature. The fact that you can skip a padding scheme may help in brute forcing a signature, but it doesn't magically erase the fact that a brute force effort must take place (If you want to brute force a signature).
So, let's move on:

If you set this byte to [B]01 [/B]you will make the bootROM check all of that padding, and make sure it is all "fffff". If you don't, it will just skip along. In both cases however the bootROM will keep reading until it finds this [B]00 [/B]byte at the end. Once it finds this [B]00 [/B]byte, it says "OK, I parsed all of the padding, now we will continue on to the other important bits"

The next few bytes aren't really that important for us. The [B]30[/B] byte must always be set to [B]30, [/B]and it does some minor thing. The [B]31 [/B]is completely ignored  (Nintendo ¯\_(ツ)_/¯ ), and this other [B]30 [/B]must always be set to a value of [B]30[/B].
After that, we get to the good stuff.
This [B]0d[/B] value (in lime green) is the most important value in the entire signature, and I'll tell you why:

This [B]0d [/B]value, tells the parser how long the next value is going to be (The washed-out lime color, [B]060960...[/B]). But here's something funny: The parser completely skips this next value!
This value that follows the [B]0d [/B]is called [B]inner block data, [/B]and it is supposed to tell the parser which type of hashing algorithm was used. We all know we are using SHA256, and the bootROM expects the signature to use this hashing algorithm for the hashing process, and the bootROM never reads this value!
When the bootROM never reads a value, it completely skips it. This means that I can, for example, add a 5, so the parser will know the length of [B]inner block data [/B]is 5, and it will skip 5 bytes (5 pairs of characters, 10 characters). Or I can type [B]0f[/B] and it will skip exactly 15 bytes [SIZE=4][COLOR=#ff0000][B]*[/B][/COLOR][/SIZE]. Note that this value can only be written as hexadecimal, i.e in 0x00 form (Numbers in base 16).
Here's what the parser does when it sees this value:

[ul]
[li]Firstly, it comes to the byte which declares how many bytes the next value is going to be:
[CENTER][IMG]https://media.giphy.com/media/3ohhwnZayJt016WgQU/giphy.gif[/IMG][/CENTER]
[/li]
[li]Then, it reads this value. In this case, [B]0d[/B] in hexadecimal means [B]13[/B] in base 10. This means that we will skip 13 bytes, or 26 characters (Since a byte is a pair of two characters)
[CENTER][IMG]https://media.giphy.com/media/3o7aCREOl8HjYn9dbW/giphy.gif[/IMG][/CENTER]
[/li]
[li]Then it does the skipping process...
[CENTER][IMG]https://media.giphy.com/media/l1J9DH1kYsut59xLO/giphy.gif[/IMG][/CENTER]
[/li]
[li]And it continues on normally the parsing process.[/li]
[/ul]

If however, you were to modify this value: Instead of [B]0d [/B]you modified this to, for example [B]0f[/B], you would skip 15 bytes instead of 13. So in total 30 characters:

[CENTER][IMG]https://media.giphy.com/media/3oKGz8EaoTu8JCfExq/giphy.gif[/IMG][/CENTER]

OK, so we can skip any number of bytes we want, essentially moving the pointer to whatever point we want. This is cool and all...  but we don't have a use for it (...yet).
Let's just finish explaining the parsing process before we move on to sighax and its skipping trick.

We left off at parsing [B]inner block size[/B] and [B]inner block data[/B], so naturally, we continue on parsing normally.
After that follows a [B]04 [/B]and [B]20[/B] that tell the parser some information, but the parser skips these values as well.

Now [I]finally [/I]we get to the finishing part of the signature, and this is the hash. As you already know, the fundamental idea behind a signature is a hash comparison.
You have one hash which you encrypt (Called the [B]correct hash[/B]), and one hash which you calculate on the spot (called the [B]calculated hash[/B]), and if those two hashes match, then the signature is legit.

After the final [B]20 [/B]byte is the [B]correct hash[/B].
What the bootROM does when it gets to this part, is it [U]jumps ahead[/U] to the next hash, which is the [B]calculated hash[/B].
Once the pointer is at the start of the [B]calculated hash, [/B]the bootROM hashes the NAND i.e. it generates a new hash right there on the spot, then it overwrites whatever hash would have been there.
Afterwards, it compares this newly created hash with the [B]correct hash[/B], which is located directly above. If the comparison goes well, and the two hashes are identical, then the signature is 100% legit.
If they don't match, then the signature is not legit, and the bootROM will refuse to load the NAND image. If you were to install any hacks in the NAND, then the calculated signature would change, and then the comparison would fail, and you would be forced to try to find another signature which, when decrypted, would give you this desired hash of a modified NAND, something which is pretty hard to do.
You'd have to brute-force a signature, which, when decrypted with the public key, would give the desired hash in the [B]correct hash[/B] field.

[B][SIZE=6]The trick[/SIZE][/B]

Did you notice the big [B][SIZE=5][COLOR=#ff0000]*[/COLOR][/SIZE][/B] that I put above?

"When the bootROM never reads a value, it completely skips it. This means that I can, for example, add a 5, so the parser will know the length of [B]inner block data [/B]is 5, and it will skip 5 bytes (5 pairs of characters, 10 characters). Or I can type in [B]0f[/B] and it will skip exactly 15 bytes [SIZE=4][COLOR=#ff0000][B]*[/B][/COLOR][/SIZE]. "

It's because it's here where we do the magic for sighax.

Think about this: You can move the pointer wherever you want thanks to the [B]0d[/B] value, and you also brute force a signature (given enough computational power) which when decrypted with the public key will give you your desired layout of all the bytes. What can we do with these two facts?

Well, what we [I]can[/I] do is shift the signature, so that the [B]correct hash [/B]is in the location for the [B]calculated hash, [/B]thereby making it so that the [B]calculated hash[/B] and [B]correct hash[/B] overlap. Now, why would this be useful?

We can change the [B]0d [/B]value so that the pointer is moved right at the start of the [B]calculated hash, [/B]which also happens to be the start of the [B]correct hash[/B] (since the two hashes now overlap). Now, when the bootROM goes ahead and does its overwrite procedure for generating the hash (for the comparison), it will overwrite not only the [B]calculated hash[/B] but also the [B]correct hash[/B].

So now, when it overwrites the [B]calculated/correct hash[/B] with the newly generated hash (which it does on boot), it will compare the [B]calculated hash[/B] with the [B]correct hash.[/B]
However! Since the [B]calculated hash [/B]and the [B]correct hash[/B] are in the same location, it would just compare this block to.... itself... right? And this will always... succeed...
And this exactly is the ingenious trick behind sighax! [B]This[/B] is how we can sign our own firmwares, and exactly [B]this[/B] is how we can have a hack on coldboot!

So now that we can sign our own firmwares, we can install whatever hack we want to the NAND. We essentially can do whatever we want with our 3DS.


[CENTER][h][B][SIZE=6]SO WE HAVE SIGHAX, NOW WHAT?[/SIZE][/B][/h][/CENTER]

Now that we can sign our own firmwares, we can write anything to the NAND and it will always be accepted by the bootROM. And we are essentially finished!

Boot9strap is installed to the NAND with [URL='https://gbatemp.net/members/d0k3.29073/']d0k3[/URL]'s SafeB9SInstaller, and with that we have a coldboot hack that is executed by the bootROM on cold boot. Boot9strap's overall goal is to load a boot.firm file from the SD card, and that boot.firm file can be whatever you want. CFW, a Nintendo FIRM, or even your own OS written from scratch.

However! Boot9strap is [B]a lot more[/B] than just injecting the NAND with code that loads a custom firmware from the SD card and then signing it with the magic sighax signature. Boot9strap is a whole piece of work on its own, and it can [U]dump the bootROM of your 3DS.[/U]
The details of what it does are out of the scope of this writeup, however I may look into writing another guide to explain it. The main take-away point is that it loads a [U]boot.firm[/U] file from the SD card.


[CENTER][h][SIZE=6][B]BUT WAIT, WHAT THE HECK IS NTRBOOT?[/B][/SIZE][/h][/CENTER]

Ah, NTRBoot is a special case of installing CFW.

When Boot9Strap was first released and the bootROMs got dumped, people looked through the bootROM code and discovered something quite peculiar.

Whenever your 3DS turns on from cold boot, the bootROM checks to see if a special key combination is being held down, the [B]START + SELECT + X + LID CLOSED[/B] combination. If it is checked and it is being held down, then the bootROM will try to boot from a DS cartridge, kinda like how your PC can boot from a DVD drive to install Windows. The catch though, is that the firmware that you will put on the DS cartridge must be signed as well. With sighax however we can just sign it easily.

This allows us to make a malicious DS cartridge that can give us code execution, and ARM9 code execution at that, giving us an incredibly powerful entrypoint into the 3DS, which is [B]unpatchable[/B] on top of all that!


[CENTER][h][B][SIZE=6]CONCLUSION[/SIZE][/B][/h][/CENTER]


I hope that this writeup has made sense to you. There may be a number of mistakes, and I am doing my best to find them and fix them. I am also requesting that any developers reading this to correct me on the technical details, as my goal is not to spread misinformation.
If anyone reading this has any questions, please, send them to me. The feedback that I have gotten over the past months from the readers I have asked has been overall positive, which worries me as I haven't had any negative feedback at all.


Apart from that... thanks for reading! I hope that I have helped you gain a basic understanding of the 3DS.


[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] SoC stands for System On (a) Chip. It is where all of the processing hardware for the 3DS is located at.
[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 machine code was in the bootROM, not the actual source code. However, you can disassemble the machine code into assembly, reverse engineer it, and then get the "source code".
[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 on coldboot, but in a method very different to Boot9Strap's. I will not go into details as it is now history.
[sup]17[/sup] A parser is the computer program that reads a piece of data and converts it to something that it can understand
[sup]18[/sup] I know the developers are most likely cringing and writing hate comments, but this isn't some university lecture. This is a post on an online forum trying to explain to people, in simple terms, what sighax is.
[sup]19[/sup] It's important to note that there is no DEP here, so we don't have to worry about using ROP.