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).
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.
>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.
This assumes that the script contains the word "debugger" in clear text, however it may not. It may decrypt or descramble a string and then eval() it. Your approach wouldn't catch that.
