Written on the front
In the past two days, I suddenly wanted to see Wenxin Yiyan's http communication request interface, so I thought about using F12 to take a look.
Who knew that when I just opened the developer tools, I was actually passively debugger.
The debugger keyword that was directly written by JS was brokenpointed. Okay, if you don't let debugging, don't let debugging, after closing the developer tools, you jump straight to a blank page.
In fact, I encountered a similar situation a few years ago, but I was only shallow at the time, and I didn't take it seriously, so I didn't study it. This time, I ran into it again, after all, it was no longer me back then, so I came to study it.
analysis
We all know what the browser's developer tools can do, serious usage: debug code logic during development, modify layout styles, improper usage: change elements to deceive people, find website interfaces to write crawlers, reverse js to crack encryption, etc., so the front-end is not safe, never trust the user's input.
This situation can indeed do some defensive operations on the user side, but it can also be bypassed. (PS: Thanks to the big guy in the comment area for his advice: developer tools Ctrl+F8 can disable breakpoint debugging, learned)
Start with a wave of analysis.
First of all, to prevent you from debugging with F12, first use the debugger keyword to prevent you from doing anything. Then, after you close it, you jump directly to a blank page and don't let you continue.
This requires a mechanism for developer tools to detect that you have opened the developer tools and jump to a blank page for you.
So, the key is to implement the detection of developer tools.
implement
After some research, it turns out that this debugger may not only be a function that prevents you from debugging, but also serves to determine whether the developer tools are open. How?
The debugger itself is just debugging, preventing you from continuing to debug the frontend, but the code doesn't know if the user has opened the developer tools, so you can't do anything further, such as jumping to a blank page.
However, one thing is that when you open the developer tools, the debugger hits the breakpoint, and the program stops there, and if you don't open the developer tools, the program doesn't stop to the breakpoint. That's right, that's how we can tell, time intervals. Under normal circumstances, the time interval before and after debugger is negligible. However, when you open the developer tools, this time interval is generated, and judging this time interval, you can know whether the developer tools are opened or not.
Directly on the sample code
<!DOCTYPE html>
<html>
<header>
<title>test</title>
</header>
<body>
<h1>test</h1>
</body>
<script>
setInterval(function() {
var startTime = performance.now();
// 设置断点
debugger;
var endTime = performance.now();
// 设置一个阈值，例如100毫秒
if (endTime - startTime > 100) {
window.location.href = 'about:blank';
}
}, 100);
</script>
</html>
Detection is performed by setting up a timed loop task.
In the case of not playing developer tools, debugger will not execute the page stuck, but it is precisely the use of debugger, if you open the developer tools will be stuck by debugger, then the context time interval will increase, in the judgment of the time interval, you can cleverly know that the developer tools are absolutely open, and then jump directly to the blank page, all in one go.
Test
Now for the test, turn on the F12
Close Developer Tools.
Perfect!
Write on the back
This does block access to information via developer tools, but only in the browser scenario. This is not the only way I want to get the API interface for the conversation.
Thanks to the comments for your advice: the developer tool Ctrl+F8 can disable breakpoint debugging
Or rather, isn't it good to open an agent to grab a package?
Author: Silver Sky Flying Feather
Link: https://juejin.cn/post/7337188759055663119