starred/devtools-detector

Fork 0

mirror of https://github.com/AEPKILL/devtools-detector.git synced 2026-04-26 23:15:48 +03:00

[GH-ISSUE #76] Very easy to bypass #145

New issue

Open

opened 2026-03-13 17:26:24 +03:00 by kerem · 9 comments

kerem commented

2026-03-13 17:26:24 +03:00

Owner

Originally created by @doctor8296 on GitHub (Nov 4, 2024).
Original GitHub issue: https://github.com/AEPKILL/devtools-detector/issues/76

console.log = () => {};
console.table = () => {};
Function.prototype.constructor = () => {};
setInterval = () => {};

for (let i=0;i <1e6; i++) {
    clearInterval(i);
}

delete Navigator.prototype.userAgent

And a lot more.
The only people likely to open the developer tools intentionally are those who know exactly what they’re doing, which might make this method less effective in practice, even if it technically works as designed.

The only case I can imagine is comical one:
@ Open devtool
@ Sees it has devtool protection
@ Nah, I am too lazy to go any further

However, I really appreciate the impressive amount of research that’s gone into ensuring compatibility across nearly all browsers. Thanks for all the hard work!

Originally created by @doctor8296 on GitHub (Nov 4, 2024). Original GitHub issue: https://github.com/AEPKILL/devtools-detector/issues/76 ```js console.log = () => {}; console.table = () => {}; Function.prototype.constructor = () => {}; setInterval = () => {}; for (let i=0;i <1e6; i++) { clearInterval(i); } delete Navigator.prototype.userAgent ``` And a lot more. The only people likely to open the developer tools intentionally are those who know exactly what they’re doing, which might make this method less effective in practice, even if it technically works as designed. The only case I can imagine is comical one: @ Open devtool @ Sees it has devtool protection @ Nah, I am too lazy to go any further However, I really appreciate the impressive amount of research that’s gone into ensuring compatibility across nearly all browsers. Thanks for all the hard work!

kerem commented

2026-03-13 17:26:36 +03:00

Author

Owner

@doctor8296 commented on GitHub (Nov 5, 2024):

By the way, here another way to stuck the browser without ability to debugg it during crash trigger:

(async function f() {f(), f()})();

@doctor8296 commented on GitHub (Nov 5, 2024): By the way, here another way to stuck the browser without ability to debugg it during crash trigger: ```js (async function f() {f(), f()})(); ```

kerem commented

2026-03-13 17:26:41 +03:00

Author

Owner

@AEPKILL commented on GitHub (Nov 8, 2024):

Yes, this library merely adds a little bit of difficulty for the debuggers. If there's a higher demand for anti-debugging, you can try WebAssembly or VMP, or implement the core logic on the server side.

@AEPKILL commented on GitHub (Nov 8, 2024): Yes, this library merely adds a little bit of difficulty for the debuggers. If there's a higher demand for anti-debugging, you can try WebAssembly or VMP, or implement the core logic on the server side.

kerem commented

2026-03-13 17:26:46 +03:00

Author

Owner

@doctor8296 commented on GitHub (Nov 8, 2024):

@AEPKILL, my focus is more on strengthening the system—using unredefinable methods and similar techniques. I’m researching this a lot and working to counter script-based attacks, which are the most common. I’ve developed anti-cheat measures for several browser games, and while I haven’t yet implemented my strongest concept, it's beyond any existing protections out there, the same can be pretty much be used by your library. Because the only purpose of it is to protect source code and prevent debugging, so I think it can be useful in this case.

Maybe I will show later some of my tricks and how they can be used to protect this library from almost any "script based attacks"

@doctor8296 commented on GitHub (Nov 8, 2024): @AEPKILL, my focus is more on strengthening the system—using unredefinable methods and similar techniques. I’m researching this a lot and working to counter script-based attacks, which are the most common. I’ve developed anti-cheat measures for several browser games, and while I haven’t yet implemented my strongest concept, it's beyond any existing protections out there, the same can be pretty much be used by your library. Because the only purpose of it is to protect source code and prevent debugging, so I think it can be useful in this case. Maybe I will show later some of my tricks and how they can be used to protect this library from almost any "script based attacks"

kerem commented

2026-03-13 17:26:51 +03:00

Author

Owner

@AEPKILL commented on GitHub (Nov 9, 2024):

@doctor8296 Your ideas are very interesting. I'm particularly intrigued by the unredefinable methods you mentioned. Can you share some more details about how they work?

@AEPKILL commented on GitHub (Nov 9, 2024): @doctor8296 Your ideas are very interesting. I'm particularly intrigued by the unredefinable methods you mentioned. Can you share some more details about how they work?

kerem commented

2026-03-13 17:26:56 +03:00

Author

Owner

@doctor8296 commented on GitHub (Nov 9, 2024):

@AEPKILL sure, but I'd prefer to talk privately about it, because some of protection methods are not public yet.
Where can we do that, I have plenty of options, like telegram or discord (same username) or maybe just over email

@doctor8296 commented on GitHub (Nov 9, 2024): @AEPKILL sure, but I'd prefer to talk privately about it, because some of protection methods are not public yet. Where can we do that, I have plenty of options, like telegram or discord (same username) or maybe just over email

kerem commented

2026-03-13 17:27:01 +03:00

Author

Owner

@AEPKILL commented on GitHub (Nov 9, 2024):

@doctor8296 Sure, I understand your need for privacy. I think email would be a great way to have this discussion. Please send your thoughts and details to my email address at [a@aepkill.com]. Looking forward to hearing from you soon!

@AEPKILL commented on GitHub (Nov 9, 2024): @doctor8296 Sure, I understand your need for privacy. I think email would be a great way to have this discussion. Please send your thoughts and details to my email address at [a@aepkill.com]. Looking forward to hearing from you soon!

kerem commented

2026-03-13 17:27:06 +03:00

Author

Owner

@AEPKILL commented on GitHub (Nov 9, 2024):

@doctor8296 It's almost 11 pm local time. I'm going to bed now. Sorry I might not reply to your emails and messages promptly.

@AEPKILL commented on GitHub (Nov 9, 2024): @doctor8296 It's almost 11 pm local time. I'm going to bed now. Sorry I might not reply to your emails and messages promptly.

kerem commented

2026-03-13 17:27:11 +03:00

Author

Owner

@nabilfreeman commented on GitHub (Sep 8, 2025):

There is always the solution of overriding the loaded source file, changing all isOpen calls to false and refreshing the page which completely negates this library. But I think this is still a decent first line of defense against most normies.

@nabilfreeman commented on GitHub (Sep 8, 2025): There is always the solution of overriding the loaded source file, changing all isOpen calls to false and refreshing the page which completely negates this library. But I think this is still a decent first line of defense against most normies.

kerem commented

2026-03-13 17:27:16 +03:00

Author

Owner

@doctor8296 commented on GitHub (Sep 8, 2025):

There is always the solution of overriding the loaded source file, changing all isOpen calls to false and refreshing the page which completely negates this library. But I think this is still a decent first line of defense against most normies.

@nabilfreeman It is not always. Try remove it from a properly obfuscated source code.

@doctor8296 commented on GitHub (Sep 8, 2025): > There is always the solution of overriding the loaded source file, changing all isOpen calls to false and refreshing the page which completely negates this library. But I think this is still a decent first line of defense against most normies. @nabilfreeman It is not always. Try remove it from a properly obfuscated source code.