Как снять карту детекта сайта: находим fingerprint-скрипты сами

20 августа 2026 года разработчик Мэтт Каллаган (блог laserphile) опубликовал разбор странного бага: его Bluetooth-наушники с multipoint переставали переключаться с компьютера на телефон. Каждый раз, когда открыта вкладка AliExpress. Он не стал гадать — он инструментировал браузерные API и посмотрел, что происходит внутри страницы. Оказалось, два обфусцированных скрипта из анти-фрод стека Alibaba поднимали по аудиоконтексту и снимали отпечаток устройства через звук, которого никто не слышит.

Это идеальная иллюстрация того, чего почти никто не делает перед настройкой профилей или запуском парсера: не читает детект-стек площадки, а угадывает его. Ниже — практическая методика, как снять карту детекта конкретного сайта своими руками, за час, без реверса обфускации и без платных сервисов.

Зачем снимать карту детекта

Типичный цикл выглядит так: аккаунты банят — крутим настройки антидетект-браузера наугад — меняем прокси — снова банят. Между «банят» и «настройками» нет данных: непонятно, что именно площадка считывает и на каком слое ловит.

Карта детекта закрывает этот разрыв. Это список: какой вендор защиты стоит, какие скрипты его реализуют, какие API они трогают и куда уходит результат. Дальше становится видно, где действительно узкое место — в IP, в сетевом отпечатке или в железном слое браузера. Это одинаково полезно трём аудиториям:

• Мультиаккаунтингу — понять, по какому сигналу склеиваются профили. IP у них разные, а аудио-стек, WebGL-рендерер и hardwareConcurrency часто одинаковые на всю ферму.
• Скрапингу — понять, стоит ли вообще поднимать браузер или задача решается HTTP-клиентом с корректным TLS-отпечатком.
• Приватности — увидеть, что именно магазин или сервис собирает о вашем устройстве помимо cookies.

Шаг 1. Определить вендора защиты по сети

Первое, что вы делаете, — открываете DevTools на вкладке Network, загружаете страницу и смотрите заголовки и cookies первого документа. Опознавательные знаки известны и стабильны:

• CF-RAY в заголовках ответа и cookie cf_clearance — Cloudflare.
• Cookie _abck и скрипт с функцией bmak — Akamai Bot Manager.
• Переменные и cookies с префиксом _px — PerimeterX (HUMAN).
• Cookie datadome и отдельный JS с домена вендора — DataDome.
• Пустой 429 без тела ответа — характерная подпись Kasada.

Если руками лень, есть открытые детекторы вроде microlinkhq/is-antibot (30+ провайдеров) и браузерные расширения-детекторы на 26+ вендоров. Они дают быстрый первый ответ, но не отвечают на главный вопрос — что именно измеряется в вашем браузере. За этим надо идти дальше.

Шаг 2. Вытащить список подозрительных скриптов

Отфильтруйте Network по типу JS и выпишите всё, что грузится не с основного домена или лежит в служебных каталогах. В кейсе AliExpress это были два файла с явно служебными путями:

• 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. Инструментировать fingerprint-API

Это ядро метода и ровно то, что сделал Каллаган: он обернул конструктор AudioContext и AudioNode.prototype.connect(), после чего увидел два живых аудиоконтекста на странице, где нет ни одного медиаэлемента и ни одного вызова play().

Логика простая: вы подменяете интересующий вас метод своей обёрткой, которая логирует вызов со стеком и передаёт управление оригиналу. Стек вызовов показывает, какой именно скрипт дёрнул API. Вставлять такой сниппет удобнее всего через DevTools Sources → Snippets либо через расширение, выполняющее код на document-start — важно успеть до загрузки анти-фрод скрипта.

Минимальный набор ловушек, который закрывает большинство сигналов:

1. HTMLCanvasElement.prototype.toDataURL и getImageData — канвас-отпечаток.
2. WebGLRenderingContext.prototype.getParameter — модель видеокарты и драйвера, точность шейдеров.
3. AudioContext / OfflineAudioContext и AudioNode.prototype.connect — аудио-отпечаток.
4. Геттеры navigator.hardwareConcurrency, navigator.deviceMemory, navigator.plugins, navigator.webdriver.
5. RTCPeerConnection — WebRTC и локальные адреса.
6. screen.width/height, devicePixelRatio, Intl.DateTimeFormat().resolvedOptions() — экран и таймзона.
7. navigator.mediaDevices.enumerateDevices — список аудио- и видеоустройств.

По итогам прогона у вас появится список: какие из этих API вообще были вызваны, сколько раз и кем. В разобранном кейсе скрипты Alibaba трогали канвас и toDataURL, WebGL-рендерер и точность шейдеров, аудио через осциллятор и анализатор, размеры экрана и devicePixelRatio, hardwareConcurrency и deviceMemory, плагины, поддержку кодеков, WebRTC, тайминги производительности, паттерны движения мыши и касаний, датчики движения устройства и свойства-индикаторы автоматизации.

Что именно делали аудио-графом

Полезно понимать, как выглядит измерение, чтобы узнавать его в других местах. Граф был такой: пилообразный осциллятор → AnalyserNode → ScriptProcessorNode, читающий результат анализа → GainNode с нулевым усилением → destination. Звука нет, громкость не при чём — её попросту нет. Но подключение к destination, по формулировке автора, заставляет браузер активно обрабатывать граф, хотя итоговая громкость равна нулю. Именно живой аудиотракт и держал открытым Bluetooth-путь, ломая multipoint-переключение наушников.

