reverse-skills-max/vendor-new/apk-reverse/docs/tool-verification/EXTENSION-rootdump.md

Extension verification — root-side memory dump (the route that does not use frida)

Covers the 2026-09 extension pass that added the §Dumping when frida is refused section to references/advanced-unpacking.md. It is the follow-up to docs/tool-verification/EXTENSION-device-run.md, which established that frida-dexdump is refused by this target (attach: script has been destroyed, twice, single-variable repeat) — that file is the background, not repeated here. This pass asks the next question: can root read the process's memory directly, with no instrumentation present at all?

Strength labels, as defined in this directory's README:

• observed — reproduced here, with the exact command and its output.
• inferred — follows from observed facts, but the step itself was not executed.
• unverified — assumed, or reported by a tool and not independently confirmed.

Target identity is deliberately absent; the package appears as <PKG>. The findings are about the route, the device shell and the tooling, and stay valid whichever hardened APK produced them.

Environment (observed)

Item	Value
Device	the same physical arm64 device as EXTENSION-device-run.md: Android 11 (API 30), kernel 4.14.186, Magisk root
Instrumentation	none — the device-side frida-server was left stopped for the whole pass; ps -A | grep -i frida returned nothing before and after
Sample	360-jiagu hardened, Flutter AOT payload, installed and untouched (no reinstall, no repack)
Root access	adb shell 'su -c "…" — full root, no avc: denied in any read attempt below
Device shell	toybox (grep, dd, ps, stat, awk, sed); no findstr, no ls --time-style, no map_files entries

Two shell facts were measured before anything else, because both silently corrupt a naive dump and neither announces itself:

$ adb shell 'su -c "grep --help"'      # → -a -b -o -z -E -F available
$ adb shell 'su -c "dd --help"'        # → iflag=skip_bytes,count_bytes available

1. The sample does not stay up, with or without frida (observed)

The control assumption going in was that the sample is stable when nothing is attached. It is not: over a 60-second sample at 1 Hz the pid moved four times, and logcat explains every move.

pid sequence, ps -A -o PID,NAME | grep -w <PKG> once per second:

20:31:02 16729 … 20:31:07 16729
20:31:08 17951 … 20:31:23 17951
20:31:26 20021 … 20:31:42 20021
20:31:43 21632 … 20:32:00 21632
20:32:01 (none)  20:32:02 22770 …

The platform's own record of two of those transitions:

09-21 20:31:43.327 I/ActivityManager: Process <PKG> (pid 20021) has died: fg  TOP
09-21 20:31:43.394 I/ActivityManager: Start proc 21632:<PKG>/u0a623 for top-activity {<PKG>/.MainActivity}
09-21 20:32:01.463 I/ActivityManager: Process <PKG> (pid 21632) has died: fg  TOP
09-21 20:32:01.555 I/ActivityManager: Start proc 22770:<PKG>/u0a623 for top-activity {<PKG>/.MainActivity}

• observed: each process lives 7-18 s, then dies as a foreground, top process, and is started again by ActivityManager because the activity stack is still on top. Lifetime is not constant.
• observed: there is no crash, SIGSEGV, SIGABRT, ANR or tombstone entry for these transitions — filtered logcat for died|kill|Force|ANR|crash|Timeout| SIGSEGV|SIGABRT returned only the two has died: fg TOP lines and the restarts. A clean self-exit, not a platform kill.
• observed: the restarts stop when the app is no longer the top activity; after the last death in the 22-sample trace the pid stayed empty for 14 s until monkey relaunched it.
• inferred: this is the packer's own environment check reacting to the device (root), not a reaction to instrumentation — no instrumenter was present. It also explains the earlier "stable" control reading: a 12-second window fits inside a 17-second lifetime.
• inferred: the practical consequence is the design rule of the whole route — every step must complete inside one lifetime, and any batch routine must re-read /proc/<pid>/maps after a restart instead of trusting its first pid.

2. The map is the cheapest source of dex images (observed)

/proc/<pid>/maps for the live sample: 522,795 bytes, 5,617 regions. ART names the dex images it holds, so no search is needed for those:

7129d8c000-712a60f000 r--p  [anon:dalvik-classes.dex extracted in memory from /data/app/~~…/base.apk]
6f9ba03000-6f9be2b000 r--p  [anon:dalvik-classes.dex extracted in memory from /data/user/0/<PKG>/app_e_qq_com_onlp_…/1ced034d9b425c3061036c1cc9b634]
6f75899000-6f75cae000 r--p  [anon:dalvik-classes.dex extracted in memory from /data/user/0/<PKG>/app_sodler/com.kwad.components.tachikoma/5.6.10.1/base-1_apk]
… 17 such regions in total

Export command actually used (decimal offsets; see §4 for why not hex):

