VM HANDLER DECODING STATUS - IS THE 256-ENTRY TABLE ALREADY DECODED?
Analysis only. No files changed. Checked git branches, logs, and all folders.
ANSWER: YES. It is already decoded in two places, and the DoubleCloner copy is complete.
1) DOUBLECLONER main BRANCH (also origin/vm-engine) - WORKING SPEC
app/src/main/cpp/spec/dispatch_64.json
All 256 opcodes -> 218 distinct handler VAs.
app/src/main/cpp/spec/handler_class.json
218/218 handlers disassembled: ASM, widths, calls, end type.
app/src/main/cpp/spec/handler_families.json
4 families: conditional-test (187), jni-call (23), data-move (4), exception-or-return (4).
app/src/main/cpp/vm/isa_table.h
Widths for all 256 opcodes, from 21,069 decoded instructions across 546 VM methods.
app/src/main/cpp/spec/ghidra_interpreter_map.json
Ghidra-derived map, 256 dispatch rows.
app/src/main/cpp/spec/unimplemented_opcodes.txt
Current status: 232 implemented, 4 reported unimplemented, 10 raised,
10 never terminated.
vmtest/oracle/dispatch_table.txt
The raw 256-entry table (0x00-0xff).
vmtest/oracle/disasm.py
vmtest/ghidra/DumpHandler.java
vmtest/ghidra/WalkSlots.java
The tools that produced it.
VM.md
Overview and layout.
Handler breakdown from handler_class.json:
- 218 handlers total
- 202 end at the dispatch loop, 16 return
- 162 are indirect
- 23 have decoded JNI calls
2) CMASTERCLONER docs/sdk-audit BRANCH - ORIGINAL RE WRITE-UP
docs/reverse-engineering/:
- LIB_CMVM_VMINTERPRET.md
- LIB_CMVM_VMINTERPRET_CORRECTED.md
- LIB_CMVM_VMINTERPRET_PART6.md
- vm_dispatch_verified.json
- vm_handler_analysis.md
- vm_instruction_format.md
- vm_instructions_01.json, _02.json, _03.json
- vm_instructions_summary.md
- vm_decoded_methods.md
- analyze_vm.py
vm_decoded_methods.md decodes the 11 wrapper methods, including OooOO0O.
CAVEAT: its addresses (e.g. dm1.OooOO0 at 0x58598, data 0x3838e) are from an older
libcm.so. The current libcm.so has dm1.OooOO0 at 0x53cd0 with its program at 0x3198e.
So the wrapper-level decode is partially stale; the opcode table and handlers are current.
3) OTHER BRANCHES
CMasterCloner vm-recovery:
RECOVERY_REPORT.md, gen/vm/... (Java classes).
Java recovery, NOT opcode handlers. No 256-entry table.
CMasterCloner master:
app/src/main/java/com/cmaster/cloner/vm.java, vm0..vm2.java.
Unrelated obfuscated classes. Not VM decoding.
CMasterCloner apktool-refactor:
app/src/main/java/.../vm.java etc.
Same - unrelated classes.
DoubleCloner vm-engine:
Same spec as main (merged). Duplicate of the complete spec.
COMPLETENESS VERDICT
- Opcodes mapped: 256/256
- Distinct handlers disassembled: 218/218
- Instruction widths: 256/256
- Implemented: 232/256 (the 4 "reported unimplemented" - 0x11, 0x33, 0xa5, 0xe8 -
are implemented but cannot be exercised by the sweep host; 10 raised, 10 never terminated)
- Wrapper streams: 11/11 decoded, with the stale-address caveat above
NOTE: VM.md still says "Opcode implementations: stubbed - coverage counter only" and
"Escape opcode: not started". That status table is OUT OF DATE - later commits implemented
the 0x53/0xe8/0xa9/invoke families, and unimplemented_opcodes.txt is the current source
of truth.