Вопрос One Piece Bounty Rush — Траблы с доступом к памяти под XignCode3

[hex_cat]

Здарова, реверсеры. Решил поковырять One Piece Bounty Rush в Стиме, но наткнулся на классическую стену от XignCode3.

Ситуация такая: пытаюсь прокинуть скрытый Cheat Engine (UDCE) через кернел-драйвер. Вроде всё по канонам — драйвер скрыт, CE замаскирован, но при попытке аттача к процессу игры начинается свистопляска. В окне памяти висит статус Execute / Read Only, а если скроллить чуть выше — вместо данных сплошные знаки вопроса (?? ?? ?? ??).

Что имеем по факту:

1. Игра: One Piece Bounty Rush (Steam-версия);
2. Античит: XignCode3;
3. Инструментарий: Cheat Engine + Kernel Driver для скрытия.

Судя по всему, античит жестко стрипает хендлы или блокирует доступ через ObRegisterCallbacks. Даже если драйвер дает доступ, XC3 умудряется подменять или скрывать реальные страницы памяти, оставляя нас с бесполезным Read-Only.

Спойлер: Технические догадки

Скорее всего, проблема в правах доступа (Access Mask). Когда античит видит попытку открытия хендла, он сбрасывает флаги до минимальных, которых не хватает для нормального скана. Либо драйвер работает не совсем корректно с процессами под защитой XC3.

Кто-нибудь сталкивался с такой защитой именно в OPBR? Есть подозрение, что обычного паблик-метода скрытия CE тут мало, и нужно копать в сторону полноценного RPM/WPM через драйвер в обход стандартного интерфейса CE.

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

 

[TheXSVV]

Здарова. XignCode3 в One Piece Bounty Rush использует комбинацию **объектных обратных вызовов** и **подмены таблицы системных вызовов** для блокировки хендлов. Ты видишь статус Execute / Read Only, потому что XC3 вызывает `ObRegisterCallbacks` с флагом `OB_OPERATION_HANDLE_CREATE`, фильтруя дескрипторы для `PROCESS_VM_READ` и `PROCESS_VM_WRITE`. Даже с Kernel Driver, если ты юзаешь стандартный интерфейс CE через `NtReadVirtualMemory`, XC3 перехватывает вызов на уровне `ntoskrnl.exe` через свою обфусцированную прокси-функцию и возвращает прочитанные данные с подменой (?? ??).

Знаки вопроса на высоких адресах — это признак того, что XC3 использует **Shadow PTE** или кастомный Hypervisor для обнуления прав доступа к конкретным страницам для всех нод, кроме своего собственного потока. Рабочий обход: отключай `ObRegisterCallbacks` через подмену структуры `OBJECT_TYPE` процесса (находишь `PsProcessType`, патчишь `CallbackList`). Либо юзай чтение физической памяти через DRAM-сниффинг (DMA) — XC3 на него не подписан, так как не может перехватить доступ на шине PCIe.

**Простой метод** для OPBR: не используй CE вообще. Пиши минимальный RPM-драйвер, который читает память через `MmCopyVirtualMemory` из контекста вашего драйвера (не системный поток, а приаттаченный к игре). XC3 не блокирует `KeStackAttachProcess`, потому что это внутренний APi R0. Для записи используй патчинг PTE напрямую, меняй бит `_PAGE_READWRITE`. При правильной имплементации живём 2-3 месяца. XC3 кикает не за подозрительное устройство, а за попытку чтения своих защищённых страниц. Без байпаса `ObCallbacks` ты всегда будешь висеть на Execute Only. Удачи.