If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

[PSA] Strong anti-piracy measures implemented by Nintendo for online.

After doing some research earlier today into how the Switch gains authorization to play a given game online, I learned that Nintendo has implemented some very strong anti-piracy measures in this regard -- they can actually perfectly detect whether a digital copy of a game has been legitimately purchased. I figured I'd make a post explaining the process, since it's pretty technically interesting.

Overview

Here's what happens when you attempt to connect online in a game, in the abstract:

Your console verifies that it can connect to the internet.

Your console verifies that it can get a device authorization token to go online -- that it is not banned.

Your console authorizes the Nintendo Account being signed into.

Your console obtains an application authorization token for the specific title being played.

Hopefully at a high level, all that makes sense. Now, let's dive in to more technical detail:

Your console verifies that it can connect to the internet.

This step is pretty self-explanatory, but I'm including it for the sake of being thorough. Your console periodically connects to "ctest.cdn.nintendo.net", and checks the response for a special header -- "X-Organization: Nintendo". If that header is present, your console concludes it has access to the internet. Otherwise, it decides it doesn't -- it's really straightforward.Let's get to the more interesting stuff.

Some background

For those that haven't read my other Switch networking post, I recommend you go do so -- it's pretty interesting. There's only one really important bit to keep in mind for this, though, so I'll just repeat it here:
On the Switch, only bugyo is unauthenticated -- every other server authenticates requests, and will reject any requests lacking the right client certificates. In addition, client certificates are now console-unique, and burned in at the factory. Client certificate private key data is stored encrypted using keydata only available to TrustZone (an isolated security-focused cpu core, which provides a cryptography API), and the ssl module retrieves it on boot by interfacing with the settings service to retrieve the encrypted data and then requesting that the spl module pass it to TrustZone for decryption via the "GenerateAesKek" and "DecryptPrivk" commands.
Note that unlike the 3DS, this means that Nintendo can tell what console makes a given request. This means Nintendo can block misbehaving user's certificates, leaving them permanently unable to use any of Nintendo's network.

Your console verifies that it can get a device authorization token to go online

This is one of the meatier bits of the online connection process. Nintendo has a special server for handing out device authorization tokens -- "dauth-lp1.ndas.srv.nintendo.net" (Device AUTHorization, and lp1 is the "live production" environment for retail online services). One thing that's important to note is that these tokens don't blanket-authorize all system operations -- they are handed out to specific parts of the system, specified by a client id in the token request. With that out of the way, here's how device authorization works:

Dauth sends back as a json a random "challenge" string, and a constant "data" string.

Your console treats the "data" string, decoded as base-64, as a cryptographic key source, and uses the SPLservices to transform it with TrustZone only keydata and load it into an AES keyslot.

Your console generates its authorization request data -- this is done by formatting the string "challenge=%s&client_id=%016x&key_generation=%d&sy stem_version=%s" with the challenge string, the client ID requesting a token, the master key version, and the current system version digest.

Your console calculates an AES-128 CMAC using the trustzone-only key it derived over its authorization request, appends "&mac=%s" to the request data (formatting with the url-safe base 64 encoded CMAC), and fires the request off to the "/device_auth_token" endpoint.

If all goes well, dauth returns a token for your console. (If your console is banned, as one of mine is, you will instead receive an error message informing you that your console is not allowed to use online services).

This is a pretty effective custom scheme -- it requires, in order to get a token, that the requester be able to perform TrustZone-only cryptographic operations for the current system version. Provided TrustZone isn't compromised on the latest firmware, this is totally safe. TrustZone is, for better or worse, compromised on all system versions due to shofusel2, though. This means the only real benefit here is that dauth provides an ideal place for console bans to be implemented -- almost all interesting online functionality requires a dauth token of some kind, including purchasing and installing new games from the eShop, so consoles that get blocked here can't do much besides install system updates.

Your console authorizes the Nintendo Account being signed into.

This is actually somewhat uninteresting, too -- there is nothing Switch unique here. Your console performs pretty bog-standard oauth authorization talking to "api.accounts.nintendo.com" -- this is the same process performed on a PC, and so I won't go into it in detail here.
The only meaningful upshot to this component is that it allows Nintendo to block specific accounts, and because all requests require a client certificate, any blocked account can be immediately associated to a console.
Your console obtains an application authorization token for the specific title being played.

This is the really interesting component -- and it's where Nintendo's strongest security measure lies.Like dauth, Nintendo has a special server for this -- "aauth-lp1.ndas.srv.nintendo.net" (Application AUTHorization). Going online in a game requires getting a token from the "/application_auth_token" endpoint. Here's how that works, at a high level:

Your console retrieves its certification to play the title it's trying to connect online with, and sends that to aauth.

If all goes well, aauth returns an application authorization token.

Now, that's not too complicated. But what's really interesting is the bit where your console retrieves its certification to play the title it's trying to connect online with.Let me explain that in more technical detail for both cases:

Gamecards

If you are playing a gamecard, your certification is your gamecard's unique certificate. This is signed by Nintendo using RSA-2048-PCKS#1 at the time your gamecard is written, and contains encrypted information about your gamecard (this includes what game is on the gamecard, among other, unknown details).

