Hacker News Reader

Comment by probably_wrong | Hacker News Reader

I've never tried YouTube, but I have downloaded videos from sketchier streaming websites using the web developer tools.

Almost all of them have the same protection: some code that triggers only when you open the tools and stops the video by creating a debugger statement you cannot skip and triggering some cpu-heavy code (probably an infinite loop, although I wouldn't discard cryptominers). More importantly this code also clears the network request information, making it more difficult to analyze the traffic sent so far. Note to Firefox devs: enabling "persist logs" should persist the logs. Don't clear them!

None of this is perfect and I never found a video I couldn't eventually download (timing attacks ftw), but I do wish I could find a deeper explanation on how this all works.

View on HN

>Almost all of them have the same protection: some code that triggers only when you open the tools and stops the video by creating a debugger statement you cannot skip

If you missed it, not so long ago there was a submission that evaded exactly this. Their solution is so simple yet effective: Recompiling the browser with the debugger keyword renamed. Made me smile.

https://news.ycombinator.com/item?id=36961445

Honestly recompilation shouldn't even be necessary, browsers should just let us disable the debugger statement when "clever" sites start taking advantage of it. This usage of debuggers to circumvent our tools is abuse and should be literally impossible unless we consent to it.

Our computers are our realms. God giveth and god taketh away.

Just wait until you won't even be able to open devtools on a WEI protected website. For your security, of course.

Can't wait when websites start voluntarily cutting themselves out of non-WEI traffic. This means we can take it and serve it, and we will.

Chrome Developer Tools allows this. There's a button in the Source tab to deactivate breakpoints from debug statements. The button looks like an arrow cut in half.

This doesn't work for debugger statements.

You're wrong, it very much does work for debugger

I believe the reason you and the person you're replying to disagree, is that it works for existing debugger statements, but seemingly doesn't work for debugger statements injected after you toggle the flag.

The "disable breakpoints" button is seemingly performing a one-time imperative action on toggle (maybe "find all the breakpoints + debugger statements in existing loaded code, and patch/unpatch them") rather than being a declarative state-change in the system (i.e. "disable this tab's access to the debugger/breakpoint logic itself").

I love this exchange. It’s so symbolic of how discussion and disagreement in general works

If I recall, you can work around this by putting a conditional breakpoint on the debugger statement and then setting its return value to just `false`.

You just need to disable breakpoints in the 'Sources' tab of dev tools and refresh. Then you can get the .mp4 or .m3u4 url that can be used with yt-dlp.

> Their solution is so simple yet effective: Recompiling the browser with the debugger keyword renamed

Not exactly what I'd call simple...

Conceptually simple at least :-)

Definitely a clever hack

Try Anti-Anti-Debug [0]. It's a simple extension to bypass those kinds of anti-debugging techniques. Made it in a few hours a while ago for similar reasons.

0: https://chrome.google.com/webstore/detail/anti-anti-debug/mn...

Can you make one for Firefox too? ;-)

it's a simple script, should be portable to firefox with minor modifications. The source code is available on Github [0].

0: https://github.com/Andrews54757/Anti-Anti-Debug

I don't think this will work out-of-the-box in Firefox. Firefox handles the console object differently than Chrome, especially when it comes to the console.clear() method.

In Firefox, when a console is cleared, it's not just the display that's cleared. The entire console object is reset. This means that any modifications made to the console object, such as redefining console.clear(), are lost when console.clear() is called.

You can try this on this demo [1] website that uses devtools-detector library [2]

[1] https://blog.aepkill.com/demos/devtools-detector/

[2] https://github.com/AEPKILL/devtools-detector

This is great. I was wondering why does it disable console.table, but then I went to one of my favorite shady sites I screw around with from time to time (I intercept and patch setTimeout/setInterval to disable particular function doing constant debug() injection), lo and behold tables dates and big arrays (not yet covered by your tool) spamming in console :o slowing down devtools window to a crawl.

For console.clear I have this

    window.console.clear = function clear() {console.log(clear.caller, "Asshole script called console.clear()")}

hoping I get a glimpse of what exactly is calling it.

Than you for this valuable tool; Looking forward to using it!

> some code that triggers only when you open the tools

I've seen this technique too, but I feel that this is a major flaw on the browser's side. It should be impossible to tell if the dev tools is open or not. Surely this can be done right?

A LOT of things should be impossible for the website to tell. Focus, drm, mobile/Desktop

All (3) Browser engines are anti consumer spyware. There is no way to convince me otherwise. Why google and apple are not fixing this is obvious but Mozilla just keeps disappointing.

I'm desperately waiting for a Foss alternative.

There is no reliable way to tell if they are, so developers have to either listen for sudden page height changes (which usually happens when the dev tool is open, however undocking it fixes the problem) or use one of the few dirty hacks with the Javascript objects, but these are getting patched every year.

One trick that sometimes works for me on Firefox is shift+right click the video -> This Frame -> Open Frame in New Tab. and the dev tools work there

Sometimes, especially if you're on the mobile version of the site, the video will be an actual <video> tag you can open in another tab.

Also, the "Open With"[0] browser extension can detect a video/frame's URL when you right click on it, if you want to use that to quickly open it in yt-dlp/mpv.

0: https://addons.mozilla.org/en-US/firefox/addon/open-with/

Have you tried using wireshark to analyze the traffic? That's the first idea I had since you said these pages are trying to detect your browser's developer tools.

You can use something like mitmproxy or HTTP Toolkit to examine things exactly, as those can't be interacted with or detected like the dev tools can.

You can also use mitmproxy to remove or add debugger statements.

How does that work with certificate pinning?

It doesn't, you'd have to unpin certificates in whatever application you're using. Browsers generally don't do certificate pinning though, they'll (correctly) respect your installed certificates, which would include the mitmproxy one.

I see, thanks.

I just use the logs of my filtering proxy.

What proxy do you use?

Reply on news.ycombinator.com