TPM и Secure Boot: Как мы дошли до жизни такой. История гонки вооружений

[0wn3df1x 4 679]

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

---

В последние дни игровое сообщество гудит от негодования. Причиной тому стало всё более активное внедрение обязательных требований TPM 2.0 и Secure Boot в популярных мультиплеерных играх. Новость о том, что для запуска Battlefield 2042 теперь требуется Secure Boot, вызвала волну негативных отзывов, а сегодняшний анонс от Activision, что будущая Black Ops 7 потребует того же, лишь подлил масла в огонь.

Многих игроков это приводит в недоумение: зачем разработчики заставляют лезть в системные настройки BIOS и включать какие-то непонятные функции, которые, к тому же, иногда требуют сложных манипуляций с диском? Чтобы ответить на этот вопрос, нужно понять, что эти требования — не прихоть, а новый рубеж в многолетней гонке вооружений между создателями читов и античитерскими технологиями.

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

Глава 1: Эпоха внутрипроцессных манипуляций — читы пользовательского режима (Ring 3)

Глава 1: Эпоха внутрипроцессных манипуляций — читы пользовательского режима (Ring 3)

1.1 Истоки: от отладки к развлечению

На заре игровой индустрии концепция «чита» родилась не как инструмент нечестной игры, а как незаменимое средство для самих разработчиков. В процессе создания сложных игровых миров тестировщикам и программистам требовался способ быстро проверять определённые механики, не проходя игру часами. Так появились чит-коды — специальные комбинации клавиш или скрытые команды, дарующие бессмертие, бесконечные ресурсы или возможность перемещаться между уровнями. Они были отладочными инструментами, позволявшими мгновенно оценить работоспособность конкретного сегмента игры.

Иногда эти коды по недосмотру, а иногда и намеренно, оставались в финальных версиях продуктов. Это превратило их в культурный феномен, форму легального читерства, которая позволяла игрокам по-новому взглянуть на игру, преодолеть сложные участки или просто повеселиться, обладая божественной силой. Однако эта форма вмешательства была ограничена тем, что предоставили сами создатели. Настоящая война началась, когда игроки захотели получить возможности, которые не были предусмотрены разработчиками, и для этого создали свои собственные инструменты.

1.2 Рождение трейнеров: внешнее вмешательство

Следующим шагом эволюции стали трейнеры — внешние программы, созданные для целенаправленного изменения поведения игры путём манипуляции её памятью. В отличие от заложенных разработчиком кодов, трейнеры давали игроку полный контроль, позволяя изменять любые числовые значения в игре: от количества жизней и патронов до внутриигровой валюты.

В 80-х и 90-х годах, в эпоху дискет и пиратства, трейнеры часто были неотъемлемой частью взломанных версий игр. Хакерские группы встраивали их прямо в исполняемый файл. При запуске игры сначала загружался интро-экран группы, а затем появлялось меню трейнера, где можно было выбрать желаемые опции (например, бесконечные жизни, убийство с одного удара). После этого загружалась сама игра. Такие релизы помечались знаками «+» после названия, где каждый плюс означал одну читерскую функцию (например, «GameName +++»).

Так или иначе, трейнеры имели фундаментальное ограничение: они были созданы для конкретной версии конкретной игры. Любое обновление от разработчика, которое меняло расположение данных в памяти, делало старый трейнер бесполезным. Сообществу требовался более универсальный подход, который позволил бы любому пользователю самостоятельно находить и изменять нужные значения.

1.3 Универсализация подхода: сканеры памяти

Прорывом стали универсальные сканеры и редакторы памяти, такие как ArtMoney, а позже — его более мощный преемник Cheat Engine. Эти программы демократизировали процесс читерства, превратив его из искусства для избранных программистов в доступную технологию. Их принцип работы был основан на простом методе поиска по известному значению, который называется «отсеивание».

Процесс отсеивания выглядит следующим образом:

1. Первичный поиск: Игрок запускает игру и сканер памяти. Допустим, у персонажа 100 единиц здоровья. Игрок вводит в сканер число 100 и запускает поиск. Программа сканирует всю оперативную память, выделенную игровому процессу, и находит тысячи, а то и миллионы адресов, где в данный момент хранится значение 100.
2. Изменение значения: Игрок возвращается в игру и намеренно меняет искомое значение. Например, получает урон, и его здоровье падает до 85.
3. Отсеивание: Игрок снова переключается на сканер и вводит новое значение — 85. Программа выполняет «отсеивание»: она проверяет все адреса, найденные на первом шаге, и оставляет в списке только те, значение в которых изменилось со 100 на 85. Количество потенциальных адресов резко сокращается.
4. Повторение: Этот цикл повторяется несколько раз. Игрок лечится до 95, отсеивает по значению 95. Снова получает урон до 70, отсеивает по значению 70. После нескольких таких итераций в списке остается всего один (или несколько) адрес — это и есть ячейка памяти, отвечающая за здоровье персонажа.

Найдя нужный адрес, пользователь получал две ключевые возможности:

• Прямое изменение (Write): Можно было просто вписать в ячейку любое желаемое значение, например, 999999, чтобы получить огромное количество патронов или денег.
• «Заморозка» (Freeze): Это более продвинутая функция. Активировав её, пользователь приказывал сканеру с высокой частотой (сотни раз в секунду) принудительно записывать в найденный адрес определённое значение (например, 100 для здоровья). Таким образом, даже если игра пыталась уменьшить это значение после получения урона, программа-сканер мгновенно перезаписывала его обратно, создавая эффект бессмертия.

Cheat Engine пошёл ещё дальше, предоставив инструменты для дизассемблирования кода, поиска указателей (чтобы находить динамически выделяемую память) и даже инъекции собственных скриптов на языке Lua, позволяя создавать сложные читы прямо на лету. Эти инструменты стали золотым стандартом для однопользовательских игр, но с приходом мультиплеера правила игры кардинально изменились.

1.4 Техническая основа онлайн-читов: новая арена

Как только игроки вышли в онлайн, ставки мгновенно выросли. Манипуляции с памятью перестали быть личным делом и начали напрямую влиять на других людей. Поле битвы между читерами и разработчиками переместилось в многопользовательские игры, но фундаментальные технические принципы остались прежними, поскольку вся борьба разворачивалась на одном и том же уровне системных привилегий — в пользовательском режиме, также известном как Кольцо 3 (Ring 3).

