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

[0wn3df1x 4 683]

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

---

В последние дни игровое сообщество гудит от негодования. Причиной тому стало всё более активное внедрение обязательных требований 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, это выглядит как неоправданное усложнение. Но на самом деле это — прямое следствие войны, в которой поле битвы расширилось до самого компьютера.

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

[Ленивый 5 015]

1 час назад, Dusker сказал:

Да никому не надо рисковать аккаунтом, на котором долго набивается рейтинг. 

Может он его на продажу набивает

42 минуты назад, jk232431 сказал:

К слову и русификатор на такую игру уже не сделать будет.

Вот и хорошо — поскольку это будет уже не игра, а сервис-казино.

[Dusker 670]

@0wn3df1x @Freeman665 

В играх есть режим спектры. Наблюдателя тобишь. А еще можно посмотреть реплеи. Если кто-то подозревает неладное, то можно дать репорт.

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

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

[Freeman665 7 716]

21 минуту назад, Dusker сказал:

Никому не надо рисковать аккаунтом.

В теории — никому. На практике все же находятся такие.

[Tirniel 1 554]

7 часов назад, 0wn3df1x сказал:

До сих пор у этой модели был один изъян: ее можно было обойти. Прямой доступ к памяти процесса на клиентском ПК (ReadProcessMemory, WriteProcessMemory - наши старые знакомые) позволял энтузиастам создавать трейнеры, которые делали то же самое, но бесплатно. Даже перенос части логики на сервер не спасал.

А вот полный перенос игры в облако решает эту проблему кардинально и окончательно. Когда вся игровая логика будет исполняется на удаленном сервере, у пользователя на компьютере не будет ничего, кроме видеопотока. Взламывать будет нечего. И здесь издатель получает абсолютный, неоспоримый контроль.

• Хотите сэкономить время и увидеть все сундуки на карте? Платите. Других вариантов нет.

И буквально несколькими комментами ранее тем же человеком был указан один из методов обхода данной ситуации.

13 часов назад, 0wn3df1x сказал:

Механизм выглядит так:

1. Игрок получает видеопоток с игрового сервера.
2. Этот видеопоток перехватывается (например, с помощью виртуального “второго монитора” или внешней карты видеозахвата).
3. Он подается на вход нейронной сети, работающей на том же или на втором компьютере.
4. ИИ в реальном времени анализирует картинку: распознает модели противников, подсвечивает их даже в дыму или тени, вычисляет упреждение для стрельбы, реагирует на вспышку выстрела за долю секунды.
5. Проанализировав ситуацию, ИИ отдает команды на специальное USB-устройство, которое система видит как обычную мышь или клавиатуру, и производит выстрел с нечеловеческой точностью.

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

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

[BossDigger 6]

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

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

Уже обошли. Как и RV.

Читы уже тестировались до выхода вчерашней беты.

12 часов назад, Dusker сказал:

@0wn3df1x @Freeman665 если игрок не замечает, что против него используют чит, откуда взяться проблеме с читерами в принципе? 

Если ты не замечаешь, то это не значит отсутствие проблемы. У тебя очень наивная позиция.

[piton4 5 725]

50 минут назад, BossDigger сказал:

 

Если ты не замечаешь, то это не значит отсутствие проблемы. У тебя очень наивная позиция.

    
 

Если что-то в не поля твоего зрения, значит этого не существует. Это фундаментальные основы реальности, и насколько помню, преподаётся на теоретической физике ещё в начальных классах. Ты в школе не учился?

[Сильвер_79 9 082]

16 минут назад, piton4 сказал:

 Если что-то в не поля твоего зрения, значит этого не существует. Это фундаментальные основы реальности, и насколько помню, преподаётся на теоретической физике ещё в начальных классах. Ты в школе не учился?

У меня этот принцип знает даже кот! Он прячется за шторой, и раз он оттуда ничего не видит, значит опасности нет. И пофиг, что полтулоыища из-за шторы торчит.

4 минуты назад, Фри сказал:

