30 KiB
Extension verification — extraction shells and the Dex-VMP boundary (bench rows B3 / B4)
Covers benchmark rows B3 (extraction-shell skeleton detection) and B4 (Dex-VMP boundary: refuse-to-repack and downgrade the deliverable). Strength labels are this directory's own three tiers: observed (an exact command and its output are quoted here), inferred (follows from observed facts; the step was not executed), unverified (assumed or externally reported, not reproduced here).
Everything below was produced on this repository's Windows 11 host with the rootless
PC toolchain in tools/_work/ENV.md; the device results in §4 name a
<DEVICE> and use <PKG> placeholders for the target package.
0. Headline
| Question | Answer | Strength |
|---|---|---|
Does stub% separate a skeleton copy from a genuine dex? |
Only when the shell writes bare return-void. Three other measured emptying shapes score 0.0 %–2.3 %, at or below the untouched control (1.9 %) |
observed |
Was the pre-existing trivial_ratio detector correct? |
No — two defects, one of which inverted the ranking and named a fully-nop-wiped skeleton the "most likely original" | observed |
Is repos/CyReverse's shipped "extraction shell" asset usable as a shell fixture? |
No. The pair differs by six bytes and one body; neither is a shell | observed |
Is DexPatcher/assets/ezAndroid.apk a Dex VMP? |
No. It is a JNI-sinking target: 7 native declarations, an exported Java_* for each, 34,566 clean dalvik instruction decodes, zero structural errors |
observed |
| Can a static dex probe decide VMP vs not? | It can decide "not dex-VMP" when the bodies decode cleanly and each native declaration has an export. It cannot decide whether the native island performs runtime hardening | observed (negative half) / unverified (positive half) |
Does dex_mem_scan.py find and cut a dex out of a blob? |
Yes — exact offset, no false hits in 2 MiB of noise, image accepted by the judge | observed |
| Does it reach a dex in a live process's anonymous mapping? | Not measured here. The fixture is built and the commands staged; the device was held by another row throughout | unverified |
One claim in this pass was retracted: §3.4 records a Dex-VMP verdict drawn from a desynchronised decoder and the measurement that killed it.
1. B3 — the shipped CyReverse "extraction shell" assets are a 6-byte difference, not a shell
Source: repos/CyReverse/app/src/main/assets/{classes3.dex, classes3_extracted.dex}
(12,536 B each).
$ python skills/apk-reverse/scripts/dex_dump_validate.py tools/_work/bench/unpack/b3
== dex dump validation: 2 file(s), 2 parse, 0 rejected ==
name size sha256[:12] ver cksum sig class noco code stub%
cyrev-extracted.dex 12536 c2d7345e955a 037 ok BAD 4 0 20 10.0%
cyrev-skeleton.dex 12536 ba9d5b120a3a 037 ok ok 4 0 20 10.0%
A byte diff of the pair (tools/_work/bench/unpack/b3/analyze_pair.py) locates every
difference:
$ python tools/_work/bench/unpack/b3/analyze_pair.py
len A=12536 len B=12536
first diff offset = 8 (0x8)
diff byte count = 6
diff ranges:
0x8 .. 0x8 (1 B) <- dex checksum (header offset 8)
0xa .. 0xb (2 B) <- dex signature, first half (offset 12 is 4 B wide)
0x121c .. 0x121c (1 B) <- INSNS of PluginClass->getString, units 0 and 2
0x121e .. 0x121e (1 B)
0x1220 .. 0x1220 (1 B)
Per-method census of the pair shows the "extracted" copy is the degraded one:
== cyrev-skeleton.dex == Lcom/cyrus/example/plugin/PluginClass;->getString insns=3 units=001a 0087 0011
== cyrev-extracted.dex == Lcom/cyrus/example/plugin/PluginClass;->getString insns=3 units=0000 0000 0000
const-string v0, "…"; return-object v0 was overwritten with three 0x0000 units in
exactly one of the twenty bodies, and the header was re-fixed. The shipped
classes3_extracted.dex is not an extraction shell and not a recovered dex:
it is a single-body demonstration of body clearing, with 19 of 20 bodies identical to
the skeleton. Neither file can test extraction-shell routing — 10.0 % stub% on both
sides is a coincidence of the same body set, not a signal.
Consequence for the benchmark row: B3 cannot be run against this asset pair. The skeleton measurement below had to be built from a real application dex instead.
2. B3 — measured stub% across every emptying shape, with a zero-change control
Fixture builder: tools/_work/bench/unpack/b3/make_skeleton.py derives each variant
from a real 982,480-byte application dex (src-r2pay.dex, extracted from
tools/_work/bench/apks/r2pay-v1.0.apk, sha256 c89ff2364879…). Every variant is
byte-length preserving: only the insns array of a code_item is rewritten and
the tail is nop-filled, so offsets, class table and string table are untouched and the
header is re-fixed with dexutil.fix_dex_header (signature first, checksum last).
$ python tools/_work/bench/unpack/b3/make_skeleton.py src-r2pay.dex skel
source: src-r2pay.dex
ctrl.dex fraction=0.00 mode=return emptied=0/5061
skel-25.dex fraction=0.25 mode=return emptied=1265/5061
skel-50.dex fraction=0.50 mode=return emptied=2531/5061
skel-75.dex fraction=0.75 mode=return emptied=3796/5061
skel-all.dex fraction=1.00 mode=return emptied=5061/5061
pruned.dex fraction=1.00 mode=pruned emptied=5061/5061
nopfilled.dex fraction=1.00 mode=nop emptied=5061/5061
allstub.dex fraction=1.00 mode=allstub emptied=5061/5061
throwstub.dex fraction=1.00 mode=throw emptied=4134/5061
Verdicts from dex_dump_validate.py over the whole set — the decisive matrix:
$ python skills/apk-reverse/scripts/dex_dump_validate.py tools/_work/bench/unpack/b3/skelall
name size sha256[:12] ver cksum sig class noco code stub% erased% emptied%
allstub.dex 982480 c8d7ca8fb163 035 ok ok 647 250 5061 100.0% 0.0% 100.0%
ctrl.dex 982480 1b3a97896b40 035 ok ok 647 250 5061 1.9% 0.0% 1.9%
nopfilled.dex 982480 de92dcea4eaf 035 ok ok 647 250 5061 0.0% 100.0% 100.0%
pruned.dex 982480 58d7fa3dce48 035 ok ok 647 250 5061 93.2% 0.0% 93.2%
skel-25.dex 982480 63346d9b41f5 035 ok ok 647 250 5061 1.7% 0.0% 1.7%
skel-50.dex 982480 d84601b7aa47 035 ok ok 647 250 5061 1.7% 0.0% 1.7%
skel-75.dex 982480 64114285656d 035 ok ok 647 250 5061 2.1% 0.0% 2.1%
skel-all.dex 982480 6345daef0a3f 035 ok ok 647 250 5061 2.3% 0.0% 2.3%
throwstub.dex 982480 cab8fd51a743 035 ok ok 647 250 5061 1.9% 0.0% 1.9%
Read the mode= column against stub%:
| Emptying shape (what the shell leaves behind) | stub% |
Separated from ctrl (1.9 %)? |
|---|---|---|
bare return-void in every body (allstub) |
100.0 % | yes, by 98 points |
body truncated to const/4 v0,#0; return v0 + nop fill (pruned) |
93.2 % | yes |
nop fill, no return at all (nopfilled) |
0.0 % | no — scores below the untouched control |
new RuntimeException; throw stub (throwstub) |
1.9 % | no — indistinguishable from control |
| 25 % / 50 % / 75 % of bodies emptied with a legal minimal body | 1.7 / 1.7 / 2.1 % | no |
Three conclusions, all observed:
- The threshold is not a number, it is a shape.
stub%is bimodal — it is either ≈ control (blind) or ≈ 100 % (sighted). There is no intermediate band where a threshold could sit, so the "tens of percent" calibration the reference file describes has no measured support. - Partial extraction is invisible.
skel-75.dex— three quarters of all bodies emptied — reports 2.1 % against a 1.9 % control, a 0.2-point difference inside the sampling noise of what a real app's own trivial bodies contribute. - The two shapes that defeat it are the two that real shells prefer.
throw new RuntimeExceptionstubs are the classic 360/legu family shape, and a nop-wiped body is what a shell writes when it clears the slot before decrypting.
The false-negative on nopfilled was a defect, not a boundary, and is fixed in §3.
The throwstub blind spot is a boundary and is documented as one.
3. B3 — defects found in dex_dump_validate.py, and the fix
3.1 Defect 1: a fully nop-filled body was classified real
classify_body skipped every 0x0000 unit and then fell through to return "real"
when nothing else was found. Measured consequence: nopfilled.dex — all 5,061
bodies wiped — reported stub% = 0.0, and the ranking named it the most likely
original:
$ python skills/apk-reverse/scripts/dex_dump_validate.py …/skel/{nopfilled,ctrl}.dex
ranking (most likely original first):
1. nopfilled.dex stub%=0.0 cksum=ok sig=ok classes=647
…
verdict: nopfilled.dex is the most likely original (1 copy(ies) in this set)
An agent routing on that line patches a wiped skeleton. That is the failure the file exists to prevent, so the defect is on the wrong side of "the tool still produces output".
Fix. classify_body gained two classes and a wider body scan:
erased—insns_size > 0with every unit0x0000. A real compiler never emits a whole body of nops, so this is skeleton evidence.minimal— a body truncated toconst/4 vR,#0; return vR(legal, and the shape the detector is blind to by design). Reported separately so the blind spot is visible rather than hidden insidereal.- The early-exit
meaningful > 1 → realbecamemeaningful > 2, so the two-unit minimal body reaches its own verdict instead of being mislabelled.
trivial_ratio keeps its original definition so previously recorded numbers stay
comparable; emptied_ratio = (stub + erased) / with_code is the new skeleton signal,
and rank_key sorts on it low-first with bodies_erased as a tiebreak.
3.2 Defect 2 (retracted in-flight): 0xNN0E is not malformed
An intermediate version of the fix classified a lone 0x020E unit as malformed,
reading a non-zero high byte on a 0x0E opcode as an illegal return-void. The
control dump proved otherwise — 82 of the untouched dex's own bodies are exactly that
shape — and const/4 v0, #0; return v0 is a legal minimal non-void body. The class was
renamed minimal, its comment corrected, and the fixture extended with pruned.dex
to measure it deliberately (93.2 %, stub% sighted). Recorded here because the
mislabel would have taught the next reader that ordinary short methods are damage.
3.3 Post-fix behaviour, and no regression on the recorded fixture
nopfilled.dex is now ranked last and flagged:
8. nopfilled.dex stub%=0.0 erased%=100.0 cksum=ok sig=ok classes=647 <-- SKELETON: emptied%=100, extraction-shell shape
9. …
verdict: skel-25.dex is the most likely original (1 copy(ies) in this set)
The pre-existing acceptance fixture from EXTENSION-unpacking.md §2 still produces
its recorded verdict, with only the two new columns appended:
$ python skills/apk-reverse/scripts/dex_dump_validate.py tools/_work/t2-unpack --find 'Lcom/stub/'
== dex dump validation: 7 file(s), 4 parse, 3 rejected ==
01_original_shell.dex 8923752 bcd1c0488e86 035 ok BAD 4 160 29 3.4% 0.0% 3.4%
02_duplicate.dex 8923752 bcd1c0488e86 035 ok BAD 4 160 29 3.4% 0.0% 3.4%
03_broken_magic.dex 8923752 33eee53b1317 ? REJECTED: magic=b'XXXX'
04_tampered_body.dex 8923752 b89bc8cc73d9 035 BAD BAD 4 160 29 3.4% 0.0% 3.4%
05_truncated.dex 65536 e6687390a663 035 REJECTED: file_size=8923752 actual=65536
06_extracted_skeleton.dex 8923752 85e56fed1d56 035 ok ok 4 160 29 100.0% 0.0% 100.0%
07_tiny_garbage.dex 16 be45cb2605bf ? REJECTED: too small (16 B) to carry a dex header
verdict: 01_original_shell.dex is the most likely original (2 copy(ies) in this set)
Same winner, same three rejections, same dedupe group. The change is additive on that fixture and corrective on the new one.
3.3b The ranking was still pointing at a modified image (found by independent review)
The first fix above added the emptied_ratio signal — and then kept ranking on a
metric this same pass had just proved insensitive to skeletons. Reproduced by
leading the review on the variant set:
$ python skills/apk-reverse/scripts/dex_dump_validate.py tools/_work/bench/unpack/b3/skel
ranking (most likely original first):
1. skel-25.dex stub%=1.7 erased%=0.0 cksum=ok sig=ok classes=647
2. skel-50.dex stub%=1.7 erased%=0.0 cksum=ok sig=ok classes=647
3. ctrl.dex stub%=1.9 erased%=0.0 cksum=ok sig=ok classes=647
…
verdict: skel-25.dex is the most likely original (1 copy(ies) in this set)
skel-25.dex — a dex with 25 % of its bodies removed — was named the most likely
original, and the genuine untouched control ranked third. The cause is the bimodality
of §2: inside the low band the ratio is not a signal, and 1.7 % versus 1.9 % is noise
(the extracted bodies are replaced by const/4 + return, which lowers the
return-void count relative to the control). An agent routing on that line adopts a
modified image as its baseline, and every later diff is then built on the wrong
artifact — the same class of failure as the defect in §3.1, reached by a different
path.
Fix. rank_key became three-level, with an explicit eviction level so that either
signal can disqualify an image instead of the two merely tying:
emptied_ratio >= 0.5sorts last. Nothing mostly emptied is a candidate however else it scores. This level exists because the count below cannot see thereturn-void-in-every-body skeleton: that image hasminimal = erased = 0, so a pure-count key ranked it first — measured, and it is why this level was added rather than the count being promoted alone.bodies_minimal + bodies_erasedlow-first. This orders the low band, where the count is monotone: 82 untouched, then 1299 / 2524 / 3736 / 4946 at 25 / 50 / 75 / 100 %.emptied_ratiolow-first, then header verdicts, then name.
Result on the same command:
ranking (most likely original first):
1. ctrl.dex stub%=1.9 erased%=0.0 min/erased=82 cksum=ok sig=ok
2. only.dex stub%=1.9 erased%=0.0 min/erased=82 cksum=ok sig=ok
3. throwstub.dex stub%=1.9 erased%=0.0 min/erased=82 cksum=ok sig=ok
4. skel-25.dex stub%=1.7 erased%=0.0 min/erased=1299 cksum=ok sig=ok
5. skel-50.dex stub%=1.7 erased%=0.0 min/erased=2524 cksum=ok sig=ok
6. skel-75.dex stub%=2.1 erased%=0.0 min/erased=3736 cksum=ok sig=ok
7. skel-all.dex stub%=2.3 erased%=0.0 min/erased=4946 cksum=ok sig=ok
8. allstub.dex stub%=100.0 erased%=0.0 min/erased=0 cksum=ok sig=ok <-- SKELETON
9. pruned.dex stub%=93.2 erased%=0.0 min/erased=344 cksum=ok sig=ok <-- SKELETON
10. nopfilled.dex stub%=0.0 erased%=100.0 min/erased=5061 cksum=ok sig=ok <-- SKELETON
verdict: ctrl.dex is the best-supported candidate for the original (1 copy(ies) in this set)
The control wins and every skeleton sorts behind it. The verdict line now states the
key and its limits instead of declaring a winner outright, and phrases the result as
"best-supported candidate" with an instruction to confirm before patching. --trim,
--json and --find are unchanged (verified: the recorded fixture still returns
01_original_shell.dex first, --json only gained keys). Note the residual limit the
report prints rather than hides: throwstub.dex still ranks third, because no body
statistic here sees a throw-stub skeleton. That is a boundary, not a bug — it is
listed in §7 with the reproduction.
3.4 A retracted Dex-VMP verdict — the measurement that killed it
An intermediate workbench script of mine
(tools/_work/bench/unpack/b4/vmp_probe.py, vmp_methods.py) decoded instruction
widths from a hand-written table and reported:
code_items=22424 desync=1393 (6.21%) bad_op=0xf8 / 0xef / 0xea / …
I read that as "bodies present but not decodable → private opcodes → Dex VMP". The reading was wrong, and the error was my table's. The official decoder settles it:
$ E:\tools\android-14\dexdump.exe -d tools/_work/bench/unpack/b4/orig/classes.dex
Processing 'orig\classes.dex'...
Opened 'orig\classes.dex', DEX version '035'
… 943,223 lines …
instruction lines (hex:...) : 348566
code items resolved ('insns size :') : 22424
code '(none)' : 1179
One of the methods my script called a desync decodes cleanly under dexdump:
--- androidx.appcompat.app.AlertController$ButtonHandler.<init>:(Landroid/content/DialogInterface;)V
insns size : 11 16-bit code units
1fd564: 7010 9b05 0100 |0000: invoke-direct {v1}, Landroid/os/Handler;.<init>:()V
1fd56a: 2200 040e |0003: new-instance v0, Ljava/lang/ref/WeakReference;
1fd56e: 7020 fb76 2000 |0005: invoke-direct {v0, v2}, Ljava/lang/ref/WeakReference;.<init>:(Ljava/lang/Object;)V
1fd574: 5b10 ed08 |0008: iput-object v0, v1, …$ButtonHandler;.mDialog:…;
1fd578: 0e00 |000a: return-void
My script consumed 9 of 11 units and stopped on 0xed; 0xed is a legal
invoke-*/range opcode. The lesson is the one the reference file already states and
this pass then failed to apply: a hand-rolled opcode table is not a VMP detector, and
"my decoder desynchronised" is a statement about my decoder. Any future
"rare-opcode density" metric must be validated against dexdump on the same file
before it is allowed to inform a verdict.
The corrected count of bodies that fail to decode as dalvik in this dex is 0.
Correction confirmed by an independent path: dexdump emits 34,566 instruction lines
and reports no structural error for any of the 22,424 code items.
4. B4 — the Dex-VMP judgement chain, re-opened
4.1 Static findings (observed)
Target: repos/DexPatcher/assets/ezAndroid.apk, 2,984,841 B, sha256
76e3fa8119cf8b7c…, package <PKG> (the ezAndroid CTF sample shipped in DexPatcher).
$ python skills/apk-reverse/scripts/dex_dump_validate.py …/b4/orig/classes.dex
classes=2905 methods_with_code=22424 stub%=1.9 cksum=ok sig=BAD
- Native declarations: 7, all in the app's own obfuscated classes, each with no
code (
code : (none)), enumerated fromdexdump:Lcom/example/ezandroid/C;->cf(Ljava/lang/String;I)Z,Lcom/example/ezandroid/MU;->GMS(Ljava/lang/String;)Ljava/lang/String;,Lcom/example/ezandroid/S;->Stringfjni()Ljava/lang/String;,Lcom/example/ezandroid/S;->onCreate,Lcom/example/ezandroid/S2;->onCreate,Lcom/example/ezandroid/S$1;->onClick,Lcom/example/ezandroid/S2$1;->onClick. - Two JNI exports in
lib/arm64-v8a/libezandroid.so(206,904 B, aarch64):Java_com_example_ezandroid_S_Stringfjni@0xea6c(184 B) andJava_com_example_ezandroid_MainActivity_stringFromJNI@0xe91c(184 B). Both are thin JNI wrappers that construct astd::stringand dispatch through a virtual call — the body of the check is behind the vtable, not in the wrapper. - No
JNI_OnLoadand noRegisterNativessymbol anywhere in the library; the stringJNI_OnLoaddoes not occur in the file at all. assets/holds six small opaque files (0OooOO118 B,O0ooOO126 B,oo0Ooo86 B,ooO0oo132 B,OOoo0O398 B,OOooO0260 B). Each begins with a three-unit header (05 00 38 00 02 00 …) followed by 2-byte-aligned units.- No dex string references those six filenames. Grep over the full 943,223-line
dexdumpoutput for0OooOO|O0ooOO|oo0Ooo|ooO0oo|OOoo0O|OOooO0|assets/returns 0 hits.
4.2 Verdict: JNI sinking, not Dex VMP (observed)
The reference file's Dex-VMP test is "the dump's method bodies are intact but decode
as private opcodes — rare-opcode density off the charts, unknown opcode slots". On this
target zero method bodies fail to decode, and every native declaration has a
matching exported Java_*. The dex is not carrying an encoded program; the code left
the dex for the .so, which is java2c-and-jni-sinking.md's territory, not this
file's. The two must not be conflated: an agent that reads "bodies decode as nonsense"
here will go hunting a private disassembler for code that is ordinary ARM64 in a
206 KB library.
The six assets/ files are a separate, unresolved observation: they are not
referenced by any dex string, so they cannot be load-bearing at the dex layer. Whether
the native island reads them by constructing the path at runtime, and what they
contain, is unverified here — it needs a dynamic run (§4.3), not more static
searching.
4.3 What static analysis structurally cannot see (the B4 boundary)
java2c's independent pass reached the same classification on this sample and recorded
that the hardening takes effect at runtime only. That is the general shape, and it
is the half of B4 that no dex probe can settle:
| Question | Answerable statically? | Why |
|---|---|---|
| Are the bodies real dalvik or private opcodes? | yes | dexdump decodes them or does not; measured 0 failures here |
| Did the code leave the dex for native? | yes | native access flags + Java_* exports / JNI_OnLoad |
| Does the native island check the signature / root / debugger? | no | the logic is ARM64 behind a vtable; the check may not exist in any dex |
Do those assets/ blobs get decrypted and used? |
no | the path may be assembled at runtime; grep for the literal names finds nothing |
| Does a repack actually fail, and why? | no | needs the repack installed and run against a control (G4) |
Rule this pass proposes for the reference file: a static dex probe may return
"this is not dex-VMP" when the bodies decode cleanly and every native declaration has
an export. It may not return "this is not hardened" from the same evidence —
those are different claims, and the second one is the misdiagnosis
java2c-and-jni-sinking.md was written to stop.
4.4 Repack control — observed up to the install, unverified beyond
G4 requires a zero-change control through the same pipeline. Built with the
repository's own repacker against an explicit toolchain (this host has no uber-apk-signer;
keytool lives in the JDK that ENV.md does not list):
$ python skills/apk-reverse/scripts/repack.py \
--apk tools/_work/bench/unpack/b4/ezAndroid.apk \
--out tools/_work/bench/unpack/b4/ez-ctrl.apk \
--ks tools/_work/bench/unpack/b4/ctrl.jks --signer apksigner \
--apksigner E:\tools\android-14\apksigner.bat \
--zipalign E:\tools\android-14\zipalign.exe \
--keytool "C:\Program Files\Java\jdk-17.0.4.1\bin\keytool.exe"
[in ] tools/_work/bench\unpack\b4\ezAndroid.apk (2984841 bytes)
[zip] - META-INF/1N0R.SF / 1N0R.RSA / MANIFEST.MF (signature artifact)
[zip] unsigned written: 2828919 bytes
[zip] AndroidManifest.xml STORED offset=0x31
[zip] classes.dex 3960320 bytes method=8 crc=037e9cb3
[zip] resources.arsc STORED offset=0x202f14 aligned
[sign] route: apksigner
[verify:zipalign] rc=0
[verify:v2block] present
[cert] SHA1 C9:89:C5:75:A4:83:AE:E0:A6:4B:F4:F6:0D:E3:D2:73:C2:8B:65:69
[result] OK
Zero-change repack, v2 block present, alignment verified, classes.dex carried through
at its original CRC (037e9cb3). Install and launch on <DEVICE> are unverified
in this record: the shared device was held by a parallel benchmark row (B1 L1 repack control + patched install, B2 L3 frida) for the whole window available to this pass.
No claim is made here about whether the control launches; the artifact and the command
above are the reproducible half, and the device half is the open item.
Consequently "repacking is truly refused on this target" is inferred, not
observed — it follows from the native island being the only home of the app's own
logic (Stringfjni, cf, GMS are all native declarations), which makes a
dex-level patch unable to reach the behaviour, but no device run confirms a refusal.
The honest deliverable form for this target is the G1 row annotated analysis report
with a stated boundary, with lsposed_scaffold.py / frida_rpc_serve.py named as
the routes if a device run shows the build is refused.
5. dex_mem_scan.py — the cut half is measured, the in-process half is not
The script's job splits cleanly into find-and-cut (locate dex\n03x in a blob and
write exactly the declared file_size) and reach the blob at all (do it against a
live process's anonymous mappings through /proc/<pid>/mem). Only the first half was
measurable in this pass, and it was measured with a synthetic high-entropy capture
built to have the shape a heap buffer presents:
$ python … # 2 MiB of random bytes with a 4,124-byte dex written at offset 0x9a000
fixture dex: 4124 bytes, magic=b'dex\n039\x00'
capture written: …/memscan/anonregion.bin 2097152 bytes dex at 0x9a000
$ python skills/apk-reverse/scripts/dex_mem_scan.py …/anonregion.bin --dump …/scanout
== dex memory scan: 1 capture(s), 1 hit(s) ==
capture offset ver file_size classes state
anonregion.bin 0x9a000 039 4124 1 ok
wrote …/scanout/anonregion+0x0009a000.dex
$ python skills/apk-reverse/scripts/dex_dump_validate.py …/scanout
name size sha256[:12] ver cksum sig class noco code stub%
anonregion+0x0009a000.dex 4124 d3dedcd2b75e 039 ok ok 1 0 5 0.0%
Exact offset, zero false hits in 2 MiB of noise, the extracted image byte-identical by construction and accepted by the judge including its checksum and signature. That is the whole find-and-cut path, observed — the halves compose correctly.
What is not measured. The live-process half: the fixture that would exercise it is
built and staged (§6), but the shared device was held by a parallel benchmark row for
the entire window this pass had, so dex_mem_scan.py has still never been run against
a real anonymous mapping here. The one related number that exists is from the earlier
root-dump pass, and it is a zero: 142 anonymous regions scanned, no hits, against
17 dex images found in named ART mappings with no search at all. A zero-hit scan is
weak evidence for the reasons listed in the script's own header, and the honest
summary is "the finder works on a shape that looks right; its in-process reach is
unverified".
To close it (all commands staged, none run in this pass):
adb push tools/_work/bench/unpack/memscan/out2/memfixture.jar /data/local/tmp/
adb push tools/_work/bench/unpack/b3/src-r2pay.dex /data/local/tmp/payload.dex
adb shell 'su -c "CLASSPATH=/data/local/tmp/memfixture.jar app_process /system/bin \
com.revprobe.memfixture.Main /data/local/tmp/payload.dex"' &
# the fixture prints its own pid, truncates the on-disk payload so the heap copy is the
# only remaining source, and writes /data/local/tmp/memfixture.maps
adb shell 'su -c "grep -c . /proc/<pid>/maps"' # confirm cheap maps first
adb shell 'su -c "grep -v \"/\" /proc/<pid>/maps"' # the anonymous set to export
Note the fixture deliberately truncates its source file: a scan that finds the dex after that point cannot have found a file copy, which is what makes the result attributable to memory rather than to disk.
6. Not done — and why
- No device run of the B4 control build. The shared device was locked by another
benchmark row for the whole window;
devlock.py acquire unpacktimed out twice (900 s and 1,800 s waits). Install, launch, time-to-death and refusal/success are thereforeunverified. - No in-process run of
dex_mem_scan.py. The fixture is built and staged (tools/_work/bench/unpack/memscan/, §5), the arm64app_processroute is chosen because this host has noandroid.jarand therefore cannot compile a real APK at all, and the closing commands are listed — but the device was never available, so the anonymous-mapping hit rate remains unmeasured. The only related measurement is the earlier pass's 0 of 142 anonymous regions. - Whether the
assets/blobs are live. Needs a dynamic run (read the files out of the process after the native island runs, or hook the path construction). - No end-to-end FART splice. The reference file's FART loop needs a live
extraction-shell target; nothing in
repos/is one (§1), and building an actively resisting shell is out of scope for this pass. - A real APK build on this host. The build-tools directory ships
d8,aapt2,apksignerandzipalignbut noandroid.jar, and noandroid.jarexists anywhere on the machine (searched the tool directories,C:\Program Files, and the SDK path). Anyjavacagainstandroid.*fails with "package android.os does not exist". APKs can still be repacked here (repack.pydoes not recompile), which is why §4.4 works and the self-built-APK route in the task brief does not.
7. Reproduction
python tools/_work/bench/unpack/b3/make_skeleton.py tools/_work/bench/unpack/b3/src-r2pay.dex tools/_work/bench/unpack/b3/skel
python tools/_work/bench/unpack/b3/analyze_pair.py
python tools/_work/bench/unpack/b3/crosscheck.py tools/_work/bench/unpack/b3/skel/*.dex
python skills/apk-reverse/scripts/dex_dump_validate.py tools/_work/bench/unpack/b3/skelall
python skills/apk-reverse/scripts/dex_dump_validate.py tools/_work/t2-unpack --find 'Lcom/stub/'
python tools/_work/bench/unpack/b4/vmp_boundary.py tools/_work/bench/unpack/b4/orig/classes.dex
E:\tools\android-14\dexdump.exe -d tools/_work/bench/unpack/b4/orig/classes.dex
python skills/apk-reverse/scripts/dex_mem_scan.py tools/_work/bench/unpack/memscan/anonregion.bin --dump tools/_work/bench/unpack/memscan/scanout
Raw captures live beside the fixtures: evidence/prefix-validate.txt (before the fix,
including the inverted ranking) and evidence/postfix-validate.txt (after). The
memscan/ tree carries the staged (unrun) in-process fixture: plain/com/revprobe/memfixture/Main.java
(no-android.jar form), build.ps1 (the APK build that cannot complete here, kept as
the record of why), and out2/{classes.dex,memfixture.jar}.
To re-verify the fix from scratch, the two commands that matter are
dex_dump_validate.py …/skelall (expect nopfilled.dex flagged, not ranked first) and
dex_dump_validate.py tools/_work/t2-unpack --find 'Lcom/stub/' (expect
01_original_shell.dex still the winner).