claude-code-reverse

Local Binary Reverse

Perform evidence-first static analysis on an explicitly specified local target. Read-only by default, do not execute the target, and do not exaggerate "visible strings" into "proven runtime behavior."

Autonomy boundaries

• Can be done directly: read a single local file specified by the user; run file, hashes,strings, symbol tables, dependency tables, section tables, and read-only disassembly tools; write analysis caches to the current user's private cache.
• Obtain consent first: run the target, attach a debugger, inject/hook, unpack to the user's directory, install analysis tools, upload samples, analyze unauthorized software or protected data.
• Refuse outright: bypass licenses, billing, or access controls, extract credentials, create crack patches, evade detection, or redistribute proprietary code/resources.
• If uncertain about ownership, the target path, or the deliverable, clarify first; do not scan the entire machine looking for a "possible target."

1. Pin down the target and the question

First record:

1. The exact target path or command name.
2. The specific question the user wants to verify, such as the source of UI text, a feature flag, a network endpoint, a dependency, or a version difference.
3. The two exact files for version comparison (if applicable).

Do not treat a process name, application name, or guessed path as a confirmed target. Do not run the target to "see what happens."

2. Establish file identity

Use the extract.shin the same directory. It only accepts regular files or commands that can be resolved by command -v , and caches are isolated by content SHA-256 and stored in ${XDG_CACHE_HOME:-$HOME/.cache}/claude-code-reverse/。

SKILL_DIR=/path/to/claude-code-reverse
bash "$SKILL_DIR/extract.sh" info --target /absolute/path/to/target
bash "$SKILL_DIR/extract.sh" dump --target /absolute/path/to/target
bash "$SKILL_DIR/extract.sh" search --target /absolute/path/to/target "literal anchor"
bash "$SKILL_DIR/extract.sh" diff --target-a /path/to/v1 --target-b /path/to/v2 "literal anchor"

info must first provide the normalized path, file type, byte count, and SHA-256. If the target changes during analysis, rerun info and dump; do not reuse old caches to draw conclusions.

3. Choose read-only tools by format

First use command -v <tool> to verify the tools exist. If missing, report the missing items; do not quietly switch to an approach that executes the target.

Format	Preferred evidence	Optional deeper tools
Mach-O	file、otool -L、otool -l、nm	otool -tvV, installed decompilers
ELF	file、readelf -h -l -d -s、objdump -x	objdump -d, installed decompilers
PE/COFF	file、objdump -x, ASCII/UTF strings	objdump -d, installed PE tools
Wasm	file、wasm-objdump -x	wasm2wat
ZIP/JAR/APK/packaged resources	List the directory first; do not unpack to disk	Unpack in a user-approved temporary directory, then analyze item by item

Do not use lddon untrusted targets, because some implementations may execute code through a loader. Do not directly output a full disassembly, full strings, or full symbol table for large files; first narrow the scope with literal anchors, and keep the raw large output in the cache or a separate artifact.

Common failure signals

• strings Almost no output: the target may be stripped, compressed, encrypted, or just a launcher; check the file type and section table first, and do not conclude from this that "there is no implementation."
• Right after dump, it says the cache does not exist: the content hash has already changed, indicating the target file was updated; re-run info and dump, and do not reuse the conclusion from the old version.
• The same string appears repeatedly: a universal/fat binary may contain multiple architecture slices; check by architecture first, and do not directly interpret the number of repetitions as the number of calls.
• ASCII search has no hits: the PE or resource file may use UTF-16; confirm that the local strings implementation supports the corresponding encoding option before searching, and do not assume cross-platform parameters are consistent.

4. From Evidence to Conclusion

Converge in the following order:

1. Use product copy, endpoints, configuration keys, error messages, or symbol names as literal anchors.
2. Extract the context around the anchor, and record the source file and SHA-256.
3. Cross-check symbols, import dependencies, adjacent constants, or the differences between two versions.
4. Distinguish conclusion levels:已观察(directly present in the file),强推断(multiple pieces of static evidence are consistent),未知(requires runtime or server-side evidence).

The existence of a string does not mean the code path is reachable, the existence of an import does not mean the function is called, and client-side copy cannot prove server-side policy either.

5. Claude Code Compatibility Mode

When --target is not provided, the script retains the original Claude Code shortcut mode:

bash "$SKILL_DIR/extract.sh" dump
bash "$SKILL_DIR/extract.sh" search "usage limit reached"
bash "$SKILL_DIR/extract.sh" diff 2.1.190 2.1.191 "literal anchor"

When you need Claude Code's installation location, anchor map, and specific limitations, read references/claude-code.md. Do not apply Claude-specific anchors to other targets.

Static Analysis Boundaries

Static analysis usually cannot prove the true semantics of server-delivered content, runtime-generated values, encrypted data, dynamically loaded paths, optimized-away logic, or obfuscated variables. When you need to cross these boundaries, clearly state the missing evidence and the side effects of the next step, then request permission.

Completion Criteria

• Report the target's canonical path, file type, byte count, and SHA-256.
• List the commands actually run this time and the locations of key output.
• Attach direct evidence to each conclusion, and mark 已观察、强推断 or 未知。
• Explain the static analysis boundaries not covered.
• Confirm that the target was not executed or modified, and that the sample was not uploaded to an external service.