サイトのデテクターカードを取得する方法：フィンガープリントスクリプトの監査

2026年8月20日、開発者のマット・カラガン（ブログlaserphile）は、奇妙なバグの分析を公開しました。彼のBluetoothヘッドフォンは、コンピュータから電話に切り替わることができなくなりました。毎回、AliExpressのタブが開かれると発生しました。彼は推測することなく、ブラウザのAPIを調査し、ページ内で何が起こっているのかを確認しました。すると、Alibabaのアンチフロードスタックからの2つの難読化されたスクリプトが、オーディオコンテキストを介してデバイスのフィンガープリンティングを行っていることが判明しました。

これは、ほとんどの人がプロファイルの設定やパーサーの起動前に行わないことの理想的な例です：サイトの検出スタックを読み取らずに推測すること。以下は、特定のサイトの検出マップを自分の手で作成するための実践的な方法です。1時間で、難読化のリバースなしで、無料のサービスを使わずに行えます。

なぜ検出マップを作成するのか

典型的なサイクルは次のようになります：アカウントが禁止される — アンチデテクトブラウザの設定をランダムに調整する — プロキシを変更する — 再び禁止される。「禁止される」と「設定」の間にはデータがありません：サイトが正確に何を読み取っているのか、どの層で捕まえているのかが不明です。

検出マップはこのギャップを埋めます。これは、どの防御ベンダーが存在し、どのスクリプトがそれを実現し、どのAPIに触れ、結果がどこに送られるかのリストです。次に、本当にボトルネックがどこにあるのかが見えてきます — IP、ネットワークフィンガープリンティング、またはブラウザのハードウェア層です。これは3つのオーディエンスにとって同様に有用です：

マルチアカウント — プロファイルがどの信号で結合されるかを理解する。IPは異なりますが、オーディオスタック、WebGLレンダラー、hardwareConcurrencyはしばしばファーム全体で同じです。
スクレイピング — ブラウザを立ち上げる価値があるのか、HTTPクライアントで正しいTLSフィンガープリンティングで解決できるのかを理解する。
プライバシー — 店舗やサービスがクッキー以外にあなたのデバイスについて何を収集しているのかを見る。

ステップ1. ネットワークから防御ベンダーを特定する

最初に行うことは、DevToolsを開き、Networkタブでページを読み込み、最初のドキュメントのヘッダーとクッキーを確認することです。識別子は知られており、安定しています：

CF-RAYがレスポンスヘッダーにあり、クッキーcf_clearance — Cloudflare。
クッキー_abckと関数bmakを持つスクリプト — Akamai Bot Manager。
_pxプレフィックスの変数とクッキー — PerimeterX (HUMAN)。
クッキーdatadomeとベンダーのドメインからの別のJS — DataDome。
ボディなしの空の429 — Kasadaの特徴的な署名。

手作業が面倒な場合は、microlinkhq/is-antibot（30以上のプロバイダー）などのオープンな検出器や、26以上のベンダー用のブラウザ拡張機能を使用できます。これらは迅速な最初の回答を提供しますが、あなたのブラウザで何が測定されているのかという主要な質問には答えません。それを知るためには、さらに進む必要があります。

ステップ2. 疑わしいスクリプトのリストを抽出する

NetworkをJSタイプでフィルタリングし、主要ドメインから読み込まれないすべて、またはサービスディレクトリにあるすべてをメモします。AliExpressのケースでは、明らかにサービスパスを持つ2つのファイルがありました：

assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

アンチフロードスクリプトの兆候：難読化されたコード、パスにバージョン、スタティック用の別のサブドメイン、ページの視覚部分との関連がないこと。難読化を開いて読む必要はありません — 次のステップでスクリプトが自分自身について教えてくれます。

ステップ3. フィンガープリンティングAPIをツール化する

これはメソッドの核であり、カラガンが実行したことです：彼はAudioContextとAudioNode.prototype.connect()のコンストラクタをラップし、その後、メディア要素やplay()の呼び出しがないページ上に2つの生のオーディオコンテキストを見ました。

