Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Evading JavaScript anti-debugging techniques

nullpt.rs

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Evading JavaScript anti-debugging techniques

#11

Post by 8chanAnon »

crazygringo wrote: post #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?

The Javascript statement is simply "debugger". Very easy to abuse. Of course, there are other techniques for breaking devtools. There are JS libraries designed for the purpose of detecting that the dev console is open. The response may be to run the debugger command, freeze the code, reload the web page or, worse, do some serious hanky-panky (it's not hard to crash the web browser; an endless loop can do that).

Re: Evading JavaScript anti-debugging techniques

#12

Post by 8chanAnon »

chmod775 wrote: post #4
lini wrote: post #3

You 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.

>That will not pass integrity checks (the script inspecting its own code).

I've not seen anything like that. The integrity checks are generally limited to verifying the document location and the presence of certain elements in the DOM. Obfuscation techniques have become so sophisticated that integrity checks are not really necessary. Bot challenges (such as the one used by CloudFlare) may go so far as to test graphic elements like the canvas to ensure that the JS is actually running in a browser but I don't think this is a common thing for the average website that just wants to keep bots from scraping them.

Re: Evading JavaScript anti-debugging techniques

#13

Post by j0hnyl »

lini wrote: post #3

You 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.

This won't work with obfuscated JS.

Re: Evading JavaScript anti-debugging techniques

#14

Post by hoten »

8chanAnon wrote: post #9
hoten wrote: post #5

Earlier quoted context omitted.

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.

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.

Re: Evading JavaScript anti-debugging techniques

#16

Post by connor4312 »

8chanAnon wrote: post #2

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…

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."

Re: Evading JavaScript anti-debugging techniques

#17

Post by nullpt_rs »

jkingsman wrote: post #6

I'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

I knew I forgot to mention something :) I do love this option but I wasn't able to get it to work with this obfuscation technique either.

Re: Evading JavaScript anti-debugging techniques

#18

Post by matheusmoreira »

8chanAnon wrote: post #9
hoten wrote: post #5

Earlier quoted context omitted.

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.

> Problem is that the devtools are not available due to the repeated abuse of the debugger and console clear commands.

Sounds like we need a way to disable web site access to those commands.

Re: Evading JavaScript anti-debugging techniques

#19

Post by matheusmoreira »

8chanAnon wrote: post #11
crazygringo wrote: post #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?

The Javascript statement is simply "debugger". Very easy to abuse. Of course, there are other techniques for breaking devtools. There are JS libraries designed for the purpose of detecting that the dev console is open. The response may be to run the debugger command, freeze the code, reload the web page or, worse, do some serious hanky-panky (it's not hard to crash the web browser; an endless loop can do that).

> Problem is that the devtools are not available due to the repeated abuse of the debugger and console clear commands.

What methods do they use to detect debugging tools and how do we defeat them?

Re: Evading JavaScript anti-debugging techniques

#20

Post by [deleted] »

8chanAnon wrote: post #2

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…

[deleted]
Post reply on HN