Avoid the detection of "whether Chrome DevTools(console) is open"

There are so many ways to detect the use of DevTools, that it would be difficult to block them all. As DevTools gains new features, there are new ways to detect its use. Any third-party tool to block detection can't be trusted to block 100% of detection techniques.

There is a bug reported to the Chromium team here on the idea of integrating detection blocking directly into Chrome.

Disable javascript

The only way to definitively block any detection of the use of DevTools is to disable javascript. You can still execute javascript in the DevTools console when javascript for a page is disabled. I have found it sufficient to disable javascript immediately after opening DevTools, like this:

1. Open DevTools Command+Option+J (Mac) or Control+Shift+J (Windows, Linux)
2. Type the hotkey to open the command menu – Cmd+Shift+P (Mac) or Ctrl+Shift+P (Windows, Linux)
3. Type dis and hit return to select the Disable Javascript option.
4. … inspect the website …
5. Re-enable javascript by evoking the command menu and typing ena and hit return (selecting the Enable Javascript option)

Of course, this method is useless for monitoring malicious code because no code is running when javascript is disabled. But at least it may give you a chance to set breakpoints before re-enabling javascript.

Chrome DevTools Protocol

It may be possible to use the Chrome DevTools Protocol to connect to a separate instance of Chrome and inspect a website without opening DevTools in that instance at all:

The Developer Tools front-end can attach to a remotely running Chrome instance for debugging. For this scenario to work, you should start your host Chrome instance with the remote-debugging-port command line switch:

chrome.exe --remote-debugging-port=9222

Then you can start a separate client Chrome instance, using a distinct user profile:

chrome.exe --user-data-dir=<some directory>

Now you can navigate to the given port from your client and attach to any of the discovered tabs for debugging: http://localhost:9222

The most popular method of detecting if dev tools is open involves invoking console.log() which happens only when devtools is opened.

Below is an example:

var image = new Image();Object.defineProperty(image, 'id', {    get: function() {        $('#<element_to_remove_on_detection>').remove();        console.clear();    }});console.log('%c', image);

In the above case, a new image object is created and the getter is overridden for the 'id'. When console.log is invoked, the getter is called as well.So basically, any time the getter is called, the website knows that the devtools has been opened because console.log() doesn't get called until devtools is open.It is a really clever way of detection. Nonetheless, when trying to debug such code, Simply using extension like Resource Override and injecting

console.log = null;

Into the head of the page should stop the website from detecting if devtools is open.

For me, I just added a breakpoint at the top of the offending script, then ran Image = null in the developer console.

I found this solution by googling how websites do that, which brought me this stackoverflow post, I could see in my console a new Image was being logged, so setting Image to null causes an error, which causes the detection to fail.