Вы что творите? Вы что вытворяете я вас спрашиваю? В смысле вас уже 100!? Я уже могу железки на обзор просить?

Спасибо вам, для меня это немного пранк который вышел из под контроля)) Обняла-приподняла 🥰

Как взрослая положила для вас обещанный пост в отложку, а мне тут пока на новом месте стул и стол выдают. 😎

Riot Vanguard - один из немногих consumer-продуктов, который всерьёз залез в зону, где обычно живут EDR, VBS и UEFI-security. Для нас он интересен не тем, что ловит читы, а тем, как он это делает: работа в ядре, манипуляции с CR3/PML4, жёсткие требования к IOMMU/TPM и координация с вендорами материнок.

[ Ранний boot и хуки через HAL ]

Драйвер Vanguard стартует на boot-этапе, становясь одним из самых ранних модулей в ядре Windows. Это даёт контроль над загрузкой других драйверов и диспетчеризацией.

В публичных реверсах описан нетривиальный приём перехвата syscall’ов без прямого патчинга SSDT. Вместо этого используется PMC-путь через HalCollectPmcCounters:
🔸 Драйвер подменяет указатель на обработчик, который дёргается в контексте HalCollectPmcCounters.
🔸 Идёт проверка: действительно ли мы на пути системного вызова?
🔸 Управление уходит в кастомную HandleSyscall, которая фильтрует и логирует нужные Nt*-операции.

Такой подход снижает вероятность срабатывания PatchGuard и других проверок целостности, но при этом даёт широкое покрытие по системным вызовам, которые важны для мониторинга читов и обходов.

[ Guarded Regions: теневые PML4 и подмена CR3 ]

Критичные игровые структуры скрыты не только от user-mode, но и от других kernel-контекстов. Как это реализовано (по публичному реверсу Xyrem):
🔸 Клонируется PML4-таблица процесса игры; в клон добавляется запись на «секретный» регион виртуальной памяти.
🔸 На функцию контекстного переключения вешается хук.
🔸 Поток из вайтлиста - подмена CR3 на вариант с модифицированной PML4.
🔸 Любой другой поток получает обычный CR3.
В результате стандартная логика чтения памяти (включая кастомные ring-0 тулзы) и примитивный PFN-брутфорс этот регион просто не видят.

[ Экосистема доверия: VBS, UEFI и принудительный комплаенс ]

Vanguard жёстко опирается на VBS / Memory Integrity. Любой баг в Secure Kernel (например, CVE-2024-21302 с даунгрейдом системных файлов) - это брешь в фундаменте самого античита. Поэтому Riot вынуждены и адаптировать свои low-level техники под патчи Microsoft, и тащить за собой пользовательскую базу на актуальные конфиги ОС.

