Table of Contents

Gateway 3DS History

Nowadays, no one is surprised by the ability to flash Nintendo 3DS. However, 10 years ago, when the Nintendo 3DS family of consoles was just beginning to gain popularity, no one had heard of "Custom Firmware" (CFW). However, a paradox occurred, called Gateway 3DS – a flash cartridge that essentially was CFW.

The Gateway cartridge marked the beginning of a long history of Nintendo 3DS hacking, which continues to this day.

Gateway logo

History

The first mentions of a full-fledged Nintendo 3DS hack (here implying that you can do something meaningful with the console, not just cause an error) date back to December 2012. It was then that Twitter user OzModChips posted a photo of a Nintendo 3DS console with the words WE HACKED IT! on the bottom screen.

Hacked Nintendo 3DS

But, as you understand, there is a huge gap between hacking a console and a ready-made product that an ordinary person can use.

However, the "gap" turned out to be not as wide as one might think. On May 30, 2013, a note appeared on the website www.gateway-3ds.com stating that the wait was over and the first backup device that would allow playing 3DS games would soon be on sale.

Gateway 3DS announcement

That is, it was about the Gateway 3DS flash cartridge.

On July 11, 2013, Gateway announced on their website that pre-orders for flash cartridges were opening. The developer also provided some details about the product:

1. The flash cartridge is launched using an exploit, so it is highly dependent on the firmware version;

2. The Gateway kit will consist of two cartridges: a red 3DS cartridge (for launching games) and a blue DS cartridge, which is intended for the exploit.

3. Work is underway to create an exploit for consoles with firmware 6.x+.

On July 29, 2013, the first shipments of cartridges began.

Now, the only question is, how did the Gateway cartridge work?

Exploit

Somewhere in 2012, a user named ichfly noticed a text field in the Nintendo DS profile editor (and the 3DS had full hardware and software support for Nintendo DS games) where a message could be entered, which later appeared in PictoChat. The length of this message was limited only by graphics. That is, there was a limited number of characters that could be entered.

Nintendo 3DS Nintendo DS settings

So what?

It turns out that Nintendo 3DS applications can interact with data from the Nintendo DS mode. In our case, the "System Settings 3DS" application reads data from the Nintendo DS firmware, which is stored somewhere in memory and has nothing to do with the 3DS. And it turns out that if you change this data from the Nintendo DS mode, the "System Settings 3DS" application will read the modified files.

Remember I mentioned above that the character length is limited by graphics? The developer didn't even think that this string could be accessed from another place. And if the user couldn't select a free window to continue entering characters because there were no such windows, nothing prevented doing it with a program located on an NDS flash cartridge.

In simple terms, it looked like this: if you manually entered a message (the process is shown in the photo above) and pressed the OK button, this value was simply added to memory without any checks. But memory itself is limited, so if it overflows, anything can happen. Including writing some code and forcing the console to execute it.

We don't need a graphical interface because it just replaces the text mode. It's like with the command line, we can open a program with a mouse by double-clicking on the icon, or we can open the command line and launch the desired program with text.

This is how MSET appeared - the System Settings 3DS exploit, which caused a stack overflow, allowing the execution of unsigned code.

Nintendo 3DS MSET exploit

The problem is that this exploit has a rather limited application. But it allows you to run code from another place.

It turned out that in the console's RAM there was a string "SYS:/Launcher.dat". Essentially, this was the address of the configuration file for Nintendo 3DS, which was used by the console for the Home menu. The MSET exploit replaced this address with "YS:/Launcher.dat", and the memory card address was just "YS:". Then the console tried to read another file located on the console's memory card.

The code located in the Launcher.dat file allowed dumping the Nintendo 3DS RAM. Then began a long and tedious work related to decrypting what was happening in the Nintendo 3DS memory and trying to understand how it reacted to changes.

And at the very end, the Gateway developers gained fairly full access to controlling what was happening on the console. As a result, the Launcher.dat file was rewritten to launch games and became the basis of Gateway cartridges.

It turned out to be a kind of nesting doll, where one exploit causes an error that ends with calling a file containing another (deeper) exploit and firmware patches that allow launching games.

That is, in essence, it was not a pure flash cartridge. After all, changes were made to the console's firmware, and nothing prevented the Gateway developers from making games launch from the console's memory card.

So why was the red flash cartridge needed? It's hard to believe, since we're talking about a device made for piracy, but they built a DRM system (digital rights management) into the red flash cartridge, designed to check that the red Gateway cartridge was inserted into the console. A kind of protection needed to ensure that the cartridge was still bought, and not just flashed the console (as is done now).

And if you thought that this was impudence on their part, then no! This whole story becomes much more fun if you know the continuation.

Madness

In October 2013, hacker Smealum presented a way to launch a copy of the console's firmware from a memory card. He called this function redNAND. Imagine that you start the console, but the operating system loads from the memory card. You can do anything with this firmware, since the original remains in the console's system memory. This made it possible to keep the system firmware at version 4.5, while its copy could be updated to any version, so that the console always remained up-to-date.

And in November 2013, clones of Gateway – R4i Gold 3DS Deluxe – began to appear en masse on the market.

R4i Gold 3DS Deluxe

And then it began.

The Gateway developers, of course, immediately stole Smealum's work and in early December 2013 implemented the new function into their cartridge's firmware (calling it emuNAND). Then, seeing how shamelessly the R4i 3DS team copied their work (the R4i 3DS team simply took the latest Gateway firmware stored in the Launcher.dat file and added a little of their own), they released another firmware that included code that checked the checksum of the Launcher.dat file, and if it didn't match, it bricked the console! Yes, imagine, it was the console that broke, not the pirate flash cartridge.

So many R4i Gold 3DS Deluxe users turned their consoles into bricks without even realizing that there was a hidden struggle between Gateway and R4i 3DS team.

But the funniest thing was that Gateway, trying to dig a hole for the R4i 3DS team, also set up their own users. After all, any small change in the file, which could even be related to incorrect file writing on the memory card, led to a change in the checksum of the Launcher.dat file and subsequent bricking of the console, even for users of the original Gateway flash cartridge.

If you looked at the Gateway developers' website during these events, you would see offended innocence.

Offended innocence

In the fourth paragraph, they write: «We continue to investigate individual incidents of bricks reported by users of genuine Gateway 3DS cartridges. To date, individual incidents of bricks blamed on us have been refuted and turned out to be related to the use of clones and modified versions of our official files».

If you listen to them, it seems that clumsy clone developers got into their miracle program and messed something up. Like, it was because of this that consoles were bricked, and not because they added some code that deliberately ruined consoles.

But... This is very easy to check, which is what various people did. For example, the fairly famous French hacker/developer Mathieu Hervais (@Mathieulh) wrote on Twitter in mid-January 2014:

French hacker/developer Mathieu Hervais

Ok, I just found the time to look at GW Launcher.dat (yes, I'm a bit late), and the bricking procedure is definitely intentional.

So it wasn't clumsy clone developers who messed up the file, but specifically written code that ruined consoles.

Epilogue

What these people did defies any explanation.

Of course, one could say that it was their work, and it was stolen. But ruining the consoles of users who had no idea that someone stole something from someone – that's too much. Especially since the entire product was initially built on someone else's copyright and an attempt to circumvent it. In the 90s, one could say that we were making a product for game developers, but in 2013, such an excuse no longer worked.

One can argue endlessly about whether they were right or not, but I believe that ordinary users should not suffer in the struggle between two companies.

These were the glorious developers of this cartridge. Fortunately, over time, they realized that this should not be done and stopped ruining consoles. If you used a Gateway clone, you simply received a message that this cartridge was not supported.