Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

ericdraken.com

Post reply on HN
Print view View original

361–370 of 659 posts

Re: Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

#361

Post by docmars »

1vuio0pswjnm7 wrote: post #157
faraggi wrote: post #45

Earlier quoted context omitted.

> among other things what else do you MITM for?

MITM is kind of a silly term for what the computer owner is doing when using a forward proxy. If the computer owner binds the proxy to a localhost address, the unencrypted requests need only go over the loopback. There need be no unencrypted requests travelling over the LAN. The computer owner, the "MITM", is on their own computer sitting in between an application and the network interface. That is exactly where they…

For any gamers out there, Reshade's installer is another example where TLS istn't implemented properly. It fails to download effect/shader packages for basic setup on up-to-date Windows machines because it requires that you disable TLS 1.3 globally on Windows so it can use 1.1 or 1.2.

[1] https://reshade.me/forum/troubleshooting/8746-reshade-v-5-8-...

Re: Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

#362

Post by dividuum »

throwaway2037 wrote: post #334
ben_w wrote: post #140

Earlier quoted context omitted.

If the ads were silent banners changing the aspect ratio of the videos, I wouldn't mind them. 30 second un-skippable advert to see a 7 year old 45 second clip? I press "back" and watch neither. Thinking of supporting creators: I looked at Nebula a while back as an alternative; I think there was some UX issue back then, but they've likely improved it and I should look again.

If the ads were silent banners changing the aspect ratio of the videos, I wouldn't mind them. This is an interesting idea. It is already used to some extent in live football matches broadcast on TV. The sidelines have their ads replaced. I think your idea is a good one and deserves some testing by Google/YouTube.

You just know it would end up looking like the TV in idiocrazy after a year.

Re: Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

#363

Post by esaym »

I found it odd that the article complained about squid proxy being slow. There was a memory leak issue in the 4.x versions, it was fixed sometime in the 5.x version. I dealt with it for like 2 years but could never figure out where the leak was. I charted[0] the process size, you can see in June where I upgraded to 5.7. Before then, I had just cron'd a restart every week.

[0] https://i.imgur.com/hRromEd.png

Re: Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

#364

Post by lucb1e »

punnerud wrote: post #15
phito wrote: post #8

Very nice writeup. I was kinda hoping to find a way to MITM devices that don't allow the installation of custom CA's. I have some IoT devices that do not expose a local API and only exposes the data through the cloud, and would like to capture the device to cloud traffic... I guess the only way to do that would be to dump the flash memory, replace the CA and reupload the dump to the device?

It’s called certificate-pinning if they “hard coded” a certificate, yes then you have to replace/remove it and move the same certificate to your MITM proxy to decrypt traffic. A good write up here for ways to try to intercept IoT devices without any hardware/firmware job: https://robertheaton.com/2019/11/21/how-to-man-in-the-middle...

Note for other readers: the two sentences in the parent post have nothing to do with each other. The Robert Heathon post does not describe how to break cert pinning without needing hardware/firmware modifications unfortunately.

The only relevant thing to repeat here might be this

> if you can’t get access to your IOT device’s hardware in order to add a new root CA to it, your journey mostly ends here. Don’t lose hope though. Leave your setup running for a while and see if anything strange happens. When I attempted the above process on my baby’s crib, the device refused to trust Burp’s certificate and so refused to complete a TLS handshake with my laptop. But after a minute or two of repeated failures, the crib started sending out some of its system status data over plain, unencrypted HTTP!

Re: Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

#365

Post by 38 »

jjallen wrote: post #122

I just subscribe to YouTube premium to support my favorite application out there. I learn so much from the people who spend hours and hours making videos every month that I am more than happy to pay a measly $13 or whatever it is every month to YouTube.

[flagged]

Re: Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

#366

Post by lucb1e »

sgammon wrote: post #178

Remember, app authors, pin your cert roots! :)

if you want to DRM your app, yeah. In that case, also don't forget to check for microG or root (super scary stuff, a user having admin on their own device, imagine!) and ensure that the device isn't muted during ads as well as disabling app backups (they might be able to get at their own data!!1) and turning off screenshots (no benefit, but it can be claimed to be a security benefit just like denying root and turning off backups, and it will serve to further annoy the user).

If you don't mind that users can see what you're leaking to the server from their device, or sending to their device, then please don't use certificate pinning, or at least make it an option...

Not sure which side you're on here

Re: Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

#367

Post by alwayslikethis »

yukIttEft wrote: post #347
userbinator wrote: post #193

Earlier quoted context omitted.

Yes, and this also answers the other comment about what else I MITM for: blocking devices that I can't inspect the traffic of is another reason, since the proxy is the only way out of the network.

layperson here: won't, say a banking app complain about the now new cert it deals with instead of the bank-cert?

Banking apps generally hardcode their certs in to prevent this, so this wouldn't work unless you find a way to replace that cert too.

Re: Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

#369

Post by Lio »

imglorp wrote: post #343
Lio wrote: post #274

Earlier quoted context omitted.

Part of the objection to ads is the tracking. If you subscribe to YouTube premium you’re making yourself even more identifiable. You end up seeing more creepy ads elsewhere on the web using your viewing history to target you. Versus an adblocker which will help hide you from Google everywhere.

I'd like to address the concept of "ads are creepy" which you will hear often. It's a false equivalence. Most prominently you'll see the flag under "privacy settings" something like "don't show me relevant ads"; this is obviously a manipulative placebo. Ads are not the problem. That creepy feeling is the awareness that "they know everything about you", or literally how your vivisected intellect is presented in a mark…

That’s a very interesting point.

It does seem weird though that the surveillance firms would go to the lengths of using dark patterns and persistent nagging to get users to allow targeted ads if it didn’t matter to them.

Re: Block YouTube ads on AppleTV by decrypting and stripping ads from Profobuf

#370

Post by rollcat »

rs_rs_rs_rs_rs wrote: post #21
greyface- wrote: post #17

Earlier quoted context omitted.

> It does tend to get me profiled as a "bot" by CloudFlare Since Cloudflare employees are known to lurk here, I'd like to know: is this considered a false positive, or working as intended?

Not a CF employee but I am pretty sure it's working as intended as they built and use this: https://github.com/cloudflare/mitmengine

> We consider an HTTPS connection to be intercepted when there is a mismatch between the expected client request signature corresponding to the browser identified by the User Agent, and the actual client request fingerprint of the request.

Sounds like something that would be "trivial" to defeat, by means of "emulating" other TLS implementations more closely?

Post reply on HN