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

31–40 of 53 posts

Re: Evading JavaScript anti-debugging techniques

#31

Post by 8chanAnon »

russelg wrote: post #25
matheusmoreira wrote: post #19

Earlier quoted context omitted.

> 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?

They don't need to detect the devtools being open, debugger is a no-op when the devtools aren't open so you can just run it in a loop forever.

The debugger command abuse can be defeated (as already mentioned in this thread). A devtool detector is used in order to invoke stronger blocking methods such as forcibly reloading the web page until the console is closed.

Re: Evading JavaScript anti-debugging techniques

#32

Post by 8chanAnon »

connor4312 wrote: post #16
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 l…

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?

Re: Evading JavaScript anti-debugging techniques

#33

Post by 8chanAnon »

js2 wrote: post #22
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…

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

Yeah. I used to do that sort of stuff a lot in my younger years, lol.

Re: Evading JavaScript anti-debugging techniques

#34

Post by 8chanAnon »

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

Earlier quoted context omitted.

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.

Re: Evading JavaScript anti-debugging techniques

#36

Post by leptons »

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…

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.

Re: Evading JavaScript anti-debugging techniques

#37

Post by TechBro8615 »

codetrotter wrote: post #29
TechBro8615 wrote: post #26

Earlier quoted context omitted.

Also note that as far as the sketchiness scale goes, this is basically a 5/10. Now consider the same tools in the hands of malware distributors. For example, I've seen these anti-debugger techniques on NFL piracy websites when I tried to investigate why my CPU was pinned to 100% while I was streaming the game.

> I've seen these anti-debugger techniques on NFL piracy websites when I tried to investigate why my CPU was pinned to 100% while I was streaming the game Probably safe to assume they were mining cryptocurrency with your browser while you were watching the stream.

Probably. I got distracted by the game so I never found out. And I only visit those websites when I'm watching a stream anyway. Really it's quite a clever distribution vector, since it involves long sessions and any experts in the audience will be too distracted to look too deeply, or at least unmotivated to investigate and publish research against a site that helps them watch the games they want to watch. It's a symbiotic relationship in a way...

I did notice the ad serving infrastructure seemed quite sophisticated. There were so many domains and proxies and redirects. Luckily uBlock Origin blocks almost all of them. And usually, I can avoid any of the "bonus" features by opening the video player iframe in its own tab (but sometimes this isn't possible, or the video player tab has some scripts to make it annoying to run in isolation).

One thing I like to do during the commercial breaks is paste the URL of the site into GitHub Code Search. This always leads to interesting results, including blocklists, people's personal media scrapers, or sometimes even the (re-)publishing infrastructure of the sites themselves. It's also a great way to find alternative URLs or other streaming sites.

Re: Evading JavaScript anti-debugging techniques

#39

Post by pcthrowaway »

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.

Couldn't you load the site with devtools open and javascript disabled, add the override, and enable javascript?
Post reply on HN