First put the original web content into the original content editor, then put the content you want to display after detecting DevTools into the modified content editor, select the anti-debug techniques you want to apply, click Generate and then you can see the obfuscated result in the result editor.
You can also click the Test button after generating the obfuscated result to perform a quick test.
Technologies marked in red can detect the occurrence of DevTools, meaning that changes can be made to web content after DevTools are detected.
This technique disables the shortcuts F12, Ctrl+Shift+I, Ctrl+Shift+J, and Ctrl+U as well as right-clicking.
This is the most basic technique and has the least impact, as it is so simple to circumvent. Opening the DevTools through the hamburger menu, or opening them before loading the page still works.
This technique will constantly trigger breakpoints. The implementation is very minimalistic, but does the job.
This can be very annoying, but the effect is also very obvious. If there are only a few breakpoints in the whole code, you can use the "never pause here" functionality of the DevTools.
This technique will constantly clear the console, making it harder to debug JavaScript code via console.log and similar functions.
As it can be circumvented by setting the "Preserve log" function, its impact is only minor.
This technique modifies built-in functions to make them behave differently than expected. This implementation changes the behavior of console.log to output nothing
This is a bit annoying but not too problematic.
This technique detects the opening of the DevTools by comparing the inner- and outerWidth of the window.
This technique, at least in theory, could be effective, as it could stealthily alter the behavior of the code as soon as open DevTools are detected. For example, this could prevent malicious code to trigger in the first place. However, this implementation in particular can be tricked by opening the DevTools in "detached" mode, i.e. in a separate window.
This technique detects the opening of the DevTools by constantly check the time before and after a breakpoint. If the breakpoint is hit (which are enabled by default) we know that the DevTools must be open. The static threshold might not work well on all devices and the technique might also report a false positive if you switch to another tab.
This technique could also be abused to modify the content and script behavior on-the-fly only for people trying to analyze the website. However, the breakpoint might be suspicious.
This technique is basically the opposite of MonBreak: it detects if someone opens the DevTools and then sets a breakpoint.
This technique is more stealthy than MonBreak, but on the other hand useless unless somebody sets a breakpoint. As with previous techniques that detect the DevTools/debugger, this could be abused to make the website behave differently under analysis.
Opening the DevTools slows down the console, triggering this technique. This specific implementation calculates a baseline and thus only works if they are not open from the beginning already.
As with previous techniques, this one could be abused to hide client-side attacks.