Кольцо 3 — самый низкий уровень в архитектуре колец защиты процессоров x86, на нём работают все пользовательские приложения, включая игры и читы. Они обладают одинаковыми, ограниченными правами и не могут напрямую управлять оборудованием, в отличие от ядра операционной системы, которое находится в привилегированном Кольце 0 (Ring 0). Основным вектором атаки в этой симметричной среде было и оставалось прямое манипулирование памятью игрового процесса, но теперь — с целью получить преимущество над живыми противниками.

Для достижения своих целей читы использовали два основных подхода:

1. Внешний доступ через системный API. Классический метод заключался в использовании стандартных функций операционной системы, таких как Win32 API в Windows. Ключевыми инструментами в арсенале читера были три функции: OpenProcess(), ReadProcessMemory() и WriteProcessMemory(). С помощью OpenProcess() чит, зная идентификатор процесса игры, получал дескриптор (handle) — специальный объект ядра, дающий право на дальнейшие операции. Затем, используя этот дескриптор, чит мог сканировать память игры в поисках нужных значений (например, координат других игроков) с помощью ReadProcessMemory() и изменять свои собственные данные (например, углы прицеливания) функцией WriteProcessMemory().
2. Внутренний доступ через инъекцию DLL (DLL Injection). Это более продвинутый и скрытный метод. Его суть заключалась в том, чтобы заставить игровой процесс загрузить стороннюю динамически подключаемую библиотеку (DLL), содержащую код чита. После инъекции код этой DLL начинает выполняться внутри адресного пространства самой игры, как будто он является её неотъемлемой частью. Это давало читу колоссальные преимущества: ему больше не нужно было использовать ReadProcessMemory или WriteProcessMemory, которые легко обнаружить. Он мог напрямую обращаться к памяти, вызывать внутренние игровые функции (например, функцию отрисовки или расчёта полета пули) и изменять данные изнутри. Этот подход был значительно сложнее для обнаружения, так как с точки зрения системы все операции выглядели легитимными действиями самого игрового процесса.

1.5 Механизм действия: Wallhack и Aimbot

Два классических примера читов, реализованных на этом уровне, — это Wallhack и Aimbot.

• Wallhack (операция чтения): Этот чит позволяет видеть противников сквозь стены. Технически это достигалось путем многократных вызовов ReadProcessMemory (при внешнем подходе) или прямого чтения из памяти (при инъекции DLL) для получения структур данных, содержащих координаты всех игроков на карте. Получив эти координаты, читерское приложение отрисовывало их на экране в виде иконок или прямоугольников поверх игрового окна, создавая так называемый оверлей.
• Aimbot (операция записи): Этот чит автоматически наводит прицел на противника. Сначала он, как и Wallhack, с помощью ReadProcessMemory получал координаты своего игрока и цели. Затем он вычислял необходимые углы обзора (горизонтальный — yaw, и вертикальный — pitch), чтобы прицел указывал точно на врага. Наконец, с помощью WriteProcessMemory чит перезаписывал адреса в памяти, отвечающие за текущие углы обзора игрока, мгновенно наводя прицел на цель. Поскольку игра постоянно обновляет эти значения на основе ввода мыши, читу приходилось перезаписывать их с высокой частотой, чтобы поддерживать захват цели.

1.6 Ранние контрмеры и патовая ситуация в Ring 3

Первые античитерские системы также работали в пользовательском режиме и пытались противостоять этим угрозам. Основные методы включали:

• Сканирование сигнатур: Подобно антивирусам, античит сканировал запущенные процессы (в поисках cheatengine.exe или artmoney.exe) и файлы на диске в поисках известных сигнатур (уникальных последовательностей байт) читерских программ и их окон (по заголовку окна).
• Хукинг API: Античит перехватывал вызовы таких функций, как OpenProcess или ReadProcessMemory, чтобы отслеживать или блокировать несанкционированный доступ к памяти игрового процесса.
• Проверка целостности: Античит мог сканировать список загруженных в игру DLL-модулей в поисках посторонних библиотек или проверять хэш-суммы критических участков кода игры в памяти, чтобы убедиться, что они не были изменены.

Фундаментальная проблема этого этапа заключалась в том, что и чит, и античит действовали на одном и том же уровне привилегий. Это создавало симметричную войну, где ни одна из сторон не могла получить решающего преимущества. Чит мог так же легко обнаружить и отключить античит пользовательского режима, как античит мог обнаружить чит. Если античит мог сканировать память читерской программы, то и чит мог делать то же самое с античитом. Если античит мог установить перехватчик API, то чит мог его обнаружить и снять. Эта патовая ситуация означала, что борьба сводилась не к контролю над системой, а к игре в «кошки-мышки», основанной на обфускации кода и скорости выпуска обновлений. Чтобы выйти из этого тупика, одной из сторон необходимо было подняться на более высокий уровень привилегий. И читеры сделали этот шаг первыми.

Глава 2: Спуск в ядро — доминирование Кольца 0

Глава 2: Спуск в ядро — доминирование Кольца 0

2.1 Асимметричная война: невидимый и всемогущий чит

Тупиковая ситуация, сложившаяся в пользовательском режиме (Ring 3), была недолгой. Она была обречена с самого начала, потому что одна из сторон имела возможность перейти на уровень с несоизмеримо большими полномочиями. Как было упомянуто ранее, ядро операционной системы (Ring 0) обладает абсолютным контролем над всеми пользовательскими приложениями. Программа в Ring 3 подобна арендатору квартиры, в то время как ядро — это управляющий всего здания с ключами от всех дверей, доступом к камерам наблюдения и возможностью в любой момент отключить электричество. Для разработчиков читов осознание этого простого факта определило следующий шаг: чтобы победить, нужно было перестать быть жильцом и стать управляющим.

Переместив свой код в Ring 0, читеры получили абсолютное, асимметричное преимущество над любым античитом, работающим в Ring 3. Чит, реализованный в виде драйвера уровня ядра (файла с расширением .sys), становился практически невидимым и неуязвимым для программ из пользовательского режима. С его новой позиции он мог не просто манипулировать игрой, но и манипулировать самой операционной системой, заставляя её лгать античиту.

