Luma3ds: [Feature Request] Telemetry Block

Created on 31 May 2017  Â·  22Comments  Â·  Source: LumaTeam/Luma3DS

So I know there are some closed and locked issues on the matter, but having read through all of them and in light of some new information, I find that I can only open a new issue since the previous ones are no longer open for updates.

A post on GBATemp has brought to light that usage data is sent to Nintendo's servers despite disabling the options in System Settings. The relevant post is here.

Since the previous reasons on why disabling usage data seems to be based on the fact that Nintendo included a built in option to opt-out, this new information shows that this built-in option does not cover everything that could get a homebrew user banned.

Summarized; whenever a game or homebrew app is running and also has an open internet connection, title information and duration online is sent to Nintendo regardless of the settings you have on the 3DS. This means that any homebrew that establishes an internet connection to any server also sends info to Nintendo. This alone is enough to risk getting restricted.

This could possibly be avoided by simply sending a different Title ID when using Homebrew. Even if Luma3DS does not directly do it, some kind of patch that homebrew makers could use that allows them to define a different TitleID to be sent when online could be implemented.

Since this feature request has been denied in the past due to the belief that the built-in settings would be enough, I was hoping that with this new information, should this feature still not be considered that a new reason as to why be presented.

Thank you for your consideration. I don't view this as a discussion forum and will not be responding to any replies unless it's a request for more information from the contributors.

drama duplicate enhancement

Most helpful comment

I did some testing using the SSL patch from @SciresM and think I found the network request mentioned in the gbatemp thread that @AnalogMan151 linked.

It's a request made to https://nasc.nintendowifi.net/ac and it includes the following fields in the POST data: gameid, sdkver, titleid, gamecd, gamever, mediatype, makercd, unitcd, macadr, bssid, apinfo, fcdcert, devname, servertype, fpdver, devtime, lang, region, csnum, uidhmac, userid, action, ingamesn

But as far as I can tell, this request is only sent by applets/games that use friends list features. So I'm pretty sure this can't leak homebrew info unless the homebrew uses the frd:* services.

All 22 comments

We're following the discoveries actively elsewhere, and that post didn't provide any proof of its claims. As far as we know until now, data which can lead to banning is only sent while the SpotPass option is turned on. Obviously other data could be being sent, but we haven't found anything potentially compromising yet. All we can recommend to do is:

  • recommending that the option be turned off
  • recommending not to play online with anything out of region or not coming from the eShop (reminding also that in this latter case we don't support piracy)

I'll leave the discussion open (in case proof comes to light), but keep it civil and free of entitlement (not referring to you, but to potential commenters) or I'll close and lock.

Are communications encrypted on an open network, or would it be easy enough to determine this stuff using a linux distro and wireshark or something like that? I know I have a dongle that does promiscuous mode on *nix...

Is the banwave related to BOSS? Also could downgrading friend list stop the bans?

@urherenow there is a patch to skip SSL checks so you can use a proxy to sniff requests. https://github.com/SciresM/3DS-SSL-Patch

Might be a bit irrelevant to the topic, but - is it possible to implement a feature that would make a log of console web activity over 48 hours? Like, to where it connects and what data it sends, especially during sleep mode and while using SpotPass(console still uses SpotPass in sleep mode to snatch news or maybe some new game stuff, even then you have it off, right? Like, Swapdoodles are delivered via SpotPass, if I get it right). Mayhaps this kind of log would be solid proof of how Nintendo gets their hands on titleid data and how it's used.
Onto the topic - rather than blocking telemetry, may it be easier to implement some sort of listing feature, where user would fill configuration file with titleid's of all homebrews installed, and then Luma would use Download Play titleid to mask them and make appear differently for Nintendo servers, since it's suspected that it's homebrew cia's are what might be the trigger for console ban? I'm not sure how easily such feature would be implemented, but I guess it might work out? Especially since checking titleid isn't that hard on your own.

Downgrading friends list now.

ALL RIGHTS RESERVED
On May 31, 2017 01:32, "TLNiles" notifications@github.com wrote:

Might be a bit irrelevant to the topic, but - is it possible to implement
a feature that would make a log of console web activity over 48 hours?
Like, to where it connects and what data it sends, especially during sleep
mode and while using SpotPass. Mayhaps this kind of log would be solid
proof of how Nintendo gets their hands on titleid data and how it's used.
Onto the topic - rather than blocking telemetry, may it be easier to
implement some sort of listing feature, where user would fill configuration
file with titleid's of all homebrews installed, and then Luma would use
Download Play titleid to mask them and make appear differently for Nintendo
servers, since it's suspected that it's homebrew cia's are what might be
the trigger for console ban? I'm not sure how easily such feature would be
implemented, but I guess it might work out? Especially since checking
titleid isn't that hard on your own.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AuroraWright/Luma3DS/issues/477#issuecomment-305097194,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AbLLUttG1f8EeQDq_-yByO46Ux93OtHgks5r_QlxgaJpZM4Nq6Q1
.

So to make it clear this thread isn't for speculation or asking for features but for discussing tangible proof. I gave a few recommendations earlier, and that's where we are at right now.

Well, from the information I have. Hexediting localfriendseed_B won't do anything because it's not signed by the bootrom signature, its signed by Nintendo. So hexediting would still leave us with the same seed.

@Derek1199

1) You don't sign with signatures, you sign with private keys (corresponding to the public keys everyone has).

2) The bootrom was made by Nintendo

