Robber scans Windows executables for DLL hijacking opportunities

The search order is the attack surface Robber reads

Windows loads DLLs by searching a fixed set of directories in order: the executable's own directory first, then System32, Windows, then PATH entries. If a DLL is not found in a system directory, an attacker who can write to an earlier directory in that chain can drop a malicious copy and have it loaded instead. Robber is built entirely around that ordering, and the project describes itself as a free, open source tool for finding DLL hijacking opportunities in Windows executables with no third-party dependencies. The intended reader is a Windows security reviewer or a software engineer auditing what happens when a shipped application starts on a machine where an attacker has write access to one directory in the chain. The homepage is https://mojtabatajik.github.io/Robber/, and the licence is GPL-3.0. What you get is a triage tool that narrows a directory tree down to a handful of binaries worth attention, not an exploit generator.

Import table against disk, per executable

The core mechanism is a comparison rather than a signature database. Robber walks a directory tree, checks each executable's import table against what is actually on disk, and reports which ones are worth looking at and why. That means the tool is answering a concrete question per binary: of the DLLs this program asks for, is any of them missing from the system directories but present or creatable in an earlier directory in the search order. The results view goes further than a yes or no. Expanding any executable shows which DLLs are hijackable, what methods those DLLs export, and the full search order with writability flags for each directory, so you can see exactly which directory would have to be writable for the hijack to land. Both standard and delayed imports are scanned, which matters because a program can defer a load and still be hijackable in a way a naive import parse would miss.

Best, Good and Bad ratings come from thresholds you set

Rather than emitting a flat list of hits, Robber grades each executable. The Color Config panel controls the thresholds for Best, Good and Bad ratings. Best, shown in green, means few imported DLLs and a small binary, which the project explains as easy to build a proxy DLL that stubs everything out. Good, in yellow, means moderate complexity. Bad, in red, means lots of imports or a large binary, and it is described as harder to proxy without crashing the app. The logic is a proxying feasibility estimate rather than a severity score, and the thresholds behind the colours are adjustable, which is the right design because the number of exports you are willing to stub depends on the application. Settings and the last scan path are remembered between sessions, so a repeated audit does not start from scratch.

CLI filters narrow a large tree before you read anything

The command line exists for the case where the directory is too big to click through. The invocation takes a required target directory and a list of options:

Robber.exe --path <dir> [options]

The option set covers image architecture, signing status, the rating, and writability:

--path <dir>               Directory to scan (required)
--output <file>            Write to file (.json or .csv). Default: stdout
--image-type any|x86|x64
--sign any|signed
--rate any|best|good|bad
--write-perm               Only show results in writable directories
--best-dll-count <n>       (default: 2)
--best-exe-size <n>        KB threshold (default: 10240)
--good-dll-count <n>       (default: 5)
--good-exe-size <n>        KB threshold (default: 51200)
--help

The rating thresholds are expressed as a DLL count and a file size in kilobytes, with defaults of two DLLs and 10240 KB for Best, and five DLLs and 51200 KB for Good. The write-perm switch is the one to reach for first in a real audit, since a directory nobody can write to is not a hijacking opportunity in practice.

stdout carries results and stderr carries progress

Output is split by design: progress goes to stderr, results to stdout, which makes it pipe friendly. In practice that means you can post process with jq or redirect to a file without stripping progress output by hand:

Robber.exe --path "C:\Program Files" --rate best --output hits.json
Robber.exe --path "C:\Program Files" | jq '.[].exePath'
Robber.exe --path "C:\Tools" --sign signed --write-perm

The three examples cover the three common shapes: writing a filtered result set to a JSON file, pulling the executable paths out of a JSON array with jq, and asking only for signed binaries that sit in writable directories. The GUI offers the same kind of narrowing through filters on architecture, signing status, severity, or whether the executable's directory is actually writable, and an Export action that saves as JSON or CSV. The two front ends therefore differ in ergonomics rather than in coverage: the GUI is for exploration, the CLI is for repeat runs and for feeding a report pipeline.

System DLLs are excluded, but elevation changes the stakes

Two behaviours reduce the noise you would otherwise have to filter yourself. System DLLs from System32, SysWOW64 and Windows\System are excluded automatically, which the project frames as no false positives from redistributable runtimes such as msvcr120.dll. That single rule removes a large class of results, since most applications import at least one runtime library that ships with the operating system. The second behaviour is a flag rather than a filter: executables that request administrator rights, marked by requireAdministrator or highestAvailable, are flagged, with the reason given plainly. A hijack on a process that runs as administrator is a privilege escalation and not just code execution, so the severity of a finding depends on how the target binary is launched. That distinction is the difference between a low priority note and a serious finding, and the tool surfaces it rather than leaving it to the reader to infer from the manifest.

Building from source needs Delphi XE2 and nothing else

The tool is written in Pascal and shipped as a Windows executable, with a GUI and a command line in the same binary. Building it is described in a single sentence: Delphi XE2 or later, open Robber\Robber.dproj, build, and nothing else is needed. The absence of third-party dependencies means the project does not drag in a package manager step, a runtime redistributable or a separate PDF or JSON library, which makes it simple to build in a sealed build environment and simple to copy to a reviewer's laptop. The repository layout is small, with the Robber source directory, a Resources folder and a Jekyll configuration file at the top level. On maintenance, the release history jumps from version 1.7 in February 2020 to version 2.0 on 2026-04-29, and the last push was on 2026-07-08. The large gap between 1.7 and 2.0 means the older documentation you may find online describes a different tool.

Editorial conclusion

Robber fits security reviewers who need a shortlist of executables worth auditing for DLL hijacking on Windows, especially where binaries ship into writable directories. It does not fit a Linux or macOS pipeline, and it does not produce a working proof of concept, so the proxy DLL still has to be built and tested by hand. Verify first that Robber.exe --path on a copy of the target directory completes cleanly, that the Best and Good thresholds in the Color Config panel match your definition of a feasible proxy, and that the GPL-3.0 licence in the LICENSE file fits how the tool is distributed inside your organisation.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. MojtabaTajik/Robber on GitHub
3. Project website
4. README
5. Releases