Home
RE-Toolkit is a reverse-engineering workstation provisioner and binary-analysis
pipeline for Debian and Kali Linux. install-retoolkit.sh provisions the
toolchain; analyze-binaries.sh drives it, running a target through a
type-appropriate sequence of analysis stages and producing structured JSON plus
a self-contained HTML report.
This wiki is the reference documentation. The README is the short introduction, and CHANGELOG.md holds the release history.
Current version: 3.7.3
| If you want to | Read |
|---|---|
| Install RE-Toolkit | Installation |
| Analyze your first binary | Usage |
| Understand how it works | Architecture and Design |
| Know what a stage does | Stage Reference |
| Interpret the output | Output and Reports |
| Tune behavior | Configuration |
| Run dynamic analysis safely | Dynamic Analysis |
| Understand the threat model | Security Model |
| Fix something that broke | Troubleshooting |
| Contribute code | Development |
- Installation covers requirements, the layered install model, opt-in components, verifying an install, and recovering from a partial one.
- Usage documents every command-line option with worked examples, from a single binary to a batch run.
- Architecture and Design describes the component model, run lifecycle, dispatch model, tool execution model, scoring model, and the design decisions behind them, with diagrams.
- Stage Reference documents all 46 analysis stages: what each produces, how to disable it, and which tools it invokes.
- Configuration lists environment variables, skip controls, timeouts, and rule paths.
-
Output and Reports explains the output tree, the
_summary.jsonschema, the scoring bands, and how to read a report. - Dynamic Analysis explains the four-tier model and the risk associated with each tier. Read it before enabling anything above Tier 1.
- Security Model covers trust boundaries, the input sandbox, and operational guidance for handling hostile samples.
- Troubleshooting is organized by symptom, with causes and resolutions.
- FAQ answers the questions that come up most often.
- Development explains how to add a stage, integrate a tool, run the test suites, and clear the definition-of-done gates.
Three facts explain most of RE-Toolkit's behavior.
The dispatcher decides, not the stage. A stage never chooses whether to run. Type detection classifies the target, the dispatcher selects the applicable stages, and each stage only decides how to do its job when asked.
_summary.json is the source of truth. Stages write files, but the
deliverable is the structured findings those files feed into the summary. The
HTML report renders that JSON and is never independent of it.
Stage numbers are not execution order. Filenames are numbered by where their output belongs in a directory listing. Summary, visualization, and report carry low numbers but run last, because each consumes upstream results. This is explained in Architecture and Design.
- Commands are shown as an operator would run them, with
sudowhere the installer requires it. - Paths are relative to the repository root unless stated otherwise.
- Per-version history is not repeated here. When behavior changed and the change matters, the current behavior is documented; the history is in the changelog.