Чтобы попасть в ядро, читерам нужно было заставить систему загрузить их собственный, как правило, неподписанный драйвер. Это было нетривиальной задачей и породило целый подпольный рынок:

• Покупка украденных сертификатов: Разработчики читов приобретали на черном рынке цифровые сертификаты, украденные у легитимных компаний, чтобы подписывать свои вредоносные драйверы и выдавать их за доверенное ПО.
• Эксплуатация уязвимостей: Использовались уязвимости в уже существующих, подписанных драйверах (например, в драйверах от производителей оборудования), чтобы через них загрузить в ядро свой собственный код.
• Отключение проверки подписи: В некоторых случаях читы требовали от пользователя вручную перевести Windows в «Тестовый режим», который отключает обязательную проверку цифровых подписей драйверов.

Оказавшись в ядре, чит получал в свое распоряжение мощнейшие инструменты для маскировки и атак:

• Прямая манипуляция объектами ядра (DKOM — Direct Kernel Object Manipulation): Это, по сути, редактирование внутренней кухни операционной системы. Например, когда античит запрашивал у Windows список запущенных процессов, он обращался к системной структуре данных. Чит-драйвер мог найти свой собственный процесс в этом списке и просто удалить запись о нем. В результате, с точки зрения античита, читерской программы просто не существовало в системе.
• Хукинг таблицы диспетчеризации системных сервисов (SSDT Hooking): Это еще более коварный метод. SSDT — это таблица, которую ядро использует для поиска нужных системных функций. Чит мог подменить адрес в этой таблице. Например, когда античит пытался вызвать функцию OpenProcess, чтобы получить доступ к памяти игры, его запрос перехватывался читом. Чит мог либо полностью заблокировать вызов, либо вернуть античиту ложную информацию, сохраняя свою деятельность в тайне.
• Прямое чтение памяти без API: Находясь в ядре, читу больше не нужно было использовать функции вроде ReadProcessMemory, которые легко отследить. Он мог напрямую обращаться к любой физической ячейке памяти, что делало его действия абсолютно невидимыми для любых программных средств мониторинга из Ring 3.

2.2 Ответный удар: античиты спускаются в ядро

Столкнувшись с угрозой, которую невозможно было обнаружить из пользовательского режима, разработчики игр были вынуждены последовать за читерами в Ring 0. Так появились античиты уровня ядра, такие как BattlEye, Easy Anti-Cheat (EAC) и более поздний Riot Vanguard. Их основной задачей было восстановить паритет, действуя на том же уровне привилегий, что и читы.

Их арсенал был зеркальным отражением арсенала читеров:

• Проверка целостности ядра: Античит-драйвер при запуске создавал слепок ключевых областей ядра, включая таблицу SSDT и другие критические структуры. Затем он периодически сравнивал текущее состояние системы с этим эталонным слепком. Любое несоответствие (например, обнаруженный хук в SSDT) немедленно сигнализировало о компрометации системы и приводило к отключению от игры.
• Блокировка доступа к памяти на уровне ядра: Используя привилегии Ring 0, античит мог на системном уровне блокировать попытки создания дескриптора процесса игры (через OpenProcess) со стороны любых подозрительных приложений, эффективно лишая их возможности читать или писать в память игры.
• Системный мониторинг через обратные вызовы (Callbacks): Античиты регистрировали в ядре специальные функции-перехватчики (callbacks) для отслеживания таких событий, как создание процессов и потоков, загрузка модулей и драйверов по всей системе. Это позволяло им в реальном времени анализировать активность на компьютере и выявлять подозрительное поведение, характерное для читов.

2.3 Новое поле битвы и цена доверия

Этот переход превратил ядро операционной системы в новое поле битвы. Но на этот раз война снова стала симметричной: руткит сражался против руткита на одном и том же, самом привилегированном уровне. Это привело к очередной патовой ситуации, но с гораздо более высокими ставками.

При этом такой переход имел далекоидущие последствия. Античит, по своей сути, превратился в специализированный руткит, который пользователи добровольно устанавливали на свои системы. Это стирало границу между игровым приложением и операционной системой, предоставляя сторонней компании полный контроль над компьютером пользователя. Такой уровень инвазивности вызвал серьезные опасения по поводу безопасности и конфиденциальности, ведь уязвимость в античит-драйвере могла привести к компрометации всей системы.

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

Глава 3: Атаки извне — аппаратные и гипервизорные эксплойты

Глава 3: Атаки извне — аппаратные и гипервизорные эксплойты

Когда битва в ядре достигла своего апогея и превратилась в симметричную войну руткитов, разработчики читов сделали следующий логический шаг: они вышли за пределы операционной системы. Если нельзя было гарантированно победить внутри Ring 0, нужно было найти уровень, с которого сам Ring 0 выглядел бы как подконтрольная территория. Новые векторы атак были нацелены на уровни, находящиеся вне юрисдикции ОС, что делало даже самые продвинутые античиты уровня ядра абсолютно слепыми.

3.1 Аппаратный призрак: атаки через прямой доступ к памяти (DMA)

Архитектура шины PCI Express (PCIe) позволяет периферийным устройствам, таким как видеокарты или сетевые адаптеры, становиться «bus master» — то есть получать право на прямой доступ к физической оперативной памяти системы, минуя центральный процессор. Эта возможность, предназначенная для повышения производительности, стала основой для одного из самых мощных и практически необнаруживаемых методов читерства.

• Механизм атаки: Невидимое вмешательство
  Атака с использованием DMA требует двух компьютеров.
  • В основной игровой ПК устанавливается специальная плата PCIe (часто на базе FPGA — программируемой логической интегральной схемы), которая подключается ко второму, внешнему компьютеру. Можно представить эту плату как внедренного шпиона с высшим уровнем допуска, который не подчиняется центральному командованию (ЦП).
  • На втором ПК запускается сама читерская программа. Логика чита отправляет команды (например, «прочитать память по адресу X» или «записать значение Y по адресу Z») на DMA-плату. Эта плата, будучи доверенным устройством на шине PCIe, выполняет эти команды, напрямую обращаясь к физической памяти игрового ПК.
     