Отдельный кейс: ресёрчеры Riot (Nick Peterson и Mohamed Al-Sharifi) нашли, что на ряде плат UEFI рапортует ОС о включённом Pre-Boot DMA Protection, хотя IOMMU фактически ещё не инициализирован. В это окно «злой» PCIe-девайс успевает читать и модифицировать физическую память (загрузчик, ядро, драйверы) ещё до старта ОС. Затронуты Asus, Gigabyte, MSI, ASRock (см. CERT/CC VU#382314). Дальше Riot сделали красивое: не просто зарепортили баг, а через свой механизм VAN:Restriction запретили запуск игр на уязвимых прошивках, вынудив пользователей обновить BIOS. По сути, прикладной софт выступил частным комплаенс-контроллером и аттестатором железа.

[ Вместо выводов ]

Vanguard - шикарный полигон, где техники из академических пейперов и малвари (CR3-свапы, нестандартный HAL-хукинг, скрытые регионы памяти) работают в дикой природе на миллионах машин. Бонусом - публичная багбаунти на HackerOne с отдельным скоупом под Vanguard. Интересует:
🔸 LPE через их драйвер.
🔸 Обходы детектов и Guarded Regions.
🔸 Баги целостности и приватности платформы.

Так что если любите что-то пожёстче - стоит присмотреться: суммарные выплаты Riot на HackerOne уже исчисляются миллионами долларов. 🥂

你好 комрады! 🏴‍☠️

Под вечер понедельника обращу ваш взор на восток где пару месяцев назад прошел «Tencent cloud hackathon intelligent penetration challenge», на самом сайте можно полазить и посмотреть презы и репы проектов, даже видосики есть. Тут все вводные, доки и таймлайны с самого ивента, а сводная репа с итоговыми проектами здесь. Всем хорошей недели, постараюсь в серединке найти время на лонгрид. 🖤

Реверс довольно популярного server crash эксплойта для CS2 😎
У автора кстати есть много интересных видео на тему читов и реверса в играх, рекомендую посмотреть.
https://www.youtube.com/watch?v=9IUWPT0UVPg

你好 комрады! 🏴‍☠️

🪭 Разбираем Tencent ACE Part 1(будет 2 части так как в одну все не влезло)

Когда говорят про kernel-level античиты, на Западе принято вспоминать Riot Vanguard. Тут есть забавный нюанс: Riot на 100% принадлежит Tencent. Прямой связи «ACE → Vanguard» нет, но при общем владельце логично ожидать обмен экспертизой.

В тени остаётся куда более масштабный монстр - Tencent Anti-Cheat Expert (ACE). По заявлениям Tencent, он обслуживает 700M+ игроков, а в 2025-м поехал за пределы Китая. При этом англоязычной аналитики по нему почти нет - весь ресерч живёт исключительно на хардкорных китайских реверсерских форумах вроде kanxue и 52pojie.

🔷 [ Это не «просто драйвер», а экосистема ]

ACE - это зонтик сервисов, раскатываемый через Tencent Cloud. Существует он в разных вариациях: от лёгкого SDK для разных платформ до полноценного kernel-агента (ACE-BASE.sys + ACE-GAME.sys).

📊 Немного цифр из отчёта за 2024 год (25 не нашла):
🔸 +74% YoY - рост числа семплов PC-читов.
🔸 85,8% читов - кастомные. Создатели читов используют облачные пакеры, генерирующие уникальный бинарь под каждого юзера. Сигнатурный анализ тут кажется мёртв, всё уходит в облачный ML. Агент стримит туда гигантские объёмы телеметрии: дампы аномальных участков памяти, трейсы подозрительных потоков и сырые инпуты мыши/клавиатуры для поведенческого анализа.
🔸 187,65 млн наказаний за нарушения в экономике (вероятно, это микс HWID-банов, теневых банов и вайпов, но точной детализации в отчёте нет).

🔷 [ Supply Chain и региональная специфика ]

В том, что ядро античита грузится вместе с ОС, нет ничего нового. Инновация ACE - в модели доставки. Китайский рынок - это сотни тысяч компьютерных клубов с разрозненным парком тачек, анонимными юзерами и постоянно переразворачиваемыми образами ОС.

Компьютерные клубы в КНР - строго регулируемая среда. Они обязаны идентифицировать посетителей, логировать активность и выполнять требования по ИБ. Поэтому ACE имеет pre-start режим: он раскатывается не как игровая либа, а как компонент golden image клубной тачки через популярные платформы управления.

Античит оказывается в образе ОС рядом с системами идентификации и пр. Со всеми вытекающими нюансами с приватностью.

👀 Интеграция kernel-драйвера в инфраструктуру сотен тысяч клубов - звучит как гигантская поверхность для Supply Chain атаки.

#tencent #dma #anticheat

Ахой, комрады! 🏴‍☠️

Riot выкатили апдейт Vanguard и о боже мой - он переходит в On-Demand режим. Условие одно: хост должен пройти Vanguard Pre-Check. По сути, Riot строят endpoint zero-trust благодаря которому античит может себе позволить уходит в модель «по требованию», перекладывая работу на TPM, IOMMU и гипервизор.

Что именно они пытаются сломать из типичных векторов атаки?

[ BYOVD и Runtime Driver Attestation ]

Классический BYOVD‑паттерн сегодня - это не попытка сломать DSE/PatchGuard, а загрузка своего подписанного, но уязвимого драйвера, чтобы использовать его как сервис для kernel‑примитивов. Такие драйверы дают:
🔸 произвольную запись и чтение в kernel‑память;
🔸 убийство любых процессов и служб из Ring 0;
🔸 зачистку EDR‑хуков (PsSet*NotifyRoutine, ObRegisterCallbacks).

Сценарий до обновления был простым: грузим дырявый драйвер, делаем грязную работу и выгружаем BYOVD до того, как античит вообще появился в системе. Проблема античитов и многих EDR одна и та же - они не видят момент загрузки драйвера, если сами ещё не живут в ядре.

Новая модель использует Runtime Driver Attestation из Windows 11 25H2 (кстати, эта фича заимствована из архитектуры безопасности Xbox и допилевалась совместно с Xbox OS Security team) Суть в следующем:
🔹 Windows считает кумулятивный хеш по цепочке загруженных драйверов и фиксирует это в TPM;
🔹 на старте Vanguard запрашивает отчёт об этих измерениях и сверяет его со своим списком известных BYOVD‑артефактов.

[ HWID‑баны и TPM ]

Баны по железу живут давно, и рынок спуферов прекрасно эмулирует серийники дисков или MAC‑адреса. Но у TPM 2.0 есть Endorsement Key, привязанный к конкретному модулю и предназначенный для построения доверия к платформе. И если dTPM можно заменить или перепаять, то fTPM встроен в CPU/чипсет, и его замена означает замену процессора или платы.

[ IOMMU ]

Главное преимущество DMA-атак в том, что PCIe-устройство читает RAM напрямую в обход ОС. Riot завязывают Pre-Check на обязательную конфигурацию IOMMU. С ним каждый девайс получает свою таблицу отображения памяти. В итоге массмаркетовый DMA-чит внезапно слепнет: он видит только строго выделенный ему диапазон памяти или ловит fault от гипервизора. Имхо, это не серебряная пуля - рынок DMA уже давно адаптируется, маскируясь под легитимную периферию и атакуя UEFI для тихого патча IOMMU-таблиц. Но порог входа возрастает кратно.

[ VBS/HVCI как фильтр Ring 0 ]

Гипервизор создаёт изолированный контекст, в котором живут чувствительные компоненты ОС. Страницы кода Ring 0 получают статус «исполняемый» только после проверки подписи. Попытки мапнуть произвольный RWX‑кусок в kernel‑пространство натыкаются на политику безопасности, а не на голый MmMapIoSpace.
Побочный, но важный эффект: при включённом HVCI Windows начинает гораздо жёстче применять собственный Vulnerable Driver Blocklist. Большая часть исторических BYOVD‑драйверов на таком конфиге просто не загрузится, даже с правами админа.

[ Secure Boot и классические буткиты ]

Буткиты обычно работают в зоне «до того, как система проснётся полностью» (например, патчат ntoskrnl.exe в полете из хранилища в RAM). Обязательный UEFI Secure Boot делает следующее:
🛡 прошивка проверяет подписи загрузочных компонентов;
🛡 неподписанный или подменённый bootloader просто не исполняется;
🛡 Windows Boot Manager стартует, только если вся цепочка доверия не нарушена.

Для буткита это означает, что вместо комфортного патчинга на этапе загрузки придётся либо компрометировать ключи UEFI, либо эксплуатировать уязвимость в уже подписанном компоненте.

[ Что остается из очевидного? ]

Riot не обнуляют всё. Для атакующей стороны остаются вполне реальные векторы:
🎯 user‑mode уязвимости в RiotClient/Vanguard (DLL sideloading, TOCTOU‑гонки вокруг integrity‑чеков, PEB‑unlink и прочие трюки);
🎯 атаки на инфраструктуру аттестации (TPM API, TBS‑слой, попытки hypervisor escape там, где VBS включен в legacy‑режимах);
🎯 классические social / supply‑chain атаки - чит‑лоадер, который маскируется под легальный софт внутри пользовательских компонентов.

Кто-то ковырял уже RDA под 25H2? 🌚

Кто если не я поделится с вами ссылочками на подкаст с @justmarfix из ЛК по теме его нашумевшего ресерча 😎

🎵 Яндекс.Музыка
🎵 Подкасты Apple

Охаё, комрады. 🏴‍☠️

Продолжая топик понедельника, хочется немного затронуть тему того, где проходит граница ответственности вендора. Недавно на HackerOne отправили 7 уязвимостей в Vanguard от CVSS 3.8 до 7.8, приняли 0, потому что «DLL hijacking требует локального доступа, значит это out of scope». Формально - да. Практически - ну такое.

Что удалось сделать на этой «out of scope» поверхности:
🔸 Получить произвольное выполнение кода внутри EV‑подписанного RiotClientServices.exe через DNSAPI.dll sideloading.
🔸 Обойти VAN 57 integrity‑чек Vanguard через TOCTOU‑подмену: на диске лежит честная Microsoft‑овская DLL, а в памяти уже крутится код атакующего.
🔸 Отлинкать пейлоад из всех трёх списков загрузчика в PEB, чтобы он не светился в стандартном перечислении модулей.

⏱️ Результат: 41+ минут непрерывного исполнения, 33 тестовые сессии, ноль реакции Vanguard на уровне user‑mode.

Контекст прав тоже радует:
Директория Riot Client из коробки даёт BUILTIN\Users права Modify.
То есть:
— админ не нужен;
— физический доступ не нужен;
— любая малварь, которая уже есть на тачке (эксплойт в браузере, трояннутый мод, npm‑пакет и т.п.), может просто положить DLL, которая будет исполняться внутри доверенного EV‑подписанного процесса при каждом запуске клиента.

Важно: kernel‑драйвер Vanguard (vgk.sys) здесь как раз ведёт себя прилично - он режет кросс‑процессную память от пейлоада, вторую линию обороны не проломили. Но user‑mode trust boundary, то есть основная detection surface античита, оказывается пробита полностью: лоадер, живущий внутри подписанного Riot‑процесса, для user‑mode выглядит как «часть себя».

И вот тут начинается тот самый холивар, о котором я говорила в начале поста. Практический эффект от всего вышеописанного: любая малварь, уже попавшая на тачку, получает дополнительный устойчивый плацдарм внутри доверенного процесса, который сам по себе продаётся как компонент безопасности. Вендор строит сложную модель доверия вокруг TPM, IOMMU, HVCI и measured boot, но в пользовательском слое оставляет дырку уровня “любой код, попавший в систему, может регулярно жить внутри нашего доверенного процесса без особого сопротивления”. И формально это можно списать на «проблему локального компромисса», хотя по сути античит здесь усиливает последствия этого компромисса.

Это довольно показательный пример вопроса: «где проходит граница ответственности вендора безопасности/античита?».

Должен ли он:
1️⃣ Защищать только от «чистых» читов без предварительного компромисса системы?
2️⃣ Или учитывать, что его доверенный процесс сам становится идеальной точкой опоры для уже существующей малвари?

С текущей позицией багбаунти‑площадки и вендора всё это формально считается приемлемым поведением. Авторы ресерча не согласны. Честно говоря, я тоже.

Что думаете - честный out of scope или уже нет?

Ахой, пирожочки! 😘

Я максимально рекомендую вам к прочтению ресерч от @s4dbrd. Adrian провел титаническую и безумно интересную работу. Так же у него есть статический анализ BattlEye. Фидбек и вопросы можно оставить в комментариях, если не забежит сам-я все передам. :)

https://s4dbrd.github.io/posts/how-kernel-anti-cheats-work/