Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement]: Update FAQ/installation docs to note that we require real consoles, even with emulators #317

Open
1 task done
jonbarrow opened this issue Jul 28, 2024 · 0 comments
Labels
approved The topic is approved by a developer enhancement An update to an existing part of the codebase

Comments

@jonbarrow
Copy link
Member

Checked Existing

  • I have checked the repository for duplicate issues.

What enhancement would you like to see?

Right now there seems to be some confusion about whether or not you need a real console to use our servers, and why we require them. Many people understandably have the opinion that we should not have this restriction for various reasons, and many question the requirement, and some just have no idea what we support. This especially became an issue recently when people began to think we banned 1,300 people/consoles at once, which was not true. Adding this to the website should help clear this up for the majority of people.

My suggestion would be to:

  • Add the actual information/reasoning to the FAQ, near the "do we support emulators" question
  • Add links to the FAQ answer in the installation docs.

That way the information is kept where it is relevant and not duplicated on multiple pages.

Any other details to share? (OPTIONAL)

To answer the question (both for anyone looking to implement these changes, and for those curious):

Yes, even when using emulators, we require the use of a real console. If using an emulator you MUST dump the relevant system data from a legitimate console to go online on our servers

The reason is simple: security. Each console contains unique data which is tied to that specific unit, and that data is cryptographically signed by Nintendo with a private key only Nintendo has. These take the form of a "Device Certificate" (which exists on both the Wii U and 3DS) and your LCFS (LocalFriendCodeSeed, which only exists on the 3DS). These both have the aforementioned signatures, which cannot be created by anyone besides Nintendo, but CAN be validated by anyone due to the public key being known. That makes them impossible to spoof/modify, and are our only true way of issuing full console bans.

Without the ability to issue console bans, we are effectively unable to keep cheaters off of our servers long term. We always start with account bans, but if a console is the source of many banned accounts then we will outright ban the console. Many people have tried to suggest alternatives, so I'll go ahead and answer the most common suggestions I've seen:

  • "Just ban accounts" - Account bans alone are ineffective, since anyone can infinitely generate new accounts both on the website and on their console. There is nothing stopping someone from just making hundreds of new accounts each time they get banned. While we always ban accounts first, if a user continues to make new accounts and breaking our rules then we need a way to keep them off the servers permanently
  • "Ban IPs not consoles" - IP bans are ineffective as they only last as long as the user is on the same IP address, which is especially common on the 3DS given that it is a mobile console. Once a user's IP changes, then their console can immediately go back online. An IP address can be changed in many ways, such as:
    • Using a proxy server
    • Using a VPN
    • Changing your ISP
    • Moving your network (such as moving to a new house/city)
    • Changing networks (going to a friend's house, public wifi, using a mobile hotspot, etc.)
    • Having a dynamic IP address (not everyone has a static IP, and their IP will naturally change even without doing anything)
  • "Ban VPNs'' - VPN bans are ineffective since again there are multiple ways to change an IP address, and it's just a cat and mouse game where we always lose. VPN banning is not a trivial task, as there's no true "source of truth" for EVERY VPN providers IPs/ranges, and a provider can change them at any time. Not to mention that there are perfectly legitimate reasons to use a VPN, and a VPN ban would block those legitimate users. There's also nothing stopping someone from renting a cheap $5/m VPS and running their own proxy/VPN that way
  • "Generate/sign your own dumps"/"Assign your own IDs to emulators"/some variation of this kind of idea - This has a combination of all the previously mentioned issues. There's no solid, reliable, way to prevent people from infinitely generating these types of files/IDs/whatever
    • If we handed them out with no verifications, then there's literally nothing stopping someone from just mass generating them
    • If we generate them per account, then a "console ban" is as effective as an account ban. Users could simply create new accounts to get new files
    • If we generate them per IP address, then a "console ban" is as effective as an IP ban. Users could simply use a different IP address to get new files. If we could effectively limit this to a single IP, we would just do IP bans
    • Etc.

Trust me. We have spent several years thinking about ways to try and do this, and there simply isn't. There isn't an idea that you can come up with that we haven't already considered. The only effective, long term, way to permanently keep a console/player off our servers is to ban something which can't be infinitely generated/modified. That means it has to be:

  • Unique (to only target specific devices)
  • Signed (to prevent tampering)
  • Users can't sign new data (to prevent generation)

And only device certificates/LocalFriendCodeSeeds match this criteria. Thus the requirement for a real console, even when using an emulator.

In the past we DID try to allow emulator users online without real console dumps, and it was immediately abused by cheaters to the degree that we HAD to take this away.

@jonbarrow jonbarrow added enhancement An update to an existing part of the codebase awaiting-approval Topic has not been approved or denied approved The topic is approved by a developer and removed awaiting-approval Topic has not been approved or denied labels Jul 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved The topic is approved by a developer enhancement An update to an existing part of the codebase
Projects
Status: Todo
Development

No branches or pull requests

1 participant