Youtube for Android TV can't be intercepted

[Hezuikn]

output.txt

[pimterry]

Thanks for the report! That's the youtube app, right?

I think this script isn't your issue, because youtube doesn't actually use certificate pinning at all. I've just tested, and with a fresh emulator using HTTP Toolkit without unpinning anything, I can capture all HTTPS and replace response content (e.g. replace all images) in Youtube no problem, like this:

While this script will remove certificate pinning, it doesn't disable absolutely all HTTPS checks entirely, that would be very insecure & dangerous.

If you want to intercept traffic, you will need to install your certificate into the device. If you're trying to debug HTTPS and you're not sure how to do this it's easiest to just use HTTP Toolkit which is free and does this automatically, take a look at https://httptoolkit.tech/android/ (or https://httptoolkit.tech/blog/inspect-any-android-apps-http/ for detailed instructions).

If you want to use another tool, that's fine too, but you need to install your certificate into the system trust store on the device. There's a blog post with lots more details on how that works internally here: https://httptoolkit.tech/blog/intercepting-android-https/

[Hezuikn]

its the yt tv app(https://play.google.com/store/apps/details?id=com.google.android.youtube.tv); i was already using httptoolkit; intercepting https requests from the normal youtube app works; with httptoolkit being disconnected the tv app functions properly as soon as i reconnect it does the thing on the screenshot;

[pimterry]

Ah, I see, ok. I've reopened this to track that more clearly.

I've tried to test this, but I don't have a paid Youtube TV account. When I do use the basic functionality though, it doesn't show any failed connections in HTTP Toolkit at all for the initial app setup.

Can you share what appears in the HTTP Toolkit UI? Are there any lines like Connection rejected for <domain>?

[Hezuikn]

when you say paid account do you mean tv.youtube.com or yt premium? what version of android and the app did you use testing?

[Hezuikn]

"at all for the initial app setup." there was no setup for me

[Hezuikn]

i have tested with the same results on android 11.0(R), 8.1(Oreo), 5.1(Lollipop) and these apks: https://files.catbox.moe/plwp84.apk (httptoolkit), https://files.catbox.moe/0bkk3k.apk (com.google.android.youtube.tv) both x86

[pimterry]

Ah, my mistake, I was testing this: https://play.google.com/store/apps/details?id=com.google.android.apps.youtube.unplugged. A different app, also from Youtube, but called "Youtube TV", not "Youtube for Android TV".

That Aborted connection to youtube.com is a strong signal that there is indeed issues here, and I can reproduce the same thing. You're totally right then, thanks for reporting this!

I'll try to find some time soon to do a deeper investigation, but I don't know when I'll have time to dig into this. Notably I can see that from the Frida script that setDefaultHostnameVerifier is being called at runtime though, which is a pretty likely pinning candidate. It seems plausible that the stub there isn't quite working quite correctly, or at least that looking at the usage of that API in the APK might lead towards the rest of the pinning code.

Let me know if you make any progress yourself, any hints in the right direction would be very useful to work out how to extend the script to cover this case.

[pimterry]

you just drag the APK on to the screen:

Yep, that'll do it! Alternatively you can use adb install <apk> on the command line. There's also alternatives like Aurora or GApps that you can install instead of the Google Play store to install apps more easily.

[Hezuikn]

its works when excluding 443; could the app be made to "ignore" non http packets?

[pimterry]

If you disable 443, this probably works because it's not intercepting lots of interesting traffic at all. Do you still see the data you're looking for in HTTP Toolkit in that case?

It's not usually possible in cases like this to detect non-HTTP packets, because Youtube is rejecting the connection before the initial handshake is completed, so the HTTP or non-HTTP data inside the connection hasn't been received yet. There is a small chance that it's possible if Youtube is declaring that it's using a non-HTTP protocol via ALPN in the TLS handshake, but I've looked at this before for other similar use cases and it doesn't seem to be widely used for that.

Given that, there's not much we can do automatically. I think that means that disabling forced redirection for port 443 is probably your best option, if that does work for you.