Manual Token Retrieval Not Possible On Android

[Primative1558]

Following the instructions from this repository's wiki leads to a dead end when running the NSO app on Android: https://github.com/frozenpandaman/s3s/wiki/mitmproxy-instructions

The current version of the NSO app (v. 2.10.1) appears to have some procedure to prevent logins when the network traffic is being monitored by mitmproxy. When attempting to log in when both the proxy and CA system certificate are configured on emulated/rooted Android 11, the NSO app still disallows a login. This attempt yields the error code 2817-0599. This problem still occurs when the Android's root status is hidden from NSO by Magisk, as a login attempt will fail and yield a different error code if it is not hidden. Error code 2817-0599 has been seen in an older Splatoon fan project when using Android: https://github.com/eliboa/ink-proxy/issues/1

Please update the mitmproxy instructions page on the wiki to confirm that manual token retrieval is no longer possible on Android. Also, since the NSO app now requires Android 8.0 or above, any unrooted Androids running 6.0/6.0.1 will also no longer work, which needs to be noted in the instructions page.

EDIT: It would also be helpful to correct this comment, since it is no longer true: https://github.com/frozenpandaman/s3s/issues/21#issuecomment-1251894033

[samuelthomas2774]

Coral (the Nintendo Switch Online app) still doesn't have a custom network security policy and as far as I can tell isn't manually validating the server certificate.

I can't find what that error code means but this suggests it is to do with root detection or modifying the app, as if it is actually sending the request it is accepting the certificate:

What error code do you get without Magisk and without mitmproxy?

[frozenpandaman]

FYI, just a quick note that I'm traveling for this next week, so I can respond & look into this more when back home.

Thank you for the prompt response and interest, Sam! I'll look forward to hearing OP's answer.

It would also be helpful to correct this comment, since it is no longer true

I'm not going to retroactively edit a 2 year old comment that's obviously not true anymore, though.

[Primative1558]

I can't find what that error code means but this suggests it is to do with root detection or modifying the app, as if it is actually sending the request it is accepting the certificate:

Do we know what else could cause an invalid token, as in that post?

What error code do you get without Magisk and without mitmproxy?

I don't get an error code without either, I'm able to log in properly.

[Primative1558]

I'm not going to retroactively edit a 2 year old comment that's obviously not true anymore, though.

I don't quite see how the comment is obviously not true anymore. When setting up this procedure it seemed still valid to me.

[samuelthomas2774]

Do we know what else could cause an invalid token, as in that post?

It's mostly to do with root detection, anti-debugging, code injection, etc. The native library that generates the token also uses the [package name](https://developer.android.com/reference/android/content/Context#getPackageName()) and signing certificate, so if you modify and repack the application it will always return invalid tokens.

2.10.1 also uses automatic integrity protection, although this just causes the app to crash. Nintendo's checks also used to cause the app to crash but now just cause it to generate invalid tokens.

Also, since 2.9.0 the x86/x86_64 library always seems to generate invalid tokens. You need an arm device for it to work, so probably not an emulator.

What error code do you get without Magisk and without mitmproxy?

I don't get an error code without either, I'm able to log in properly.

Sorry I meant like, the error code without hiding Magisk/root and the error code without mitmproxy separately. Also, when using mitmproxy what requests do you see?

I'm not going to retroactively edit a 2 year old comment that's obviously not true anymore, though.

I don't quite see how the comment is obviously not true anymore. When setting up this procedure it seemed still valid to me.

It's from two years ago, and Nintendo breaks token generation most updates. (The comment is actually still technically correct though, and it's always needed root access and root detection bypasses so nothing has really changed, except most people probably can't use a virtual device now.)

[niyari]

This is off topic. I believe version 2.10.1 worked fine in a certified secure x86_64 emulator (one with Google Play pre-installed). Changing the environment properly protects the app. I agree that the broad technical details have not changed.

[Primative1558]

if you modify and repack the application it will always return invalid tokens.

Thank you for explaining that. I did not modify the app, and it was downloaded from the Play Store before Magisk was installed (which allowed root on an emulated production build of Android, as in here).

Also, since 2.9.0 the x86/x86_64 library always seems to generate invalid tokens. You need an arm device for it to work, so probably not an emulator.

Since I was able to log in before rooting on an emulator (and here as well), it is possible to log in on an emulated Android. Could the library be affected by rooting or the CA system certificate installation?

Sorry I meant like, the error code without hiding Magisk/root and the error code without mitmproxy separately.

I was getting error code 2816-0583 with MagiskHide turned off for NSO. Based on this thread, it seems that code indicates the NSO app detecting root on the device.

I stopped getting error 2816-0583, and began getting error 2817-0599 instead when MagiskHide was enabled for NSO. This was basically an older version of Zygisk since I was using an older version of Magisk to use it on an emulator.

Also, when using mitmproxy what requests do you see?

I'm not familiar with using the tool, aside from trying to find the access tokens for SplatNet. What types of requests should I be looking for?

It's from two years ago

Since the most reliable method to root Android on an emulator is a three-year old procedure, I still find the comment a bit misleading.

Nintendo breaks token generation most updates.

Thank you for clarifying that.

(The comment is actually still technically correct though, ... except most people probably can't use a virtual device now.)

Got it. And yes, I think the current issue is that emulated Android is no longer be usable here.