• Почему это так эффективно?
  Потому что с точки зрения операционной системы и центрального процессора ничего не происходит. ЦП — это мозг системы, а ОС — его сознание. Все программные античиты, даже уровня ядра, полагаются на то, что ЦП обрабатывает все запросы к памяти. Атака через DMA полностью обходит этот контур. Это как если бы кто-то мог читать ваши мысли и управлять вашими руками, не посылая сигналов в ваш мозг. Операционная система и все работающее на ней ПО, включая античит-драйвер, остаются в полном неведении. Для них не происходит никаких подозрительных вызовов API или обращений к памяти со стороны программного обеспечения.

3.2 Кукловод в тени: читы на основе гипервизора (Кольцо -1)

Другой, не менее изощренный подход к выходу за пределы ОС — это использование виртуализации. Гипервизоры первого типа (bare-metal), такие как KVM или Hyper-V, создают уровень абстракции над физическим оборудованием, позволяя запускать операционные системы в изолированных виртуальных машинах. Этот уровень работает с более высокими привилегиями, чем ядро гостевой ОС, и его условно называют «Кольцо -1» (Ring -1). Если ядро (Ring 0) — это бог внутри операционной системы, то гипервизор — это сущность, которая создала саму эту вселенную.

• Интроспекция виртуальных машин (VMI): Взгляд извне
  Это ключевая технология для гипервизорных читов. VMI позволяет гипервизору заглядывать внутрь работающей виртуальной машины, инспектировать и изменять состояние ее памяти и регистров ЦП с позиции высших привилегий.
   
• Механизм атаки: Манипуляция симуляцией
  Игра и античит запускаются внутри гостевой виртуальной машины, которая для них является абсолютно реальной операционной системой. Сама читерская программа работает на хостовой ОС или непосредственно в гипервизоре. Используя библиотеки VMI (например, LibVMI), чит находит в памяти гостевой виртуальной машины игровой процесс и выполняет те же операции чтения и записи, что и обычные читы. Он может на мгновение заморозить виртуальную машину, изменить нужные значения (например, координаты прицела), а затем разморозить ее. С точки зрения античита, работающего внутри виртуальной машины, время просто сделало микроскопический скачок вперед, а данные изменились сами по себе. В его операционной среде нет никакого вредоносного кода, и никаких несанкционированных обращений к памяти не происходит.

3.3 Инверсия доверия: когда система лжет сама себе

Появление DMA и гипервизорных читов стало переломным моментом, который полностью инвертировал традиционную модель безопасности. Десятилетиями безопасность строилась на предположении, что ядро ОС является конечным корнем доверия. Эти атаки доказали, что если злоумышленник может получить привилегии ниже или вне ядра, целостность всего программного стека теряет смысл. Античит в ядре может докладывать, что система чиста, но он не способен осознать, что за ним самим наблюдают и манипулируют им с более высокого уровня. Это осознание стало главным катализатором перехода индустрии к модели доверия, укорененной в аппаратном обеспечении. Программное обеспечение больше не могло доверять самому себе; его нужно было «заякорить» на чем-то неизменяемом и физически существующем.

Глава 4: Создание аппаратного корня доверия — современная парадигма защиты

Глава 4: Создание аппаратного корня доверия — современная парадигма защиты

Атаки извне операционной системы поставили индустрию перед фактом: программное обеспечение больше не может служить доказательством собственной целостности. Перед разработчиками встал критический вопрос: «Как система может доказать, что она не работает под управлением вредоносного гипервизора и ею не манипулирует читерское DMA-устройство?» Ответ лежал не в создании еще более сложного программного обеспечения, а в спуске на самый фундаментальный уровень — к кремнию. Нужен был якорь, корень доверия (Root of Trust), выкованный не в изменяемом коде, а в физически неизменяемом оборудовании.

4.1 UEFI Secure Boot: Криптографический привратник

Традиционный процесс загрузки через BIOS был уязвим для буткитов — вредоносных программ, которые заражали главную загрузочную запись (MBR) и загружались еще до старта ОС, получая контроль над Ring 0 с самого начала. Технология Secure Boot, являющаяся частью стандарта UEFI, заменила этот проходной двор на строгий криптографический контроль.

Можно представить Secure Boot как элитного привратника на входе в систему. У него есть два списка:

1. Белый список (база данных db): Список хэшей и цифровых сертификатов доверенных программных компонентов (загрузчиков, драйверов), которым разрешен вход.
2. Черный список (база данных dbx): Список подписей известного вредоносного или скомпрометированного ПО, которому вход категорически воспрещен. Этот список имеет приоритет.

При включенной Secure Boot каждый компонент, исполняемый в процессе загрузки, должен предъявить свой «пропуск» — цифровую подпись. Эта проверка проходит по цепочке: прошивка UEFI проверяет подпись загрузчика ОС (например, Windows Boot Manager), а тот, в свою очередь, проверяет подпись ядра операционной системы. Если на каком-либо этапе подпись недействительна, отсутствует или находится в черном списке, загрузка немедленно прерывается. Secure Boot — это силовой компонент, принуждающий систему к загрузке только доверенного кода. Для борьбы с читами его роль ключевая, так как он напрямую блокирует загрузку неподписанных драйверов уровня ядра, которые являются основой для большинства современных читов и руткитов.

4.2 Trusted Platform Module (TPM 2.0): Неподкупный нотариус

Если Secure Boot — это привратник, который обеспечивает порядок, то TPM — это неподкупный нотариус и бортовой самописец в одном лице. TPM — это специализированный, защищенный от взлома криптопроцессор, который существует в виде отдельного чипа на материнской плате (dTPM) или интегрирован в прошивку/ЦП (fTPM). Его главная функция — выполнять криптографические операции и хранить секреты в среде, полностью изолированной от основной ОС.

Ключевая функция TPM в этом контексте — Измеряемая загрузка (Measured Boot). Этот процесс работает параллельно с Secure Boot и выполняет другую задачу: он не запрещает, а протоколирует.

Platform Configuration Registers (PCRs): Криптографический слепок системы

Внутри TPM есть 24 специальных регистра (PCR), защищенных от прямого изменения. Единственная операция, которую можно с ними произвести, — это «расширение» (extend). Представьте, что у вас есть восковая печать. Вы не можете стереть с нее оттиск, но можете приложить новую печать поверх старой, создав новый, уникальный комбинированный узор. Операция extend работает так же: 

