dirble scans web directories by guessing words and reading status codes

A path guesser that reads the status code as a verdict

Dirble is a website directory scanning tool for Windows and Linux, designed to be fast to run and easy to use. The mechanism is a wordlist plus a set of transformations, and the readme explains it in terms of jobs and wordlists. A job is any task which can be run independently of other tasks, for example requesting a series of URLs. A wordlist is a list of words with a defined transformation, for example the list of admin, config and shop together with the transformation append .php forms a single wordlist instance. What makes it a scanner rather than a curl loop is the classification step. Dirble detects files based on the response code sent by the server, and the behaviour is loosely categorised by response code type. A 200 means the path exists and is valid. A 301 or 302 is a redirection, and the code, size and Location header are reported. A 404 is not found, and by default these responses are not reported at all. Every other response code is reported in the Dirble format of plus the url with the code and size in brackets. The default of hiding 404s is what keeps the output readable, and the negative case is where the tool's limits start.

A directory is a 301 with and without a slash

The directory detection rule is precise and worth knowing exactly, because it is the part most people get wrong when they write their own scanner. A path is classified as a directory if a request to the url with no trailing slash returns a 301 or 302 redirection to the url with a trailing slash. Such a path is reported with a D prefix and, if recursion is enabled, added to the scan queue. The readme draws attention to a subtlety that matters in practice. This method is not dependent on the redirection target existing or being accessible, so a separate request will be made to determine the response code and size of the directory. In other words, Dirble does not trust the redirect to be a reliable indicator that the directory is there, and it checks again. Listable directories are detected separately, by inspecting the content of the url with a trailing slash. If it returns a 200 and the body contains either parent directory, up to or directory listing for, case insensitively, then it is likely to be a listable directory. Those get an L prefix in the output. With --scrape-listable enabled, URLs are parsed out of the listing, ignoring sorting links or out of scope links, and added to the scan queue if they have a trailing slash.

Wordlist splitting is how the threading stays busy

The concurrency model is the most interesting piece of design in the project, and it is not simply a thread pool. To improve performance further, the concept of wordlist splitting is introduced, which is the process by which a single wordlist instance is broken up into multiple jobs, each responsible for a portion of the list. The number of interleaved portions that each wordlist is split into is defined by the --wordlist-split option, with a default of 3. Whenever a directory is detected and recursion is enabled, new jobs are created for each split wordlist with transformation and added to a central job queue. The maximum number of concurrent tasks is set by the --max-threads parameter, and Dirble starts jobs as they are added to the queue up to that limit. When a job completes, meaning a split wordlist is exhausted, the next job is taken from the queue. The point of splitting rather than merely adding threads is that a discovered directory produces new work immediately, and the split lets several workers pick up the same new directory at once.

Running it needs a wordlist next to the binary

There are several ways to get dirble running, and the simplest is to download one of the precompiled binaries for Linux, Windows or Mac, or to compile the source using Cargo and then run it from a terminal. The default wordlist Dirble uses is dirble_wordlist.txt in the same directory as the executable, which is a detail that catches people out, since the tool looks for that file next to the binary rather than somewhere in your home directory. There is an install in BlackArch using sudo pacman -S dirble, and there is a docker image which can be run as docker run --rm -t isona/dirble with the dirble arguments following. The help text is available through dirble --help or on the project wiki. The typical invocations show the shape of the interface. Against a site with the default wordlist from the current directory it takes an address. A different wordlist with .php and .html extensions is a wordlist flag and an extension flag. Scraping listable directories is --scrape-listable. A list of extensions and a list of hosts use the X and U flags, and multiple hosts to scan can be given on the command line with repeated u flags. The readme also shows a run in Gobuster's default style, with threading, recursion disabled and ten threads scanning the main directory, using --max-threads 10 --wordlist-split 10 with the recursion flag negated.

Building from source, and cross compiling four targets

Building locally needs cargo installed and then a release build, cargo build --release, and running make will build the binary in release mode by doing the same thing internally. For cross compilation the readme points at a makefile that handles 32 and 64 bit Linux and Windows targets, where make release builds all four using cross, which depends on having cross and docker installed and can be installed with cargo install cross. The Makefile shows what those four targets are, x86_64-unknown-linux-gnu, i686-unknown-linux-gnu, x86_64-pc-windows-gnu and i686-pc-windows-gnu, and the release target assembles per-platform zip archives containing the binary, the wordlist and the extensions directory. There is also a combined mac target for 32 and 64 bit systems, with the note that it currently only supports being run on a mac. The Cargo manifest explains the rest of the shape. The package is named dirble at version 1.4.2 with edition 2024, the author is listed as Izzy Whistlecroft of NCC Group, and the licence is GPL-3-or-later. The dependencies are a manageable list for a network tool, with curl for HTTP, clap for the command line, select and chardet for parsing, serde with serde_json for output, simple_xml_serialize for XML, simplelog for logging and ctrlc for interrupt handling. The Dockerfile is a two stage build, and the runtime stage copies the binary, the wordlist and the extensions directory out of the build stage:

FROM rust:latest as cargo-build

ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update
RUN apt-get install libssl-dev -y

WORKDIR /usr/src/dirble
COPY . .

RUN cargo build --release

The final image is debian:stretch with the libcurl4-openssl-dev runtime library installed, and the entrypoint is the dirble binary itself.

Where the status code approach fails

The limitation is structural rather than a missing feature, and it is worth being blunt about it. Dirble infers existence from the response code and, for the not found case, from the response length. A server that answers 200 for every path, which is what a catch-all handler or a single page application front end often does, produces a list of false positives, and the tool's own feature list includes a blacklisting and whitelisting of status codes and the ability to exclude ranges of response lengths from output as the mitigation. A site behind a web application firewall that returns a uniform 403 or a uniform error page has the same problem, and the exclude range option exists for that case too. The second limitation is scope. Dirble enumerates paths and scrapes listable directories. It does not do anything with what it finds beyond that, so it is a reconnaissance component of a wider assessment rather than a vulnerability scanner. The alternative approaches differ in kind. A larger web scanner in a scripting language can extend beyond path guessing into parameter fuzzing and content checks, at the cost of speed and a much larger dependency set. A search engine's own site operator tools, or a web server's access log analysis, answer the same question of what paths exist without sending a single request, and are the right choice when you have log access. Dirble is for the case where you have nothing but the address.

Editorial conclusion

dirble is worth adopting for an authorised web assessment where you need to know which paths exist on a host and want the results in a machine readable form, since the status code classification and the listable directory scraping are both implemented rather than left to interpretation. It is the wrong tool for a site behind a catch-all handler that answers 200 for every path, where the status code approach produces noise rather than signal, and it is the wrong tool for anything beyond simple path enumeration. Verify first that the server returns distinct codes for real and missing paths, that the response length heuristic is not fooled by a uniform error page, and that your rate of requests stays within what the host owner expects. The last push was on 2026-04-14 and the newest tagged release is v1.4.2 from 2019-07-09.

Frequently asked questions

Official sources

1. Isona/dirble on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases