Evading JavaScript anti-debugging techniques
1–10 of 53 posts
Re: Evading JavaScript anti-debugging techniques
#2Interesting 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.
Re: Evading JavaScript anti-debugging techniques
#3You can also use a MITM proxy tool to intercept the JS files and modify their response body to remove or replace the `debugger;` statements with something else. Might require inspecting the JS files first to see what needs to be replaced exactly, but should not take more than a few minutes.
Re: Evading JavaScript anti-debugging techniques
#4You can also use a MITM proxy tool to intercept the JS files and modify their response body to remove or replace the `debugger;` statements with something else. Might require inspecting the JS files first to see what needs to be replaced exactly, but should not take more than a few minutes.
That will not pass integrity checks (the script inspecting its own code).
It will also not work if the script is some initially obfuscated string that is passed to eval() or something more complex assembling the actual code on the fly.
Re: Evading JavaScript anti-debugging techniques
#5Interesting 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…
Would the "Local Overrides" feature of chrome devtools simplify this workflow for you?
Re: Evading JavaScript anti-debugging techniques
#6I'm surprised to not see Chrome's handy "Never pause here" menu that appears when you right click any line of JS, including debug breakpoints. This is typically what I do when there's a debug in an intervaled function (simple anti-debug commonly found on some video sites).
Example: https://i.imgur.com/BsphnEu.png
Re: Evading JavaScript anti-debugging techniques
#7I'm surprised to not see Chrome's handy "Never pause here" menu that appears when you right click any line of JS, including debug breakpoints. This is typically what I do when there's a debug in an intervaled function (simple anti-debug commonly found on some video sites). Example: https://i.imgur.com/BsphnEu.png
thats interesting. I've always seen that but always ignored it, not knowing what I could use it for
Re: Evading JavaScript anti-debugging techniques
#8> Once upon a time, whenever you tried to open your devtools on Supreme's website, you found yourself trapped in a pesky debugger loop.
Could somebody here explain what that means, since the article doesn't? What's a debugger loop? What is the actual JavaScript code that somehow prevents debugging, and how does it accomplish that?
Re: Evading JavaScript anti-debugging techniques
#9Interesting 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…
Would the "Local Overrides" feature of chrome devtools simplify this workflow for you?
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.
Re: Evading JavaScript anti-debugging techniques
#10> Once upon a time, whenever you tried to open your devtools on Supreme's website, you found yourself trapped in a pesky debugger loop. Could somebody here explain what that means, since the article doesn't? What's a debugger loop? What is the actual JavaScript code that somehow prevents debugging, and how does it accomplish that?
Using a `debugger;` statement allows you to trigger a breakpoint with code.
This only gets activated when the devtools window is opened, so placing this statement in a frequently executed piece code will continuously interrupt whatever you are doing in the devtools when you use them.
I assume in the past the tooling might not have had the necessary configuration options to suppress that, but nowadays you can just disable debugger statement breakpoints to avoid it.