Build1 publisher3 min readPublished
Renaming a class leaves behind the call graph an AI reads
A dev.to post argues that model-assisted analysis has made decompiled Android code cheap to understand, and proposes DEX encryption plus a native interpreter as the answer. Its own feature list shows what that costs to adopt.
The Engineer · Build desk
What happened
- A dev.to post says reading an Android APK used to need an experienced engineer working by hand in JADX, Apktool, Frida, Ghidra or IDA to locate the important classes, methods and execution paths.
- It lists the work AI now assists with, including identifying important classes and methods, reconstructing call relationships, locating sensitive logic, analyzing JNI interactions and generating hooks or patches.
- On that basis the author says variable renaming, class-name obfuscation and basic string obfuscation may provide less protection against increasingly capable automated analysis.
- The XopProtector project the post describes documents seven protection layers, among them DEX protection, two virtual machine layers, native and SO protection, RASP and runtime integrity.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A team already paying for R8 renaming now has to decide which handful of methods justify DEX encryption, runtime restoration and an interpreter sitting on the execution path.
- exposure Frida and hook detection and RASP ship inside the APK and run in the process an attacker controls. They land in the same cost-raising category the post assigns to obfuscation.
- contradiction The evidence for the cost collapse is the post's own narrative, and the post recommends the project its author documents; the timings and overhead figures are missing, so a team has to run the comparison on its own app.
Name obfuscation changes identifiers. The post's own example shows what survives it: call relationships, strings, parameters, return values, control flow, APIs and the surrounding context [7]. Those are what a reader needs to work out what a method does, and R8-style renaming leaves all of them in place.
The path the post draws for an unprotected app starts with JADX turning the APK into DEX and then into Java or Kotlin, and only after that does anything read the code [8]. The post puts the change in one sentence: "Understanding ordinary application code is becoming cheaper" [4]. Its answer is that protection still matters and its purpose is changing [14].
The distinction between PVM1 and PVM2 is where the engineering is. PVM1 restores packaged methods and executes them through Dalvik or ART [11]. PVM2 uses a JNI trampoline and a native interpreter, and does not write the protected method back into the DEX [11]. If the method never exists in DEX form, the decompiler step does not produce it, and an analyst works from the interpreter and its instruction encoding instead of from Kotlin.
The documented feature list is a coverage spec. It includes multiple ISAs, floating-point and double-precision instructions, and monitor-related instructions [12]. Monitor instructions are there because real Java methods contain synchronized blocks; double-precision math is there because business logic does arithmetic. Anything the ISA cannot express stays behind in the DEX. This sets the practical limit on how much of an app a team can move. The architecture diagram has seven layers [9][15] and the shipped list has six items [10][16], and the mapping between them is left to the reader.
The post reports no measurements of either kind: how long a method takes to understand with and without model assistance, and interpreter overhead on a hot path [17]. Both are what a team needs before it moves a login check into a virtualized ISA. For the cost claim to transfer to your app, your critical logic has to sit in Java or Kotlin DEX, in small enough units that the tasks in the post's list apply, which include locating encryption, authorization and validation logic and generating or modifying Frida scripts [2][3].
Every layer in the documented architecture runs on the device [18]. Frida and hook detection and RASP are in the shipped set [10], and they execute inside the process an attacker controls. The post cites OWASP as treating obfuscation as a way to increase the cost of reverse engineering, and not as a mechanism that makes reverse engineering impossible [6]. The same accounting applies to a detector shipped in the same APK as the code it is watching.
The same limit applies to the wider claim. If a check already runs on a server you operate, the decompiled client tells an analyst what to send, and that exchange runs outside the seven layers [18].
What to watch
- A timed comparison on the same APK, analyst alone against analyst with model assistance, would test the comprehension-cost claim directly.
- Published overhead figures for the PVM2 native interpreter on a hot path would tell a team which methods it can afford to virtualize.
- Whether PVM2's instruction encoding holds up once someone publishes a lifter for it.