PCR_new = HASH(PCR_old||new_data).

В процессе загрузки системы хэш каждого компонента (прошивки UEFI, драйверов, загрузчика, ядра) «расширяет» значение определенного PCR. В результате формируется уникальный набор конечных значений PCR, который служит криптографическим отпечатком пальца всего загруженного программного стека. Любое, даже малейшее, изменение в любом из компонентов приведет к совершенно другому конечному значению PCR.

Secure Boot и Measured Boot работают в идеальной синергии:

• Secure Boot (Привратник) гарантирует, что загружается только доверенный код.
• Measured Boot (Нотариус) создает неизменяемую запись, криптографически доказывающую, что был загружен именно этот доверенный код и ничего более.

Таким образом, теперь у клиентской машины есть и силовой механизм для обеспечения доверия, и нотариальный механизм для его подтверждения. Она может создать локально проверяемое доверенное состояние. Но эта информация бесполезна, пока она заперта внутри самого компьютера. Чтобы она имела ценность для онлайн-игры, это состояние нужно как-то доказать удаленному серверу. Этот процесс называется удаленной аттестацией.

Глава 5: Удаленная аттестация — протокол верификации сервера

Глава 5: Удаленная аттестация — протокол верификации сервера

Удаленная аттестация — это протокол, который связывает аппаратный корень доверия на клиентской машине с удаленным игровым сервером. Именно этот механизм позволяет превратить локальный «акт о целостности системы», составленный «нотариусом» TPM, в неоспоримое доказательство для сервера, которому нужно решить: пускать игрока или нет.

Можно представить это как работу дипломатического курьера. У него есть сверхсекретный документ (состояние системы), который нужно доставить в центр. Чтобы доказать подлинность, он использует специальный, защищенный от вскрытия кейс (TPM) с уникальным серийным номером (ключ EK). Для каждой миссии он ставит на кейс новую одноразовую пломбу (ключ AK), подлинность которой можно проверить по серийному номеру кейса.

Криптографическое рукопожатие: пошаговый разбор

Удаленная аттестация — это, по сути, криптографическое рукопожатие (хендшейк), в котором сервер бросает клиенту вызов, а клиент должен предоставить неоспоримое аппаратное доказательство своей честности.

Ключевые участники:

• Аттестуемый (Attester): Игровой клиентский ПК. Наш дипкурьер.
• Проверяющий (Verifier): Удаленный игровой сервер (например, серверы Riot или Activision). Центр, принимающий донесение.
• TPM-ключи:
  • Endorsement Key (EK): Уникальный, неизменяемый ключ, встроенный в TPM производителем. Это серийный номер кейса, доказывающий, что он подлинный, а не дешевая подделка.
  • Attestation Key (AK): Ключ для подписи, генерируемый TPM для конкретной сессии. Это одноразовая пломба, используемая для этой конкретной миссии. Она криптографически связана с серийным номером, но не раскрывает его напрямую, защищая приватность.

Процесс аттестации (Миссия дипкурьера):

1. Вызов (Challenge): Игровой сервер отправляет клиенту случайное, одноразовое число, называемое nonce. Центр сообщает курьеру секретное слово дня, например, «гроза». Это нужно, чтобы убедиться, что курьер не пытается использовать старое донесение.
2. Генерация «цитаты» (Quote): Клиентское приложение обращается к своему TPM с командой TPM2_Quote. TPM берет текущие значения PCR (тот самый отпечаток пальца системы), объединяет их с полученным от сервера nonce («гроза») и подписывает весь этот пакет данных закрытой частью своего Attestation Key (AK). Курьер кладет в кейс сам документ (значения PCR) и листок с кодовым словом «гроза», после чего защелкивает кейс и ставит на него одноразовую пломбу (AK). Этот запечатанный пакет и есть «цитата».
3. Ответ: Клиент отправляет серверу «цитату», журнал событий TCG (TCG Event Log — человекочитаемый лог того, что именно измерялось в PCR, чтобы сервер мог сам перепроверить вычисления) и сертификат открытого ключа AK. Курьер передает в центр запечатанный кейс, а также сопроводительные документы, подтверждающие подлинность пломбы.
4. Верификация: Сервер выполняет несколько проверок:
   • Проверяет цифровую подпись на «цитате» с помощью открытого ключа AK, убеждаясь, что пломба не подделана и принадлежит настоящему кейсу.
   • Проверяет, что nonce внутри «цитаты» совпадает с тем, который он отправил («гроза»). Это защищает от атак повторного воспроизведения (replay attacks).
   • Воспроизводит вычисления, проигрывая полученный TCG Event Log, чтобы рассчитать, какими должны быть конечные значения PCR для чистой системы.
   • Финальная проверка: Сравнивает значения PCR из подписанной «цитаты» с ожидаемыми значениями, которые он только что рассчитал. Центр вскрывает кейс и сверяет полученный документ с эталонной копией, которая хранится у него в сейфе.

Если все проверки проходят успешно и значения совпадают, сервер получает криптографическое доказательство того, что клиент загрузился с нетронутым, известным и доверенным программным стеком.

Применение в античитах: Паспортный контроль
Если аттестация проходит успешно, игроку разрешается подключиться к серверу. Если она проваливается (значения PCR не совпадают, подпись неверна, nonce не тот), соединение отклоняется. Это эффективно блокирует игроков, которые отключили Secure Boot, загрузили руткит или иным образом изменили ядро своей ОС.

Этот подход представляет собой фундаментальный сдвиг в работе античитов. Он превращает античит из инвазивного детектива, который бегает по системе клиента с лупой, в строгого, но эффективного пограничника на стороне сервера. Ему больше не нужно обыскивать каждого входящего — достаточно проверить его паспорт (цитату TPM). Вместо того чтобы античит-драйвер активно охотился за руткитами, он просто запрашивает у аппаратного обеспечения (TPM) подписанный отчет о состоянии системы, а верификацию выполняет сервер. Это более элегантный, безопасный и потенциально менее ресурсоемкий способ проверки доверия, превращающий роль античита из активного сканера в пассивного верификатора аппаратного доказательства.

Глава 6: Укрепление системы и взгляд в будущее

Глава 6: Укрепление системы и взгляд в будущее

