From fa2f62107f4dbd22061d35de6da1d06598a5a6c5 Mon Sep 17 00:00:00 2001 From: inliver233 Date: Mon, 21 Sep 2026 22:01:28 +0800 Subject: [PATCH] docs: stop citing workbench paths that are not shipped Eight citations in the reference documents pointed at tools/ paths, and .gitignore excludes tools/ -- so neither an installed skill nor a clone of this repository can open them. Each is now either an inline statement of the fact or a pointer to the evidence file under docs/tool-verification/ that actually holds it. One of the eight was introduced by the benchmark pass itself (protocol-reverse.md cited a workbench script). The evidence records keep quoting tools/_work/... deliberately: there they are operation records of where a run happened. docs/tool-verification/README.md now states that distinction and the rule that follows from it -- a reference document never cites a tools/ path as its evidence, even when the work happened there. --- docs/tool-verification/README.md | 8 +++++++- .../references/kernel-and-environment-hardening.md | 11 +++++------ skills/apk-reverse/references/on-device-tooling.md | 4 ++-- skills/apk-reverse/references/protocol-reverse.md | 6 +++--- 4 files changed, 17 insertions(+), 12 deletions(-) diff --git a/docs/tool-verification/README.md b/docs/tool-verification/README.md index fc75b54..6dadc81 100644 --- a/docs/tool-verification/README.md +++ b/docs/tool-verification/README.md @@ -12,7 +12,13 @@ build time) the figure is kept and the target is named generically. Targets measured: Flutter AOT applications, multi-dex, mid-size native library sets, no packer. -The APKs themselves are **not** in this repository (`.gitignore` excludes `*.apk`). +The APKs themselves are **not** in this repository (`.gitignore` excludes `*.apk`, and `tools/`). + +**Workbench paths are an operation record, not a pointer.** A record may say a run happened *at* +`tools/_work/...` so the command can be judged; `.gitignore` excludes `tools/`, so that path is not +something a reader can open. Anything a reader is *meant* to follow is named under +`docs/tool-verification/` or inside the skill — that rule is why a reference document never cites a +`tools/` path as its evidence, even when the work happened there. ## Strength labels diff --git a/skills/apk-reverse/references/kernel-and-environment-hardening.md b/skills/apk-reverse/references/kernel-and-environment-hardening.md index db56e62..94b3d26 100644 --- a/skills/apk-reverse/references/kernel-and-environment-hardening.md +++ b/skills/apk-reverse/references/kernel-and-environment-hardening.md @@ -92,14 +92,13 @@ documentation (sources at the end of the section); none were re-measured here Sources: KernelSU README + FAQ (github.com/tiann/KernelSU), APatch FAQ (apatch.dev, project originally at github.com/bmax121/APatch), fetched 2026-09. Device facts (Magisk alpha on kernel -4.14.186) are `observed` in `tools/_phone-modules/README-手机模块环境.md`. +4.14.186) are `observed` on the reference device used for this pass. ## 3. Environment-hiding modules: Zygisk-Assistant vs Shamiko Both are Zygisk modules that hide root + Zygisk from target apps. **Do not install both** — they overlap in function (mount-namespace handling, trace wiping) and interfere; this is documented in -the module ecosystems and was the deciding fact on the reference device (`observed` in -`tools/_phone-modules/README-手机模块环境.md`: Shamiko kept as a backup zip, uninstalled). +the module ecosystems and was the deciding fact on the reference device (`observed`: Shamiko kept as a backup zip and uninstalled there). The practical difference is their **denylist dependency** (from each project's own README, `inferred`): @@ -117,7 +116,7 @@ ZygiskNext) is the supported path. The denylist/enforcement settings are the par wrong: **enforcement off, list populated** is the working combination for both. Verification status: neither module's hiding effect was tested against a real detector on the -reference device (`tools/_phone-modules/README-手机模块环境.md` §未覆盖的验证) — treat every +reference device — treat every "this hides X" claim above as documented-but-unproven here. ## 4. Kernel-level interception — the map, and the version gate @@ -137,7 +136,7 @@ uname -r # on the device. The gate for most of this section is 5.10+ expects it) targets GKI kernels. Source: the Android kernel architecture documentation on source.android.com (GKI and eBPF pages). On the reference device (kernel **4.14.186**) this entire row is **closed** — `observed` (the version), with the - consequence recorded in `tools/_phone-modules/README-MCP与网络环境.md`: eBPF-based tooling + consequence that eBPF-based tooling (stackplz, mcp-termux's tracing half) is unavailable there. Write the one-line environment fact per `detection-and-anti-analysis.md` Step 5 and do not revisit it. @@ -255,7 +254,7 @@ rather than to any tool: ## 6. What the reference environment chose (and why it generalises) On the 4.14-kernel reference device, the escalation ladder terminates early — and that is the -honest outcome (`observed`, from `tools/_phone-modules/README-*.md`): +honest outcome (`observed` on that device): | Layer | Status on a 4.14 Magisk device | |---|---| diff --git a/skills/apk-reverse/references/on-device-tooling.md b/skills/apk-reverse/references/on-device-tooling.md index 28a51c7..9b0eb00 100644 --- a/skills/apk-reverse/references/on-device-tooling.md +++ b/skills/apk-reverse/references/on-device-tooling.md @@ -6,7 +6,7 @@ is no laptop in the loop. This file covers the **on-device toolchain** and — m when each tool beats its PC counterpart and when it does not. Evidence basis: the facts below come from a real configured environment (Android 11, Magisk + -Zygisk, LSPosed v1.9.2, MT Manager 2.26.9), archived in `tools/_phone-modules/`. Framework +Zygisk, LSPosed v1.9.2, MT Manager 2.26.9). Framework activation and the module set are `observed` there; per-workflow usability notes are `measured` where marked, otherwise `inferred`. The MT MCP tool surface is from MT's official documentation (`observed` as a list; live invocation requires the service to be running — see §2). @@ -87,7 +87,7 @@ code 2 — usable as a loop check ("is it up yet") while you start it by hand. ` LSPosed (via Zygisk) gives you a **Java-layer hook platform that needs no PC at runtime**: write/ install a module once, and it applies to target apps at every launch. -Facts from the reference environment (`observed`, archived in `tools/_phone-modules/`): +Facts from the reference environment (`observed`): - Activation is verifiable from logs: the `ZygiskCompanion: welcome to LSPosed!` banner, the version line, the `lspd` daemon process running as system. diff --git a/skills/apk-reverse/references/protocol-reverse.md b/skills/apk-reverse/references/protocol-reverse.md index e8509a3..e6ba0a4 100644 --- a/skills/apk-reverse/references/protocol-reverse.md +++ b/skills/apk-reverse/references/protocol-reverse.md @@ -31,9 +31,9 @@ sequence". That is the whole format; the schema supplies meaning and nothing els | Wire type 5 | fixed 4 bytes (fixed32/sfixed32/float) | | Wire types 3/4 | group start/end, legacy; treat as unsupported when walking a modern payload | -A host-side check of the rules, including the canonical `150 -> 96 01`, lives in -`tools/_work/t4-dbi/pb_selftest.py` (workbench, not shipped with the skill). Measured output on the -fixture built there: +A host-side check of the rules, including the canonical `150 -> 96 01`, was run independently of the +shipped decoder — `docs/tool-verification/EXTENSION-protobuf-raw.md` records that cross-check against +the official runtime. Measured output on the fixture built for it: ``` message (29 B): 089601120774657374696e671a0508011201782206038e029ea7052800