Interesting though it involves recompiling the web browser. I have encountered this issue on many websites and my response is to stream the website through a proxy server which can then save the content (both outgoing and incoming) to the local disk for analysis. Using the browser's debugging tool is a lost cause when you're dealing with obfuscated code. The approach that I use is to isolate the target JS, modify it by including calls to a websocket, save the code to disk and instruct the proxy server to load the code from disk instead of from the website. This way the website appears to work normally except with my modification. In some cases, it may be necessary to isolate an additional file or two due to dependencies.
The reason for the websocket is that the browser console is also rendered inoperable due to the debugger statements and console clear commands emanating from the website JS. A websocket is then the only way to transfer actionable information (such as a password or a secret link). It's not an easy or quick process but, by inserting websocket calls in interesting places, it is possible to figure out what the JS is doing. It also helps a lot to prettify the JS in order to study it. There are websites that can do that for you. Unfortunately, the prettification of the JS may break it so you're still stuck with doing the modifications in the original JS.
I built my own proxy server for this task but I imagine that the same may be possible with a tool like HTTP Toolkit but that means getting the Pro version.
In the VS Code JS debugger, there's an option to "exclude caller" on a call frame that which prevents stacks with the given caller from pausing at a location. As mentioned elsewhere, browser devtools have something similar with "Never pause here." Do you think there's more than tools can do to make your process easier?
I maintain the vscode debugger and found both the article and your comment interesting--there's a large overlap between "programs with anti-debugger techniques" and "programs that are hard to debug."
The overlap would be due to the JS obfuscation. This makes it both hard to debug and hard to run the debugger. What is needed is a way to unravel the obfuscation. This is mostly driven by a massive lookup table which contains text strings to be substituted for the coded vars in the JS. For example, a var called _0xff09b8 might be the code for 'toString'. Harder examples may involve coded vars that are used to call a function which generates the array subscript needed for the table lookup. It is literally mind-bending.
What I'm saying is that we need a way to get that table (array) and perform the substitutions in order to recreate the original code as text instead of numbers. This is likely way beyond the scope of a debugging tool. Or is it?
> Interesting though it involves recompiling the web browser.
Years ago I really wanted to disable the blink tag, so I just ran `perl -pie "s/blank/abcde/g"` on the binary and that worked well enough.
I'll bet you could so something similar with "debugger". On macOS, you'd break code signing, but you could re-sign it or strip the signing and let it run unsigned.
macOS verifies signatures of all apps. Windows comes close, if you configure enough GPOs, otherwise it just gives you a warning. (If you've seen the "unknown publisher" warning that literally everyone immediately clicks past, that's what I mean.)
Been doing stuff similar to this for decades(?) using the Fiddler proxy. It does so much stuff browser extensions or browser inspectors don't. One of my most important tools for website debugging/hacking/workarounds.
Local Overrides does what? Problem is that the devtools are not available due to the repeated abuse of the debugger and console clear commands. The other problem is storing content on the local disk for study. I don't think devtools do that.
Local Overrides stores the files you chose to override in a folder of your choosing. Subsequent requests for that resource while devtools is open will replace the contents with your local copy.
So the idea is store it in local Overrides, find the bad anti debug code and remove it, then you get back full control in devtools.
That might be useful in some simpler cases. Lately, I've been hacking into some really hard stuff that pretty much required the use of two web browsers due to caching, garbage popups and other matters. One browser doing the debugging and the other that I could cold-start without losing any work. The proxy server makes this division of labour possible.
The reason for the websocket is that the browser console is also rendered inoperable due to the debugger statements and console clear commands emanating from the website JS. A websocket is then the only way to transfer actionable information (such as a password or a secret link). It's not an easy or quick process but, by inserting websocket calls in interesting places, it is possible to figure out what the JS is doing. It also helps a lot to prettify the JS in order to study it. There are websites that can do that for you. Unfortunately, the prettification of the JS may break it so you're still stuck with doing the modifications in the original JS.
I built my own proxy server for this task but I imagine that the same may be possible with a tool like HTTP Toolkit but that means getting the Pro version.