reso7200/molt-dex

Пролить кожу приложения и прочитать, что под ним.

Поэтапный, доказательный навык для обратной инженерии, моддинга и оценки приложений Android. От простых АПК до сильно запутанных. Построен на apktool, adb и scrcpy, со временем выполнения разрешение и подключение через DexKit и Xposed API.

Что это такое

molt-DEX - это навык Клода: упакованный Трубопровод, который берет приложение Android от «здесь есть APK» до «здесь есть то, как оно построено, как оно работает». ведет себя, и где его слабости".

Он был извлечен из реальной работы, реверс-инжиниринга и моддинга большого, запутанного приложения. (Инстаграм) в различных версиях. Техники, которые пережили версию за версией, — это те, которые Запеченный здесь.

Полный спектр запутывания. ** Простые приложения, R8 / ProGuard имя запутывание, шифрование строк, отражение, упаковка, нативные заглушки и антитампер, каждый со способом его обнаружения и способом через него. apktool, а не JADX Это объясняется тем, что апктоол декодировал малый и ресурсы, которые туда и обратно (можно восстановить и переустановить). Декомпиляция Java — это дополнительное удобство, а не источник Правду. **Статическое для понимания, устройство для подтверждения.

---

What it is

molt-DEX is a Claude skill: a packaged pipeline that takes an Android app from “here is an APK” to “here is how it is built, how it behaves, and where its weaknesses are.”

It was distilled from real work, reverse-engineering and modding a large, obfuscated app (Instagram) across many versions. The techniques that survived version after version are the ones baked in here.

• Full obfuscation spectrum. Plain apps, R8/ProGuard name obfuscation, string encryption, reflection, packing, native stubs, and anti-tamper, each with a way to detect it and a way through it.
• apktool, not JADX. It reasons over apktool-decoded smali and resources, which round-trip (you can rebuild and reinstall). A Java decompile is an optional convenience, never the source of truth.
• Static to understand, device to confirm. Read the code to form a hypothesis, then prove or kill it on a real device with adb and scrcpy. Every claim cites evidence: a smali method, a string-table hit, a logcat line, a screenshot.

Why it holds up: resolve by shape, not by name

This is the whole idea. In an obfuscated app you almost never have the real name of a class or method, and whatever name it has changes on the next release. So you never anchor on names. You anchor on things that stay put:

• literal strings a method uses (log lines, error text, QPL tags),
• JSON / wire keys it parses,
• method shape (parameter types, return type, static vs instance, arity),
• class relationships (superclass, implemented interface, callers and callees),
• resource names.

Find the member by that description, statically (a string index over the decoded tree) and at runtime (a DexKit query inside the live app). When the app updates and the method moves, you re-run the same description and find it again. This is why a module built this way keeps working when Instagram ships a new build, and it is the backbone of every stage below.

Authorization: what the work touches