dd if=/proc/<pid>/mem iflag=skip_bytes,count_bytes skip=<DEC_START> count=<SIZE> \
   of=/data/local/tmp/t2dump/dexNN.bin bs=64k

All 17 regions exported; 16 of 17 completed inside one lifetime, two of the trailing regions were cut short by the restart described in §1 and came back as 0-byte files — which is the failure mode to expect, and the reason the batch must be re-entrant.

3. Validation: what the exported images actually are (observed)

The dumps are page-aligned and therefore 0..4095 bytes longer than the image they carry, so all 17 were rejected on first validation:

== dex dump validation: 7 file(s), 0 parse, 7 rejected ==
dalvik-classes.dex_…base.apk.dex  8925184  REJECTED: file_size=8923752 actual=8925184

Trimming each file to the file_size field at dex-header offset 32 (dropped 68 … 3,724 bytes per file) then gave a clean run:

== dex dump validation: 17 file(s), 17 parse, 0 rejected ==
name        size      sha256[:12]   ver  cksum   sig    class  noco   code   stub%
dex16.bin   122460    3fc5581d6eb3  035  ok      BAD      103   207   8974    1.1%   (ksad dynamic apk)
dex08.bin  1069516    613cfef811ab  035  ok      BAD     1285   432   8929    0.9%   (kwad ksdp)
dex14.bin  8923752    1497590d0a24  035  ok      BAD        4   160     29    3.4%   (from /data/app/…/base.apk)
dex01.bin  3212480    fb61a3f085f5  035  ok      ok      3169   785  15924    1.0%   (pangle live-lite classes6)
… 17 images, stub% 0.9 – 3.4, 17/17 unique by sha256

ranking (most likely original first):
  1. dex08.dex  stub%=0.9  cksum=ok  sig=BAD  classes=1285
  …
 17. dex14.dex  stub%=3.4  cksum=ok  sig=BAD  classes=4

What this means, and what it does not:

• observed: the route produces real, parseable dex from a hardened app's process memory without any instrumentation — 17 images, one class count 103 up to 10,148, stub% in the low single digits. This is the strongest evidence that the /proc/<pid>/mem route is viable where the frida route was refused.
• observed: the image that came from the app's own base.apk defines 4 classes on an 8.9 MB file (sig=BAD on the untouched image). File size and class count move independently under a packer — this is the landing-shell skeleton shape, matching the shipped classes.dex recorded in EXTENSION-unpacking.md.
• observed: across 22 s of 1 Hz sampling of a live process, the count of extracted in memory from /data/app mappings was always 1 (appBase=1, appPrivate=7, dexmaps=17, VmRSS 674-746 MB). No second application dex mapping ever appeared.
• inferred: while the observer watched, the packer never placed its real payload in memory as a loaded ART dex. Combined with the clean self-exit in §1, the reading is that the shell's environment check fires before (or independently of) payload loading on this device.
• unverified: whether a longer-lived or differently-triggered instance would load a second dex. No attempt was made to defeat the check, by task instruction.

4. Searching memory for a decrypted dex: what the device shell does to you

Two blind searches were run for the pattern the payload would leave if it were sitting in a native or heap buffer rather than a loaded dex.

Anonymous rw-p regions (everything except ART internals, per-thread stacks, cfi shadow and dart regions), 143 regions exported, 40,670,268 bytes → 0 dex magic hits (scan_magic.py, dex\n03x with file_size cross-check).

ART main space (dalvik-main space (region space), 1 GB reservation) sampled in 64 MB windows from the start of the space → 0 dex magic hits in the 192 MB covered, at ~10 MB/s:

maps_line=12c00000-52c00000 rw-p … [anon:dalvik-main space (region space)]
region_space_base=314572800
off=0          abs=314572800 secs=6  hits=[]
off=134217728  abs=448790528 secs=7  hits=[]
PID_DEAD before off=268435456

inferred: at 10 MB/s a full 1 GB heap sweep is ~100 s — several process lifetimes — so heap search is not a plan for a sample with this restart cadence. Named ART dex mappings are free; a heap sweep is not.

Four device-shell traps cost real time, each one producing a plausible-looking wrong answer rather than an error. All four are observed:

