Эмуляция CPU, RAM и GPU: где антифрод видит не «цифры», а несостыковки стека

Эмуляция CPU, RAM и GPU: где антифрод видит не «цифры», а несостыковки стека

Разберем энтропию данного параметра: браузер редко проверяют по одному полю. CPU, память и видеокарта читаются как связка через Navigator, JS API и графический стек. Если у «мощного» профиля слабый WebGL renderer или у тонкого ноутбука внезапно 16 логических ядер, детект срабатывает не по факту, а по внутренней несогласованности.

Что обычно ломает профиль:
— navigator.hardwareConcurrency не совпадает с типом устройства и тепловым классом;
— deviceMemory выглядит слишком «ровно» для класса железа;
— WebGL vendor/renderer не бьются с OS, драйвером и шейдерным поведением;
— Canvas и AudioContext показывают признаки чужого GPU-пути.

Под капотом Chromium API важен не только ответ, но и способ его получения. Скрипты антифрода смотрят на порядок вызовов, разрешения контекстов, наличие расширений WebGL, поведение OffscreenCanvas и параметры рендеринга. Если спуфинг через инъекцию JS-кода меняет только return value, а downstream-метрики остаются прежними, профиль получается синтетическим.

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