Вопрос SCP:SL — Анализ античита, Themida 3 и расшифровка трафика

[hex_cat]

Реверс свежих апдейтов SCP:SL превратился в увлекательный квест для тех, кто любит ковыряться в защите. Последние обновления античита в игре принесли с собой плотную упаковку и виртуализацию, которая ставит в тупик стандартные методы анализа.

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

1. Попытки инжектить мануал-мап на ранних этапах инициализации античита для хука Windows API дают мало инфы. Слепое хуканье в данном случае — это оверхед, который не захватывает логику детектов.
2. Сетевой трафик активен, что подтверждается хуками на send в ws2_32.dll, но данные идут зашифрованными. В статике (IDA Pro) видны референсы на OpenSSL, cURL и Crypto-библиотеки.
3. Основная проблема — код защищен Themida 3 Virtualization. В IDA мы видим фрагментированную логику, которая не дает построить нормальный граф выполнения (true execution flow).

Когда пытаешься вытащить сигнатуры сканирования памяти или поведенческие паттерны под такой защитой, обычные хуки на сетевые функции часто вообще не триггерятся или не влияют на поток данных. Это наталкивает на мысли либо о кастомных обертках над OpenSSL, либо о том, что трафик подготавливается глубоко внутри виртуализированных функций.

Спойлер: Технические детали проблемы

Попытки классического динамического анализа упираются в Themida. Девиртуализация такого уровня сложности — задача не на один вечер, и часто проще искать точки входа в обход виртуалки. Однако если сигнатуры детектов лежат внутри защищенных секций, без понимания логики интерпретатора Themida достать их будет крайне тяжело.

Вопрос в том, стоит ли сейчас тратить время на поиск полноценного решения для девиртуализации или есть смысл пробовать аппаратные брейкпоинты (HW Breakpoints) на обращения к структурам данных, которые античит строит перед отправкой?

Если кто-то ковырял именно сетевой протокол в последних билдах SCP:SL, было бы круто услышать мысли по поводу того, как они завязываются на HWID и какие именно данные о системе летят в пакетах. По сути, Themida здесь выступает лишь как щит, но сама логика детекта все равно должна где-то пересекаться с чистым кодом или стандартными API.

Интересно, кто-то пробовал идти через трассировку выполнения в кастомных эмуляторах или сразу лезть в расшифровку cURL-запросов через перехват контекста SSL?

 

[OxSk77]

Реверс свежих апдейтов SCP:SL превратился в увлекательный квест для тех, кто любит ковыряться в защите. Последние обновления античита в игре принесли с собой плотную упаковку и виртуализацию, которая ставит в тупик стандартные методы анализа.

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

1. Попытки инжектить мануал-мап на ранних этапах инициализации античита для хука Windows API дают мало инфы. Слепое хуканье в данном случае — это оверхед, который не захватывает логику детектов.
2. Сетевой трафик активен, что подтверждается хуками на send в ws2_32.dll, но данные идут зашифрованными. В статике (IDA Pro) видны референсы на OpenSSL, cURL и Crypto-библиотеки.
3. Основная проблема — код защищен Themida 3 Virtualization. В IDA мы видим фрагментированную логику, которая не дает построить нормальный граф выполнения (true execution flow).

Когда пытаешься вытащить сигнатуры сканирования памяти или поведенческие паттерны под такой защитой, обычные хуки на сетевые функции часто вообще не триггерятся или не влияют на поток данных. Это наталкивает на мысли либо о кастомных обертках над OpenSSL, либо о том, что трафик подготавливается глубоко внутри виртуализированных функций.

Спойлер: Технические детали проблемы

Попытки классического динамического анализа упираются в Themida. Девиртуализация такого уровня сложности — задача не на один вечер, и часто проще искать точки входа в обход виртуалки. Однако если сигнатуры детектов лежат внутри защищенных секций, без понимания логики интерпретатора Themida достать их будет крайне тяжело.

Вопрос в том, стоит ли сейчас тратить время на поиск полноценного решения для девиртуализации или есть смысл пробовать аппаратные брейкпоинты (HW Breakpoints) на обращения к структурам данных, которые античит строит перед отправкой?

Если кто-то ковырял именно сетевой протокол в последних билдах SCP:SL, было бы круто услышать мысли по поводу того, как они завязываются на HWID и какие именно данные о системе летят в пакетах. По сути, Themida здесь выступает лишь как щит, но сама логика детекта все равно должна где-то пересекаться с чистым кодом или стандартными API.

Интересно, кто-то пробовал идти через трассировку выполнения в кастомных эмуляторах или сразу лезть в расшифровку cURL-запросов через перехват контекста SSL?

Ебаный ты дурак сука заебал писать свои ебаные вопросы в раздел Гайдов, ты внатуре дегенерат

 

[Holystaff]

Как обычно у хекс кэта мясные гайды

 

[TheXSVV]

Коротко. Под Themida 3 реверсить сетевой протокол через статику — пустая трата времени.

**Два реальных пути:**

**1. HW брейкпоинты на шифрованные буферы (рабочий)**
- Ставишь `DR0-DR3` на предполагаемый буфер ввода/вывода OpenSSL (`BIO` структура)
- Когда сработает — смотришь стек вызовов. Даже через виртуализацию Themida не прячет вызовы в ядро (NtDeviceIoControlFile будет виден)
- По стеку найдешь место, где данные уже в чистом виде, до шифрования

**2. Перехват SSL context (быстрее)**
SCP:SL юзает OpenSSL статически. Хукай не `send`, а `SSL_write` / `SSL_read`. Даже через виртуализацию — эти экспорты остаются в `.text` (Themida не виртуализует OpenSSL целиком, только обертки).
- Найди сигнатуру `53 56 57 55 48 81 EC` (пролог `SSL_write`)
- Дальше читай параметры: `SSL*` → `ssl->session->peer` → достанешь HWID и метрики

**Про HWID:** Они берут не MAC, а Volume Serial Number системного диска + Motherboard UUID через `WMI`. Летят в открытом виде внутри расшифрованных TLS сессий.