WebAssembly Fingerprinting проти антидетектів: чому WASM може змінити правила гри

Canvas, WebGL, WebRTC, AudioContext, User-Agent - навколо цих параметрів роками крутилася гонка між антифрод-системами та розробниками антидетект-браузерів. Користувач намагається виглядати як звичайний пристрій, антидетект узгодить видимі сайту характеристики, антифрод шукає невідповідності. Тепер у цієї гонки з'являється новий фронт, і для антидетектів він потенційно куди неприємніший за колишні: WebAssembly Fingerprinting.

Проблема тут не в черговому параметрі, який можна додати до параметрів профілю. WASM дозволяє підібратися до характеристик реального виконання коду на конкретному пристрої – а це принципово змінює саме завдання. Сучасні антидетекти - Multilogin, AdsPower, Dolphin Anty, Octo Browser, GoLogin, Kameleo, Incogniton, Linken Sphere - вже впевнено працюють із великою кількістю класичних fingerprint-параметрів. Але незалежні дослідження показують, що навіть просунуті продукти видають себе за сукупністю невідповідностей, артефактів втручання у браузер та інших сигналів. WebAssembly додає ще один шар.

Що таке WebAssembly і чому антифроду він такий цікавий

WebAssembly, або WASM — низькорівневий бінарний формат інструкцій для виконання коду в браузері. Його ключові козирі — висока продуктивність і можливість компілювати код з C/C++ та інших мов. Якщо спростити: JavaScript працює на досить високому рівні абстракції, а WebAssembly виконує обчислювальні завдання набагато ближче до нативного коду. І ось тут для фінгерпринтінгу починається найцікавіше. Класичний відбиток зазвичай запитує браузер: "що ти про себе розповідаєш?" WASM дозволяє додати друге питання: «а як ти насправді виконуєш обчислення?» - І підмінити відповідь на нього значно складніше.

У демонстрації Vektor T13 використовується компактний односторінковий WebAssembly Fingerprint Checker — лише 447 рядків разом із оформленням. Він побудований на зв'язці JavaScript і WebAssembly: JS викликає WASM-функцію, WebAssembly звертається назад до JavaScript, і так багато разів поспіль. Виходить своєрідний обчислювальний пінг-понг — JavaScript → WASM → JavaScript → WASM — і за характеристиками виконання серії таких операцій формується набір вимірювань, з якого потім виводиться ідентифікатор пристрою; у наведеній реалізації - у вигляді SHA-256.

Чому User-Agent тут майже марний

Візьмемо антидетект-профіль. На рівні браузерних параметрів він повідомляє: Windows, Chrome потрібної версії, конкретне обладнання. User-Agent відповідає профілю, Canvas виглядає правдоподібно, WebGL узгоджений, WebRTC налаштований, решта питань не викликає. Але потім сайт запускає обчислювальний тест. І якщо характеристики виконання коду статистично не сходяться із заявленим оточенням, виникає зовсім інший клас сигналу.

Саме тому стосовно цього виду аналізу Vektor T13 називає звичайну заміну User-Agent практично застарілим прийомом. Антифрод більше зобов'язаний вірити розповіді браузера себе — може вимірювати його поведінка. У цьому є фундаментальна проблема.

Найнеприємніше: WASM-відбиток може залежати від реального заліза

У вебінарі окремо підкреслюється залежність результатів від апаратних ресурсів: незважаючи на те, що код виконується всередині браузера, характеристики обчислень залежать від середовища, на якому браузер реально працює. У перспективі це дозволяє будувати класифікатори, що розрізняють реальний ПК, віртуальну машину, VDS/VPS та серверне обладнання. Vektor T13 окремо звертає увагу на серверні CPU: особливості обчислень потенційно дозволяють відрізняти серверну інфраструктуру від типового комп'ютера користувача.

Тут важливо не переоцінювати метод. Це не означає, що WebAssembly дає JavaScript команду на зразок getRealCPUModel(). Мова про інше: збираються непрямі обчислювальні характеристики, які потім статистично порівнюються з накопиченими профілями відомих середовищ. І чим більше даних накопичить антифрод, тим більше працює такий підхід.

Чому це особливо неприємно для віртуальних машин

