The Case of the 3DS Part 1: Brief History & Standings
The Nintendo 3DS has been fermenting for a while now, waiting for us to pour a glass of that sweet, sweet homebrew. Now, nearly a year and half down the track of the first publicly announced exploit, we have ARM11 code execution.
The following is a brief retelling of the public history of the 3DS being broken free of its shackles (almost completely).
A Glimmer on The Horizon
Mid December 2012 Australian console modification retailer OzModChips posted an image on Twitter showing a 3DS unit with both screens lit up, showing simply “WE HACKED IT!”.
They made a point to note that they did not have anything to do with the hack, they were simply the messengers.
This lead to a lot of excitement and suspicion around the internet as websites reacted to the news. Later the credibility of the find would be confirmed by scene veterans including Nemoid, Crediar and Yellows8, who would later explain that a save game exploit was responsible for gaining code execution.
The name of the game and the actual method however were not disclosed, because the exploit would limit users to User Land/User Mode and thus any homebrew would be limited to using assets of the system originally authorised for that game by the system. This also protected the exploit from being patched by Nintendo prematurely.
A Juicy Kernel (Vulnerability)
Later down the track reports would surface claiming that the veteran, Nemoid had managed to leverage a vulnerability within the system to gain kernel level control of the 3DS. This news claimed no hardware modification of the system and was later confirmed to use a save game exploit.
Again this secret was guarded from public distribution for fear that Nintendo could easily patch the vulnerability. Instead it was said to be distributed amongst a close circle of associates so that further experimentation could be carried out. This had a secondary effect of making sure the vulnerabilities had the opportunity to make it through to future firmware version.
Along Comes Gateway
Shooting forward through time to the end of May, 2013 information starts to surface about a new team going by the name Gateway 3DS. The claims state that they have a working “flash cart” for the system that allows users to use (illegal) ROM dumps.
To back up these claims, they also released a video showing the “flash cart” in action, running a dumped game (Luigi’s Mansion). The Nintendo piracy section of the internet was ablaze with furious excitement, while others who did not support piracy wondered curiously what would happen next.
As June flew by a lot of the eager faces started to become wrinkled with worry that the video was an elaborate hoax, and that the card would not come to market. Then, like a light at the end of the tunnel, an announcement surfaces in the first third of July stating that preorders were now being accepted through their international resellers and provided curious souls with a little more information on the product. The information mentioned the vulnerable firmware version (4.1 to 4.5) and that they will always plan to get the product updated to run on later versions of firmware, that there was a DS mode loader cartridge and a 3DS mode ROM dump cartridge, amongst other things.
The product saw several delays and prompted a lot of angst, but now nearly a year down the track, after a shaky release date issue, some drama over cartridge DRM (bricking) code and a few firmware revisions, here we are: Able to run our own homebrew.
The Chain of Command
You might be thinking, “That’s all good but how did they do it?”. Well, the explanation is complex and you could always do some research if you want to fully understand it. But the basic concept, in lay terms, is this:
A DS mode homebrew is executed which writes an exploit back to the ‘message’ section of the DS profile on the 3DS unit. This message is too long and causes the message to overflow, overwriting a section of memory. Sometimes, this can overwrite a return address (a location in the memory that tells the unit to move on to another section of code and run it).
In the case of the 3DS, the return address is known, so we are able to perform a ROP (Return-orientated programming) attack chain, or payload, injecting custom code in to the 3DS memory stack where it expects to execute the rest of the code it would normally execute.
In the case of the “flash cart” they are able to trick the system (via the ROP chain) into executing a loader that makes the 3DS treat the “flash card” as a normal 3DS game cartridge (or in later firmware, run some custom diagnostic code, and a ROM loader for the unit, as well as recently; the most exciting thing: Our own homebrew!).
So What About The Brew?
Prior to the latest Gateway 3DS firmware, reverse engineering work was done to deobfuscate (make less obscure, reveal the trick) that was being used to execute code, and around this (and other hard work), ARM9 homebrew tools were born.
Recently, our good friend 173210 announced and released his own ARM11 “Hello World” proof of concept, showing ARM11 code running from a loader like above. Others have also been developing ARM11 loader based code in tandem, with great results.
Now, with the most recent firmware by the Gateway 3DS team we are able to construct homebrew by using the talented Smealum’s ctrulib, to be run from the “flash cartridge” in a similar fashion to a commercial ROM dump.
But what is next and how do I get my hands dirty?
There’s much more pouring from the brewery, but let’s leave that for another day. If you want to know more, please stick around and wait for Part 2 of our series, “The Case of the 3DS”…