inliver233
e193f425ba
Ran the scripts against a real Flutter AOT / multi-dex / 36-.so APK (Dart 3.6.0, com.tingfeng.tool) and recorded what each one actually did. Two of them were wrong in the direction that reads as a target finding, one Coverage claim overstated what ships, and four documentation statements were false. Fixed: dart_pprefs.py decoded only the general-purpose register file, so `ldr dN,[x27,#imm]` (0xFD400000) was never matched and every double constant read from the object pool was dropped -- 302 pool offsets and 1802 sites on this sample, one of them with 150 references that would have been reported as zero. The documented advice is to count references before editing a shared constant, so a one-sided quiet gap here produces exactly the wrong decision. Now covers both register files; a purpose-written arbiter agrees with it to 0/0 across .text, against 0/302 before. Documented but deliberately not fixed, because a fix would not have been run: elf_plt.py misses the last PLT stub slot (`off < fsz - 16`), which on libloader.so turned a real, called import (dl_iterate_phdr) into "not a resolved stub". find_refs.py advertises dex-directory input but iter_files() accepts only .smali, so it answers "no references" with exit 0 for input it never read. so_constpatch.py's rebuild drops the zip `extra` field and destroys 4 KB alignment. Each has its root cause and fix sketch recorded. Documentation corrections in dart-aot.md: blutter's asm/ does contain full instruction listings with pool annotations -- the file said to ignore it, and it is the richest artifact in the chain. The first build costs ~78 s, not "tens of minutes"; MSVC 19.34 suffices, not VS 2022. The file-PP offset mapping is not recoverable from the binary (4241 shared strings, 4237 distinct deltas), so a snapshot-decoding front end is a dependency, now stated. Documented aotopsy as the no-toolchain route, and the trap that its version label is a structural profile name (it says 3.6.2 for a 3.6.0 snapshot). Coverage now separates what was measured from what is inferred, names blutter/aotopsy as a prerequisite instead of implying the pool decodes itself, lists the scripts this pass did not run, and says plainly that the packer / VMP / integrity-check scenarios were not exercised at all. Added hand-off points for JNI, dex-observed hardening, and the existing native boundary documents, plus docs/verification-jiongnew/ -- the evidence record, including the four gate outputs verbatim. No second skill: the gap is one front-end dependency, not a subject area, and relocating Flutter docs would not have supplied it.
180 lines
12 KiB
Markdown
180 lines
12 KiB
Markdown
# Findings about the skill, from measuring it
|
||
|
||
Everything here is a result about **the skill**, not about the target. Each item names the evidence
|
||
that produced it and its strength.
|
||
|
||
---
|
||
|
||
## F1 — The Coverage claim was partly aspirational, and the pass identified exactly which part
|
||
|
||
`SKILL.md`'s Coverage section lists as *covered by verified mechanisms*:
|
||
|
||
> Flutter / Dart AOT: pinning the engine version, decoding the object pool, locating and patching
|
||
> business logic inside `libapp.so` (`dart-aot.md`).
|
||
|
||
Measured against a real Dart 3.6.0 `libapp.so`, that sentence splits into three claims of very
|
||
different standing:
|
||
|
||
| Sub-claim | Standing after this pass |
|
||
|---|---|
|
||
| pinning the engine version | **verified** — the banner route (§1) is correct and 3.6.0 is confirmed three ways |
|
||
| decoding the object pool | **false as written** — the kit cannot do it; there is no resolver |
|
||
| locating business logic inside `libapp.so` | **true, but conditional** — it works, on top of an external snapshot dumper that the skill neither ships nor installs |
|
||
|
||
The worked example in `TOOL-VERDICTS.md` shows both halves at once: the chain
|
||
`"showRewardAdProvider"` → `pp+0x23548` → ref site `0x7a9464` → `ShowRewardAdFamily.call_2f28ac
|
||
@ 0x7a93ec` succeeded, and step 1 was performed by blutter, not by the skill.
|
||
|
||
The reason is structural, not a shortage of effort: `dart_pool_strings.py` reports **file offsets**
|
||
while `pp.txt` and `dart_pprefs.py` work in **pool offsets**. Over the 4,241 strings present in both
|
||
spaces there are **4,237 distinct deltas** (min −1,361,429, max +277,654). The mapping is a property
|
||
of the reconstructed pool and is not a constant, so no amount of care inside the script recovers it.
|
||
|
||
Capabilities the kit does not have, stated plainly: snapshot/object-pool deserialisation; symbol and
|
||
name recovery; a real call graph (the `--build-index` index holds raw `B`/`BL` targets only); a
|
||
decompiler; a function boundary/size table.
|
||
|
||
---
|
||
|
||
## F2 — Two scripts fail in the way that reads as a target finding (the P26 class)
|
||
|
||
The handover singled out `pitfalls.md` P26: *"a self-built analysis script fails in a way that reads
|
||
as a target finding."* This pass produced two live instances of exactly that, which is why the P26
|
||
warning earns its place.
|
||
|
||
**`elf_plt.py` returned a confident false negative.** It reports 3,437 stubs where `.rela.plt` holds
|
||
3,438, and answers `0x587060 -> not a resolved stub` for an entry that is a legitimate stub for
|
||
`dl_iterate_phdr`, with a real caller at `0x576a2c`. Nothing in the output indicates a problem. For
|
||
the script's stated purpose — deciding whether a hardening symbol exists in a library — the wrong
|
||
answer is indistinguishable from the right one.
|
||
|
||
**`find_refs.py` returns a clean empty result for input it cannot read.** Its docstring advertises
|
||
"a smali tree or a directory of dex files"; `iter_files()` accepts only `.smali`. Given the dex
|
||
directory it printed `[total refs] 0`, exited **0**, and emitted no warning. This is worse than a
|
||
crash: it is the exact input to "nothing references this, safe to patch", produced by the very tool
|
||
recommended for judging blast radius before patching.
|
||
|
||
Both, plus `dart_pprefs.py`'s silently dropped double constants, share one property: **the failure is
|
||
one-sided and quiet.** None of the three reports reduced confidence in its own output.
|
||
|
||
---
|
||
|
||
## F3 — Defects found, ranked by consequence
|
||
|
||
| # | Script | Defect | Consequence | Status |
|
||
|---|---|---|---|---|
|
||
| 1 | `find_refs.py` | `iter_files()` matches only `.smali`; dex dirs yield 0 results, no error, exit 0 | silent false "no references" on the tool whose job is blast-radius | **cause identified, not fixed** |
|
||
| 2 | `elf_plt.py` | loop bound `off < fsz - 16` misses the final stub slot | false negative for one real symbol per library, conditionally | **fixed on a copy, re-verified** |
|
||
| 3 | `dart_pprefs.py` | only the GP register file is decoded; `ldr dD,[x27,#imm]` (`0xFD400000`) and all double constants lost | under-reports pool references (302 displacements / 1,802 sites here), which breaks the "count refs to judge importance" advice in `dart-aot.md` §9/§10 — one site went `[0 refs]` → `[79 refs]` | **fixed on a copy; agrees with capstone 0/0** |
|
||
| 4 | `so_constpatch.py` | rebuild drops the zip `extra` field, destroying 4 KB alignment | for `extractNativeLibs=false` APKs the output will not load; masked here because this target is DEFLATED + `extractNativeLibs=true` | **cause identified, proven by fixture; not fixed** |
|
||
| 5 | `so_constpatch.py` | `--diff --name-regions` compares file offset with vaddr | feature completely inert on libraries where `p_vaddr != p_offset` (2 of 36 here), with no warning | cause identified |
|
||
| 6 | `so_constpatch.py` | `external_attr` rewritten on 1982/1982 entries | metadata-based integrity comparison detects the rebuild | cause identified |
|
||
| 7 | `dexutil.py` | switch payloads decoded as instructions; `decode()` does not resolve operands | caused a spurious "desync likely" verdict on `saveToLocal` | cause identified |
|
||
| 8 | `so_constpatch.py` | "N byte(s) changed" is the overwrite window, not bytes changed | overstates change count (13 reported vs 7 actual) | cause identified |
|
||
| 9 | `lib_map.py` | `?` means both "read failed" and "not probed" | a real read failure is invisible | cause identified |
|
||
| 10 | `dart_pool_strings.py` | TSV escaping is lossy for LF/CR/TAB | 7 of 18,363 rows ambiguous; 19 entries genuinely contain those bytes | cause identified |
|
||
| 11 | `elf_plt.py` | `size = 16 if ... else 16` | dead code | cause identified |
|
||
| 12 | `dex_strings.py` | `--per-file` prints only files with hits | can be misread as "only this dex was scanned" | cause identified |
|
||
|
||
Items 1-3 are the ones that changed a conclusion during this pass rather than merely being noticed.
|
||
|
||
---
|
||
|
||
## F4 — Documentation contradictions
|
||
|
||
Independently found while mapping the skill and while using it. The executable cross-reference
|
||
checkers (`check_refs.py`, `check_repo.py`) pass, so these are invisible to the repo's own gates.
|
||
|
||
| # | Location | Problem |
|
||
|---|---|---|
|
||
| 1 | `dart-aot.md` §2 | Claims blutter's `asm/` has *no instructions* — "Do not plan around it." **Wrong.** `asm/windmill_ad_plugin/src/ads/reward/reward.dart` is 1,327 lines carrying class layouts, signatures, a full instruction listing, pool annotations and resolved call targets. It is the richest artifact in the chain and the doc says to ignore it. |
|
||
| 2 | `dart-aot.md` §2 | Budgets "tens of minutes" for the first blutter build; measured **≈78 s** (~30× pessimistic). Also demands a very recent C++ compiler; **MSVC 19.34 (Nov 2022) suffices**. |
|
||
| 3 | `dart-aot.md` §7 | Presents two-byte hit chaining as an acceptance test. On this sample, 9,840 two-byte CJK candidates yield 2,081 chained runs, all garbage. |
|
||
| 4 | `signature-derived-keys.md:61` | Documents `python scripts/sig_probe.py --live --pkg <pkg>` — the script has no `--pkg`; it takes `--live PKG`. Line 54 and `pitfalls.md` P27 give the correct form. |
|
||
| 5 | `dart-aot.md:204` | `dart_disasm.py ... --index callers.json --build-index` omits the required argument value; argparse errors out. |
|
||
| 6 | `byte-level-patching.md:186` | Says different-length strings "need `dex_strpatch`-class tooling", while `dex_strpatch.py` requires `len(new) == len(old)` — it is precisely the tool that cannot do this. Contradicts `dex-patching.md:123`. |
|
||
| 7 | Coverage vs `toolchain.md` | Coverage lists Unity/IL2CPP logic recovery as **not covered**, but `toolchain.md` Tier 4 names concrete tooling without pointing back at that disclaimer, so a reader of `toolchain.md` alone would take IL2CPP for a supported route. |
|
||
| 8 | Script count | `SKILL.md`/`README.md` index 35 rows, which is 34 scripts plus the `scripts/dexpatch/` directory row. |
|
||
| 9 | `dart_pool_strings.py` docstring | Says two-byte auto-detection is unreliable (confirmed here); `dart-aot.md` §7 treats UTF-16LE hits as a reliable rule. |
|
||
| 10 | `verification.md` rung 7 | Re-downloading a distributed file to compare hashes has no landing place in `SKILL.md`'s six "done" criteria, so the two sections disagree on strength. |
|
||
|
||
Item 1 is the most damaging because it steers a reader away from the best available evidence.
|
||
|
||
---
|
||
|
||
## F5 — "verified mechanisms" left no reproducible trace in the repo
|
||
|
||
The Coverage preamble frames its list as *verified mechanisms*, and `references/long-task-discipline.md`
|
||
defines **Observed** as *"reproduced it, with the exact command and output"*. The repository contains
|
||
no sample, no fixture, no captured log or screenshot, no patch record, no test and no CI, and its
|
||
`README.md` states it holds no target-specific data.
|
||
|
||
So the strongest support the repository itself can exhibit for those claims is *Inferred*. This is
|
||
**not** an accusation that the claims are false — several were confirmed here on the first attempt,
|
||
and `dart-aot.md` §1 proved exactly right. It is a statement about evidentiary standing: the repo
|
||
asks its readers to label their own claims and does not leave itself a way to meet its own bar.
|
||
|
||
The concrete measurement figures that *are* reproducible are the 14 sample-scoped numbers listed in
|
||
the skill map (e.g. dex 4.32 MB → 7.73 MB; `.RSA` 1199 B vs 777 B at runtime; a log tag going `8 → 0`).
|
||
|
||
---
|
||
|
||
## F6 — Boundary evidence: where the skill's method held, and where it ran out
|
||
|
||
This is the observation the pass was built to produce, so it is stated as a sequence rather than a
|
||
verdict.
|
||
|
||
**Held, unchanged:** manifest and packer triage; multi-dex string/class recon at 27.6 MB across four
|
||
dex files (`dex_strings.py`, `dexutil.py`); native ELF import mapping at scale (36,974 relocations);
|
||
live-process library mapping; equal-length `.so` constant patching; the launch-timeline methodology
|
||
(`coldstart.py`); the P26 discipline itself — checking whether a tool was ever able to answer before
|
||
reading its silence as a finding, which is what turned the blutter crash from a false "unusable" into
|
||
a corrected "works after a relink".
|
||
|
||
**Ran out:** from the Dart snapshot inward. Everything past `pp.txt` is fine; getting *to* `pp.txt`
|
||
from the binary requires a container resolver the kit does not have. That is one dependency, not a
|
||
subject area.
|
||
|
||
**Not exercised at all:** packers, code virtualization, custom linkers, integrity-check redirection,
|
||
tamper-triggered suicide. This target has none of those, and the unmodified app's own startup failure
|
||
also removes the repack loop those scenarios need.
|
||
|
||
---
|
||
|
||
## F7 — A trap in this specific environment that will produce false confirmations
|
||
|
||
`androguard` 4.x (the version installed here) has **four independent reference-analysis failures on
|
||
this sample**: `get_xref_from()` returns 0 for everything, including `AdLoader.loadAd()V` which has
|
||
20+ callers by other means; `get_ref()` raises; a full `get_operands()` sweep returns 0 strings.
|
||
|
||
Anyone who reaches for androguard to double-check a "zero references" conclusion will get **zero, and
|
||
therefore agreement**. The zero-reference result in `TARGET-FACTS.md` does not come from androguard;
|
||
it comes from `dexutil.py` plus raw-byte re-checks of the bodies that would not decode cleanly. This
|
||
is worth a line in the environment documentation because it is a tool that lies in the direction of
|
||
the hypothesis being tested.
|
||
|
||
---
|
||
|
||
## F8 — Reconciling the two failures: a genuine but unproven loader signal
|
||
|
||
Recorded as a boundary between what was established and what was guessed, because collapsing them
|
||
would be its own error.
|
||
|
||
The launch does show non-standard startup plumbing (observed):
|
||
|
||
- `E LoaderLog: 10026 / 101004` on the device, `10020 / 101003` on the emulator — an SDK-side
|
||
loader logging numeric status codes
|
||
- `E Instrumentation: Uninitialized ActivityThread, likely app-created Instrumentation, disabling
|
||
AppComponentFactory` — the process is not taking the ordinary `ActivityThread` path
|
||
- `E m.tingfeng.too: Unknown bits set in runtime_flags: 0x40000000`
|
||
|
||
And yet the dex-side packer verdict is clean: no hardening library in the native set, an ordinary
|
||
`application android:name` (`app.video.guoguo.GApplication`), no known packer markers. Those two
|
||
observations sit in tension.
|
||
|
||
**Not resolved.** The `LoaderLog` emitter was not attributed to a specific class — the string exists
|
||
in `classes2.dex` and `classes3.dex` but the classes that declare it are third-party, and this pass
|
||
did not trace the call chain. Whether this plumbing is a benign logging SDK, part of the Flutter
|
||
plugin bootstrap, or a light-weight loader contributing to the abort is **unverified**. Stating it
|
||
as established would be exactly the kind of overreach this report is trying to document.
|