Віртуалізація давно використовується для поділу оточень, але з новим підходом виникає нюанс: віртуальна машина повинна не тільки повідомляти характеристики реального комп'ютера, а й досить схоже поводитися під час обчислень. У демонстрації стверджується, що WASM-тест здатний виявляти ознаки віртуалізованого середовища. Але відразу звучить важливе застереження самого Vektor T13: виявлення VM не є обов'язковим результатом - він прямо говорить, що знає спосіб впливати на результат, виділяючи браузеру пікову кількість ресурсів. Тобто ніякої магії: WASM fingerprinting не одно гарантоване виявлення будь-якої віртуалки. Це новий високоінформативний сигнал, який можна поєднувати з іншими ознаками, і саме в такому вигляді він особливо цікавий антифроду.

Що це означає для Multilogin, AdsPower, Octo та інших

Тут і розпочинається головна проблема індустрії. Антидетекти давно конкурують не кількістю перемикачів в інтерфейсі, а якістю узгодження fingerprint: під контролем сучасних продуктів — десятки параметрів, від Canvas та WebGL/WebGPU до AudioContext та апаратних характеристик. Але WASM порушує питання інакше: чи можна змусити реальне виконання коду відповідати синтетичній особистості браузерного профілю? І для різних архітектур відповідь може виявитися різною.

Multilogin традиційно відносять до найбільш технологічно розвинених продуктів категорії - він використовує власні браузерні двигуни. Однак навіть глибока модифікація Chromium або Firefox сама по собі не вирішує проблему апаратно-залежних вимірів. Якщо профіль заявляє одне оточення, а WASM-бенчмарк стабільно показує характеристики іншого, антифрод отримує додатковий сигнал узгодженості. Завдання при цьому перетворюється з «правильно підмінити fingerprint» на «правильно відтворити обчислювальну поведінку пристрою, якому цей fingerprint повинен відповідати», а це помітно складніше.

З Chromium-based продуктами - AdsPower, Dolphin Anty, Octo Browser, GoLogin, Incogniton, Kameleo - та ж логіка. Можна змінити Canvas, погодити WebGL, виставити hardwareConcurrency, але якщо вимірювана поведінка середовища конфліктує із заявленим профілем, у антифроду з'являється підстава підняти risk score, і чим більше незалежних WASM-тестів, тим важче завдання. Причому це не абстрактні міркування: незалежне дослідження антидетектів 2026 року вже обчислювало AdsPower і низку конкурентів по комбінаціях на кшталт prototype integrity і global-scope, а академічна робота Browser Polygraph окремо тестувала змінені браузери - Linken Sphere, Incogniton, GoLogin, Oc, WASM. WebAssembly лише розширює набір доступних характеристик ще далі. І питання не в тому, що якийсь конкретний антидетект «поганий» — проблема архітектурна, для всієї категорії одразу.

Чому один WASM-тест ще не знищує антидетекти

Це принципово важливе застереження. Якщо просто прогнати бенчмарк і отримати ваш WASM виповнився за 137 мілісекунд - це ще поганий відбиток. Продуктивність залежить від маси факторів: навантаження на CPU, енергозбереження, температури, фонових процесів, планувальника браузера, кількості виділених ресурсів та десятків інших умов. Реальна сила підходу народжується не з одного числа, а з серії різних тестів, повторних вимірів, статистичної нормалізації та великої бази еталонних пристроїв.

Саме тому Vektor T13 говорить про необхідність накопичувати багато статистики. У вебінарі заявляється можливість розрізняти користувачів з похибкою менше 1%, але це варто сприймати як результат конкретно представленого підходу, а не як доведену універсальну точність будь-якого WASM-фінгерпринтінгу на будь-якому сайті. Різниця важлива.

JavaScript та WASM як нове джерело ентропії

Особливо цікавою є ідея вимірювати не тільки чисту продуктивність WASM. У демонстрації межа між двома середовищами перетинається постійно — JS → WASM → JS → WASM — і кожен такий перехід додає характеристики виконання. Можна вимірювати різні типи операцій, кількість ітерацій, час переходів між контекстами, особливості обчислень та стабільність результатів. Замість одного параметра виходить цілий вектор характеристик - умовно F = {t1, t2, t3, … tn}, який після нормалізації порівнюється з відомими пристроями або класами обладнання. Тому перспективний WASM-відбиток це не черговий Canvas hash, а скоріше поведінковий відбиток обчислювального середовища.

