Atmosphere: Option to destroy/mask client-specific keys, certificate and data while using Atmosphere.

[sirocyl]

This is specifically to prevent one's console from being banned due to accidental communication with Nintendo or their servers while under an environment which would violate sanity checks, present or future.

Nintendo servers will see nonsense or zero data for units with homebrew and CFW in use, rather than a client's serial, deviceid, or other per-console unique information, and refuse access to connect.

For implementation, the original, unmodified data can remain as-is in place, where client data masking is only emulated under TZ or ssl/spl module, or be backed up to a safe, persistent location and destroyed in place on the flash in PRODINFO.

Regardless of implementation, this process _must_ be reversible by the end-user.

[Selver-gba]

To start with, this might actually work, but only if you limit the CFW/homebrew to using a 100% clean (never booted) system image to start, and prevent that system from writing to the normal eMMC partitions.

Otherwise, this appears to be an unsolvable problem. You may get 95% of the way there, but unless you block access to 100% of the data from the original eMMC partitions (not just user data), there will remain risks. The problem is you cannot know which data is "clean", and which is in some way unique enough to identify the console.

Examples:

1. The console uses the client certificate to communicate with the eshop. Some portion of the download of an update is made unique and stored on the console. Any exposure of that data can be tied back to the original console.

1. Similar to above, the console (sysnand) downloads an update, which is at least partially unique to the console and can be traced back to the console because it was provided based on the client certificate.

2. A game stores a unique ID for the user. It could be ANYTHING, such as a GUID generated for a savegame. The savegame is backed up to the Nintendo service, and thus allows Nintendo to correlate the savegame with that client certificate. A later discovery that the savegame's GUID is used is a strong indicator that the original console was hacked.

3. The game creates a globally unique data stream in a save file. Think Breath of the Wild's tracking of every place Link has walked / transported / died.... it's unique in all but the simplest of circumstances.

So, if implementing this, be careful how it's "sold", as users may misunderstand and think this feature can make CFW risk-free.

[ThatNerdyPikachu]

I’m currently implementing this in an easily reversible way that doesn’t write to PRODINFO at all by MiTMing set:cal.

However, @SciresM, if we want still want this in AMS in the first place, how do we want it toggle-able, maybe through a system setting?

[SciresM]

@ThatNerdyPikachu why mitm set:cal when you can mitm the CAL0 partition itself?

But yes, system setting would do.

[ThatNerdyPikachu]

You can MiTM BIS partition reads? If you can provide an example, I’ll switch to that, sounds way more effective.

[shchmue]

https://github.com/Atmosphere-NX/Atmosphere/blob/master/stratosphere/ams_mitm/source/fs_mitm/fsmitm_service.cpp#L266

[ThatNerdyPikachu]

oh.
I’ll need to look more into how fs_mitm does it then — thanks!

[ThatNerdyPikachu]

So should we keep a “zeroed-out” copy of PRODINFO in memory (generated on boot and saved to a file(?)), and just redirect to that? Or is there a better approach?

[SciresM]

@ThatNerdyPikachu not mitming the service saves handles in sm, which we care about. Check for file, if it doesn't exist, generate it and save to disk.

[SciresM]

Ah, meant to hit comment, not close and comment.

[SciresM]

After a little more consideration, system settings get overridden on update by careless users. Probably use a global flag instead.

[ThatNerdyPikachu]

Hmm, it should be hard to accidentally delete, I’ll do some thinking.

[sirocyl]

As #532 was, and #546 is, an implementation being worked on, consider this one closed when an implementation is ready to merge. Good work y'all :tada:

[PabloZaiden]

546 seems to be stale (and not being able to be merged) since May. Shouldn't this be re-opened?

[SciresM]

This issue isn't closed.

[sirocyl]

@PabloZaiden Not closed. The wording was changed for clarity; any implementation of this feature should close this issue.

[PabloZaiden]

Awesome. Looking forward to use this.
Thanks for the amazing work you've been doing.

[SciresM]

Closing this because I believe it's covered by the recently merged cal0 stuff.