Abusing the Chromium Devtools Scope Pane
medium.com
medium.com
As an aside, I was very glad to see that if you browse to the example sites with firefox you get an angry "This only works in Chromium based browsers" popup.
Otherwise, agreed. Users have a fundamental right to inspect code that is running on their devices (https://anewdigitalmanifesto.com/#right-to-modify), and anti-debugging techniques (including invasive systems like DRM) are distasteful because they try to deny users that right.
I'm also pleased to see the Firefox alert, but there's no specific mention I can find about why it doesn't work in Firefox. I'd love to see some more information about that.
Technologies are fundamentally devoid of ethics, as are laws of nature. A technology only works well for "good guys" if it works equally well for "bad guys".
The intent of development does initially play a role, but anything deep enough will eventually find both bad and good uses, no matter how we see the initial intent.
(But for a specific application, the intent, of course, plays a major role.)
The laws of nature are not devoid of ethics either. Screw nature. Plague came from nature.
If laws of nature are not devoid of ethics, take any fundamental law, say, Newton's laws, or classical electrodynamics, or general relativity, anything from mathematics, and try to put it anywhere in the alignment matrix but the "true neutral" cell. Explain your answer — I will gladly listen! (Not ironically.)
And pray don't screw nature. There were numerous attempts, all ended badly, just look around. You are a part of nature, by screwing nature, you also screw yourself (which is of course your inalienable right), and, sadly, others around you.
There's a good chance they already are. Your average ransomware shop probably won't pull this off, but the three letter agencies around the world with insanely good staff and a lot of budget to search for flaws in some of the most used software? You bet they already have this in their toolbelt.
One of my university professors told me, during intro. to algorithms class, "some people understand things by building them, some by breaking them, and you are of the latter type". Nothing wrong about that, the way I see it!
Anti-debugging is a whole new level of obnoxiousness. Imagine a proprietary executable that scans your memory for debuggers and similar tools and then kills them or kills itself to make it harder for you. They use your own computer to subvert you.
How is it different from that? It isn't, really.
It’s been done since at least 2 years ago, and probably longer.
Currently, if you ever pop up dev tools and see the console is constantly being cleared, the reason is to obscure that the anti debugging software is in effect.
Once the script detects dev tools is open, it will definitely not follow the normal path of pop up creation but instead default to a Rube Goldberg machine obfuscating the entire operations.
The article notes that the technique does not require logging to the console.
A non-profit built an extension that would scrape data on advertisements from users' facebook feeds (opt-in). Facebook decided they weren't a fan of this so they introduced some special mouse event handlers designed to identify mouse events generated by extensions (and unfortunately, accessibility tools). I worked with the extension author to introduce a very elaborate set of tricks to forge the 'event not generated from user input' flag so that it would keep working.
Another scenario was that I maintained an accessibility extension (keyboard shortcuts, tooltips, etc) for a browser game. The developers became increasingly hostile to extensions in general because some people used extensions to cheat. Over time I had to do things like forge properties, mask events, hide DOM elements, forge property/method names and toString values, forge stack traces, and automatically shut off functionality in response to anti-cheat code changes (using a custom structural hashing algorithm for JS I created). They still eventually found ways to detect this unfortunately and used that to aggressively harass and then ban users of my extension, but I kept the arms race up for a year or two. Chrome is very bad at protecting extension users from hostile pages - there are various ways to detect whether a user has an extension installed/enabled and it's very difficult to stop that. Most extensions also need to inject scripts into the page to work due to the poor design of WebExtensions and that is also sadly detectable :(
Oddly one far more robust approach to work around these issues is by writing a custom Chrome debugger using their debugging protocol. Custom debuggers can forge real input events, block script execution, filter stack traces, silence exceptions, etc. I eventually prototyped a replacement using this approach and got it working but it really wasn't worth the hassle.
Why did this problem need a technical solution then? Wouldn't an ADA lawsuit have both solved it plus given Facebook a very strong financial incentive to never do such a thing again?
Either the ids should be queried without side effect or not queried at all without a user action.
The second idea, using 'toString()' is well know and also works in other OO languages, Java, C#, etc.
But maybe you're point was more about how would Chrome prevent this DevTools detection? I honestly don't think they would do this, but not because of "overhead"--simply because the console and debugging is useful, and it requires displaying elements, and inspecting those. So there will be no way around having actually printed out elements when DevTools is open. Except if you always printed them out whether it was open or not, but this would be too much overhead, as Chrome only lazily executes console commands (and optimizes things away if DevTools is not open).
This is hilarious I'm saying this to you because you work at Lighthouse---so I'm about to learn something I guess! :p ;) xx haha
From the comments on that bug there's other ways to detect devtools (including timing attacks), and it wouldn't be worthwhile to track down every possible case.
As someone who uses devtools debugging a lot I think that answer is reasonable, these kinds of shenanigans mostly only slow down and amuse expert debuggers.
I disagree with this conclusion. I think websites being able to detect or interfere with devtools should be considered a security bug. Do we give up on stopping XSS and memory corruption because it's too hard to detect every possible case of them too?
The article doesn't talk about it, but I probably would have at least tried to report this to Google - maybe the Author did as such and just didn't write about it.
Two people are having a conversation.
Person #1: How do I know the difference between an "attacker" and "other entities". Could a "big company" be an attacker.
Person #2: An attacker is trying to do something bad and does not want you to see what its doing. A big company is doing something good and does not you to see what its doing.
Person #1: Wait, how do I know if what its doing is bad or good if I am prevented from knowing what its doing.
You can bypass this by killing setintervals altogether.
After a few times clicking "continue", Chrome showed me where the debugger line is in a VM script. And then I can disable it as OP said.
To defeat this you just need to XOR the value with some bits. It doesn't stop a dedicated person at all, but 99% of cheaters are deterred. So it's good enough.
[0] not my view
In the flash game ecosystem you relied on distribution to make money off a game. You wanted multiple portals to buy rights to the game. If it can be beaten quickly you make less money. So it's worth closing the door on the lowest rung of mass market cheaters.
It might even be a feature; the C# debugger, for example, will call your custom `toString()` function in order to give a nice representation in the debug window. The problem here is, of course, that the debugger is running against untrusted code.
In fact, I'd probably argue that causing user-code to run at debug time is not a good idea even if the function is guaranteed to be side-effect free.
I also believe that the same anti-debugging technique is used by obfuscator.io, and is just a feature you can enable for when obfuscating your code on there. It's called "Debug Protection". It does about the same thing you shown in your blog post, making good use of the debugger statement.
This is good to improve JavaScript and Web security. After all this input simply adds to the arm’s race.
From a hacker perspective I also enjoyed it.