ロジックは簡単です：あなたが興味のあるメソッドをラップで置き換え、呼び出しをスタックとともにログし、元のものに制御を渡します。呼び出しスタックは、どのスクリプトがAPIを呼び出したのかを示します。このようなスニペットを挿入するのは、DevToolsのSources → Snippetsを通じて、またはdocument-startでコードを実行する拡張機能を通じて行うのが最も便利です — アンチフロードスクリプトの読み込み前に間に合うことが重要です。

ほとんどの信号をカバーする最小限のトラップのセット：

HTMLCanvasElement.prototype.toDataURLとgetImageData — キャンバスフィンガープリンティング。
WebGLRenderingContext.prototype.getParameter — グラフィックカードとドライバーのモデル、シェーダーの精度。
AudioContext / OfflineAudioContextとAudioNode.prototype.connect — オーディオフィンガープリンティング。
ゲッターnavigator.hardwareConcurrency、navigator.deviceMemory、navigator.plugins、navigator.webdriver。
RTCPeerConnection — WebRTCとローカルアドレス。
screen.width/height、devicePixelRatio、Intl.DateTimeFormat().resolvedOptions() — 画面とタイムゾーン。
navigator.mediaDevices.enumerateDevices — オーディオおよびビデオデバイスのリスト。

実行の結果、これらのAPIのうちどれが呼び出されたのか、何回呼び出されたのか、誰が呼び出したのかのリストが得られます。分析されたケースでは、AlibabaのスクリプトがキャンバスとtoDataURL、WebGLレンダラーとシェーダーの精度、オシレーターとアナライザーを介したオーディオ、画面のサイズとdevicePixelRatio、hardwareConcurrencyとdeviceMemory、プラグイン、コーデックのサポート、WebRTC、パフォーマンスのタイミング、マウスの動きやタッチのパターン、デバイスの動きのセンサーと自動化の指標を持っていました。

オーディオグラフが何をしていたか

測定がどのように見えるかを理解することは、他の場所でそれを認識するために役立ちます。グラフは次のようになっていました：鋸歯状のオシレーター → AnalyserNode → 分析結果を読み取るScriptProcessorNode → ゼロ増幅のGainNode → destination。音はなく、音量は関係ありません — それは単に存在しません。しかし、destinationへの接続は、著者の表現によれば、ブラウザがグラフを積極的に処理させることを強制しますが、最終的な音量はゼロです。まさに生のオーディオトラックがBluetoothパスを開いたままにし、ヘッドフォンのマルチポイント切り替えを壊しました。

この信号の処理の違いは、プロセッサ、音響ハードウェア、OS、ブラウザ、ドライバーによって異なります — ここから、IPの変更やクッキーのクリーニングを経ても生き残る安定した識別子が生まれます。この層の詳細な分析とプロファイルの設定については、Audio Context Fingerprintingの保護に関する記事を参照してください。

ステップ4. 結果の送信をキャッチする

収集なしの送信は無意味なので、次のステップは、収集したフィンガープリンティングがどこに送信されるのかを見つけることです。NetworkをXHR/Fetchでフィルタリングし、pingタイプのリクエストを別に見る — これらはnavigator.sendBeaconによって生成され、テレメトリースクリプトが好んで使用します。なぜなら、ページを離れても生き残るからです。

ほとんどの場合、fetch、XMLHttpRequest.prototype.send、navigator.sendBeaconを追加でラップすることが有益です — そうすれば、リクエストが送信される前にその内容を見ることができます。内容はシリアライズされ、暗号化されることを覚悟してください：AliExpressのケースでは、データはAlibabaのテレメトリに送信される前に暗号化されました。しかし、それでも2つの事実が得られます：受信者のアドレスと、あなたの行動に対する送信のタイミングです。

サイトがブラウザだけでなく、モバイルアプリや別のクライアントを介しても動作する場合、同じ問題はトラフィックレベルで解決されます — そのための手法はmitmproxyを介したトラフィック監査の分析に記載されています。

ステップ5. マップを自分のプロファイルと照合する

