Гайд [Краш] Rust — Разбор проблем с EntityList и GC Handle в ESP

[hex_cat]

Разбор полетов: почему внешний ESP в Rust перестал работать и шлет мусор в консоль.

После очередного патча структуры и оффсеты в Rust поплыли, что для внешнего софта через RPM — классическая головная боль. Если у вас EntityList выдает фантомных игроков, а W2S рисует «в молоко», значит вы юзаете старую базу или криво резолвите GC хендлы.

Issue 1: Фантомные игроки и проверка имен классов
Проверка clsName[0] == '\0' — это технический приговор. Именно так вы ловите «призраков» там, где на сервере вы один. При неудачном чтении памяти или попадании на мусорную область вы не скипаете итерацию, а считаете ее валидной.
Совет: Выбрасывайте логику с проверкой на пустую строку. Если не удалось прочитать имя класса или оно не соответствует BasePlayer / Scientist — скипайте объект сразу. Идеальный вариант — чекать type_info и сравнивать указатели на классификаторы, а не парсить строки в каждом цикле, это в разы быстрее и надежнее.

Issue 2: GC Handle и EntityRealm
Если RAW ClntEnts возвращает ноль, дело не в функции декрипта, а в том, что ваш входной поинтер уже битый. Оффсет static_fields + 0x08 часто прыгает на 0x28 или 0x10 в зависимости от билда.

inline constexpr std::uintptr_t handle_table = 0xDA935B0; // Проверяйте этот RVA через IDA
inline constexpr std::uint32_t static_fields = 0xB8;
inline constexpr std::uint32_t client_entities = 0x28; // Попробуйте сменить 0x08 на это значение

Формула rcx = (handle & 7) - 1 фундаментальна для IL2CPP, но проверьте актуальность HANDLE_TABLE_RVA. Его проще всего найти через поиск ссылок на il2cpp_gchandle_get_target в GameAssembly.dll.

Issue 3: ViewMatrix и камера
Когда координаты улетают за экран (Drawn = 0), проблема либо в неверном смещении ViewMatrix, либо CameraInstance указывает на неактивную камеру (например, камеру меню).

1. Проверьте оффсет матрицы в MainCamera. В свежих билдах матрица может быть смещена или находиться в другом подобъекте.
2. Убедитесь, что вы не читаете старую матрицу до захода на сервер.
3. Для внешней отрисовки лучше дампить матрицу целиком (4x4 float) одним RPM вызовом, чтобы избежать десинхрона между осями.

Спойлер: Техническая справка по оффсетам

namespace base_networkable {
    inline constexpr std::uintptr_t typeinfo = 0xE43C280;
    inline constexpr std::uint32_t static_fields = 0xB8;
    inline constexpr std::uint32_t entity_list = 0x10;
    inline constexpr std::uint32_t buffer = 0x18;
}

Внешние читы на Rust сейчас выживают только за счет качественного обхода EAC и актуальной архитектуры. Если база «сыпется», копайте в сторону GameAssembly и смотрите, куда реально ссылается get_handle.

Кто-нибудь уже пробовал переходить на резолв через цепочки в обход дефолтных GC таблиц?

 

[tupotapokon60hz]

Ключевые инсайты из поста:

• киллер-фича с clsName == '\0';
• прыжки оффсета static_fields + 0x08;
• важность актуального HANDLE_TABLE_RVA;
• дамп ViewMatrix 4x4 одним RPM.

Сохраню в закладки! Кто уже применил эти фикс-апгрейды — отпишитесь о результатах

 

[lsww]

Hey, there's no private message option on your profile. How can I contact you

 

[TheXSVV]

По факту всё упирается в качество базы и валидации. clsName == '\0' — это не фильтр, а генератор ложных срабатываний: мусор спокойно проходит дальше. Любое невалидное чтение должно сразу резаться, без попыток «угадать», что там лежит. С static_fields та же история — если смещение прыгает между билдами, значит опора на него без актуализации обречена.


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

 

[tupotapokon60hz]

По факту всё упирается в качество базы и валидации. clsName == '\0' — это не фильтр, а генератор ложных срабатываний: мусор спокойно проходит дальше. Любое невалидное чтение должно сразу резаться, без попыток «угадать», что там лежит. С static_fields та же история — если смещение прыгает между билдами, значит опора на него без актуализации обречена.


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

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

### По clsName == '\0'

- **Проблема:** условие `clsName == '\0'` не фильтрует, а генерирует ложные срабатывания, пропуская «мусор».
- **Решение:** внедрите жёсткий фильтр: любое невалидное чтение (например, нулевой или бессмысленный `clsName`) сразу отбрасывайте. Вместо попыток «угадать» данные, фокусируйтесь на чётких критериях валидности (длина строки, допустимые символы, контрольные суммы).

### По static_fields и смещению

- **Проблема:** смещения статических полей «прыгают» между билдами → опора на фиксированные значения приводит к ошибкам.
- **Решение:**
1. Используйте **динамическое определение смещений** — сканируйте структуры на лету, опираясь на сигнатуры (магические числа, шаблоны данных).
2. Автоматизируйте сбор данных: регулярно парсите свежие билды, обновляя базу смещений.
3. Внедрите механизм **верификации структуры** (например, проверка сигнатур полей) перед использованием данных.

### По HANDLE_TABLE_RVA

- **Проблема:** устаревший `HANDLE_TABLE_RVA` ломает весь резолв → нули/случайные значения.
- **Решение:**
1. Настройте **автоматическое обновление** `HANDLE_TABLE_RVA` при каждом запуске — парсите свежую версию процесса, чтобы получить актуальное смещение.
2. Добавьте **мониторинг изменений**: отслеживайте, когда таблица перемещается, и оперативно корректируйте RVA.
3. Реализуйте **кэширование с тайм-аутом** — принудительно перечитывайте данные через заданный интервал или при явных признаках устаревания.

### По ViewMatrix

- **Проблема:** частичное чтение вызывает рассинхрон и некорректную проекцию.
- **Решение:** всегда считывайте `ViewMatrix` **одним блоком** (например, массив из 16 float). Это гарантирует:
- целостность данных (нет смещений из-за выравнивания памяти);
- корректную интерпретацию матрицы (порядок элементов критичен для вычислений).

### Общие рекомендации

1. **Строгая валидация:** любой объект/структуру проверяйте на:
- целостность (контрольные суммы, сигнатуры);
- соответствие ожидаемым диапазонам (например, координаты, размеры).
2. **Автоматизация обновлений:** создайте пайплайн для регулярного сканирования новых билдов и актуализации баз данных.
3. **Логирование ошибок:** записывайте случаи невалидных данных — это поможет быстро локализовать изменения в API/структурах.
4. **Тестирование на свежих билдах:** регулярно проверяйте работоспособность резолва на последних версиях целевого приложения.

**Коротко:**
- Отбрасывайте мусор на ранних этапах.
- Динамически определяйте смещения, не полагайтесь на статичные значения.
- Обновляйте `HANDLE_TABLE_RVA` автоматически.
- Читайте `ViewMatrix` целиком.
- Внедряйте жёсткую валидацию и автоматизацию — это минимизирует рассинхроны и ложные срабатывания.