Сап, /pr/. 6 часов ебли с одним таргетом, перепробовано всё, нужен мозг того, кто ломал современные unity защиты.
входные данные: есть либа 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