これで、サイトが実際に読み取っている信号のリストがあります。次に、これらの信号に対してあなたの作業プロファイルが何を返すのかを確認する必要があります。手順は次のとおりです：通常のブラウザで値を取得し、その後、各アンチデテクトプロファイルで取得し、比較します。

同時に重要な2つのことがあります：値はプロファイル間で異なるべきであり、セッション間で1つのプロファイル内で安定しているべきです。起動時にフィンガープリンティングが変動するプロファイルは、同一のフィンガープリンティングを持つ10のプロファイルと同様に、アンチフロードから見ても疑わしいものに見えます。

必要に応じて、置き換えが必要な層に存在することを確認してください。ここでのブラウザ間のばらつきは示唆的です：Firefoxは118バージョンからWebAudioの定数出力を提供し、分析データによれば99.24%のユーザーが3つの値に集約されます；Braveはランダムデータを混ぜ、2026年8月22日以降、特にこれらのAliExpressスクリプトをブロックしており、オーディオフィンガープリンティングの保護がデフォルトで6年以上存在していることを思い出させます；Safariはオーディオバッファにエラーを混ぜます；Chromeには攻撃的な保護がありません。

落とし穴

スクリプトがすでに実行されている。ファイルのブロックは、すでに作成されたオーディオコンテキストを消去しません — 著者は、開いているタブを閉じる必要があると明言しています。あなたのツール化についても同様です：ラップがスクリプトの後に配置された場合、何も見ることができません。
ブロックが機能性を壊す。アンチフロードスタックは、認証、支払い、実際の悪用からのアンチボット保護など、正当なものにも対応することがよくあります。検出マップを作成し、スクリプトを削除することは異なるタスクです；後者はサイトを壊します。
検出のバージョンは1つではない。スタックは、地理、デバイスタイプ、A/Bグループによって異なる場合があります。実際に作業しているIPとデバイスから検出マップを作成する意味があります。そうでなければ、他の構成を記述していることになります。
ツール化自体が検出される。オーバーライドされたネイティブメソッドは正しいtoStringを失い、接続されたデバッガーは痕跡を残します。偵察には重要ではありませんが、偵察プロファイルと戦闘プロファイルを混同しないでください — 自動化のマスキング技術はヘッドレスブラウザのマスキングに関するガイドで説明されています。

結果に必要なプロキシは何か

このようなマップからの主な実践的な結論はほぼ常に1つです：IPは最初の層に過ぎず、他のすべての層よりも早く確認されます。アンチフロードがリクエストの段階でホスティングのアドレスを見ている場合、オーディオグラフやキャンバスには到達しません — チャレンジや空の出力を受け取り、間違ったものを修正することになります。

したがって、選択のロジックは次のとおりです。深刻なスタックを持つサイト（Akamai、DataDome、PerimeterX、Alibabaレベルの独自開発）には、レジデンシャルプロキシが基本となります — 最初のフィルターで切り捨てられない実際のプロバイダーのアドレスです。モバイルアプリや、主なオーディエンスがスマートフォンでアクセスするサイトでは、モバイルプロキシがより自然なプロファイルに近くなります：オペレーターのCGNATは、アドレスを多くの生きたユーザー間で共有されることを前提としています。

逆もまた真です：マップがサイトがヘッダーやクッキーで制限されていることを示し、重いJSフィンガープリンティングがない場合、ブラウザファームは過剰であり、通常のHTTPクライアントとデータセンターアドレスで解決できます。

結論

ヘッドフォンのケースは、オーディオフィンガープリンティングの事実自体ではなく — それについては何年も知られています。重要なのは方法です：人は推測を信じず、ブラウザAPIの2つのメソッドをラップし、1晩で自分に何が収集され、どこに送信されるのかの完全なリストを得ました。同じ手法は、あなたが作業している任意のサイトで1時間で行え、ランダムに設定を試行するのにかかる月を置き換えます。バンを修正する前に検出マップを作成してください — そうでなければ、すべてのプロファイルで同じWebGLレンダラーに問題があった場合に、プロキシに予算を無駄にするリスクがあります。