Создание аппаратного корня доверия с помощью TPM и Secure Boot — это мощнейший ход в этой многолетней партии, но это не мат. Это создание укрепленной цитадели. И враг все еще может найти обходные пути. Поэтому для всесторонней защиты требуются дополнительные эшелоны обороны, закрывающие оставшиеся бреши и предвосхищающие следующие шаги противника

6.1 Противодействие DMA: Аппаратный пограничный контроль с помощью IOMMU

Удаленная аттестация доказывает, что операционная система загрузилась в доверенном состоянии. Но она не может помешать аппаратному шпиону — DMA-плате — напрямую читать и писать в память, обходя и ОС, и процессор. Эту брешь закрывает IOMMU (Input-Output Memory Management Unit) — аппаратный компонент, который действует как персональный пограничник для каждого периферийного устройства. У Intel эта технология называется VT-d, у AMD — AMD-Vi.

Если обычный доступ к памяти — это открытое поле, то IOMMU — это система строго охраняемых коридоров. Операционная система может настроить IOMMU так, чтобы создать аппаратно-обеспеченные границы, разрешая, например, сетевой карте доступ только к ее собственному буферу, а видеокарте — только к видеопамяти. Любая попытка вредоносной DMA-карты прочитать память игрового процесса за пределами разрешенного коридора немедленно блокируется на аппаратном уровне, что приводит к ошибке. В ответ на рост популярности DMA-читов, античитерские системы, такие как Vanguard и FACEIT, начали требовать обязательного включения IOMMU в BIOS, достраивая еще одну стену вокруг своей цитадели.

6.2 Оружие врага в своих руках: Virtualization-Based Security (VBS)

Гипервизор, выступавший инструментом для читеров в Кольце -1, теперь стал ключевым элементом защиты Windows. При включении VBS (Безопасность на основе виртуализации) происходит инверсия: сама Windows начинает работать в слегка ограниченной виртуальной машине (VTL0), в то время как небольшая, критически важная для безопасности часть ядра (так называемое Secure Kernel) выполняется в изолированной, сверхпривилегированной виртуальной среде (VTL1).

Ключевой функцией, которую обеспечивает VBS, является Hypervisor-Enforced Code Integrity (HVCI), также известная как Memory Integrity (Целостность памяти). Процесс проверки целостности кода ядра переносится из уязвимой среды VTL0 в защищенную VTL1. Это означает, что даже если злоумышленник скомпрометирует основное ядро (VTL0), он не сможет вмешаться в работу механизма проверки целостности, который наблюдает за ним сверху. Это не позволит ему загрузить вредоносные драйверы или модифицировать исполняемые страницы памяти. Требование включения HVCI/VBS со стороны античитов добавляет еще один мощный уровень защиты от читов уровня ядра, обеспечиваемый самим гипервизором.

6.3 Поле битвы будущего: Новые рубежи

Несмотря на все эти многоуровневые аппаратные защиты, гонка вооружений не останавливается. Она лишь переходит на новые, еще более изощренные рубежи.

• Атаки на сам корень доверия: Следующая цель — не обойти цитадель, а подделать ключи от нее. Актуальные исследования показывают не только теоретическую, но и практическую возможность атаки на само оборудование. К ним относятся физическое вмешательство для сброса PCR в TPM, использование уязвимостей в прошивке UEFI для записи поддельных измерений или эксплуатация уязвимых, но легитимно подписанных загрузчиков для обхода Secure Boot.
• Читы вне системы (Искусственный интеллект и компьютерное зрение): Читы нового поколения используют второй компьютер, который получает видеопоток с игрового ПК через карту видеозахвата. Нейронная сеть на втором ПК анализирует изображение в реальном времени, обнаруживает противников и отправляет команды на специальное USB-устройство, которое эмулирует движения мыши. С точки зрения игрового ПК и античита, это просто очень умелый игрок. Борьба с такими читами переносится с клиента на сервер: античиты начинают использовать модели машинного обучения для анализа поведения игроков, выявляя нечеловечески точные паттерны прицеливания, траектории движения и время реакции.
• Перенос доверия на сервер: Конечной точкой этой логики является полный отказ от доверия клиенту. Идеальным решением является полная симуляция игрового мира на сервере, где клиент выступает лишь в роли терминала для ввода-вывода. Хотя для динамичных шутеров от первого лица это создает неприемлемые задержки (latency). Поэтому разработчики ищут компромисс, делая сервер максимально авторитетным в принятии решений (например, в регистрации попаданий), но все еще полагаясь на аппаратную аттестацию клиента для базового допуска к игре.

---

Заключение: Бесконечная война и цена честной игры

История этой войны — это история неуклонного, каскадного падения доверия. Это сага о том, как битва за честную игру заставила нас совершить головокружительный спуск с уровня приложений, где программы сражались на равных, в самые глубокие и привилегированные недра системы, а затем и вовсе выйти за их пределы. Каждый новый этап эскалации — от манипуляций в Ring 3 до руткитов в Ring 0, а затем до аппаратных DMA-атак и гипервизорных эксплойтов — был очередным ударом по фундаментальному предположению, что программное обеспечение способно контролировать и верифицировать само себя.

Мы достигли точки, где операционная система больше не может доверять собственному ядру, а ядро не может быть уверено, что им не манипулируют с более высокого, невидимого для него уровня. И в этом смысле требование TPM 2.0 и Secure Boot — это не прихоть разработчиков и не очередной рубеж в гонке вооружений. Это официальное признание того, что в цифровом мире, где все можно скопировать, изменить и подделать, единственным источником истины, последним неоспоримым арбитром становится физически неизменяемое оборудование. Мы вынуждены заякорить эфемерный мир кода на непоколебимом фундаменте кремния, потому что все остальное оказалось скомпрометировано.

Этот сдвиг парадигмы фундаментально меняет наши отношения с собственными компьютерами. Право на честную игру вступает в прямое противоречие с абсолютной свободой пользователя контролировать свою машину. Чтобы сервер мог доверять клиенту, он должен получить криптографическое доказательство целостности всей системы, от прошивки до драйверов. Для рядового игрока, вынужденного разбираться в настройках BIOS, это выглядит как неоправданное усложнение. Но на самом деле это — прямое следствие войны, в которой поле битвы расширилось до самого компьютера.