нет не преподается. 

Это у вас в Севастополе не преподают. А в Питере это даже детсадовцы знают. @piton4 не даст соврать и школьный аттестат показать может, если захочет.

Изменено 8 августа пользователем Сильвер_79

[Фри 5 223]

*свой пост грохнул, что-то у меня сегодня недосып и отсутствие возможности определять сарказм и подобное… да и времени пофлудить нет(

[Сильвер_79 9 082]

3 минуты назад, Фри сказал:

*свой пост грохнул, что-то у меня сегодня недосып и отсутствие возможности определять сарказм и подобное… да и времени пофлудить нет(

Шуточки Питона не всегда очевидны. А смайликами он частенько пренебрегает.

Изменено 8 августа пользователем Сильвер_79

[Ленивый 5 015]

8 минут назад, Сильвер_79 сказал:

Он прячется за шторой, и раз он оттуда ничего не видит, значит опасности нет. И пофиг, что полтулоыища из-за шторы торчит.

Аналогично — кошак прячеся, а что постоянно хвост торчит это не считается.

2 минуты назад, Сильвер_79 сказал:

Шуточки Питона не всегда очевидны.

Он не шутит, в Питере своя атмосфера.

[0wn3df1x 4 683]

7 часов назад, Tirniel сказал:

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

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

У нынешних ПК игр проблема с картами решается двумя способами.

Первый, цивилизованный способ - официальная поддержка модов, как в WoW. Разработчики предоставляют специальный программный интерфейс, или API (в случае WoW - на языке Lua), который позволяет модам легально и напрямую взаимодействовать с игровым клиентом. Мод знает наши точные координаты (x, y, z), наши цели по квестам, потому что клиент ему об этом сообщает. Это санкционированный, структурированный обмен данными. В облачной модели это невозможно в принципе, так как на вашем ПК нет самого игрового клиента, который мог бы предоставить такой API. Есть лишь терминал, принимающий видеопоток.

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

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

Этап 1: Создание цифрового двойника карты
Прежде чем что-то накладывать на видеопоток, нужно иметь исходный материал. В нашем случае - идеальную, полную, чистую карту игрового мира. Ее нужно воссоздать с нуля, процесс выглядит так:

1. Тотальная зачистка карты: Один или несколько энтузиастов должны физически пройти всю игру, открыв каждый уголок карты, чтобы избавиться от "тумана войны". Нужно обойти каждую гору, заплыть в каждую пещеру.
2. Создание атласа: Затем начинается кропотливая работа по созданию гигантского изображения - атласа карты. Это сотни, если не тысячи скриншотов, сделанных на каждом уровне масштабирования, которые затем нужно программно или вручную "сшить" в единое полотно высокого разрешения. При этом нужно бороться с искажениями перспективы, цветов и так далее. Это сродни созданию спутниковой карты Земли, только без мощностей гугла и янекса.
3. Ретушь и очистка: С полученного атласа нужно убрать все динамические элементы интерфейса: иконку игрока, маркеры квестов, временные метки, всплывающие подсказки. Любой "мусор", который будет мешать последующему распознаванию. Если в игре это не отключается, то это что часы скрупулезной работы в условном фотошопе, где нужно аккуратно закрашивать элементы, стараясь не повредить оригинальную текстуру карты под ними.

Только после этой работы у сообщества появляется "Ground Truth" - эталонная карта, на которую можно наносить метки. Как показывает опыт создания карт для того же RDR2 (ещё на консольной версии), этот процесс может занимать месяцы, а то и годы, и целиком зависит от энтузиазма горстки людей.

Этап 2: Оверлей в реальном времени (кошмар инженера)
Допустим, сообщество создало эталонную карту. Теперь начинается самое сложное: как заставить программу в реальном времени понимать, что происходит на экране, и накладывать на это изображение нужные данные? 

Игрок открывает свою внутриигровую карту. Она частично покрыта "туманом войны", на ней есть его иконка, активный квест, возможно, она полупрозрачна. Программа-оверлей должна:

1. Распознать контекст: Сначала ей нужно решить задачу распознавания и регистрации изображений. Она должна посмотреть на прямоугольник на экране и сопоставить его с гигантским эталонным атласом, чтобы понять, какой именно участок карты сейчас открыт и с каким масштабом. Для этого используются сложные алгоритмы (например, на основе SIFT или SURF дескрипторов, которые ищут уникальные ключевые точки на обоих изображениях и сравнивают их). Другое разрешение экрана, обновление интерфейса от разработчиков, даже небольшое изменение цветовой палитры - все это может полностью сломать алгоритм распознавания.
2. Отследить игрока: Допустим, программа справилась и сопоставила изображения. Теперь ей нужно найти на карте иконку игрока, чтобы определить его точные координаты в данный момент времени. Это еще один цикл распознавания образов. А что, если иконка игрока меняет цвет? Или частично перекрыта другим значком? Алгоритм должен быть невероятно надежным, чтобы не ошибиться.
3. Синхронизировать данные: Игрок двигается, карта в игре смещается. Оверлей должен в реальном времени (в идеале - 60 раз в секунду) повторять все эти шаги: распознать новый участок, найти иконку, запросить из внешней базы данных координаты нужных сундуков в этой области и спроецировать их на экран с учетом текущего масштаба и поворота карты.

Любой сетевой лаг, просадка FPS, резкое открытие/закрытие карты или просто обновление интерфейса разработчиками сломает эту хрупкую систему. Вместо удобного помощника пользователь получит дерганый, мерцающий, постоянно теряющий синхронизацию оверлей.

И тут мы подходим к главному вопросу. Кто будет этим заниматься?

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

Разработка сложного CV-мода для каждой новой ААА-игры - это колоссальный труд, требующий такой же команды специалистов и постоянной поддержки. Делать это бесплатно? Слишком муторно. Продавать за деньги? Но зачем игроку платить за нестабильную, кустарную технологию, если издатель предлагает ему купить ту же самую карту всех сундуков за за те же деньги, но в виде идеально работающей, нативной игровой функции, интегрированной прямо в движок?

Поэтому, хотя теоретическая возможность такого моддинга существует, она вряд ли представляет реальную угрозу для издательской модели монетизации. Это слишком сложно, слишком дорого в разработке и слишком нестабильно в использовании, чтобы стать массовым явлением. Гораздо более реалистичным остаётся старый метод: сначала подождать год-два, пока (и если) онлайн карту полноценно заполнят, затем открыть её на втором мониторе или планшете, и постоянно сверяться с ней (и ругаться на разработчиков).

[DarkHunterRu 4 004]

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

*свой пост грохнул, что-то у меня сегодня недосып и отсутствие возможности определять сарказм и подобное… да и времени пофлудить нет(

Все нормально! Это просто у Питона сарказм очень реалистично получается

[Lancer72 95]

Читы, античиты! Это все как спор брони со снарядом — борьба будет вечной, в каждый отдельный момент времени перевес будет на чьей то стороне. На каждое умное решение со временем всегда найдется контррешение, ибо спрос рождает предложение )) 

[Dusker 670]

2 часа назад, BossDigger сказал:

Если ты не замечаешь, то это не значит отсутствие проблемы. У тебя очень наивная позиция.

Всмысле я не замечаю? Тут мне сказали, что читеры такие хитрые, что нельзя заметить, что это чит. Если никто не замечает проблему, то ее нет, чтобы проблема появилась, то нужно сначала, чтобы кто-то ее заметил. 

1 час назад, piton4 сказал:

Если что-то в не поля твоего зрения, значит этого не существует. Это фундаментальные основы реальности, и насколько помню, преподаётся на теоретической физике ещё в начальных классах. Ты в школе не учился?

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

[PermResident 2 565]

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

Цитата

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

мало того что извращуги, так еще и садисты, мучаете уникума  Хотя смотреть за этим приятно