Различия в обработке этого сигнала зависят от процессора, звукового железа, ОС, браузера и драйверов — отсюда и стабильный идентификатор, переживающий смену IP и чистку cookies. Подробный разбор именно этого слоя и настройки профилей под него — в статье про защиту от Audio Context Fingerprinting.

Шаг 4. Поймать отправку результата

Сбор без отправки бессмысленен, поэтому следующий шаг — найти, куда уходит собранный отпечаток. Фильтруйте Network по XHR/Fetch и отдельно смотрите запросы типа ping — их порождает navigator.sendBeacon, который любят использовать телеметрические скрипты, потому что он переживает уход со страницы.

Практически всегда полезно дополнительно обернуть fetch, XMLHttpRequest.prototype.send и navigator.sendBeacon — тогда вы увидите тело запроса до того, как оно уйдёт. Готовьтесь к тому, что содержимое будет сериализовано и зашифровано: в кейсе AliExpress данные шифровались перед отправкой на телеметрию Alibaba. Но даже так вы получаете два факта: адрес приёмника и момент отправки относительно ваших действий.

Если сайт работает не только в браузере, а через мобильное приложение или отдельный клиент, тот же вопрос решается на уровне трафика, а не DOM — методика перехвата и разбора описана в разборе аудита трафика через mitmproxy.

Шаг 5. Сверить карту со своим профилем

Теперь у вас есть список сигналов, которые площадка реально читает. Остаётся проверить, что отдаёт по этим сигналам ваш рабочий профиль. Порядок такой: снимаете значения в обычном браузере, затем в каждом профиле антидетекта и сравниваете.

Важны две вещи одновременно: значения должны отличаться между профилями и быть стабильными внутри одного профиля между сессиями. Профиль, у которого отпечаток скачет при каждом запуске, выглядит для анти-фрода не менее подозрительно, чем десять профилей с идентичным отпечатком.

Отдельно проверьте, что подмена вообще существует на нужном слое. Здесь показателен разброс по браузерам: Firefox с версии 118 отдаёт константный вывод WebAudio, и по данным разбора 99,24% пользователей сводятся к трём значениям; Brave подмешивает случайные данные и с 22 августа 2026 года блокирует конкретно эти скрипты AliExpress, напоминая, что защита от аудио-отпечатка стоит у него по умолчанию больше шести лет; Safari подмешивает ошибки в аудиобуферы; Chrome агрессивных защит не имеет.

Подводные камни

• Скрипт уже успел отработать. Блокировка файла не убивает уже созданный аудиоконтекст — автор прямо отмечает, что открытые вкладки надо закрывать. То же касается и вашего инструментирования: если обёртка встала позже скрипта, вы не увидите ничего.
• Блокировка ломает функциональность. Анти-фрод стек часто отвечает и за легитимные вещи — авторизацию, оплату, антибот-защиту от реального абуза. Снимать карту детекта и вырезать скрипты — разные задачи; вторая ломает сайт.
• Версия детекта не одна. Стек может отличаться по гео, по типу устройства и по A/B-группе. Карту имеет смысл снимать с того IP и того устройства, с которых вы реально работаете, иначе вы описываете чужую конфигурацию.
• Само инструментирование детектируется. Переопределённые нативные методы теряют корректный toString, а подключённый отладчик оставляет следы. Для разведки это не критично, но не путайте разведочный профиль с боевым — техники маскировки автоматизации разобраны в гайде по маскировке headless-браузера.

Какой прокси нужен под результат

Главный практический вывод из такой карты почти всегда один: IP — это только первый слой, и он проверяется раньше всех остальных. Если анти-фрод уже на этапе запроса видит адрес хостинга, до аудио-графа и канваса дело просто не дойдёт — вы получите челлендж или пустую выдачу и будете чинить не то.

Поэтому логика выбора такая. Для площадок с серьёзным стеком (Akamai, DataDome, PerimeterX, собственные разработки уровня Alibaba) базой служат резидентные прокси — адреса реальных провайдеров, которые не отсекаются на первом же фильтре. Для мобильных приложений и площадок, где основная аудитория сидит со смартфонов, ближе к естественному профилю оказываются мобильные прокси: операторский CGNAT делает адрес заведомо разделяемым между множеством живых пользователей.

И обратное тоже верно: если карта показала, что площадка ограничивается заголовками и cookies, а тяжёлого JS-фингерпринта нет, — браузерная ферма избыточна, задача решается обычным HTTP-клиентом и датацентр-адресами.

Вывод

Кейс с наушниками ценен не самим фактом аудио-отпечатка — про него известно годами. Ценен метод: человек не поверил догадкам, а обернул два метода браузерного API и за вечер получил полный список того, что с него снимают, и адрес, куда это уходит. Тот же приём занимает час на любой площадке, с которой вы работаете, и заменяет месяцы перебора настроек наугад. Снимите карту детекта прежде, чем чинить баны — иначе есть риск потратить бюджет на прокси там, где проблема была в одинаковом WebGL-рендерере на всех профилях.