DSiWare System transfer hackingYou may have read the installing boot9strap (dsiware) page over at 3ds.guide. The general gist of the method is that you get 2 3DSes (one of them has to be hacked), buy one DSi game on the hacked 3DS, do something wonky with GodMode9 on the hacked 3DS, system transfer from the hacked 3DS to the unhacked 3DS, and then you run the DSi game on the unhacked 3DS and suddenly you have Luma on it.
What is actually going on?
What is actually going on?
But there are so many things that are going on! The DSiWare guide is the biggest guide on 3ds.guide, there are many precautionary steps, so many ifs and buts everywhere! And yet, there's not a whole lot of explanations for all those things.
What I hope to achieve here is to explain what is actually going on with the DSiWare method. This is the most complicated method on the guide, and the one that has the highest chance of failure, and the fact that there are no explanations everywhere may be a contributing factor.
So, without further ado, let's jump straight in.
The actual theory behind the hack is quite convoluted, as it is not just a single exploit that is being used here, but rather, a whole series of exploits chained together.
THEORY BEHIND THE HACK
There are 4 exploits that are used:
Let's first start off with sudokuhax. Sudokuhax is an exploit for the DSi that allows you to run homebrew on your DSi, by exploiting sudoku's (a DSiWare game by EA) bad save handling. The concept is that you download sudoku onto your DSi, and then you take the SD from your DSi1 and plug it in your PC. You then run some software on your PC that will inject a custom save to the game that's on the SD card, and then you insert that SD in your DSi.
Now, when you go ahead and try to run that game on your DSi, instead of actually booting up a game of sudoku, the app will instead load and execute homebrew that's on the root of your SD card (a file named boot.nds to be exact).
Now, this is neat an all, but what does this have to do with the 3DS? See, the 3DS' eShop also had sudoku available for purchase. You could download sudoku from the eShop, follow the same instructions of putting the SD card with the DSi game in it to your PC and injecting the save, and you would have sudokuhax on your 3DS!
Unfortunately, this was only possible on 4.x firmware. After 4.x, you couldn't simply put the SD card in your PC and do the injection. You actually had to have your 3DS hacked already with some sort of exploit (the old ones from back in the day) and do some trickery with dumping and decrypting to be able to inject the haxx save into sudoku.
But, why even bother with all this to get sudokuhax on your 3DS, if your 3DS is hacked already? Well, there was no reason to, which is why it wasn't that popular.
The 3DS' NAND (NAND is the hard drive of the 3DS), contains essentially everything about your 3DS. The operating system, the system configuration, etc. However, it's not simply just one folder that contains everything, it's actually split up into many partitions. Arguably, the most important partition would be the FIRM partition.
The FIRM partition(s)2 contains the fundamental code of the operating system. As you may know, the 3DS has two processors; the ARM9 and the ARM11. (I highly recommend reading this guide to get a better understanding of how the 3DS works and what all this means)
The FIRM partition contains what code those two processors should run once they are turned on from coldboot. This means that this is going to be code that runs in the background, and does silent operation for the operating system. Things like network handling, signature verification, process managing, graphics, etc.
Also an important thing to note is that the entire NAND is encrypted. A dump of your NAND is just a huge binary blob of encrypted data, which means if you somehow got access to said dump you wouldn't be able to do anything to it............ or could you?
There's actually a really powerful exploit that allows you to modify the FIRM partitions of an encrypted NAND, and it's called FIRM known-plaintext.
The way this works, is that if you know what the specific portion of the FIRM partition looks like unencrypted, you can write modifications to it!
For example, say you had a NAND dump of a 3DS, and you wanted to install a hack to it. As you know, the entire file is encrypted, meaning that you can't write to it anything.
However, what if we were to use the FIRM known-plaintext exploit to try to write something to it? Specifically, we are targeting the FIRM partitions (because that's where the operating system resides). Now, can we use the FIRM known-plaintext exploit here? You need 3 key things to use this:
- We must know what the content looks like when it is unencrypted. Since we are targeting the Firmware of the 3DS, the actual operating system, we actually do know what it looks like unencrypted. All 3DSes share the same firmware (only O3DS/N3DS differ), same way that a lot of computers across the world share the same operating system (Windows for example). So, what you could do is get a hacked 3DS, and with the access that you have, you can decrypt and dump the firmware of it and store it somewhere. Now, you have a reference of what the firmware looks like unencrypted, and now you have fulfilled the first criteria of using the FIRM known-plaintext exploit!
You could also share this knowledge that you obtained with other people online; The guide has torrent links to all the decrypted FIRMs for all the versions of the 3DS over at the hardmod page, meaning that you can do this for any version of the firmware
- We must have some sort of access to the FIRM. I'll explain this in the next entry for this list of exploits, but suffice it to say we have fulfilled this criteria as well
- We must have something to write to the FIRM. This is obviously the easiest part; what we are going to write to the FIRM is boot9strap, the actual hack we need to, well, hack our 3DS.
DSiWare games have entire access to the NAND
DSiWare games have entire access to the NAND of the 3DS. This means that if you somehow got code execution through DSiWare (for example, with sudokuhax), you could read and write to the entire NAND however you wanted. However, the NAND that you would have access to would be entirely encrypted, so this wouldn't be all that useful. Remember though that we have the FIRM known-plaintext exploit, which allows us to write to the FIRM partitions, even if they are encrypted (if we know what they look like in plaintext)
DSiWare app contents not verified
DSiWare app contents are not verified in a system transfer. This means that you can essentially write anything to them, and they will be system transferred without issues, granted they have a good digital signature. If you don't purchase them legitimately from the eShop, they will not have a valid digital signature, and they will not be system transferred.
We have at our disposal these 4 exploits. How could we bring these together to install boot9strap on an unhacked 3DS? Well, the theory is actually quite simple.
HOW IT'S BROUGHT TOGETHER
First of all, we begin with the sudokuhax exploit, and we already hit a roadblock.
Sudoku, the actual game that is vulnerable to sudokuhax, has been removed from the eshop! It has been instead replaced by another version of sudoku that is not vulnerable to the sudokuhax exploit. What could we do now?
Well, you could do a thing called game injection. The concept is that you take a normal DSiWare game, and then you take a copy of sudoku (the vulnerable sudoku that is), and then you replace the contents of the original game with sudoku. The end result is that you have the original DSiWare game, which seems untampered if you look at it from the home menu, but if you launch it you will instead be greeted by sudoku.
This way, you can have nearly all DSi games on the eShop be suitable candidates for being used as a DSiWare haxx game. However, the game must be bigger than or equal to the size of sudoku, otherwise, sudoku won't fit, and system transfer will detect this and will not transfer the DSiWare game.
Note: If you already have the vulnerable version of sudoku, you don't need to worry about doing any kind of game injection, you only have to worry about save injection. That is why there are 2 different guides on 3ds.guide, for DSiWare Game injection and DSiWare Save injection.
Armed with this information now, you may have noticed that the guide has been providing torrents for people to pirate sudoku. Since you have to have the sudoku game to inject it into your normal DSiWare game, and the vulnerable game is not available for download anywhere (at least officially), the only way to download it to do the injection now is to, well, essentially pirate it. Just a sidenote, but an interesting one nonetheless.
Now that we have sudokuhax back in action, we can actually plan a very interesting route of attack to get CFW. The plan is as follows:
- You get a hacked 3DS, and you download a normal DSiWare game (that's bigger than or equal to in size to sudoku)
- You inject sudoku into this normal DSiWare game
- You then inject the sudoku haxx save into the sudoku game
Well, what if you system transferred this game onto another 3DS? Remember, DSiWare games have entire access to the NAND, and paired with the FIRM known-plaintext exploit, you can write boot9strap to the FIRM partitions. Also note that tampered DSiWare games will be accepted by the system transfer, as system transfer does not verify DSiWare app contents.
And that is what we do! We system transfer this malicious game onto another 3DS that is unhacked. So we continue on as follows:
- You system transfer from your hacked 3DS with the sudokuhax game to an unhacked 3DS
- You run the DSiWare game on the unhacked 3DS
- The DSiWare game uses the FIRM known-plaintext exploit to write boot9strap to your unhacked 3DS
- You have now successfully installed boot9strap on your 3DS
However, a lot of people who do use this exploit don't seem to understand what is going on with the whole NAND backup/source 3DS/target 3DS/NNID/7 day waiting period at all. Let's try to explain how a system transfer actually works.
A 3DS System Transfer is the official Nintendo method from transferring data (games, saves, NNID, photos, everything) between two 3DSes. You can system transfer between O3DS --> O3DS, O3DS --> N3DS, but you cannot system transfer from N3DS --> O3DS.
3DS SYSTEM TRANSFER
What needs to be explained first is movable.sed
movable.sed is the encryption key3 your 3DS uses to encrypt the contents of its SD card.
You might wonder why would the contents of the SD card be encrypted. Well, the answer is simple; Anti-piracy.
If the contents were not encrypted, you could for example buy one game on one 3DS digitally, and then share that same SD card around multiple 3DSes and share the game. Now, you may be thinking that this is exactly the thing that you are allowed to do with a game in cartridge form, and you would be right. This is just another Nintendo decision that may baffle some minds, and it wouldn't be the first one. The fact of the matter is this however, your SD card contents are encrypted with the movable.sed key.
Now, the important thing to note here is that this key changes upon a System Format. This is also the reason why leaving the SD card in your 3DS while doing a System format will have it formatted; It's because after the format, the contents of the SD card are useless (because movable.sed changed).
A Nintendo Network ID is the account you use to log in to the eShop and buy games, kinda like you have a Steam account to log into Steam and buy games. The NNID is also used for some other things like online games, and was used for things like Miiverse (R.I.P.)
When you buy a game from the eShop, the 3DS will connect to Nintendo's servers and write to that NNID that you purchased the game.
Now, in e.g. Steam, if you buy a game on one PC while logged in, you will be able to log in another PC with the same Steam account and download the game there. Not with NNID though. With NNID, you are tied to the 3DS system that the NNID was created on. You cannot log into an NNID that was created on another 3DS from another 3DS.
So you have 2 keywords to note here: Logged in/Logged out, and Linked/Unlinked. You can log in and out of an NNID on a 3DS (the 3DS that the NNID was created on), and the NNID will be tied to that 3DS.
The only ways to move an NNID from one 3DS to another 3DS is to call Nintendo/send them an email, or system transfer. There are no other ways to move an NNID.
The actual system transfer
A system transfer does this in a nutshell:
- Format the target 3DS completely, and format the target's SD card as well
- Make a carbon copy of the source 3DS onto the target 3DS
If you are system transferring from O3DS to O3DS or N3DS to N3DS, the 3DS will ask you to move the SD card from the source 3DS to the target 3DS. The 3DS will have taken care of movable.sed for you, so the SD card will be compatible.
If you are system transferring from O3DS to N3DS, the 3DS will ask not ask you to move the SD card from the source to the target, because the source and the target use different SD types, source uses a regular SD, while target uses microSD. And of course, you cannot insert a big SD into a microSD card slot. The 3DS will instead ask you how you want to proceed, either with wireless transfer or PC based transfer.
The wireless transfer works by wirelessly copying the entire contents of the source's SD card to the target's SD card, and this is painfully slow.
PC based transfer essentially prepares the source's SD card so that its contents can be simply dragged and dropped onto the target's microSD card.
Now, you could argue that the 3DS should ask the user if they are using a microSD to SD adapter in their source 3DS first, so that you can be given a 3rd option of moving the SD card, like you are when you are doing O3DS --> O3DS or N3DS --> N3DS, but Nintendo for some reason doesn't do that.
The way that the DSi content is copied, is not wirelessly from one 3DS' system memory to the other's. Instead, the DSiWare (with the injected game & save and all that), is copied to the SD card from the source's memory to the source's SD card, and then you move/transfer the SD card from the source to the target, and then the DSiWare is copied from the SD card to the target's memory.
After all this, it continues with the system transfer. In the very end, it formats the source 3DS and leaves the source SD card untouched, to be used with the target 3DS.
Source 3DS Recovery
Let's now explain this:
You can only system transfer between 3DSes once per week. After you system transfer, you will then be put on a 1 week cooldown.
Now, if you have prepared the DSiWare game on the source 3DS and are ready for the system transfer, once you are done, how will you recover the NNID?
The NNID will get unlinked from the source 3DS and it will be linked to the target 3DS. You will not be able to use the NNID anymore on the source 3DS, unless you move the NNID back from the target to the source.
In order to move back the NNID from the target to the source, you either have to system transfer in reverse (you have to wait the 1 week cooldown for this), or you can contact Nintendo and ask them to move back the NNID.
Also important to note is the NAND & SD backup of the source. When you make a NAND & SD backup of the source 3DS, you are essentially making a perfect image of that 3DS to be stored on your PC, which can be recovered back onto the 3DS whenever you want, whatever may happen to the 3DS. The NAND backup preserves any configuration that is in the 3DS, like logins, console-unique info (like the movable.sed), and much more. The SD backup preserves any games/saves/themes/home menu configurations that you may have had.
So you do the system transfer, the source 3DS gets formatted, and you want to recover it. You use the NAND & SD backup on the source, and the source 3DS is nearly recovered except for the NNID. And that is why you have this big ugly warning on the top of the page.
I hope I helped you gain a basic understanding of how the DSiWare system transfer exploit works. If you have any questions, or any improvements I should make, let me know! I'll try to get back to you as soon as possible.
Also, if there are any mistakes in the guide, tell me and I'll fix them ASAP. My goal here is not to spread misinformation.
1: Technically, the DSi does not store its DSiWare games on the SD card directly. It would instead store them on system memory, and offer you the option to copy those games onto your SD card from the system settings. So what you would actually do is copy the game to SD, and then do whatever you wanted to do with the game (that would now be on the SD card)
2: There are two FIRM partitions, and they are exact copies of one another. This is so that if something bad happens to the first partition, the 3DS can have something to fallback on (this is called recovery mode)
3: Technically, it's not just an encryption key, but for the purposes of this guide, we are only interested in the key part of this file
Last edited by MrJason005,