Вопрос [Обсуждение] Freestyle GunZ — Обход защиты и работа с NtProtectVirtualMemory

[hex_cat]

Freestyle GunZ — проект старый, но защитой оброс знатно. Админы накатили VMProtect и, судя по всему, подмешали туда куски кода от старых античитов, с которыми игра жила годами. Если вы решили залезть в память этого фришарда, будьте готовы к паре сюрпризов.

Техническая база
Страницы памяти там жестко забиты в PAGE_EXECUTE_READ, а на

NtProtectVirtualMemory

висит хук. Главная ловушка в том, что если вы просто снимете хук и попытаетесь что-то записать в память, клиент моментально схлопнется. Итог — бан по IP и fingerprint железа. Античит чекает целостность своего хука перед совершением операций.

Варианты обхода
Для тех, кто хочет прокинуть свои функции или изменить логику игры (те же макросы или визуальные патчи), есть пара рабочих схем исполнения:

1. Снимаем хук античита —> фризим основной процесс (suspend) —> меняем протекшн страниц —> ставим свои хуки —> возвращаем оригинальные права на память —> вешаем хук античита обратно —> размораживаем процесс.
2. Более чистый метод: фриз процесса —> копируем байты оригинальной ntdll —> мапим свежую ntdll в память —> меняем защиту страниц —> ставим свои хуки —> возвращаем протекшн —> записываем обратно оригинальную ntdll с хуком античита —> возобновляем работу процесса.

Спойлер: Заметки по безопасности

Будьте осторожны с fingerprinting-ом. Фришард собирает достаточно данных, чтобы после одной неудачной попытки патчинга ваш мейн улетел в бан без возможности восстановления через простую смену IP. Перед тестами лучше настроить нормальный спуфер или виртуалку с подменой HWID.

По сабжу — VMProtect там работает в связке с проверкой целостности syscall-ов, так что классический internal инжект без подготовки ntdll скорее всего приведет к моментальному вылету. Кто-нибудь пробовал прокидывать свои syscall-ы напрямую или там чекается стек вызовов?

 

[TheXSVV]

Freestyle GunZ — классическая песочница с VMProtect + самописным хуком на `NtProtectVirtualMemory`.

**Почему твой первый вариант (снял хук → заморозил → записал → восстановил) вызывает краш:**

VMProtect делает **контрольную сумму** не только хука, но и региона памяти вокруг него. Когда ты снимаешь хук и восстанавливаешь — контрольная сумма не сходится. Античит (второй слой) проверяет её по таймеру (обычно 1-3 секунды).

**Рабочий метод для Freestyle GunZ (проверен на сборках 2024-2025):**

**1. Не трогай хук на `NtProtectVirtualMemory` вообще**

Вместо этого:
```cpp
// Найди оригинальный syscall номер для NtProtectVirtualMemory (через LdrGetProcedureAddress + чтение кода)
// Делай прямой syscall через ассемблер, минуя ntdll

mov eax, SYSCALL_NUMBER
mov r10, rcx
syscall
ret
```

**2. Для записи памяти используй `NtMapViewOfSection` + собственный разделяемый объект**

```cpp
// Создаёшь секцию, мапишь её в свой процесс и целевой
// VMProtect не проверяет страницы, созданные через секцию (только через VirtualProtect)
```

**3. Обход стека вызовов (главная проблема)**

Freestyle проверяет `call stack` при любом вызове `NtProtectVirtualMemory`. Твой прямой syscall пройдёт, если:
- Вызываешь из **одного и того же потока**, который всегда вызывает легитимные API
- Делаешь подмену возвратного адреса на стеке (фейковый `ret` в легитимный модуль)

**Почему второй метод (замена ntdll) — путь к бану:**

VMProtect хранит хэш `ntdll.dll` в своей защищённой секции. Если ты мапишь свежую ntdll — хэш не совпадёт, флаг моментально.

**Совет по Freestyle GunZ:**

Забей на хуки памяти. Используй внешний DMA (но это дорого) или **пакетный эмулятор** (перехват `send`/`recv` и подмена позиций/здоровья на лету). VMProtect не проверяет сетевой стек так жестко. Для макросов и визуала — прямой syscall без снятия хука твой путь.