binary-re-static-analysis
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", "fin
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 428
- Лиценз
- Не е посочен. Проверете в репозитория.
- Последна проверка на записа
- Няма посочена дата
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add aiskillstore/marketplaceСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
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?
# - Does file size match? (logic bug vs truncation)
# - What pattern appears in corruption?
This step often reveals the bug category before any code analysis.
Two-Stage Approach
Stage 1 (Light): Function enumeration, strings, imports - fast, broad coverage Stage 2 (Deep): Targeted decompilation, CFG analysis - slow, focused
Stage 1: Light Analysis (radare2)
Analysis Depth Selection
| Binary Size | Command | Tradeoff |
|---|---|---|
| < 500KB | aaa | Full analysis, may be slow |
| 500KB - 5MB | aa; aac | Functions + all call targets |
| > 5MB | aa + targeted af @addr | Fast, manual depth control |
Session Setup
# Launch r2 with controlled analysis
r2 -q0 -e scr.color=false -e anal.timeout=120 -e anal.maxsize=67108864 binary
# Inside r2 (choose based on binary size):
aa # Basic analysis
aac # Also analyze all call targets (recommended for most binaries)
Critical settings:
anal.timeout=120- Prevent runaway analysisanal.maxsize=67108864- 64MB max function size- Use
aa; aacfor medium binaries,aaaonly for small ones