antior/apk-reverse
1
0
Fork 0
mirror of https://codeberg.org/reverse-skill-lab/apk-reverse synced 2026-11-15 20:34:29 +08:00
Code Issues Packages Projects Releases Wiki Activity

Stop reporting a tool's resource failure as a finding about the target

Browse Source 
A JVM reader that dies on a large or deeply nested input -- OutOfMemoryError, an OOM kill, a
container limit, a timeout -- prints an empty result that looks exactly like a reader that read the
file and found nothing. That is the `present but unreadable` case SKILL.md §Coverage names, and it is
where a wrong "that class is not in there" gets recorded.

The new section in toolchain.md says what a failed analysis actually supports (a claim about the
route, not about the artifact) and the three things to check before a negative from a heavy tool
becomes a finding: the exit code and stderr rather than stdout alone, a re-run with room to work, and
the indexed-query route that answers most location questions without materialising anything. A
deadline you set yourself gets the same reading -- it reported nothing about the target.

Also: the README claimed the scripts "work identically on Windows, macOS and Linux", while every gate
run, every test result and every figure in the evidence record comes from one Windows host. The claim
now carries the strength it actually has -- measured on Windows, `unverified` elsewhere -- and names
the usual suspects (path separators, `os.pathsep` in `APKREV_TOOLS`, console encodings, ADB shell
quoting) so a first run on another platform has somewhere to look.
This commit is contained in:
inliver233
2026-10-16 19:20:45 +08:00
parent 6ab905b2c8
commit 5c3ba9cd2e
3 changed files with 33 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+8 -1
View File
@@ -505,9 +505,16 @@ set APKREV_TOOLS=<dir>;<dir> # Windows, e.g. an SDK or proje
export APKREV_TOOLS=<dir>:<dir> # POSIX
```
The scripts themselves are plain `python3` and are intended to work identically on Windows, macOS and
The scripts themselves are plain `python3` and are designed to work identically on Windows, macOS and
Linux; where a snippet is POSIX-only it is labelled. Nothing here assumes a Unix shell.
**Measured on Windows only.** Every gate run, every test result and every figure in the evidence
record comes from one host (Windows 10.0.26100, PowerShell 7, CPython 3.14). Cross-platform behaviour
is a design intention, not an observation: treat another platform as `unverified` until the suite has
been run there, and expect the usual suspects to be the difference — path separators, `os.pathsep` in
`APKREV_TOOLS`, console encodings, and shell quoting in the ADB helpers. If you run the gates on
macOS or Linux and they pass, that is a `observed` result worth recording next to this paragraph.
| Tool | Used for |
|---|---|
| Python 3.9+ | all scripts |