Эмуляция CPU, RAM и GPU ломается не на спуфинге, а на несогласованности профиля

Под капотом Chromium API браузер собирает аппаратный профиль из нескольких независимых источников: navigator.hardwareConcurrency, deviceMemory, WebGL renderer, Canvas, AudioContext и timing-поведения. Разберем энтропию данного параметра: если ядра, память и видеокарта выглядят как набор случайных правок, детект ловит не сам факт подмены, а внутренний конфликт признаков.

Базовое правило: значения должны быть совместимы между собой и с классом устройства. • 2 ядра и 32 GB RAM — редкий профиль для типового desktop-сценария • дискретная GPU без соответствующего WebGL-рендера и расширений выглядит как ручная инъекция • мобильный стек с «мощной» памятью и desktop-таймингами часто палится через поведение event loop и шрифты

Для CPU важен не только hardwareConcurrency, но и косвенный профиль нагрузки: параллельность задач, jitter в performance.now(), очередь microtask. Для RAM браузер редко знает реальный объем, но антифрод смотрит на согласованность с device class, allocator patterns и тем, как страница переживает memory pressure. GPU же нельзя эмулировать изолированно: строка renderer, набор extensions, precision в shader precision format и результаты WebGL-дампа должны сходиться в один графический стек.

Практический подход один: не подменять каждый параметр отдельно, а строить цельный профиль устройства и проверять его через Pixelscan, CreepJS и BrowserLeaks. Если один слой говорит «ноутбук», второй — «рабочая станция», а третий — «виртуалка», детект на уровне сетевого стека и браузерных API почти всегда соберет эту картину обратно.