Evading JavaScript anti-debugging techniques
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.<p>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.<p>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.