JSはブラウザ開発者ツールが開くかどうかを検出する方法を詳しく説明します。
場合によっては、現在のユーザがブラウザ開発者ツールを開いているかどうかを確認します。例えば、フロントエンド爬虫類検査のように、ユーザーがコンソールを開けたことを検知したら潜在的な爬虫類ユーザーと見なし、他のポリシーで処理します。この記事では、開発者のツールが開くかどうかを検出するためのいくつかの先端JSの方法を説明します。
一、toStringを書き換える（）
いくつかのブラウザについては、例えば、Chrome、FireFoxは、コンソールがオブジェクトを出力する場合、オブジェクトの参照を保留し、開発者ツールを開くたびに、オブジェクトのtoStringを再起動する（）方法は、結果をコンソールに印刷する。
したがって、オブジェクトを作成し、そのtoStringメソッドを書き換え、ページ初期化時にはコンソールに印刷し（ここではコンソールが開かれていないと仮定して）、ユーザーがコンソールを開いたときには、このオブジェクトのtoStringメソッドを呼び出して、ユーザがコンソールを開く動作がキャプチャされる。
以下は、Chromeユーザの開発者ツール状態がクローズからオープンに移行すると、この動作がキャプチャされ、コールバック関数によって処理される小さな例である。
このページで初めてコンソールを開くと検出がトリガされますが、コンソールが開いているウィンドウにURLを貼り付けてアクセスするとトリガされません。このページでコンソールが開かれている場合は、リフレッシュもトリガされません。
このような方法は比較的巧妙であるが、汎用性はなく、開発者ツールがオフ状態でオープン状態に移行する過程に限定されている。
二、デブガー
コード内のブレークポイントに似ています。ブラウザは開発者ツールを開く時（コードデバッグ時のデバッグモードに対応します。）デバッグフラグを検出した時（そこでプログラム中のブレークポイントに相当します）、プログラムの実行を一時停止します。
この時は、その青い「Resume script execution」プログラムを実行し続ける必要があります。この中には一定の時間差があります。この時間差が一定の値より大きいと判断することで、開発者ツールを開いたと考えられます。この方法は、開発者のツールを開けていないとデバッグタブが停止しないので、この方法は非常に良く、汎用性が高いです。
開発者ツールが開いているかどうかをdebuggerタグで検出する例を以下に示します。
しかし、上のコードには深刻なバグがあります。debuggagerの行に行った時、ユーザーが猫の脂を見つけたら、reume script executionボタンを押していません。そのままページを終了すると、今回の開発者ツールを検出できなくなります。実際の結果は予想と違って、深刻なバグだと思います。映画の中で演じているように、地雷を踏みました。足を上げないと命をつなぐ機会があると気づきました。デバッグレッテルに着いたら、これはコンソールが開けているかどうかを検査するコードです。私は退出して他の手段を使って迂回しました。
注意すべき点がありますが、この方法を使うとデバッグレッテルにカードがあるとき、ユーザーはデバッグガータグの近くのコードを見ることができます。経験があるユーザーなら一目で中の道が見えます。デバッグレッテルを隠したり、コードを混同したりして、できるだけ読みにくいです。debuggarラベルの前後の論理をどのように隠すかについては、これらのサイトを参照してください。（現在は2018-7-4 23:12:17有効です。）
http://app2.sfda.gov.cn/datasearchp/gzcxSearch.do?formRender=cx&optionType=V1
https://www.qimai.cn/
このようなプログラムを使うと、デバッグガーは停止しない可能性があります。例えばChromeブラウザのsourceパネルはデバッグゲージの文の中で停止しないように選択できます。
このボタンが点灯されたら、上のページをテストしたら、悲劇的にコードが無効になりました。
実はデバッグレッカーにはもう一つの効果があります。例えば、デバッグを反対するために、デバッグをトリガして、デバッグ者をデバッグに疲れさせたり、追加のコストをかけてJSをカバーしたりします。上に書いてあるいくつかのサイトはこのようにしています。
以下はデバッグggarタグを使ってjsデバッグを行う簡単な例です。
実際の例では、このウェブサイト：http://jxw.uou0.com/のjs検出スクリプトは、異なる状況に対しては、また別の反転戦略があります。
再现するには、ビデオアドレス解析を貼り付けてから、検出スクリプトをロードする必要があります。例えば、このビデオを解析してみてもいいです。
開発者ツールを開けずに解析して開発者ツールを開くと、このような検出方法が使用されます。
開発者ツールを開けてアドレスを貼り付けてビデオ解析を行うと無限デバッグがトリガされます。
もちろん、上記のシナリオに対応する一番簡単な方法はChromeブラウザをDeactive breakpointに設定して、上のスクリプトは料理を休んでいますが、これでは自分でも調整できなくなりました。反対側のやつが吐き気がします。良い方法はFiddlerを使ってウェブページを修正して内容をフィルタリングしてdebuggerのラベルをフィルタリングして完璧にこのコースを解読することです。
三、ウィンドウのサイズを検出する
ウィンドウのサイズを検出するのは簡単です。まず二つの概念を明確にします。ウィンドウのアウトサイズとinnerサイズ：
window.inner Width/window.innersHeight：視認エリアの幅が高く、window.innerswidthは縦スクロールバーの幅を含み、window.inner Heightは水平（横）スクロールバーの幅を含んでいる。
window.outerWidth/window.outerHeight：inner WidthとinnersHeightの上にツールバーの幅を加えます。
検出ウィンドウのサイズについては、自分で例を書かないようにします。これに対して、専門的に在庫を書きました。http://film.qq.com/film/p/topic/thwjlxby/index.htmlです。何しろ、何百のスターは、私よりも多く書きました。コードは簡単です。部分的にはgithubで説明しています。ここではコアコードだけを分析します。ここでは、ライブラリのコアコードの分析を貼り付けます。
1.window属性を使ってサイズをチェックすると、ブラウザの互換性に問題があるかもしれません。専門の先端ではないので、Chromeとffをテストしただけで大丈夫です。
2.この案にはまだ穴があります。Chromeブラウザを使って、開発者ツールウィンドウには四つのオプションがあります。
左寄り、右寄り、下寄りはいずれも現在のウィンドウの一部の空間を占有していることが検出されますが、独立したウィンドウはウェブページのウィンドウを開く空間を占有しないので、このような状況は検出できないので、このページに行って検証してもいいです。
四、まとめ
本稿ではいくつかの検査方法を紹介しました。それぞれ長所と短所があります。以下はその欠点に対する簡単な総括です。
toStringを書き換える()：開発者ツールがオフ状態からオープン状態に移行するプロセスのみをキャプチャすることができます。
debuggerタグ：ChromeブラウザのDeactive breakpoint
にチェックを付けると、debuggerタグは停止せず、捕獲できなくなります。
ウィンドウのサイズを検出します。開発者ツールが別のウィンドウで開いている場合は検出できません。
一、toStringを書き換える（）
いくつかのブラウザについては、例えば、Chrome、FireFoxは、コンソールがオブジェクトを出力する場合、オブジェクトの参照を保留し、開発者ツールを開くたびに、オブジェクトのtoStringを再起動する（）方法は、結果をコンソールに印刷する。
したがって、オブジェクトを作成し、そのtoStringメソッドを書き換え、ページ初期化時にはコンソールに印刷し（ここではコンソールが開かれていないと仮定して）、ユーザーがコンソールを開いたときには、このオブジェクトのtoStringメソッドを呼び出して、ユーザがコンソールを開く動作がキャプチャされる。
以下は、Chromeユーザの開発者ツール状態がクローズからオープンに移行すると、この動作がキャプチャされ、コールバック関数によって処理される小さな例である。
<html>
<head>
<title>console detect test</title>
</head>
<body>
<script>
/**
*
*/
function consoleOpenCallback(){
alert("CONSOLE OPEN");
return "";
}
/**
* ，
*/
!function () {
//
let foo = /./;
// ，
console.log(foo);
// toString
foo.toString = consoleOpenCallback;
}()
</script>
</body>
</html>このページで初めてコンソールを開くと検出がトリガされますが、コンソールが開いているウィンドウにURLを貼り付けてアクセスするとトリガされません。このページでコンソールが開かれている場合は、リフレッシュもトリガされません。
このような方法は比較的巧妙であるが、汎用性はなく、開発者ツールがオフ状態でオープン状態に移行する過程に限定されている。
二、デブガー
コード内のブレークポイントに似ています。ブラウザは開発者ツールを開く時（コードデバッグ時のデバッグモードに対応します。）デバッグフラグを検出した時（そこでプログラム中のブレークポイントに相当します）、プログラムの実行を一時停止します。
この時は、その青い「Resume script execution」プログラムを実行し続ける必要があります。この中には一定の時間差があります。この時間差が一定の値より大きいと判断することで、開発者ツールを開いたと考えられます。この方法は、開発者のツールを開けていないとデバッグタブが停止しないので、この方法は非常に良く、汎用性が高いです。
開発者ツールが開いているかどうかをdebuggerタグで検出する例を以下に示します。
<html>
<head></head>
<body>
<script>
function consoleOpenCallback() {
alert("CONSOLE OPEN");
}
!function () {
const handler = setInterval(() => {
const before = new Date();
debugger;
const after = new Date();
const cost = after.getTime() - before.getTime();
if (cost > 100) {
consoleOpenCallback();
clearInterval(handler)
}
}, 1000)
}();
</script>
</body>
</html>しかし、上のコードには深刻なバグがあります。debuggagerの行に行った時、ユーザーが猫の脂を見つけたら、reume script executionボタンを押していません。そのままページを終了すると、今回の開発者ツールを検出できなくなります。実際の結果は予想と違って、深刻なバグだと思います。映画の中で演じているように、地雷を踏みました。足を上げないと命をつなぐ機会があると気づきました。デバッグレッテルに着いたら、これはコンソールが開けているかどうかを検査するコードです。私は退出して他の手段を使って迂回しました。
注意すべき点がありますが、この方法を使うとデバッグレッテルにカードがあるとき、ユーザーはデバッグガータグの近くのコードを見ることができます。経験があるユーザーなら一目で中の道が見えます。デバッグレッテルを隠したり、コードを混同したりして、できるだけ読みにくいです。debuggarラベルの前後の論理をどのように隠すかについては、これらのサイトを参照してください。（現在は2018-7-4 23:12:17有効です。）
http://app2.sfda.gov.cn/datasearchp/gzcxSearch.do?formRender=cx&optionType=V1
https://www.qimai.cn/
このようなプログラムを使うと、デバッグガーは停止しない可能性があります。例えばChromeブラウザのsourceパネルはデバッグゲージの文の中で停止しないように選択できます。
このボタンが点灯されたら、上のページをテストしたら、悲劇的にコードが無効になりました。
実はデバッグレッカーにはもう一つの効果があります。例えば、デバッグを反対するために、デバッグをトリガして、デバッグ者をデバッグに疲れさせたり、追加のコストをかけてJSをカバーしたりします。上に書いてあるいくつかのサイトはこのようにしています。
以下はデバッグggarタグを使ってjsデバッグを行う簡単な例です。
<html>
<head>
<title>Anti debug</title>
</head>
<body>
<script>
!function () {
setInterval(() => {
debugger;
}, 1000);
}();
</script>
</body>
</html>実際の例では、このウェブサイト：http://jxw.uou0.com/のjs検出スクリプトは、異なる状況に対しては、また別の反転戦略があります。
再现するには、ビデオアドレス解析を貼り付けてから、検出スクリプトをロードする必要があります。例えば、このビデオを解析してみてもいいです。
開発者ツールを開けずに解析して開発者ツールを開くと、このような検出方法が使用されます。
!function() {
var timelimit = 50;
var open = false;
setInterval(function() {
var starttime = new Date();
debugger ;if (new Date() - starttime > timelimit) {
open = true;
window.stop();
$("#loading").hide();
$("#a1").remove();
$("#error").show();
$("#error").html("\u7cfb\u7edf\u68c0\u6d4b\u975e\u6cd5\u8c03\u8bd5\u002c\u8bf7\u5237\u65b0\u91cd\u8bd5\u0021")
} else {
open = false
}
}, 500)
}();開発者ツールを開けてアドレスを貼り付けてビデオ解析を行うと無限デバッグがトリガされます。
もちろん、上記のシナリオに対応する一番簡単な方法はChromeブラウザをDeactive breakpointに設定して、上のスクリプトは料理を休んでいますが、これでは自分でも調整できなくなりました。反対側のやつが吐き気がします。良い方法はFiddlerを使ってウェブページを修正して内容をフィルタリングしてdebuggerのラベルをフィルタリングして完璧にこのコースを解読することです。
三、ウィンドウのサイズを検出する
ウィンドウのサイズを検出するのは簡単です。まず二つの概念を明確にします。ウィンドウのアウトサイズとinnerサイズ：
window.inner Width/window.innersHeight：視認エリアの幅が高く、window.innerswidthは縦スクロールバーの幅を含み、window.inner Heightは水平（横）スクロールバーの幅を含んでいる。
window.outerWidth/window.outerHeight：inner WidthとinnersHeightの上にツールバーの幅を加えます。
検出ウィンドウのサイズについては、自分で例を書かないようにします。これに対して、専門的に在庫を書きました。http://film.qq.com/film/p/topic/thwjlxby/index.htmlです。何しろ、何百のスターは、私よりも多く書きました。コードは簡単です。部分的にはgithubで説明しています。ここではコアコードだけを分析します。ここでは、ライブラリのコアコードの分析を貼り付けます。
/* eslint-disable spaced-comment */
/*!
devtools-detect
Detect if DevTools is open
https://github.com/sindresorhus/devtools-detect
by Sindre Sorhus
MIT License
comment by CC11001100
*/
(function () {
'use strict';
var devtools = {
open: false,
orientation: null
};
// inner outer threshold
var threshold = 160;
// ， ， ，
var emitEvent = function (state, orientation) {
window.dispatchEvent(new CustomEvent('devtoolschange', {
detail: {
open: state,
orientation: orientation
}
}));
};
// 500 ，
setInterval(function () {
var widthThreshold = window.outerWidth - window.innerWidth > threshold;
var heightThreshold = window.outerHeight - window.innerHeight > threshold;
var orientation = widthThreshold ? 'vertical' : 'horizontal';
// ，heightThreshold widthThreshold true， false false true， true
if (!(heightThreshold && widthThreshold) &&
// Firebug
((window.Firebug && window.Firebug.chrome && window.Firebug.chrome.isInitialized) || widthThreshold || heightThreshold)) {
// ， ，
if (!devtools.open || devtools.orientation !== orientation) {
emitEvent(true, orientation);
}
devtools.open = true;
devtools.orientation = orientation;
} else {
// ，
if (devtools.open) {
emitEvent(false, null);
}
//
devtools.open = false;
devtools.orientation = null;
}
}, 500);
if (typeof module !== 'undefined' && module.exports) {
module.exports = devtools;
} else {
window.devtools = devtools;
}
})();1.window属性を使ってサイズをチェックすると、ブラウザの互換性に問題があるかもしれません。専門の先端ではないので、Chromeとffをテストしただけで大丈夫です。
2.この案にはまだ穴があります。Chromeブラウザを使って、開発者ツールウィンドウには四つのオプションがあります。
左寄り、右寄り、下寄りはいずれも現在のウィンドウの一部の空間を占有していることが検出されますが、独立したウィンドウはウェブページのウィンドウを開く空間を占有しないので、このような状況は検出できないので、このページに行って検証してもいいです。
四、まとめ
本稿ではいくつかの検査方法を紹介しました。それぞれ長所と短所があります。以下はその欠点に対する簡単な総括です。
toStringを書き換える()：開発者ツールがオフ状態からオープン状態に移行するプロセスのみをキャプチャすることができます。
debuggerタグ：ChromeブラウザのDeactive breakpoint
にチェックを付けると、debuggerタグは停止せず、捕獲できなくなります。ウィンドウのサイズを検出します。開発者ツールが別のウィンドウで開いている場合は検出できません。