Trap	Observed behaviour	What worked
mksh arithmetic is 32-bit	$((16#7129d9a000)) → 702128128 (the low 32 bits); dd skip=702128128 then read an unrelated address and the "dump" was zeros	convert with awk (48-bit values exact in double): awk 'BEGIN{…n=n*16+v…; printf "%d", n}'
VMA page alignment	17/17 dumps rejected with file_size=… actual=…, excess 68…3724 B	trim to header file_size before validating
grep is line oriented	grep -F with a real newline in the pattern matched only 035 at the wrong offset; -E with a literal newline matched nothing	grep -z -a -o -b -E 'dex.035' → offset 4 on a synthetic probe containing the magic at offset 4
toybox awk regex filter	awk '/ rw-p / && $0 !~ /dalvik-|…/' selected all 808 map lines, including r--p system libraries, so the candidate list was meaningless	filter with grep -aE '^[0-9a-f]+-[0-9a-f]+ rw-p ' plus grep -av, keep awk for arithmetic only

/proc/<pid>/map_files/ is not a shortcut on this ROM (observed): the directory exists, is dr-x------ root root, and lists no entries, so dd if=/proc/<pid>/map_files/<start>-<end> yields 75 bytes of can't open … No such file or directory. The mem + decimal-offset form is the one that works.

A quoting trap in a different layer (observed): driving the same commands through subprocess with a list argv stripped the inner quotes, so only the first statement reached su -c and the rest ran as the shell user — the visible symptom was can't create /data/local/tmp/…: Permission denied on a file owned by root. Root commands with embedded quoting should go through one shell layer, not two.

5. Leftover dumps in the work directory — what they are (observed + inferred)

/data/local/tmp carried .so files from earlier sessions. They were verified rather than trusted:

File	Size	sha256[:16]	ELF	Sections
L_libapp.so = d_libapp.so = libapp.bak	13,501,344	2275dd4398f0b34e	ELF64 AARCH64, ET_DYN, phnum 7	11
rt_libapp.so	13,501,344	8b490512258ba1c8	ELF64 AARCH64, ET_DYN, phnum 7	11
libapp.so	12,256,160	4cfec2762c25539b	ELF64 AARCH64, ET_DYN, phnum 7	11
ll.so	6,230,040	20f2d12b5049f238	ELF64 AARCH64, ET_DYN, phnum 9	26

• observed: all four are structurally valid ELF64/AARCH64 shared objects with a complete section header table, and the three libapp variants contain the Dart AOT snapshot marker (3 occurrences each).
• observed: the libapp.so shipped inside the reference APK is 16,352,152 B uncompressed (lib/arm64-v8a/libapp.so), i.e. ~2.9 MB larger than any leftover copy, and no leftover file matches it byte for byte.
• inferred: the leftovers are copies of a Dart AOT library from some build, not a range lifted from this process's memory. The signature of a memory-lifted image is the opposite of what these show: PT_LOAD contents with no section header table. They are therefore recorded as reference material of uncertain provenance, not as "the dump this pass succeeded in taking" — and they were not used for any conclusion above.

6. Conclusions, graded

Claim	Label
Root can read /proc/<pid>/maps and /proc/<pid>/mem on this device with no avc denial and no instrumenter present	observed
17 ART dex mappings were exported from a live hardened process and, after trimming to header file_size, all 17 parsed as valid dex	observed
The dex mapping sourced from the app's base.apk defines 4 classes on 8.9 MB (landing-shell skeleton); the other 16 are real SDK dexes, stub% 0.9-3.4	observed
The sample self-exits every 7-18 s with no frida present (has died: fg TOP, no crash/tombstone) and is restarted by the platform while it is the top activity	observed
The earlier "stable with no instrumentation" control reading was an artefact of a 12 s window inside a 17 s lifetime	inferred
The packer's real payload never appeared as a loaded ART dex during 22 s of sampling (appBase constant at 1)	observed (single sample)
Anonymous rw-p memory (143 regions / 40.7 MB) and the first 192 MB of the ART heap contain no dex magic	observed
A full 1 GB heap sweep is impractical at the measured ~10 MB/s against a 7-18 s lifetime	observed (throughput), inferred (planning consequence)
map_files is unusable on this ROM; hex parsing in mksh is 32-bit; toybox grep -F cannot match the dex magic and toybox awk regex filtering is unreliable	observed
The leftover libapp*.so files are unrelated to this process's memory; provenance unverified	observed (structure/size), inferred (provenance)

7. What this pass did not establish

• Not a recovered payload. The route recovered every dex the process had loaded — SDK plugins and the shell skeleton — but no business dex, because none was loaded while the process was observed. The Flutter payload itself (libapp.so, Dart AOT) is a separate target and is not reached by a dex-oriented dump.
• Not an evasion. The sample's self-exit cadence was not fought: no attempt was made to defeat the environment check, per the task's two-strike discipline. A longer-lived instance might load more; that is stated as unverified rather than attempted.
• Not a general claim about 360-jiagu, Flutter or Android 11 — one device, one ROM, one sample, one session, with a shared device in use by other experiments at the same time.
• Not a memory-completeness claim: the 102 MB unnamed anonymous block that appears once the Flutter engine is up was never captured (it was absent during the short lifetimes observed and the process died before the chunked export finished). It is recorded here as an uncovered region, not as a scanned-clean one.