Anti-debugging, as a field, is just one of those things that I think is inherently distasteful. As in, the sole point of doing it isn't to make or fix something, like so much else in programming, it's to break something, and deny a feature. That just...feels like making a giant "screw you" to somebody else, which is very unpleasant.
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.
Important to clarify here that in describing the exploit, the author of this article is not doing anything wrong -- they're raising awareness of an issue with the Chromium dev tools that people absolutely should be made aware of. It's very much in the same vein as some of the "login interceptor" extensions that got published back when the tech community was trying to encourage sites like Facebook to switch to HTTPS. The full text of the article makes the author's intentions pretty clear, and I think it's good that they published this article.
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.
I think there is a distinction we can make here. What sets anti-debugging apart is not denying something -- after all, the point of cryptography is to make things impossible for adversaries -- but whom does it serve. In the case of anti-debugging it serves the manufacturer and third parties first, and user only gets secondary or tertiary benefits. Whereas things like full-disk encryption or encrypted messaging serve the user first. (Of course, not all crypto serves the user: imagine using MPC to bypass the Fourth Amendment protections.)
I see your point, but I think this distinction is incidental.
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.)
I strongly disagree with this. Taken to its extreme, A machine where you can push a button and kill everybody everywhere is a fundamentally immoral technology.
The laws of nature are not devoid of ethics either. Screw nature. Plague came from nature.
A technology that can affect all people on Earth is rarely strongly limited to killing people. Look at explosives. They can be used to kill and maim people at scale, and also to build roads and tunnels in mountains. Look at viruses, think of all the diseases they cause. Now also look at viral vectors that deliver medicines into patient cells, including some of the modern anti-COVID vaccines. Look at cryptography.
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.
Yeah, distasteful is putting it lightly. Its entire purpose is to deny us our computing freedom. To protect their code from us like we're some adversary in their threat model. To prevent us from understanding what our system is executing.
This is at least as ugly as binaries which embed themselves into VMs to prevent and detect reversing. I don’t condone either one but can understand first one up to a point. Rigging a website… That’s really some next level ugliness.
Yeah. Those video game obfuscation schemes work like that. Denuvo and its friends. It's a virtual machine with a instruction set designed for maximum obfuscation. Some of game's code is compiled for it in order to make reverse engineering and cracking ridiculously hard. These technologies are known for killing the game's framerate and responsible for cracked versions being superior to genuine ones.
> malicious people will use it to their advantage.
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.
Erm, the three letter agencies target their exploits usually a bit deeper in the system - and these light anti debugging exploits are indeed for ransomware, trackers, adware and obfuscation, to protect IP and malicious behavior. Afaik in the realm of web, mainly to conceil shaddy behavior. Tracking, data mining, ...
I agree, because DRM has potential to outlive copyright law. Sure, many DRMs are broken, but there are many that are not. As the arms race escalates, DRM will become harder and harder to crack (I can think of a few offhand that AFAIK have never been cracked publicly, like the encryption used on cable systems in the US). The people in control of the various DRM systems are not even thinking about future noninfringing use, because they're not even thinking about current fair use in developing these systems. These are largely people who do not think copyright should expire that are driving these anti-public efforts.
Also, think about what a waste of talented peoples' time this represents. Probably many person-hours are spent implementing these increasingly sophisticated DRM systems, and then many more trying to crack them, rendering all of it completely pointless.
You’re right, I never thought about the long term effects of DRM. But we’re really just talking about its effects on our grand children. To be fair we’ll all be dead by the time works made today will go into the public domain.
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!
That implies you'd dislike this more than most because it prevents "breaking" things efficiently by intentionally crippling tools and throwing out red herrings.
It's possible to reverse engineer closed source software. I have done 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.
"Closed source" is a pretty poor analogy, since regular executables can be disassembled or even decompiled. Reversing is a big field. DRM and obfuscation to prevent that reversing is a better analogy.
This technique is already being used in commercially available pop up scripts… everywhere.
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.
> 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.
The article notes that the technique does not require logging to the console.
One scenario where you have to do something similar to this is as an extension author, because some websites are hostile to the user. A couple examples from my past:
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?
Let me know if you manage to actually find a lawyer willing to file an ADA lawsuit over a website. I tried, most bar associations don't even have anyone to refer you to.
You could fix it by doing Object.getOwnPropertyDescriptor(div, 'id') to check if there's a getter instead of plain value, not sure about performance impact though.
But a work around might be being able to craft a Proxy target that looks like a HTMLDivElement but has a handler that captures the get('id') operation, and does the same thing as the example. In that case it may not be so easily inspectable...
No need to do any of this when you control V8. Chrome DevTools can decide to run code iff there are no side effects (by executing it and bailing on any writes/native functions like alert marked as having side effects). Presumably it costs some overhead to do that and that is why logging elements to the console does not enable the "no side effects" flag.
But I think the point is more about how does a regular web app in web land detect devtools? Not, how does an app with DevTools privileges (via a Chrome extension, or connecting to the remote debugging port) that controls V8 via debugging APIs detect/prevent if DevTools pane has been opened (there are even APIs/events for this in chrome remote debugging protocol), so no need to rely on the side effects bailout you mention if your goal is to detect DevTools panels and you have "control" over V8.
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.
> it wouldn't be worthwhile to track down every possible case.
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?
This seems like a bug, even a security relevant one?
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.
"This trick can of course be very helpful not only to attackers but to other entities as well (such as big companies who want to alter their code when it is being investigated by researchers for example)."
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 cant. Just getting a list of defined setintervals and settimeouts would help a lot, like you can access Event Listeners. Afaik devtools has no facility to do that :(
As with every frontend nuisance, such as blocking the right click, showing alerts etc, this can be sidestepped easily [0]. While this technique may deter some people, just like the above annoyances, at the end of the day the old adage still holds — if it's in the frontend, the end user can do anything and everything they want. That said, this is still cool in the technically interesting sense, haven't seen someone do this before.
This reminds me of anti-memhack techniques in game dev. If you store the players money or health in a variable, there are tools to help you find it in memory. These tools work by scanning the memory for the value you give it, changing the value in game (take damage, earn money, etc) and scanning the first scan's results for the new value.
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.
Depending on how commercially minded the company is it might range from protecting “DLC” or something else that the user should[0] pay for, anti piracy, or to extend the grace period in which certain content remains undocumented online.
To prevent wide usage of mass produced cheats, called trainers.
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.
I don’t get the thing with the ID attribute. Why doesn’t the browser engine query it as soon as the div is created in the DOM tree? Otherwise getElementById wouldn’t work.
The HTML engine probably has an internal list of ids to quickly look them up. The dev tools, however, access it externally. It's quite likely they simple use `treeNode->getId()` without being aware that this call respects JS overwrites.
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.
While this can be seen as somewhat useful, nothing stops you from deactivating breakpoints inside of the "Sources" section in devtools.
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.
I don’t buy that. That’s only true if the author is the only person to ever discover this. Instead, he had brought to light what others may know and probably do, to judge by his prior article. This means we are now aware and the Chromium devs may implement changes.
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.