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

Question

Today I see this post Find out whether Chrome console is open .

@zswang gave the way to detect if Chrome DevTools(console) is open. That's really suprise me, then I began to think is there any way to walk around this detection technique?

There are two way to detect chrome DevTools is open(detail in above post)

1. Using Object.defineProperty

   I can walk around this, it can be assign to another function.I have tried Object.defineProperty=null ,then the detect function die(I know write a mock function is better, here just an example)

2. Using obj.__defineGetter__ (Object.prototype.__defineGetter__)

   Object.prototype.__defineGetter__= null would not break the detection, how to walk around?

Finally, I have to say I don't like to be monitored.Hope there is a proper way to walk around.

Residual

How would you achieve either of the above on someone elses web page? – Disclaimer

@JaromandaX, userscripts? – Bobbysoxer

@Jaromanda X I think tempmonkey or some script manager can make my code excute before site owner's code, I don't know the detail.Actually , I also come up this question, but I afaid someone would say that should be another question..so not include at here. – Residual

changing Object.defineProperty could (probably will) kill a lot of functionality in most websites – Disclaimer

Some websites are using deceptive techniques to evade ad blockers and avoid detection by pausing their naughty activity if they detect the developer console open. – Thales

Answer 1

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

Thales

the Chrome DevTools Protocol doesn't solve it as I know? – Ament

on mac it seems to not accept the --remote-debugging-port=9222 param, or I am making a silly shell mistake? – Chukchi

@Chukchi It works for me in Edge when I type the following in to the terminal: /Applications/Microsoft\ Edge.app/Contents/MacOS/Microsoft\ Edge --remote-debugging-port=9222 and it should be the same for Chrome (I don't have Chrome installed, so didn't test). – Thales

Answer 2

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.

Cuyler

This one doesn't work for me. Or cuz I'm using Chromium? – Mcclenon

But for me it will run the console.log even the the devtool is not open. I verified it by setting 10 sec setInterval and check the console after a minute or two. And saw that all console.logs triggered even when closed – Plainlaid

Also when I use this approach I see that console.log is not invoking the getter and I see it like : id: (...) and after clicking on (...) I can invoke the getter. I tried console.log(image.id) it worked for me but the problem is it is triggered even the console is closed. – Plainlaid

Answer 3

This does not solve the root issue, but many websites punish by redirecting the page. Paste javascript:window.onbeforeunload=()=>{return true;}; into the URL bar and click cancel when the website tries to redirect you, then check "Prevent this page from creating additional dialogs" when the website does it again and click cancel.

Duchess

Answer 4

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.

Footplate

Answer 5

You could try something like this:

var oldDefineProperty = Object.defineProperty;

Object.defineProperty = function() {
    var firstArg = arguments[0];
    arguments[0] = _.extend({
        get id() {
            return firstArg.id;
        }
    }, arguments[0]);

    return oldDefineProperty.apply(this, arguments);
}

var element = new Image();
element.id = "something";
Object.defineProperty(element, 'id', {
    get: function() {
        alert("detected");
    }
});
console.log('%cHello', element);

<script src="http://underscorejs.org/underscore-min.js"></script>

This seems to prevent the alert from showing for me. I'm using the _extend function from Underscore. I don't know if I'm missing anything but just playing around.

As for __defineGetter__, this was deprecated so you'd expect this not to be used.

Hydrodynamics

Answer 6

DevTools > Settings > Preferences > Under "Sources", disable "Enable JavaScript source maps".

One site was using a source map to detect a web debugger.

For example:

const script = document.createElement("script");
script.innerHTML = "//# sourceMappingURL=/app.js.map";
document.body.appendChild(script);

If it keeps hitting the debugger statement, enable "Deactivate breakpoints" (breakpoint icon with a slash, last icon in the Sources right panel toolbar).

Accompanist

Answer 7

Try changing the view port to mobile, and refresh the page.

50% chance it will work.

Allanson