hexediting would still leave us with the same seed.

With a corrupt one

yep, the 3DS sends the FriendCodeSeed over for the login and if the signature is bad you'll get the 121 error.

We can only hope Wiimmfi decides to add support for the 3DS in the near future because the days of online play for CFW users are numbered, hah

@tuxSH oh, OK. Thanks.

On Wednesday, May 31, 2017, piratesephiroth notifications@github.com
wrote:

yep, the 3DS sends the FriendCodeSeed over for the login and if the
signature is bad you'll get the 121 error.

We can only hope Wiimmfi decides to add support for the 3DS in the near
future because the days of online play for CFW users are numbered

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AuroraWright/Luma3DS/issues/477#issuecomment-305329852,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AbWyC1dDo76GVoEKvh1HvahTCVf7IEjpks5r_eKGgaJpZM4Nq6Q1
.

I did some testing using the SSL patch from @SciresM and think I found the network request mentioned in the gbatemp thread that @AnalogMan151 linked.

It's a request made to https://nasc.nintendowifi.net/ac and it includes the following fields in the POST data: gameid, sdkver, titleid, gamecd, gamever, mediatype, makercd, unitcd, macadr, bssid, apinfo, fcdcert, devname, servertype, fpdver, devtime, lang, region, csnum, uidhmac, userid, action, ingamesn

But as far as I can tell, this request is only sent by applets/games that use friends list features. So I'm pretty sure this can't leak homebrew info unless the homebrew uses the frd:* services.

With sending system info on in settings, npvk.app.nintendo.net/reports looks like it reports play times. It includes the LFCS in the User-Agent header. It also has a X-BOSS-TaskId header of upinfo. The way it reports the playtimes (I assume, they could be something else) leads me to believe there is another request it does to update the server and client index numbers. It reports them in in a sequential index like so:

KEY_000000000000,44
KEY_000000000001,9
KEY_000000000002,0
KEY_000000000003,11

Also when installing a new title the console (even while in FBI still) requests https://kagiya-ctr.cdn.nintendo.net/title//ext_key?country= but there does not appear to be any identifiable information. For homebrew titles it just returns a HTTP 404.

The code for the request made by FBI can be seen here: https://github.com/Steveice10/FBI/blob/master/source/core/util.c#L274
It looks like it's to get the seed for the title you just installed. It does send the titleID but it doesn't send any information that could be used to identify your system.

I have fiddler sessions for all of the requests. Also yes, seems like it's safe, sends nothing of the console. Also looks like it's unique at this stage to FBI (I was mistaken).

My investigation thus far shows no signs Luma should do anything to patch the telemetry out. Turning off SpotPass Sharing with Nintendo seems to remove all of the major telemetry functions that may be an issue, and if you turn off Friend settings (see what you're playing) it seems to turn off the rest.

The only thing I'm not 100% confident in is the Friend Notification setting. It clearly sends more data when opening apps and this is on, but I'm still working out how PRUDP functions. I however don't think it is sending anything of importance. It sends this data over UDP 9103, and does not obey proxy settings.

Edit: Also the server it sends data to seems to be on AWS.

Edit: Seems like I'd need to work out when the RC4 shared secret/key is exchanged. Ref: http://3dbrew.org/wiki/PRUDP

Do we know yet if it's ok to unhide what title were using as long as it's a
legit title ID were using?

On Jun 10, 2017 10:49 PM, "James Elliott" notifications@github.com wrote:

My investigation thus far shows no signs Luma should do anything to patch
the telemetry out. Turning off SpotPass Sharing with Nintendo seems to
remove all of the major telemetry functions that may be an issue, and if
you turn off Friend settings (see what you're playing) it seems to turn off
the rest.

The only thing I'm not 100% confident in is the Friend Notification
setting. It clearly sends more data when opening apps and this is on, but
I'm still working out how PRUDP functions. I however don't think it is
sending anything of importance.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AuroraWright/Luma3DS/issues/477#issuecomment-307608418,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AbWyC1wxbHBHzdz6q4uEruC2uKqHbx7bks5sC3_MgaJpZM4Nq6Q1
.

Realistically I'd recommend using Rosalina and HBL with the only titles installed having legit ID's. Run everything else via HBL. A lot of CIA apps are being converted to use HBL 2.0, so seems like no reason not to. If the main developer has not, a lot of people are posting on gbatemp.

Edit: Unless we can be sure the payloads sent over UDP don't contain data that could compromise the system using Rosalina to take over a title for HBL is the safest thing to do for homebrew apps. Unless someone else knows more than me that may contradict this, which is entirely possible. Blocking the UDP packets is not an option since they are required for online play.

These are good news :D

Based on @james-d-elliott's findings, there is no evidence to suggest any incriminating TIDs or otherwise are sent to Nintendo provided the SpotPass and Friends options are turned off, thus there is no reason for Luma itself to patch these options out.

I'm going to close this now; if more information is discovered regarding the data in the UDP packets, I'll reopen this issue.

Additional to what @Hikari-chin mentions if you use Luma 8 and Rosalina to launch homebrew (absolutely amazing and user friendly feature), and launch all other homebrew titles through the menu you're theoretically completely safe since the titles are never properly launched via home menu, and never have a ticket installed. You could also restore a pre-cfw NAND if you were really worried and wanted to remove all traces of CFW titles but I doubt that it's needed.

Was this page helpful?
0 / 5 - 0 ratings