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 · 3 comments · Fixed by #355
Open
1 task done
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
@coolpic783
Copy link

Could this, by chance, be included in the existing FAQ entry for "Does Pretendo work on emulators?"

For Example, something like this:

Cemu 2.1 officially supports Pretendo under your network account options in the emulator. For information on how to get started with Cemu, check out the documentation.
Some 3DS emulators or forks might support us, but we do not have any official recommendation or setup instructions at this time. The final builds of Citra do not support Pretendo.
While some 3DS emulators are supported, for security reasons we do still require the use of a real console to dump the relevant system data in order to go online. Please refer to (insert documentation here) for more information.

@coolpic783
Copy link

I'm new here, so I don't know exactly where the necessary documentation would be covering that, but this is roughly what that would end up looking like:
Image

@coolpic783
Copy link

One other thing since, again, I'm new here, where in the repository would I find the files in order to add to the FAQ?

coolpic783 added a commit to coolpic783/PretendoWebsite that referenced this issue Nov 25, 2024
Added an FAQ entry covering the usage of emulators, as noted in PretendoNetwork#317 . I have not yet added the FAQ to the docs, just added a question and answer to the FAQ.
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
2 participants