[Andrews54757]

I've noticed that a lot of websites will try to prevent you from using the debugger. They use various techniques ranging from calling `debugger` every second to entrapped sourcemaps to make debugger features work against you!

Take a look at disable-devtool [1], it surprises me just how many methods can be used to detect usage of an invaluable tool that should be a user's right to use. These "exploits" should really be patched browser-side, but I don't see any active efforts by browsers to fix this.

I've created a simple anti-anti-debug extension [2] that monkey-patches my way around these anti-debug scripts. It works fine for now, but I can't imagine it working consistently in the long term once the inevitable arms race begins.

How can we get Google, Mozilla, etc... to care about dev tool accessibility?

[1]: https://github.com/theajack/disable-devtool

[2]: https://github.com/Andrews54757/Anti-Anti-Debug

[cxr]

Imagine if browser developer tools were reasonably architected so e.g. opening the DOM inspector didn't provide a vector for anti-tamper code targeting the JS debugger to DOS your attempts to poke at the CSS or read network requests. Or get this: for non-hostile content—like something you yourself have written—maybe you could have the debugger and the inspector open in separate windows, or even have multiple object inspectors open on different objects at the same time. Gee. Fuckin' novel idea. Maybe this is something we'll be able to look forward to once the year 2000 rolls around.

[supriyo-biswas]

A simple way to solve this issue is to just deprecate the debugger statement and have people rely on setting up breakpoints manually, or request an explicit opt in into the debugger statement so that random websites don’t hijack it.

[Andrews54757]

That would be helpful, but there are also other methods that don't involve using the debugger. For example, one technique involves periodically printing a custom object to the console with a toString getter. This is programmatically called by the browser only when the devtools are opened. This allows the website to know when you've opened devtools and they will redirect/block/crash your browser in response.

[no_time]

They don't need to deprecate it. I remember reading a blogpost here that was about bypassing these kinds of checks. They recompiled SpiderMonkey with the debugger() method renamed to something else.

[jeroenhd]

I've pondered why websites who are that afraid of reverse engineering don't simply feed the browser mock data or kill a user's session (with a five minute IP block) when the browser requests a source map. Almost all browsers request them by default the moment you open the debugger and normal users very rarely hit the debugger.

Sure, it'd be trivial to circumvent such a block, but it'd easily inconvenience most of the low-hanging fruit enough that things like community maintained ad blockers could become ineffective. Surely simply never serving ads to people who open the dev tools would prevent the 99.9% of normal users from using effective ad blockers in their browsers.

[Andrews54757]

I've seen some websites do this in the wild, it's why I recommend turning the sourcemaps off in the troubleshooting section of my anti-anti-debug tool.

It's pretty easy to circumvent this method, but honestly the user shouldn't have to configure their browsers to be resistant to anti-debugging. From the side of the website, it should be impossible to know if the debug tools are just open.

[iudqnolq]

I haven't seen any anti reverse engineering on sites with significant technical expertise. For example Facebook just prints a very reasonable warning. I've seen anti-debugger stuff only on relatively shady and cheap websites. I suspect the issue with your suggestion is it would require replacing static file serving with a smarter backend.

[quickthrower2]

The ultimate way is process everything on the server with a sockets to webapi adaptor on the client. Then all you see is commands coming from the server to pull various strings.

[youngtaff]

Even then some sites detect the DevTools connection and prevent you from normal (on-site) actions