Reverse engineering Nintendo's game server protocols has been one of my favorite and long-lasting projects so far. Since I started the project around 7 years ago, it has led to a popular open source repository, several bug bounties and more than 150 pages of documentation.
This article provides an overview of how the game server protocols are designed, and also includes some history. If you are merely interested in Python code or technical documentation, check out my GitHub repository instead.
History
Nintendo first introduced online play on the Nintendo DS, back in 2005. Mario Kart DS was the first game that supported online play. The servers provided basic functionality for leaderboards, match making and authentication. During a match, players communicated directly with each other by peer-to-peer. Since then, Nintendo has released three major generations of online technology:
- Nintendo Wi-Fi Connection (DS and Wii, released in 2005)
- Nintendo Network (3DS and Wii U, released in 2012)
- Nintendo Switch Online (released in 2017)
Every generation has substantially improved the online architecture, both in terms of player experience (features, reliability and latency) and technical design (using modern standards and technology).
Nintendo Wi-Fi Connection
Nintendo Wi-Fi Connection was primarily designed for ease of use. No account registration was required. Instead, every console automatically registered itself when it went online for the first time. Instead of HTTP, the servers primarily used a custom text-based protocol. A packet exchange could look like this:
recv: \lc\1\challenge\AMDOLXQODS\id\1\final\
send: \login\\challenge\2K7cFsjHMjKxmnEPeeVlaH8bA3HaOfvn\authtoken\NDSTp+9qRq+i/G80XAUf/gB1Wnf5uyNMaiM1XZRbsT0t6kBMe4IHXTRhzpKbqFAV4blBiK6/dfFI/c6EffiDE1YfcBHBsym/IlDyUVux5I2h6lJvaS90gYrficSc/T+XLG+\response\ac3e3ff5e061f1657d24787f7d8f6df3\firewall\1\port\0\productid\1238\gamename\mariokartds\namespaceid\0\id\1\final\
recv: \lc\2\sesskey\192823131\proof\354703510cab4aa90634cd254a485f44\userid\442395452\profileid\474514632\uniquenick\4rk8j7pdtAMCJ3thdsd7\lt\EPc0zxLcxPeQPsC3dNimZR__\id\1\final\
send: \getprofile\\sesskey\192823131\profileid\474514632\id\2\final\
recv: \pi\\profileid\474514632\nick\4rk8j7pdtAMCJ3thdsd7\userid\442395452\email\4rk8j7pdtAMCJ3thdsd7@nds\sig\e24ed22481d1f41a2e44728a82eef5ae\uniquenick\4rk8j7pdtAMCJ3thdsd7\pid\11\lon\0.000000\lat\0.000000\loc\\id\2\final\
...
send: \logout\\sesskey\192823131\final\
The infrastructure was hosted by GameSpy, which, after being acquired by Glu Mobile, announced that it would shut down its servers in 2014. For most people, this was the end of online play on the DS and Wii, although a fan-made project was launched that still allows people to play online today.
Nintendo Network
With Nintendo Network, the online architecture was completely redesigned. Nintendo no longer relied on GameSpy and instead arranged its own communication protocols and server hosting. Many new features were introduced such as friend lists, rewards and Miiverse. Nintendo eShop purchases were no longer tied to the console, but to a Nintendo Network ID instead, and could be redownloaded or transferred to a new console at any time. On the Wii U, the Nintendo Network ID became mandatory to play online. All online progress was tied to it.
With the 3DS and Wii U, Nintendo also introduced the NEX and Pia libraries. These are used by almost all games that support online play. NEX is the framework that implements communication with the game servers. It is based on Quazal Rendez-Vous, but has been customized by Nintendo and extended with additional services such as data storage. Pia is the library that Nintendo uses for peer-to-peer communication. Although some of its design choices are inspired by NEX, Nintendo designed and implemented this library entirely from scratch.
In March 2023, the game servers of Mario Kart 8 and Splatoon were shut down to deal with a security issue. Most people believe that this is caused by ENLBufferPwn, which was a vulnerability in a first-party library that uses Pia internally. Although the servers went back online in August 2023, Nintendo later announced that it will shut down all 3DS and Wii U servers for good in April 2024.
Nintendo Switch Online
In 2017, with the release of the Nintendo Switch, the online ecosystem was entirely redesigned again. Many new features were added, such as save data backups, smartphone services and online play invitations. Instead of a Nintendo Network ID, eShop purchases and online progress are now tied to a Nintendo Account, which can be linked to multiple consoles at once.
Both NEX and Pia received major improvements and continued to be developed. However, Nintendo also designed some internal libraries with a more specific purpose. The ENS library is used by Animal Crossing: New Horizons to implement a game-specific HTTP API. The Eagle library is used by battle royale games (such as Tetris 99) to implement communication through a relay server, because a peer-to-peer network becomes inefficient when the number of participants becomes too large.
Online play had always been free, but Nintendo started to require a small fee in 2018. This is not surprising if you consider that Nintendo has obtained a large player base and many new features have been introduced on the Nintendo Switch. There was also an enormous increase in the number of games that support online play. For comparison: there were less than 50 NEX servers on the Wii U. The Switch has more than 1,000 with more being launched every week.
In 2021, NEX finally began to be phased out. Since it was based on Quazal Rendez-Vous, which was initially released in 2005, the core of its design was more than 15 years old. Also, various critical vulnerabilities had been discovered in both its client code and server code. The replacement for NEX is called NPLN. Although old games continue to use NEX, more and more new games use NPLN since it was released.
Authentication
This section gives an overview of the authentication process of Nintendo Network and Nintendo Switch Online. It is clear that the security has been dramatically improved on the Nintendo Switch.
Nintendo Network
On the 3DS and Wii U, a single account server was responsible for everything related to Nintendo Network IDs. Although a client certificate is required to access the server, this certificate is the same on every console and can easily be found online. During authentication, the console simply sends its Nintendo Network ID and password to the server. After that, the console can request the IP address and port of the game server for a given title ID. The first time a player goes online, a game server account is automatically created and tied to the Nintendo Network ID. The credentials for the game server account are received from the account server together with the address of the game server.
Security-wise, this scheme was somewhat weak. There was no way to detect piracy. While online cheating sometimes led to an account or device ban, the latter could easily be bypassed by spoofing the serial number. Furthermore, bans were implemented on the account server, but the account server could easily be bypassed after obtaining credentials for the game servers once.
Nintendo Switch Online
On the Nintendo Switch, the situation was dramatically improved. Let's take a look:
Unlike the game server credentials that were used previously, a token is only valid for a limited amount of time (usually a few hours). Once the token has expired, the Switch has to authenticate itself all over again.
Every Switch is given a unique device certificate during production. Because the certificate is signed by Nintendo, it is impossible to forge. The only way to obtain a new certificate is to buy a Switch and dump it. Because a device token is required for almost every single Switch server, this allows Nintendo to ban devices in a central place. If a device shows suspicious behavior (such as piracy or online cheating) Nintendo can easily ban the device and stop it from using any online feature whatsoever.
Every purchased game also comes with an application certificate. This certificate is either stored on the game card or provided by the server when the game is purchased in the eShop. This has some major security benefits for Nintendo:
- It is impossible to access a game server without purchasing the game, since an application certificate is required to access it.
- When a certificate has leaked online, Nintendo can easily ban the certificate from online play.
- When multiple people use the same certificate to play online, Nintendo can detect that an illegal copy was made.
Using an invalid or banned application certificate is the most common cause for a device ban on the Nintendo Switch.
Finally, once the console has obtained a device and application token, it logs in on the BaaS server using credentials that are generated per user. If a Nintendo Account is linked to the given user, and the user has purchased a Nintendo Switch Online subscription, the BaaS server returns an ID token that can be used to log in on a specific game server.
To summarize, accessing a game server is only possible after purchasing a Switch and the game. Nintendo can detect illegal copies and accurately ban individual devices and games. Other than purchasing a new device or game, there is no way to bypass the ban.
NEX Overview
In this section, we dive deeper into the architecture of NEX. Being designed in 2005, its architecture is somewhat dated. We will first provide a general overview of its architecture and authentication mechanism. Then, we take a deeper look at its protocol and how it has changed on the Nintendo Switch.
In case you skipped the previous sections: NEX is the framework that Nintendo developed for game servers. It was originally designed by Quazal in 2005, but customized by Nintendo for its own consoles. Almost every game with online features uses NEX.
A Custom RMC Protocol
At its core, every NEX server provides a bunch of services. Every service has a specific purpose, such as match making, leaderboards or authentication. To interact with a service, the client sends a remote method call (RMC) request to the server. The server processes the request and sends an RMC response back to the client. The client may also provide services to the server of its own. In Nintendo games, the client uses this feature to provide a notification service to the server, so that the server can notify the client about interesting events.
NEX uses a simple wire format to implement RMCs. Every service, and every method within a service, is identified by a hardcoded ID. The payload of the request and response depends on the method that is called. If an RMC fails, the server returns one of a predefined set of error codes.
A Kerberos Based Design
To implement authentication, NEX uses a design that is strongly related to Kerberos. Rather than a single server, every game server actually consists of two servers: an authentication server and a secure server. The authentication server only provides a single service: the ticket granting service. The actual game services are provided by the secure server.
It is not possible to establish a connection directly with the secure server. Instead, a ticket is required that can only be obtained from the authentication server. On the 3DS and Wii U, anyone can request a ticket from the authentication server for any user. However, the ticket is encrypted with a key that is derived from the password of the user. It is only possible to decrypt this ticket if you know the password of the user. On the Switch, the client must provide an ID token to the authentication server and the authentication server only returns a ticket if the ID token is valid.
Reliable Transmission over UDP
In the 3DS and Wii U era, NEX servers used a custom protocol that is implemented on top of UDP. The protocol is called PRUDP and its aim is to reliably and securely transmits packets over UDP. To achieve reliability, the PRUDP protocol provides the following features:
- Every packet is given an incrementing sequence ID. This ID is used to ensure that packets are received in the correct order.
- When an endpoint receives a packet, it must send an acknowledgement packet in return. The packet is retransmitted periodically until it has been acknowledged. This ensures that no packets are lost.
- To detect broken connections, an endpoint can send a ping packet to the other side. If the ping packet is not acknowledged after a given amount of time, the connection is considered dead.
The following features are provided for security:
- All packets are encrypted with a session key. The session key for the secure server is received from the authentication server together with the ticket. Communication with the authentication server is encrypted with a hardcoded key instead.
- During the handshake with the secure server, the client must provide a ticket. The server verifies the ticket and only accepts the connection request if the ticket is valid.
Improved Security with WSS
The encryption scheme of PRUDP had several weaknesses. Because the communication with the authentication server uses a hardcoded key, it can easily be decrypted. Even the communication with the secure server was prone to man-in-the-middle attacks because of weaknesses in RC4.
On the Nintendo Switch, communication with the game server uses WebSockets over TLS instead of UDP. This immediately provides reliability and security. A lightweight version of PRUDP is implemented on top of the WebSockets layer to implement the remaining features such as ticket validation.
Although even the Nintendo Switch implementation of the protocol had several critical flaws, its security was much stronger than the previous protocol.
The Future with NPLN
In 2021, Nintendo released the first game that uses NPLN, a modern replacement for NEX. This was a complete redesign with almost no similarities to NEX. NPLN uses gRPC to provide a rich set of services to games. Instead of hosting an independent server for each game, a single gateway server handles all incoming traffic. Individual games are separated by assigning a 'tenant id' to each game that must be sent to the server along with each request. Behind the scenes, a large number of 'backyard' services are provided that can be used by administrators to configure or observe NPLN tenants.
NPLN is actively being developed with monthly releases. The number of games with NPLN is steadily increasing. Big first-party games, such as Splatoon 3, occasionally get an NPLN service that is designed exclusively for them. In short, NPLN seems to be the future of online gaming on the Nintendo Switch.
My Personal Experience
You might wonder how one can stay motivated to work on a project for such a long time. For me, the motivation has always come from a desire to learn. It all started when I wanted to know how Donkey Kong Country: Tropical Freeze requests its leaderboards. Then, I looked into Mario Kart 8 and found that it uses exactly the same protocol. From there, I started looking into other games on the Wii U, and later moved on to the Nintendo Switch.
I've always set a clear goal for myself. For example: 'I want to download the leaderboards of Mario Kart 8 with a Python script'. Often, I was able to achieve these goals. Sometimes, I was not. In any case, I learned a lot from it and published a large amount of information over the years.
Sources
In addition to my own reverse engineering experience, I used the following sources for the history section of this article: