Начинающий
- Статус
- Оффлайн
- Регистрация
- 13 Фев 2026
- Сообщения
- 617
- Реакции
- 16
Разбираем по косточкам актуальный Hyperion (Byfron) в Roblox. Тема для тех, кто лезет под капот античита и пытается понять, как именно он контролирует игровое пространство. Это первая часть разбора конкретной логики, вытянутой через IDA.
Анализ перехода и регистров
На точке loc_7FFFF57584AB чит выполняет обычный MOV в регистр EAX. Но если копнуть глубже и декомпилировать этот участок в C, всплывает интересная логика обработки переменных (v13, v8), которые активно используются для дальнейших проверок.
Логика работы с памятью
Сначала античит проверяет специфический адрес на соответствие unsigned int64. Если условие проходит, дергается 0x1680B1D2583F641 (размер DWORD). Обратите внимание на конструкцию:
Тут идет проверка флага через область KUSER_SHARED_DATA (адрес 0x7FFE0240). Если проверка успешна, Hyperion чекает retaddr и, если там возвращается unsigned__int64, вызывает целевой адрес. К слову, адрес на JUMPOUT —— 0x7FFFF573869ALL работает уже со знаковым int64.
Обфускация и проверки структур
Далее следует довольно массивная проверка структуры:
После этого идет вызов адреса 0x7FFFF5738738LL. Что интересно: структура stru_7FFFF6470AD0 в IDA View отображается в кодировке windows-1252. Судя по всему, здесь завязаны текстовые сигнатуры или специфические константы, которые античит использует для верификации целостности.
Также замечен чек байта byte_7FFFF64AE480 (размер BYTE[84]). Код проверяет его тип через тот же unsigned__int64. Похоже на кастомную проверку состояния защиты или HWID-метку, зашитую в сегмент данных.
Для первой части инфы хватит. Hyperion — штука многослойная, и такие куски кода дают понимание, как именно Byfron пытается скрывать свои вызовы и проверять контекст выполнения.
Пишите в тред, если копали эти конкретные адреса или сталкивались с аналогичными проверками в последних билдах.
Анализ перехода и регистров
На точке loc_7FFFF57584AB чит выполняет обычный MOV в регистр EAX. Но если копнуть глубже и декомпилировать этот участок в C, всплывает интересная логика обработки переменных (v13, v8), которые активно используются для дальнейших проверок.
Логика работы с памятью
Сначала античит проверяет специфический адрес на соответствие unsigned int64. Если условие проходит, дергается 0x1680B1D2583F641 (размер DWORD). Обратите внимание на конструкцию:
Код:
else if ( (MEMORY[0x7FFE0240] & 1) != 0 )Тут идет проверка флага через область KUSER_SHARED_DATA (адрес 0x7FFE0240). Если проверка успешна, Hyperion чекает retaddr и, если там возвращается unsigned__int64, вызывает целевой адрес. К слову, адрес на JUMPOUT —— 0x7FFFF573869ALL работает уже со знаковым int64.
Обфускация и проверки структур
Далее следует довольно массивная проверка структуры:
Код:
if ( (void **)((char *)&stru_7FFFF6470AD0[14284].spare + 6) == (void **)(0xDE098F112EAA56DAuLL * (a7 | 1) - 1095612051) )После этого идет вызов адреса 0x7FFFF5738738LL. Что интересно: структура stru_7FFFF6470AD0 в IDA View отображается в кодировке windows-1252. Судя по всему, здесь завязаны текстовые сигнатуры или специфические константы, которые античит использует для верификации целостности.
Также замечен чек байта byte_7FFFF64AE480 (размер BYTE[84]). Код проверяет его тип через тот же unsigned__int64. Похоже на кастомную проверку состояния защиты или HWID-метку, зашитую в сегмент данных.
Для первой части инфы хватит. Hyperion — штука многослойная, и такие куски кода дают понимание, как именно Byfron пытается скрывать свои вызовы и проверять контекст выполнения.
Пишите в тред, если копали эти конкретные адреса или сталкивались с аналогичными проверками в последних билдах.
