Droptext.cc

Final report - VM decode and dcvm run

FINAL REPORT - VM BYTECODE DECODE AND dcvm RUN

1. DEPENDENCIES ADDED
- Approved 8: unidbg-api/android/unicorn2/dynarmic 0.9.8, commons-logging 1.2,
jna 5.13.0, unicorn 1.0.14, keystone 0.9.7.
- Added: slf4j-api-1.7.36, slf4j-simple-1.7.36, gson-2.10.1.
- unidbg 0.9.8 transitives via mvn dependency:copy-dependencies: apk-parser 2.6.10,
capstone 3.1.8, commons-codec 1.15, commons-collections4 4.4, commons-io 2.11.0,
demumble 1.0.4, fastjson 1.2.83, native-lib-loader 2.3.5.
- Still missing: org.scijava:nativelib - NOT on Maven Central (search 0 results;
1.0.0/1.0.2/1.0.3 all 404) and not a transitive of unidbg 0.9.8. NOT needed for these
runs. parsington is on Maven Central but also not needed.

2. COMMANDS AND EXIT CODES
mvn dependency:copy-dependencies (unidbg 0.9.8) -> 0 (20 jars)
NDK clang build of dcvm.so -> 0 (5.4 MB)
javac EngineRun.java -> 0
EngineRun program 1 (31ebe, length 187) -> 0
EngineRun program 2 (32636, length 130) -> 0
copy logs/cp.txt/dcvm.so to ~/results/ -> 0

3. REAL OUTPUT (TRIMMED)

Program 1 - dm1.OooOO0O:
IMPLEMENTED_SLOTS=246
PATH 00:9e 04:9b 06:9b 08:59 40:1e
UNIMPL count=0 ops=
WRITES allWrites=3 | pc=0x6 op=0x9b slot=2 val=0x1 | pc=0x4 op=0x9b slot=1 val=0x0 | pc=0x0 op=0x9e slot=0 val=0x3af8c39e
DIAG stopped at pc=0x40 opcode=0x1e
DIAG last jni off=0x100 a=0x3af8c39e b=0x809e
DIAG path[4] pc=0x40 op=0x1e -> MATCH
RESULT: engine executed inside the runtime

Program 2 - o0O00OOO.OooO:
IMPLEMENTED_SLOTS=246
PATH 00:9e 04:78 08:9e 0c:04
UNIMPL count=0 ops=
WRITES allWrites=2 | pc=0x8 op=0x9e slot=1 val=0xffffffffd9fcb04e | pc=0x0 op=0x9e slot=0 val=0x7affaa6f
DIAG stopped at pc=0xc opcode=0x04
DIAG last jni off=0x138 a=0xffffffffd9fcb04e b=0x65b53621
DIAG path[3] pc=0xc op=0x04 -> MATCH
RESULT: engine executed inside the runtime

4. SLOT -> CLASS.METHOD -> ARGS

The unidbg JNI fake only logs the wrapper offset and guest pointers; it does NOT resolve
the class/method name.

Program JNI off Class/method (resolved?) Args (guest) Result
dm1.OooOO0O 0x030 FindClass (name at guest ptr) a=0x40111000, b=0 resolved
dm1.OooOO0O 0x2f0 field/method lookup (name at guest ptr) a=0xc3a34da5, b=0x40112000, c=0x40113000 resolved
dm1.OooOO0O 0x100 NOT RESOLVED (stop) a=0x3af8c39e, b=0x809e BackendException
o0O00OOO.OooO 0x030 FindClass (name at guest ptr) a=0x40114000, b=0 resolved
o0O00OOO.OooO 0x2f0 field/method lookup (name at guest ptr) a=0x65cbd482, b=0x40115000, c=0x40116000 resolved
o0O00OOO.OooO 0x030 FindClass (name at guest ptr) a=0x40117000, b=0 resolved
o0O00OOO.OooO 0x108 GetMethodID (name at guest ptr) a=0xbbd0c56, b=0x40118000, c=0x40119000 resolved
o0O00OOO.OooO 0x138 CallDoubleMethodA (member_slots.tsv) a=0xffffffffd9fcb04e, b=0x65b53621, c=0xbfffe950 BackendException

Every difference from the static decode:
- Same opcodes executed (9e, 9b, 59, 1e / 9e, 78, 9e, 04).
- UNIMPL count=0 - no unimplemented opcodes.
- Both runs stopped early at a JNI call because unidbg's fake JNI threw BackendException -
a harness/JNI limitation, not an opcode fault.
- Program 1 path vs attributed pc -> SAME PC; program 2 DIFFERENT PC (0x04 at pc 0xc vs
attributed pc 0x0) - a diagnostic attribution difference, not a decode mismatch.
- IMPLEMENTED_SLOTS=246 is the JNI table slot count, not the 256 opcodes.

5. NOT RUN
- The remaining bytecode after the first JNI call in each program (engine stopped early).
- Real device Frida/jnitrace trace (no device in this environment).
- The slot -> real class.method resolution (needs the device trace).
- No app code / CloneRunner changes; no commit/push.

CONTEXT.md written at the repo root (local only).
Results in ~/results/: out1.log, out2.log, cp.txt, dcvm.so.


Kilo

Views: 6, posted on: 2026-11-11

More texts about Deps, commands, output, slot table, NOT RUN: