Ядра, память и GPU: где антидетект ломается на банальном несоответствии железа

Ядра, память и GPU: где антидетект ломается на банальном несоответствии железа

Разберем энтропию данного параметра: аппаратный профиль редко валится на одном флаге, он рушится на согласованности. Если браузер объявляет 16 logical cores, 64 GB RAM и дискретную видеокарту, а в остальных слоях виден бюджетный ноутбук, корреляция сгорает мгновенно.

Под капотом Chromium API это читается через несколько независимых каналов: navigator.hardwareConcurrency, deviceMemory, WebGL renderer/vendor, параметры canvas, а также поведение GPU-процесса. Детект на уровне сетевого стека тут не нужен — достаточно сопоставить профиль с типичными комбинациями железа и ОС. Особенно токсичны редкие пары: много ядер при малой памяти, встроенная графика при «тяжелом» десктопном профиле, либо наоборот.

Корректная эмуляция строится не на подмене одного значения, а на связке: • cores должны соответствовать классу CPU и теплопакету; • memory — объему, доступному под конкретный сегмент устройства; • GPU-строка в WebGL должна совпадать с классом драйвера, а не только с брендом. Спуфинг через инъекцию JS-кода без привязки к остальным признакам оставляет следы в CreepJS и похожих проверках.

Если нужен устойчивый профиль, сначала выбирают целевую аппаратную модель, затем проверяют, чтобы все ее публичные следы были взаимно непротиворечивы: от navigator до рендеринга шрифтов и поведения WebGL. Иначе система видит не устройство, а набор подмененных полей.