[REVERSE] Бетонная стена с libunity.so. Frida и самописные дамперы не берут.
Аноним
19/02/26 Чтв 16:19:09
№
1
входные данные: есть либа libunity.so, вытянутая из апк. Файл зашифрован или накрыт кастомным пакером. в статиике (Ghidra/IDA) полная каша, ни вменяемых энтрипоинтов, ни читаемого кода
что я делал- статический анализ: пробовал декрипторы на основе известных сигнатур паттернов unity-шифрования0- мимо. ковыряли libmain.so и libil2cpp.so в надежде найти ключи или алгоритм распаковки в рантайме- глухо.
Frida /динамика: пытались зацепиться через frida-server (arm64), чтобы перехватить dlopen или dlsym и дождаться момента, когда либа ляжет в память расшифрованной. итог: ptrace_attach блокируется намертво, анти-отладка выкидывает сразу, даже с патченными серверами.
прямойй дамп памяти: пробовали парсить /proc/[pid]/maps и тянуть регионы либы через самописные скрипты с root-доступом. Система возвращает либо нули, либо битые заголовки ELF, которые не линкуются.
gitHub acactions: пытались поднять окружение для сборки кастомного лоадера, который бы дампил память изнутри процесса, но билд падает на этапе линковки зависимостей
авопрос: как сейчас обходят блокировку ptrace и читают память процесса, если стандартные дамперы и Frida не могут даже инициализироваться? Есть ли способы декрипта либы без рантайма, если ключи запрятаны глубоко?
и короче, пацаны, я всё это добро (зашифрованную либу, main и хуйню одну) залил на workupload. кто хочет размять мозги и показать, что динамика ещё жива - попробуйте вытянуть хоть что-то вменяемое. Если получится сделать чистый дамп или найти, где этот пакер прячет ключи — с меня респект и вечная память в треде и трс20
ссылка - https://workupload.com/file/KkCcCSABtbC