Use when analyzing binary structure, disassembling code, or decompiling functions. Deep static analysis via radare2 (r2) and Ghidra headless - function enumeration, cross-references (xrefs), decompilation, control flow graphs. Keywords - "disassemble", "decompile", "what does this function do", "find functions", "analyze code", "r2", "ghidra", "pdg", "afl"
SkillScore95Maintained
Automatic
◆Security & AppSec pack
Last verified 8/21/2026
What it changes
Passed 19 of 20 test cases with the skill, and 11 of 20 without it.
Without skill55%
With skill95%
Checks it passed that the model alone missed
The session setup explicitly configures `anal.timeout=120`.
The JSON schema root contains top-level array `functions_analyzed`.
The response specifies `cmp -l expected.txt actual.txt | head -20`.
and 11 more in the full report
9 fixed12 passed either way1 still failing0 broke
Pass-rate lift
+41 pp
Tokens
+122%
Agent turns
0%
Response time
-36%
Model gemini-3.6-flashMeasured 8/21/2026v121 of 22 cases passed with skill · 20 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
After running input through binary `svc_bin`, we have files `actual.txt` and `expected.txt`. We want to list the first 20 byte-level differences between these files using standard Linux CLI tools. What command line should be run?
What was checked, without and with the skill
Checked
Without skill
With skill
The response specifies `cmp -l expected.txt actual.txt | head -20`.
Missed
Passed
case-22 · gemini-3.6-flash · 8/21/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md401 linessingle file
Static Analysis (Phases 2-3)
Purpose
Understand binary structure and logic without execution. Map functions, trace data flow, decompile critical code.
When to Use
After triage has established architecture and ABI
To understand specific functions identified as interesting
When dynamic analysis is impractical or risky
To build hypotheses before dynamic verification
Pre-Analysis: Compare Known I/O First
CRITICAL: Before diving into disassembly, check if known inputs/outputs exist.
⚠️ REQUIRES HUMAN APPROVAL - Get explicit approval before any execution, even for I/O comparison.
# SAFE: Use emulation for cross-arch binaries (after human approval)
# ARM32:
qemu-arm -L /usr/arm-linux-gnueabihf -- ./binary < input.txt > actual.txt
# ARM64:
qemu-aarch64 -L /usr/aarch64-linux-gnu -- ./binary < input.txt > actual.txt
# Docker-based (macOS/cross-arch - see dynamic-analysis Option D):
docker run --rm --platform linux/arm/v7 -v ~/samples:/work:ro \
arm32v7/debian:bullseye-slim sh -c '/work/binary < /work/input.txt' > actual.txt
# x86-64 native (still requires approval):
./binary < input.txt > actual.txt
# Compare outputs:
diff expected.txt actual.txt
cmp -l expected.txt actual.txt | head -20 # Byte-level differences
# Record findings:
# - Where does output first diverge?