И эта война не окончена. Она лишь переходит на новый виток. Следующими полями сражений станут серверные ИИ, анализирующие поведение игроков, атаки на сам аппаратный корень доверия и еще более изощренные методы обхода, не требующие модификации системы. Битва между читерами и разработчиками игр стала миниатюрной моделью всей современной кибербезопасности, заставляя нас снова и снова отвечать на один и тот же вопрос: чему мы еще можем доверять? Сегодня цена честного матча в онлайн-шутере — это частичка контроля над собственным устройством. И этот компромисс, как никакой другой, определяет нашу цифровую эпоху.

[mahaleksmos 9]

Так там вроде уже читеры были)))  в бетке. 

[piton4 5 686]

49 минут назад, mahaleksmos сказал:

Так там вроде уже читеры были)))  в бетке. 

300k на минуточку. Может конечно в новости очепятка, хз    или я что-то не так прочёл

[edifiei 6 005]

17 часов назад, mahaleksmos сказал:

Так там вроде уже читеры были)))  в бетке. 

 

16 часов назад, piton4 сказал:

300k на минуточку. Может конечно в новости очепятка, хз    или я что-то не так прочёл

Оказалось что эта МЕГАзащита обходится отключение интернета в момент  проверки….

[0wn3df1x 4 679]

40 минут назад, edifiei сказал:

Оказалось что эта МЕГАзащита обходится отключение интернета в момент  проверки….

Это как раз то, о чём я писал между 4 и 5 главами.

Аппаратный корень доверия - это лишь полдела. Можно построить несокрушимую крепость из кремния, с башнями из Secure Boot и стражниками TPM, но вся эта мощь абсолютно бесполезна, если нет надёжного способа проверить пропуск на входе. А способ этот - удалённая аттестация. Без неё это равносильно навешиванию сложного и дорогого замка на картонную дверь.

Теория

1. Стены и башни (Secure Boot & TPM): Они на месте. Secure Boot гарантирует, что при загрузке системы в неё не проник вражеский лазутчик (неподписанный драйвер). TPM (через Measured Boot) скрупулезно записывает в свой защищенный журнал (PCR-регистры) каждый шаг загрузки, создавая уникальный "отпечаток" состояния системы. Оборудование - тот самый "неизменяемый арбитр" - свою работу выполняет безукоризненно.
2. Протокол проверки (Remote Attestation): Когда игрок запускает игру, привратник у ворот (лаунчер игры) должен провести строгую проверку. Он связывается со столицей и получает оттуда секретный пароль на сегодня (nonce). Затем он просит внутреннего нотариуса (TPM) поставить на отчет о состоянии крепости (значения PCR) свою уникальную печать (Attestation Key), приложив к нему и сегодняшний пароль. Этот запечатанный и заверенный отчет (quote) отправляется в столицу. Там его сверяют с эталоном. Если отчет подлинный и состояние крепости "чистое" - ворота открываются.

Эта система теоретически безупречна. Она не доверяет ничему, что может быть подделано программно, и опирается только на аппаратное доказательство. Где же провал?

Практика
Провал кроется не в крепости и не в протоколе. Он кроется в инструкции, выданной привратнику на воротах. В программной логике лаунчера игры.

Разработчики античита допустили фундаментальную, классическую ошибку в проектировании систем безопасности, реализовав так называемый принцип "fail-open" (отказ в сторону открытия) вместо единственно верного "fail-closed" (отказ в сторону закрытия).

Что происходит в итоге:

1. Начало проверки: Игрок запускает Battlefield 6. Лаунчер (привратник) начинает процедуру аттестации и отправляет на сервер ЕА (в столицу) запрос на получение nonce (секретного пароля).
2. Обрыв связи: В этот самый момент игрок выдергивает сетевой кабель. Связь со столицей прерывается.
3. Критическая ошибка логики: Лаунчер не получает ответа от сервера. Вместо того чтобы следовать принципу "fail-closed" ("Нет связи со столицей? Значит, проверка не пройдена, ворота остаются закрытыми до восстановления связи и успешной верификации!"), программа выполняет катастрофическую инструкцию "fail-open". В коде, вероятно, написано что-то вроде:

   try {
       // Попытаться провести удаленную аттестацию
       performRemoteAttestation();
   } catch (NetworkTimeoutException e) {
       // Ой, сервер недоступен. Наверное, у него проблемы.
       // Не будем мешать игроку, пропустим его.
       // Ведь главное — чтобы он мог играть!
       bypassSecurityCheck();
   }

4. Обход защиты: Проверка безопасности просто пропускается. Игра считает, что все в порядке, и продолжает загрузку, не получив ни подтверждения, ни опровержения чистоты системы.
5. Восстановление связи: Как только игра прошла этот этап и загрузила главное меню, игрок снова подключает интернет. Теперь игра может свободно общаться с серверами для подбора матчей, и никто уже не вспомнит о той маленькой сетевой ошибке на старте.

Вся архитектура безопасности, спустившаяся до уровня кремния, была повержена одной строчкой кода в блоке catch. Разработчики построили неприступную крепость, но научили привратника на воротах впадать в панику и открывать их нараспашку, если у него на мгновение пропадает телефонная связь. 

[PermResident 2 561]

20 часов назад, piton4 сказал:

300k на минуточку. Может конечно в новости очепятка, хз    или я что-то не так прочёл

вот вам 300к читеров, на правах наброса

и Античит Battlefield 6 потребовал от игроков удалить с компьютера Valorant

3 часа назад, 0wn3df1x сказал:

// Ой, сервер недоступен. Наверное, у него проблемы. // Не будем мешать игроку, пропустим его. // Ведь главное — чтобы он мог играть!

для Beta верное решение, всё правильно сделали.

3 часа назад, 0wn3df1x сказал:

Аппаратный корень доверия - это лишь полдела. Можно построить несокрушимую крепость из кремния, с башнями из Secure Boot и стражниками TPM, но вся эта мощь абсолютно бесполезна, если нет надёжного способа проверить пропуск на входе.

3 часа назад, 0wn3df1x сказал:

Вся архитектура безопасности, спустившаяся до уровня кремния, была повержена одной строчкой кода в блоке catch. Разработчики построили неприступную крепость, но научили привратника на воротах впадать в панику и открывать их нараспашку, если у него на мгновение пропадает телефонная связь. 

