21–30 of 53 posts
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.
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…
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.
Unfortunately that won’t be an option with Web Integrity….
And before a developer for these commerce websites jumps up and says “ah but supreme are trying to prevent bots from buying up all of their merch and scalping it”:
Supreme are restricting supply so they can maximise profits.
They are selling on the web rather than through traditional retail outlets using this method not to reach a wider audience for the audience’s sake but to have a larger number of people who are willing to pay an even higher price.
The web, the system that brings free information to the masses requiring no knowledge of the underlying technologies, is too important to compromise for these e-commerce platforms attempting to have their cake and eat it to.
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
Earlier quoted context omitted.
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?
Unfortunately that won’t be an option with Web Integrity….
Glad you have said it. And before a developer for these commerce websites jumps up and says “ah but supreme are trying to prevent bots from buying up all of their merch and scalping it”: Supreme are restricting supply so they can maximise profits. They are selling on the web rather than through traditional retail outlets using this method not to reach a wider audience for the audience’s sake but to have a larger numb…
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.
As us "old school crackers" would say, "NOP those out!"
As for obfuscation, you can unpack the scripts in order to do the needful, then use the proxy to "transparent redirect" requests for them to your own locally hosted unpacked and modded version.
Earlier quoted context omitted.
Glad you have said it. And before a developer for these commerce websites jumps up and says “ah but supreme are trying to prevent bots from buying up all of their merch and scalping it”: Supreme are restricting supply so they can maximise profits. They are selling on the web rather than through traditional retail outlets using this method not to reach a wider audience for the audience’s sake but to have a larger numb…
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.
Probably safe to assume they were mining cryptocurrency with your browser while you were watching the stream.
Earlier quoted context omitted.
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?