-
-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
Provisioning a reverse-engineering environment and then driving it. The installer builds the toolchain; the analyzer runs a target through a type-appropriate sequence of analysis stages and produces structured findings plus a report.
It is aimed at malware analysis, incident response, vulnerability research, and software assurance work where you need depth across many tools without assembling and invoking each one by hand.
Nothing stops you from running Ghidra, radare2, capa, and the rest individually. RE-Toolkit addresses what happens after that becomes routine: provisioning is reproducible, coverage is broad by default rather than dependent on remembering which tool applies, and results are parsed into a single structured artifact instead of scattered across a dozen output formats.
The part that is genuinely hard to reproduce by hand is synthesis. Findings from many tools are correlated into one explainable verdict, with the evidence for each contributing signal recorded.
No. It targets Debian and Kali Linux and depends on Linux package management and tooling throughout.
It analyzes Windows and macOS binaries perfectly well. Windows PE, .NET, and Mach-O are all supported target types. The analysis host must be Linux.
Install it in a disposable virtual machine. The installer performs a system-wide install that adds a package repository, builds software from source, and places tools on the system path. Beyond that, analyzing hostile files on a machine you depend on is not a good practice regardless of the tooling.
MIT for RE-Toolkit's own code. The tools it installs and invokes each carry their own licenses, which the MIT license here does not cover. Review those before redistributing anything.
Long enough that you should not wait on it. Ghidra is a large download and several components compile from source. The exact time depends on network speed and host performance.
Usually because they are not failures. Some tools are unavailable through apt
on some distributions and are recovered by source builds in a later layer. Wait
for the post-LAYER-2H summary, which separates recovered packages from genuinely
unresolved ones.
Yes, and it is the intended way to repair a partial install. It is idempotent:
existing components are detected and skipped. Use --force when you need to
rebuild something that is already installed.
sudo ./install-retoolkit.sh --verifyThis produces a PASS/FAIL table for every tool without changing anything. Worth running after any install, because an installer can complete without obvious error while leaving specific tools unusable.
Layer 6 was renumbered to Layer 12 and Layer 7 was reserved but never used. The gap is preserved deliberately, since renumbering would invalidate every log file and document that refers to a layer by number.
No, and this is deliberate. The installer adds distribution packages, a third-party repository, and source-built software, and no script can reliably reverse all of that. Discard the virtual machine instead, which is why installing into a disposable VM is the documented practice. Installation shows how to remove the RE-Toolkit-specific parts if you need to.
No. Type detection classifies the target and the dispatcher selects the applicable stages. An APK, a .NET assembly, and an ELF binary are all handled by the same command with no extra options.
Because 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, since each consumes upstream results. This is correct behavior and is explained in Architecture and Design.
Yes, and directories are recursed fully by default. Use --include-ext or
--exclude-ext to filter during the walk, --max-depth to limit recursion, and
--preserve-tree to mirror the input layout in the output.
It was probably already analyzed. Targets with existing output for their recorded
hash are skipped, which makes re-running against a large tree cheap. Use
--overwrite to force reanalysis.
--no-ghidra has the largest effect, since Ghidra is usually the slowest stage.
Then -j 4 for batches, extension filtering for large trees, and a lower
--tool-timeout for triage. Avoid --deep-analysis unless you need it.
No. Each target is copied into a per-run sandbox and every stage operates on the copy. After the run, the original's SHA-256 is re-verified to prove it was not modified. If that check ever fails, it is a security bug worth reporting.
analyze-binaries.sh -t sample.exe -o ./out --yara-rules ~/rules/custom.yarSet YARA_RULES in your shell profile to make it persistent. Point at a
deduplicated master file rather than a directory, since rule identifiers must be
unique across the whole set.
Open index.html for a run, or _report.html for one target. For automation,
read _summary.json, which is the authoritative artifact. The report renders
that JSON and is never independent of it.
It is the sum of weighted signals, mapped to a band: critical at 100 and above, high from 60, medium from 30, low from 10, informational below that.
Treat it as a triage aid rather than a verdict on intent. A legitimate packed commercial application and packed malware can score similarly, because the observable properties overlap. The evidence list is there so you can see what drove the number.
Not necessarily, and this distinction matters. A stage that did not run produces no findings, which is not the same as a stage that ran and found nothing. Check the tool coverage panel in the report, which distinguishes ran, skipped, timed out, and failed.
Because indicator extraction reads output other stages produced, which contains tool self-reports and version strings that resemble indicators. Indicators are classified three ways: behavioral, infrastructure, and dropped noise. The report shows behavioral first and tags infrastructure separately. Genuine noise reaching the behavioral set is a classifier bug worth reporting.
Yes. Reports and visualizations are entirely self-contained: inline SVG, inline styling, no content delivery network references, and no JavaScript libraries fetched at view time. They render identically on an isolated network and generate no outbound traffic when opened.
The report is safe to open, and its content is not trusted. Everything under the output tree came from a hostile binary: extracted strings, carved files, and resources are all attacker-controlled. Do not execute anything found there, and be careful opening extracted documents in applications that process active content.
Not by default. Static analysis never executes the target. Dynamic analysis is
opt-in via --dynamic, and even then only Tier 1 runs unless you pass
--allow-real-execution. Tier 1 emulates rather than executes, so nothing
reaches the host kernel.
Because the difference between emulation and execution is categorical rather than
incremental. --allow-real-execution is an explicit consent gate and cannot be
set implicitly by any other option.
No, by design. Dynamic stages cross-reference the strings, imports, signatures, and indicators that static analysis produces. Running dynamic alone would make the dynamic results themselves less useful.
Possibly, but there are other explanations that are not equivalent: it may have
detected the analysis environment, failed to run, or waited longer than the
timeout. Check the tier status and error output, and consider extending
--dynamic-timeout. Malware routinely alters behavior when it detects a sandbox.
Start with Tier 1. It carries no execution risk and often answers the question. Escalate only when you need behavior emulation cannot produce, and only inside a disposable VM. See Dynamic Analysis.
Create a file in stages/static/ defining one stage function, wire it into
lib/dispatch.sh, register a skip control in the driver, and consume its output
in the summary stage if it should influence the verdict. Full instructions are in
Development.
The character U+2014 is prohibited across the repository and enforced by a CI
gate. An em-dash inside an installer here-string once broke a release, so the
rule is enforced mechanically rather than by review discipline. Use --, -,
: or ,.
Because the scoring logic lives inside a bash heredoc and cannot be imported. The
test deliberately mirrors it, including the exact band boundaries. Changing a
weight or threshold requires updating the mirror in the same commit, which is
stated in CONTRIBUTING.md and in the test's own header.
In CHANGELOG.md. Source headers describe current behavior only. Embedded
per-release changelogs in source once grew past a thousand lines and pushed the
actual documentation below the point anyone would read it.
Yes. Point the library and stage directories at your checkout:
export RETOOLKIT_LIB_DIR=~/dev/retoolkit/lib
export RETOOLKIT_STAGES_DIR=~/dev/retoolkit/stages/static
~/dev/retoolkit/analyze-binaries.sh -t sample.exe -o ./outYou still need the toolchain installed. Use --skip-source when provisioning so
the installer does not overwrite /opt/retoolkit.
RE-Toolkit 3.7.3 -- MIT License. RE-Toolkit analyzes hostile binaries and, when
explicitly enabled, executes them: run it in a disposable virtual machine. Wiki
pages are kept at parity with the README and CHANGELOG.md in the
repository.
Getting started
Reference
Understanding it
Help
Contributing