Even though DS cards weren't affected by the curse of the compact disc, Trademark-based tricks were no longer enough to deter the production of Flashcarts. Thus, this time, Nintendo reinforced its traditional security with extra layers to regain control of game distribution.
Security mechanisms
To understand the new system that has been put in place, let's take a look at each area, separately.
Encryption system
While the game data in the ROM still remains unencrypted, the Nintendo DS debuts a symmetric encryption system to protect the communication between the Memory Interface and the Slot-1 card.
The 'Header' area of the card contains a value called Gamecode, which serves as the game's unique identifier. The Memory Interface uses this information to generate KEY1, the encryption key. Using the Blowfish encryption algorithm in combination with KEY1, the Memory Interface encrypts further commands sent to the card .
Afterwards, KEY1 is mixed with the internal clock and other values of the cartridge header to generate a new key called KEY2. The fundamental difference from KEY1 is that KEY2 incorporates randomness to make it unpredictable. Furthermore, its encryption relies on multiple XOR and shift operations to obfuscate the data .
KEY1 and KEY2 are used at different stages by the Slot-1 interface to encrypt its communication with the card. KEY1 is also used by the ARM7 BIOS to validate the DS card and initialise the card interface.
DS card validation
To put this new system into use, the BIOS includes routines that validate the Slot-1 card upon startup. This works as follows :
- The ARM7 BIOS retrieves the ROM chip ID of the card, saves it on RAM and then proceeds to enable KEY1 and KEY2 encryption.
- The first 2 KB of the 'Secure area' are copied to RAM in random order. The first 8 bytes of this chunk store a string called Secure Area ID, the next values contain checksums (CRC16 type) and other metadata. All of this comes encrypted with KEY1, and the Secure Area ID is encrypted twice with KEY1 using different parameters.
- The ARM7 BIOS decrypts the Secure Area ID and verifies that the result matches
encryObj. If it does, the card has passed the first test. After this, the string is destroyed to prevent revealing the algorithm. If the validation fails, the 2 KB of Secure Area are filled with garbage, preventing further access to the card. - The second test involves retrieving the chip ID again. The number of reads depends on the internal clock. In the end, if the value of the chip ID matches the first chip ID stored, the second test has passed.
- Finally, the rest of the Secure area is fetched in random order and reconstructed in RAM. After this, the firmware is executed.
If everything goes well, the firmware will find the required executable of the card in RAM, allowing the user to launch the game. Otherwise, the game entry will be shown greyed out.
Download Play protection
Programs received via Download Play must be signed by Nintendo using a separate asymmetric encryption system. Specifically, RSA-1024 combined with SHA-1 . Of course, only Nintendo knows the private key.
Signature verification is performed by the system firmware, which also stores the public key.
Defeat
If you were an avid DS homebrew user between 2007 and 2011, it's very likely you came across endless catalogues of community-made software, from emulators and game ports to multimedia players, along with the many tools available to run this. The truth is, before all the easy-to-use tricks were discovered, hackers had a hard time circumventing Nintendo's complex system.
Existing Slot-2
Because the GBA subsystem still executes cartridges without any meaningful protection (aside from trademark tricks), existing GBA flashcarts remained compatible with the Nintendo DS. This enabled to run GBA homebrew, which worked fine if you didn't mind missing out on the new functionality exclusive to DS titles.
As always, flash cartridges also enabled users to run pirated ROMs. However, since Nintendo couldn't alter the GBA's protection system (as doing so could potentially render existing games unusable), no extra measures were implemented.
Enhanced Slot-2
Example of Slot-2 flashcart that can launch DS games. This requires a passthrough method to bootstrap it.
Ever since the console reached the shelves, people around the world had been conducting clandestine research in an attempt to decipher the intricacies of Slot-1, the ARM7 BIOS, and the firmware.
In January 2005, Rafael Vuijk (known as DarkFader), published a method to inject arbitrarily code in DS mode. This used an FPGA connected between the Slot-1 socket and the card pins of Metroid Prime Hunters: First Hunt . In essence, Vuijk discovered that by tampering with the header values, the execution of Slot-1 could be redirected to Slot-2 (where GBA flashcarts lived). However, as the DS encryption system wasn't yet fully understood, this required a genuine DS card to pass the initial validation checks. In any case, this model was dubbed DS Passthrough and would serve as the basis for executing Slot-2 programs in DS mode.
Subsequent months saw a proliferation of Slot-2 flashcarts appearing on the market. These new variants embedded ARM9 code that executed once bootstrapped from Slot-1. Meanwhile, the bootstrap itself was accomplished using a variety of 'passthrough methods' discovered over the same year, including:
- PassMe: Originally designed by
Natrium42, these were third-party Slot-1 cards that bundled integrated circuitry and a slot for a genuine Slot-1 card. They were essentially a commercialised version of Vuijk's invention for the average user. Over time, multiple manufacturers came up with smaller and simpler revisions. - WiFiMe: Developed by Tim Schuerewegen in April 2005, this was a suite that included a modified Ralink Wi-Fi driver and a command-line utility for Windows 2000 and XP. With the use of a compatible Wi-Fi card, a PC could broadcast a customised DS program that the console could download through Download Play . Once launched, it would redirect execution to Slot-2. This exploited the fact the firmware didn't check the RSA signatures of particular areas of the binary.
- FlashMe: Developed by
Loopyin April 2005 , this addressed the inconveniences of the previous two methods. By bridging theSL1terminal and running a specially crafted homebrew program (bootstrapped by another method), it became possible to modify the firmware so that it automatically bootstrapped Slot-2 code in DS mode.
As expected, later batches of Nintendo DS units shipped with updated firmwares that patched these tricks. Thus, hackers and manufacturers turned to exploiting deficiencies in the ARM7 BIOS (which were far more difficult to fix). This became PassMe2 . Even so, the cat-and-mouse continued until the next revelation delivered a major blow to Nintendo.
Native Slot-1
The 'R4 DS' was one of the first Slot-1 flashcards to reach the market. Right afterwards, a swamp of replicas flooded it.
In January 2006, Martin Korth, developer of the Nintendo DS emulator called 'NO$GBA', managed to extract the ARM7 BIOS and reverse engineer the Slot-1 security system . With this, new tools and documentation revealed the true mechanisms of the Nintendo DS' security. As you have seen in this article, the encryption model is effective until the key is discovered (this is a weakness of symmetric encryption systems, unlike asymmetric encryption systems such as RSA, where the private key is kept by a separate entity).
What happened then? Well, for starters, PassMe cards were quickly replaced by NoPass cards. Their function was the same but they no longer required a genuine card inserted. The second major disruption became a new wave of plug-and-play Slot-1 flashcards, which loaded homebrew directly from Slot-1 (by including either a MicroSD socket or internal rewritable memory).
Since the encryption system couldn't be altered without introducing breaking changes that would affect all existing retail games, Nintendo ultimately lost this battle. The only remaining option was to pursue the legal route, just like they did with their previous console.
Closing observations
This is my personal opinion, but it's astonishing how simple it became to acquire and use plug-and-play flashcards compared to previous consoles. In older articles, I've described that if users ultimately wanted to run homebrew programs or pirated games, they would have to get down the rabbit hole and follow some cumbersome method.
In the case of the DS, however, flashcards were literally sold just like retail games (albeit with a different 'style' of marketing), and I bet it must have been truly concerning for game studios to see how painless it was to resort to piracy.
Slot-1 flashcards were a very active industry between 2007 and 2011. These are just a handful of the many offerings. Thanks anonymous donor for sending me these!
Another sticking aspect is the sheer number of branded flashcards (aside from all knock-offs) that appeared on the market. If you look at it from a technical perspective, the purpose of a flashcard is very straightforward: to redirect commands to the MicroSD card (where a game ROM or homebrew is stored) . But as this industry progressed, some manufacturers took extra steps to design better software running within the flashcard (referred to as 'kernel' or 'firmware') or even integrate rather unusual hardware. For instance, the 'N-Card' offered embedded storage, while the 'SuperCard DSTwo' bundled an Ingenic Jz4740 (a MIPS-compatible CPU) running at 360 MHz! I haven't seen this level of passion since the era of expansion cartridges.