In the gamecard case, the data uploaded to aauth is "application_id=%016llx&application_version=%08x&d evice_auth_token=%.*s&media_type=GAMECARD&cert=%.* s", formatted with the title ID for the game being played, the version of the game being played, the token retrieved from dauth, and the gamecard's certificate (retrieved from FS via the "GetGameCardDeviceCertificate" command), formatted as url-safe base64.

This code lives at .text+0x7DE1C for 5.0.0 account.

Digital games

Your certification for a digital title is your console's ticket. For more technical details on what's inside a ticket, see my previous post on the eShop/CDN (linked up above). The important details are that tickets contain the Title ID of the game they certify, the Device ID of the console they authorize, the Nintendo Account ID used to purchase them, and are signed by Nintendo using RSA-2048 (cannot be forged).

In this case, your console talks to the "es" service, and sends a command to retrieve an encrypted copy of the relevant ticket along with the encryption key. This encryption is AES-128 CBC, using a key randomly generated via cryptographically-secure random number generation. The key itself is encrypted using RSA-OAEP 2048. To skip over some technical details, this is a one-way encryption which only Nintendo can reverse, so even if you obtained the output of the es command you would not be able to determine the encryption key being used (and thus couldn't decrypt the ticket).

The data uploaded to aauth in this case is "application_id=%016llx&application_version=%08x&d evice_auth_token=%.*s&media_type=DIGITAL&cert=%.*s &cert_key=%.*s", formatted with the title ID for the game being played, the version of the game being played, the token retrieved from dauth, the encrypted ticket encoded with url-safe base64, and the encrypted key encoded with url-safe base64.

This code lives at .text+0x7DE98 for 5.0.0 account.

And that's that (with the additional case where if the console fails to find a certificate, a special "NO_CERT" request is sent, but this is pretty irrelevant because sending a NO_CERT request gets your console banned). In both relevant cases, aauth validates the certification, and returns a token only if the certification is valid.

Practical Impact

These are extremely strong anti-piracy measures -- Nintendo did a great job, here.

In the gamecard case, Nintendo can detect whether or not the user connecting has data from a Nintendo-authorized gamecard for the correct title. This solves the 3ds-era issue of gamecard header data being shared between games. Additionally, there's a fair amount of other, unknown (encrypted) data in a certificate being uploaded -- and certificates are also linked to Nintendo Accounts when gold points are redeemed. Sharing of certificates should be fairly detectable, for Nintendo.

In the digital game case, Nintendo actually perfectly prevents online piracy here. Tickets cannot be forged, and Nintendo can verify that the device ID in the ticket matches the device ID for the client cert connecting (banning on a mismatch), as well as that the account ID for the ticket matches the Nintendo Account authorizing to log in. Users who pirate games definitionally cannot have well-signed tickets for their consoles, and thus cannot connect online without getting an immediate ban -- this is exactly how I would have implemented authorization for digital games, if I were them.

tl;dr: Don't pirate games -- it will lead to your console being banned from going online, and every banned early-hardware-revision switch is an enormous waste.

That's a huge step forward. The Wii U and 3DS detection methods were so terrible that you could download pirated games directly off the eShop. It's my understanding that you just had to install a ticket onto your system, and the eShop would let you download the game even though there wasn't any record of you buying it.

"Macs are the Perfect Computers," said the Perfect Idiot.

(\__/)
(='.'=)This is Bunny. Copy and paste Bunny into your
(")_(")signature to help him gain world domination.

I've actually just been hacking my 3ds for the first time these last couple days lol. That feature does basically exist that you're talking about. There's a homebrew app called freeshop that allows you to download whatever titles are authentic to your 3ds in an enctitlekeys.bin file generated by your system. With that, freeshop is designed to only download games you have legitimately purchased, and, because of this, the software is apparently totally legal even though it downloads from CDN servers. The big butt is that a website exists which allows you to easily generate a false bin file that gives your console access to basically anything on the eshop.

I've actually just been hacking my 3ds for the first time these last couple days lol. That feature does basically exist that you're talking about. There's a homebrew app called freeshop that allows you to download whatever titles are authentic to your 3ds in an enctitlekeys.bin file generated by your system. With that, freeshop is designed to only download games you have legitimately purchased, and, because of this, the software is apparently totally legal even though it downloads from CDN servers. The big butt is that a website exists which allows you to easily generate a false bin file that gives your console access to basically anything on the eshop.

Yeah, so definitely a step up.

"Macs are the Perfect Computers," said the Perfect Idiot.

(\__/)
(='.'=)This is Bunny. Copy and paste Bunny into your
(")_(")signature to help him gain world domination.

Yeah it's not looking good for cheaters. Any kind of tampering is detectable so far. A lot of the major sites were posting articles last week when some hackers were replacing their gamer icons with porn or something, and those images started showing up on multiplayer Luigi's balloon world.

Yeah it's not looking good for cheaters. Any kind of tampering is detectable so far. A lot of the major sites were posting articles last week when some hackers were replacing their gamer icons with porn or something, and those images started showing up on multiplayer Luigi's balloon world.

It's about time Nintendo got with the program. I haven't bought any of the current gen consoles, but leaning towards an xbox if I do. I might get a switch if call of duty comes in November, but my daughter wants one of the other consoles. Money don't come easy like it did 10 years ago.