вот только откуда нам знать что они сделали это не специально? Специально открыли двери для всех желающих, зная что среди них будут те самые и… заранее пометили их, а часть заблокировали. Да и проверили на практике ложные срабатывания, чтобы исключить подобное на релизе. Кто их знает.

Что если задача изначально была не блокировать читеров, а пометить их и изучить их инструменты.

Изменено 11 августа пользователем PermResident
дополнение

[edifiei 6 005]

5 часов назад, PermResident сказал:

 

Что если задача изначально была не блокировать читеров, а пометить их и изучить их инструменты.

Так вроде для этот его в 2042 добавляли.

Я думаю, тут просто дали с подливой.

[Trace of Riddles 29]

В итоге после всех нововведений количество читеров уменьшилось? 

Мне кажется что нет. 

В 11.08.2025 в 18:10, PermResident сказал:

вот только откуда нам знать что они сделали это не специально? Специально открыли двери для всех желающих, зная что среди них будут те самые и… заранее пометили их, а часть заблокировали. Да и проверили на практике ложные срабатывания, чтобы исключить подобное на релизе. Кто их знает.

Что если задача изначально была не блокировать читеров, а пометить их и изучить их инструменты.

Типа многоходовочка от разработчиков? Смешно же. Это работает в обе стороны. 

Изменено 12 августа пользователем Trace of Riddles

[mahaleksmos 9]

Я честно хз че и как с этим кодом. Но игра стоит бабки. Если прям вы уверены в читерстве блок на игру и всё. Пусть в сингл играет и норм.

[PaigeHess 0]

В 11.08.2025 в 13:24, 0wn3df1x сказал:

Это как раз то, о чём я писал между 4 и 5 главами.

Аппаратный корень доверия - это лишь полдела. Можно построить несокрушимую крепость из кремния, с башнями из Secure Boot и стражниками TPM, но вся эта мощь абсолютно бесполезна, если нет надёжного способа проверить пропуск на входе. А способ этот - удалённая аттестация. Без неё это равносильно навешиванию сложного и дорогого замка на картонную дверь.

Теория

1. Стены и башни (Secure Boot & TPM): Они на месте. Secure Boot гарантирует, что при загрузке системы в неё не проник вражеский лазутчик (неподписанный драйвер). TPM (через Measured Boot) скрупулезно записывает в свой защищенный журнал (PCR-регистры) каждый шаг загрузки, создавая уникальный "отпечаток" состояния системы. Оборудование - тот самый "неизменяемый арбитр" - свою работу выполняет безукоризненно.
2. Протокол проверки (Remote Attestation): Когда игрок запускает игру, привратник у ворот (лаунчер игры) должен провести строгую проверку. Он связывается со столицей и получает оттуда секретный пароль на сегодня (nonce). Затем он просит внутреннего нотариуса (TPM) поставить на отчет о состоянии крепости (значения PCR) свою уникальную печать (Attestation Key), приложив к нему и сегодняшний пароль. Этот запечатанный и заверенный отчет (quote) отправляется в столицу. Там его сверяют с эталоном. Если отчет подлинный и состояние крепости "чистое" - ворота открываются.

Эта система теоретически безупречна. Она не доверяет ничему, что может быть подделано программно, и опирается только на аппаратное доказательство. Где же провал?

Практика
Провал кроется не в крепости и не в протоколе. Он кроется в инструкции, выданной привратнику на воротах. В программной логике лаунчера игры.

Разработчики античита допустили фундаментальную, классическую ошибку в проектировании систем безопасности, реализовав так называемый принцип "fail-open" (отказ в сторону открытия) вместо единственно верного "fail-closed" (отказ в сторону закрытия).

Что происходит в итоге:

1. Начало проверки: Игрок запускает Battlefield 6. Лаунчер (привратник) начинает процедуру аттестации и отправляет на сервер ЕА (в столицу) запрос на получение nonce (секретного пароля).
2. Обрыв связи: В этот самый момент игрок выдергивает сетевой кабель. Связь со столицей прерывается.
3. Критическая ошибка логики: Лаунчер не получает ответа от сервера. Вместо того чтобы следовать принципу "fail-closed" ("Нет связи со столицей? Значит, проверка не пройдена, ворота остаются закрытыми до восстановления связи и успешной верификации!"), программа выполняет катастрофическую инструкцию "fail-open". В коде, вероятно, написано что-то вроде:

   
   try {
       // Попытаться провести удаленную аттестацию
       performRemoteAttestation();
   } catch (NetworkTimeoutException e) {
       // Ой, сервер недоступен. Наверное, у него проблемы.
       // Не будем мешать игроку, пропустим его.
       // Ведь главное — чтобы он мог играть!
       bypassSecurityCheck();
   }

4. Обход защиты: Проверка безопасности просто пропускается. Игра считает, что все в порядке, и продолжает загрузку, не получив ни подтверждения, ни опровержения чистоты системы.
5. Восстановление связи: Как только игра прошла этот этап и загрузила главное меню, игрок снова подключает интернет. Теперь игра может свободно общаться с серверами для подбора матчей, и никто уже не вспомнит о той маленькой сетевой ошибке на старте.

Вся архитектура безопасности, спустившаяся до уровня кремния, была повержена одной строчкой кода в блоке catch. Разработчики построили неприступную крепость, но научили привратника на воротах впадать в панику и открывать их нараспашку, если у него на мгновение пропадает телефонная связь. 

И вот на этом фоне особенно заметно, как в играх вроде 1вин ключевую роль играет именно стабильность работы и уверенность в том, что процесс всегда будет под контролем.

Даже при корректном fail closed сценарии критично то, как именно обрабатывается состояние системы после обрыва связи. Если лаунчер слишком агрессивно блокирует игрока (из-за ложных срабатываний или временных проблем на стороне сервера), это превращается уже в точку отказа для добросовестных пользователей. Поэтому надежная архитектура должна включать не только fail closed, но и механизм отложенной верификации. То есть игра запускается в ограниченном режиме или с временным токеном, но окончательная проверка состояния обязательно проходит при восстановлении соединения. Иначе система превращается либо в дырявую, либо в непрактичную