Cracking a "Developer Tools Killer" script…
Tags: developertools, debugging, browsers
Published: 2023-11-14 10:16:06

---
title: Cracking a "Developer Tools Killer" script…
published: true
description: People try to block you from using browser developer tools to inspect their pages. And fail.
tags: developertools, debugging, browsers
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jzhesmp5do330plgmiug.png
# Use a ratio of 100:42 for best results.
# published_at: 2023-11-14 10:03 +0000
---

The other day I got an email from somebody who took one of my developer tools courses and he said he found a website that cannot be debugged. So I looked, found a nasty script and show you how to work around that one. You can [watch the video on YouTube](https://www.youtube.com/watch?v=ZGHvDChh2aQ) or read on… 

{% youtube ZGHvDChh2aQ %}

I was intrigued and asked if I can see the web site. Turns out it's one of those, let's say a website with lots of videos, not necessarily all of it safe for work and not necessarily all of it legal. I went into my private browsing mode, turned on my VPN and took a look in Firefox what's going on there. 

I looked at the sources and I [found a script](https://github.com/codepo8/console-killer/blob/main/consolekiller.js) that's actually pretty good in trying to prevent you from using the developer tools. So let's take a look at what it does and how we can work around it. I un-minified and documented the script and what it does are some really nasty things. You can [check it on GitHub](https://github.com/codepo8/console-killer) and also [try the demo page yourself](https://codepo8.github.io/console-killer/demo.html).

```javascript
var tryCount = 0;
var minimalUserResponseInMiliseconds = 200;
function check() { 
    console.clear();
    before = new Date().getTime();
    debugger;
    after = new Date().getTime();
    if (after - before > minimalUserResponseInMiliseconds) { 
        document.write(" Dont open Developer Tools. ");
        self.location.replace(
            window.location.protocol + window.location.href.substring(
                window.location.protocol.length
            )
        );  
    } else { 
        before = null;
        after = null;
        delete before;
        delete after;
    }
    setTimeout(check, 100);
}
check();
window.onload = function () { 
    document.addEventListener("contextmenu", function (e) { 
        e.preventDefault();
    }, false);
    document.addEventListener("keydown", function (e) {
        // Ctrl+Shift+I 
        if (e.ctrlKey && e.shiftKey && e.keyCode == 73) { 
            disabledEvent(e);
        }
        // Ctrl+Shift+J 
        if (e.ctrlKey && e.shiftKey && e.keyCode == 74) { 
            disabledEvent(e);
        } 
        // Ctrl+S 
        if (e.keyCode == 83 && (navigator.platform.match("Mac") ? e.metaKey : e.ctrlKey)) { 
            disabledEvent(e);
        }
        // Ctrl + U 
        if (e.ctrlKey && e.keyCode == 85) { 
            disabledEvent(e);
        }
        // F12
        if (event.keyCode == 123) { 
            disabledEvent(e);
        } 
    }, false);
    function disabledEvent(e) { 
        if (e.stopPropagation) { 
            e.stopPropagation();
        } else if (window.event) { 
            window.event.cancelBubble = true;
        } 
        e.preventDefault();
        return false;
    }
};
```

The first, and common thing is to block the context menu and all the keyboard shortcuts to open developer tools by adding handlers on the document. `Ctrl+Shift+I` is blocked, so is `Ctrl+Shift+J`, `Ctrl+U` and `F12`. They also blocked `Ctrl+S` to prevent saving the website to look at the source code. All these handlers call the `disabledElement` function which stops the propagation, does a cancel bubble, prevent default and returns false for good measure.

So that means all of the normal ways of opening developer tools should not be available to you when you have that website open in your browser. 

The other clever thing they did was actually embed that into the main HTML document instead of having a killer script like [we have here](https://github.com/codepo8/console-killer/blob/main/consolekiller.js). So you can not block the script resource as it would mean you can't see the page at all.

If you try the script, it seems that it is working in blocking you out. I'm on a Mac and for some reason `Option+Command+I` still works, which allows me to open developer tools. Then I encountered the next naughty thing that they're doing here, which is that they have a `debugger` statement in there. I've seen this in several websites - they throw you into an endless loop with a `debugger` statement. If you try to skip over that one, it will keep going to the same point and stop you there. 

The script also reads how long it takes for you to turn the debugger on and off. And then it does a document write and reload of the page if it happens. I don't know why that's in there. I never managed to trigger it. But, okay, good luck. Probably there was something else that people tried to do. If you know, tell me about it.

Then they do a `setTimeout` with 100 milliseconds and keep calling that `check` function, which does a `console.clear()` and invokes that debugger. Now how can we work around that? The easiest way is to turn off all breakpoints. When you reload the page, you don't have that debugger problem any longer. 

![Deactivating all breakpoints in Chromium Developer Tools](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/llpheqabt4ii3x2a3tny.png)

What you still have is that they're doing another naughty thing which is clearing the console continuously to prevent you from entering anything. One way around that is to turn on preserve log. That way you get a report that the console was cleared but you can still use it.

![Preserving log in console](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jib9kkzmlojpcdmhzgmd.png)

The biggest mistake that the script creators did was not to use a closure (probably because they need the `timeout`). So, as the `check()` function is a global one, I can also simply overwrite it with `function check(){return true;}` and it stops annoying me. 

It is fun to see how far people go to stop you from looking into their code. And there are legitimate reasons to turn off debugger tools for certain web sites. For example, when I worked on Microsoft Edge, we considered proposing a standard HTTP header that would disallow developer tools for banking sites and such. Bad actors [do use Developer Tools with remote access software to fake for example bank transfers](https://discourse.mozilla.org/t/allowing-websites-to-disable-client-devtools-to-stop-bank-scammers/79286/3) so it would make sense to have a standard way. This hacky script is impressive, but in the end just a nuisance.