Від Canvas Fingerprinting до Computational Fingerprinting

У цьому, мабуть, і є головний перехід. Перше покоління фінгерпринтінгу питало: що повідомляє браузер? Що браузер малює? Canvas і WebGL стали способом виміряти результат роботи графічного стека, WebGPU пішов глибше - у бік GPU. WASM дозволяє поставити таке запитання: як пристрій обчислює? А це вже набагато ближче до ідеї computational fingerprinting. У такому світі антидетект мало підмінити navigator.userAgent, navigator.hardwareConcurrency, WebGLRenderer, Canvas, AudioContext і ще десяток API - всі ці значення повинні бути фізично узгоджені з поведінкою системи, що спостерігається.

Новий рівень перевірки узгодженості

Представимо профіль: Windows 11, Chrome, Intel Core i5, звичайний домашній ПК, Canvas, WebGL і WebGPU. Але WASM-профіль показує обчислювальні характеристики, статистично властиві серверному оточенню. Сам собою цей факт ще означає фрод. Однак тепер антифрод може скласти воєдино репутацію IP, TLS-відбиток, браузерний fingerprint, Canvas, WebGL, WebGPU, профіль виконання WASM і поведінкові сигнали - і отримати значно сильнішу модель ризику. Це той напрям, у якому розвиваються сучасні системи виявлення: ефективні саме комбінації сигналів, а чи не надія на один «магічний» відбиток.

А що щодо Cybersource, PerimeterX та Microsoft

У вебінарі Vektor T13 стверджує, що подібні технології вже застосовуються в антифрод-інфраструктурі Cybersource і PerimeterX, причому Cybersource - на більш зрілій стадії впровадження. Як ще один приклад він наводить реєстрацію в Microsoft Partner, де, за його спостереженнями, WASM-фінгерпринтінг використовується для відсіву підозрілих реєстрацій, включаючи віртуальні машини, VPS та віддалені сервери.

Тут варто бути обережним: це заяви та спостереження автора вебінару, а не публічно підтверджені технічні специфікації цих компаній, і перетворювати їх на тезу «Microsoft точно блокує VPS саме цим алгоритмом» без додаткової перевірки було б неправильно. Але сама тенденція цілком реалістична: браузерний fraud detection вже використовує багатошарову класифікацію оточень, а академічні роботи показують, що модифіковані браузери виявляються за сукупністю сигналів.

Чи знищить WebAssembly Fingerprinting антидетекти?

Якщо розуміти «знищить» буквально, ні. Але він цілком здатний знищити стару модель антидетекту, в якій вважалося достатнім акуратно підмінити набір популярних браузерів fingerprint-параметрів. І це набагато цікавіше. Multilogin, AdsPower, Dolphin Anty, Octo Browser, GoLogin, Linken Sphere, Incogniton, Kameleo, MoreLogin, Undetectable та іншим доведеться враховувати не тільки те, які значення бачить сайт, але й те, чи відповідає цим значенням реальна поведінка середовища. Фактично стартує новий етап гонки: fingerprint spoofing → fingerprint consistency → hardware & computational consistency.

Canvas можна змінити. User-Agent – ​​переписати. WebGL - узгодити. Але змусити один комп'ютер обчислювально поводитися як зовсім інший — завдання іншого рівня. Тому WebAssembly Fingerprinting варто сприймати не як ще один рядок у величезній таблиці антифроду, а як потенційний перехід від "що браузер говорить про себе" до "чого браузер є насправді". І якщо антифрод-системи зберуть досить великі датасети реальних пристроїв, віртуальних машин, серверних CPU і різних браузерних двигунів, саме ця різниця може стати для індустрії антидетектів однією з головних проблем найближчих років.

Хочете першими отримувати такі розбори та свіжі дослідження? Зареєструйтесь на Detect Expert і підпишіться - всі нові статті та дослідження будуть надходити вам у підписки. Адже знання — найкращий антидетект сьогодні!