[Feature]: Add device certificate to NASC requests

[jonbarrow]

Checked Existing

• I have checked the repository for duplicate issues.

What feature do you want to see added?

Add the 3DS device certificate to requests to NASC (either as a header or a form field). This differs from the signed LFCS which is already sent. On the 3DS the only time the device certificate is used is in communications with the SOAP server, NNAS, and (I believe) some eShop servers. NASC is only sent the serial number, LFCS, etc.

Why do you want to have this feature?

Currently we use the signed LFCS sent to NASC to differentiate between consoles and issue console bans. However this has some major downsides, namely the fact that LFCS sharing was/is a very popular method of ban bypasses when Nintendo Network was still alive. This means there can be many hundreds, or thousands, of consoles all with the same LFCS, making them all appear to be the exact same console to us. By having the device certificate on NASC we can more reliably differentiate between consoles, and issue more secure console bans without affecting multiple legitimate users (see the "Any other details" section for a note on these bans)

The device certificate is also what is used in NNAS to identify a console. The 3DS does send the device certificate to NNAS when interacting with a PNID/NNID, however we must do several steps of complicated and (to be frank) bad heuristics to link the data from NASC to the data in NNAS. This is a very imperfect system, and is error prone. Having the device certificate from the start means we no longer need to perform these heuristics and can simply lookup the device by the certificate

Having the device certificate also gives us access to the unique console ID. This makes it easier to query specific consoles in places like the admin panel

And finally, having the device certificate in NASC would allow us to securely allow Korean players following the changes from PretendoNetwork/account#101. If a Korean 3DS is unable to access the NNID settings even after a region swap (or if it can, but a user is unable to perform said region swap for whatever reason), then after the changes made by PretendoNetwork/account#101 those Korean users would be blocked from our servers. However if we have the console device certificate in NASC, we can do manual linking. Korean users can dump the relevant console data that would normally be sent to NNAS (likely through an update to Nimbus), and then after an update to the website they could manually upload that data to their PNID. We would then perform the same PNID linking process on our end using said uploaded data, the same way we would if the user had gone through NNAS on their console. Then in NASC we can simply use the device certificate to look for that console data and find the linked PNID, letting Korean users online with a connected PNID even though Korean 3DS consoles never got NNID support

Any other details to share? (OPTIONAL)

If this is added, and we use this for bans moving forward, it will erase all existing console bans. If we carry over the LFCS bans to the new device certificate system, then it fixes NOTHING with regards to LFCS sharing banning multiple people. We will just have to bite this bullet and manually redo console bans as they appear

This idea has been brought up several times by myself in our internal Discord channels. Through conversations had in said channels, this idea was determined to be much more difficult than it would seem to be

Due to this, this feature request ONLY exists as a way to communicate the idea for the wider community, in case someone would like to take a crack at it. This should NOT be seen as a task that has active energy being put into it at this time

@zaksabeast has made a partial re-implementation of the friends sysmodule in Rust, which could serve as a basis for this idea. However as @DaniElectra noted on Discord:

it's incomplete, it doesn't have the NEX functionality for example

even then, i'm on the opinion to keep things as vanilla as possible

Which is both true and fair. To use that implementation much more work would need to be done, including a Rust NEX client to create the friends server connection. Cemu has a basic PRUDP/NEX client written in C++ however, which may be useful for porting to Rust? This custom sysmodule would only need to implement the friends (3DS) protocol, which is the same use case as Cemu