Hacking The 3ds I: Introduction

Posted on 5 mins read

Hello back!
Today, a new series begin. A “journey” into hacking the Nintendo 3DS Handheld Console starts. There are several reasons why I am going to do this series;

  • Personal Interest. During the later 2014, the 3DS Scene started growing. I was there, and was told I couldn’t get anything.
  • The obnoxious sceners and community, only working for fame and personal interest.
  • The lack of information and documentation about hacking blindly (Which is basically what I’ll be doing here)
  • Exploit development is exciting and challenging

Introduction

Before doing anything, we need to know what is inside the 3DS. The inner hardware is what defines how the software works. In a first moment, we would open the console and look at the chips to identify them. This is mostly the work of hardware hackers. The Old3DS has this specs (from 3dbrew):

  • 128mb (2x64) of RAM (FCRam)
  • "DMP PICA" GPU
  • 6mb of VRAM (Video RAM, This is a dedicated RAM for the GPU)
  • ARM11 2x MPCORE at 268MHz
  • ARM9 46 at 134MHz
This are the most important pieces of hardware that we should have always in account. For extended details and New3ds information see this

In this series, I'll be talking about the MSET Exploit. Again, back in the late 2014, the Gateway Team released the Gateway 3DS Cartridge, which allowed piracy on 4.1 to 4.5 firmwares. They used an exploit on the DS Profile menu in the 3ds settings which then loaded further code from the Launcher.dat file on the SD Card. Some people were able to reverse their Launcher before they implemented more strong obfuscation, but this still was and is a seriously difficult task. My aim is to gain code execution using this exploit without reversing others' work, just by myself and my investigations, as if there were no public information (and actually there's not much information available, and obviously not documentation).

Thoughts

So basically, we have no information about anything. We are working with what is often called a "Black Box" system. The first step is hardware hacking; Is the only thing we have access to so we must start working there. Hardware is more complex with every passing day. This means that I can't do anything here by myself. Usually a career in electronics or related helps, but unfortunately until a few years ago there wasn't much information available. Sadly most people don't share their investigations publicy (for good reasons often, like avoiding legal problems or encouraging piracy). So unless you find someone with the same hardware you have and interest in hacking it, you are screwed. This is the most common scenario in console hacking, there's no public scene because those discoveries are private and only shared with certain people, otherwise the security holes would be patched quickly.


As for now, lets assume we are skilled enough to perform any of the possible hardware attacks. What shall we do first?
We must look in the different data sources in the hardware and decide if they are useful for us. For example, The 3ds has the following:

  • NAND Chip
  • SD Card
  • RAM Chips
Let's start with the NAND. In the 3ds, this is a 1GB samsung storage unit. So investigating it's datasheet and experimenting, we would eventually be able to dump its contents, as explained in post 4(IV). If we would analyse the dump carefully, we could try the following;

  • Find Strings: Such as user data, menu's text, etc..
  • Find structures or patterns: such as MAGIC signatures/numbers, headers' information (i.e. ELF), etc...
  • Modify the dump: Try modify any byte at the dump and restore it to the chip. See if it boots or it raises any error.
  • Restore another NAND dump, gotten from another unit (not the same console).

For the 3ds, the result for each test are:

  • Can’t find any string
  • Can’t find any known pattern, signature or magic.
  • Errors when we restore a modified NAND dump. May be encrypted, signed or both
  • Errors when we restore a foreign NAND dump. May be signed with unique keys per console.
So we can lead to the conclusion that the NAND is somehow encrypted, signed, or both.

Let’s move on to the next possible entry-point, the SD card. It is accessible from a PC and we can browse the files. We could try to:

  • Identify what kind of files we have. It can have content such as, pictures, videos, music, titles (applications or games), exdata(extra data), others.
  • Identify which of the things above are signed or encrypted. Try modifying them and see if they still work. Multimedia is likely going to be clear data, but titles, exdata and everything else is probably going to be, at least, console signed.
  • Try to exploit the multimedia managers. Use fuzzers to create multimedia files and try loading them. You may find crashes, and who knows, maybe an exploit, like “soundhax” which was found a lot of years later.
Sadly, this is very difficult at this point when we know little - if any - details of the system.

And our last option, the RAM. We would need a working hardware set-up that would allow us to dump the ram (see scanlime set-up above). This has been done in the 3ds by some hardware hackers, but the ones who did it did not release much details, and likely sold the work for money, so it is not available to the public ;). Assuming we have dumped the RAM, let’s proceed to analyse the dumps. We would try, but not only, the same ideas as for the NAND chip. In the 3ds, we find that RAM contents are not encrypted! We can, in fact, find strings from menus (most of them in unicode).

Conclusion

Analysing the RAM requires a whole article or two; I will be using some new techniques which may lead to code execution, and definitively, there’s going to be a lot of static reverse engineering.

I hope you enjoyed this post. If you consider any suggestion/correction, message me at twitter or mail me.

comments powered by Disqus