[HN Gopher] Evading JavaScript anti-debugging techniques
___________________________________________________________________
Evading JavaScript anti-debugging techniques
Author : hazebooth
Score : 49 points
Date : 2023-08-01 19:35 UTC (3 hours ago)
(HTM) web link (www.nullpt.rs)
(TXT) w3m dump (www.nullpt.rs)
| jkingsman wrote:
| 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
| nullpt_rs wrote:
| 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.
| jalino23 wrote:
| thats interesting. I've always seen that but always ignored it,
| not knowing what I could use it for
| lini wrote:
| 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.
| j0hnyl wrote:
| This won't work with obfuscated JS.
| chmod775 wrote:
| 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.
| 8chanAnon wrote:
| >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.
| crazygringo wrote:
| > _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?
| 8chanAnon wrote:
| 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).
| SyrupThinker wrote:
| 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.
| gmerc wrote:
| Unfortunately that won't be an option with Web Integrity....
| 8chanAnon wrote:
| 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.
| hoten wrote:
| Would the "Local Overrides" feature of chrome devtools simplify
| this workflow for you?
| 8chanAnon wrote:
| 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.
| hoten wrote:
| 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.
| connor4312 wrote:
| 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."
___________________________________________________________________
(page generated 2023-08-01 23:00 UTC)