Digler for Forensic Disk Analysis and File Recovery

Digler’s forensic recovery scope

Digler addresses a specific problem: finding deleted or otherwise recoverable data when a disk image or raw device does not provide an ordinary filesystem view. The target user is someone who already has forensic storage data and needs to inspect it, identify file-like content, and decide which files to extract. The README positions Digler for both professionals and less specialized users, but the operational workflow is clearly technical. It expects a target such as an image file or a device path, and its reporting format is Digital Forensics XML, or DFXML.

The project supports `.dd` and `.img` disk images as examples and can access physical disks directly. The documentation also says that analysis is file system agnostic, including cases involving NTFS, FAT32, and ext4, and that recovery can remain possible when metadata is lost. That claim concerns the scan process and should not be read as a guarantee that every file can be reconstructed. File carving depends on recognizing format signatures and correctly decoding the data that follows them.

Digler separates analysis from extraction through its “scan first, recover later” workflow. A scan produces a detailed report and execution log by default. Recovery can then use that report, which is useful when the analyst wants to inspect findings before copying data. The desktop application is built with Wails, while the CLI is based on Cobra. The repository therefore contains a Go command-line interface plus a separate frontend under `frontend/`.

How Digler scans and represents recovered content

The documented scan entry point takes an image or device as its argument. According to the README, Digler scans the target source, identifies supported file content, and records findings in DFXML. The report is the handoff between scanning and later recovery. The execution log provides an additional record of what happened during analysis, although the README does not define its exact schema or retention behavior.

Digler also supports recovery during scanning through an optional dump directory. The README’s example for that option is malformed, because it shows the `--dump` flag without the `digler scan` command, so the precise invocation cannot be copied reliably from the available documentation. The safer documented path is to scan first, review the generated report, and then invoke the recovery command.

For Linux users, Digler can mount scan results as a FUSE filesystem. The mounted view allows recovered files to be browsed and accessed from the report without copying everything immediately. This feature is explicitly Linux-only. On other platforms, the documented alternatives are the CLI recovery command or the desktop application, but the README does not describe a platform-specific browsing workflow.

The report is not just a human-readable log. The documentation says it can be used by the recovery command to recover specific files. That design makes the report part of the data pipeline: scan output identifies candidates, and recovery reads the source again using the report. This can be preferable to extracting files blindly, but it also means that the source image or device and the report must remain available and must correspond to each other.

Building Digler and checking supported formats

The README gives two installation routes. Precompiled binaries are available for Linux, macOS, and Windows on the project’s Releases page. For a source build, clone the repository, enter its directory, and invoke the Makefile target. The repository specifies Go 1.23.3 in `go.mod`, so the local Go toolchain should match that requirement before building.

git clone https://github.com/ostafen/digler.git
cd digler
make build

The `Makefile` builds platform binaries under `bin`. Its documented target platforms are `linux/amd64`, `linux/arm64`, `darwin/amd64`, `darwin/arm64`, and `windows/amd64`. The target builds use Go build commands and embed version, commit, and build-time metadata. The README does not document signing, checksum verification, or a package-manager installation, so those aspects remain unconfirmed.

The first practical check after installation is the format listing. The README says this command displays the supported file formats, including plugins when the plugin directory is supplied.

digler formats

The command output is the appropriate first place to verify whether the file types in a case are supported. The README names documents, images, audio, and archives as examples, but it does not publish a complete static list. For that reason, a user should not infer coverage of a specific document, media, archive, or proprietary format merely from the general feature description.

Scanning, mounting, and recovering a disk image

Start with an image copied into an accessible location. The following is the exact scan form documented by the README.

digler scan dfrws-2006-challenge.raw

The command should produce the default DFXML report and execution log. The README does not specify their default filenames, so the user should observe the files created in the working directory rather than assume particular names.

For a Linux-only interactive inspection, the report can be mounted. Replace the image, report, and mountpoint with paths that exist for the case.

digler mount dfrws-2006-challenge.raw report.xml --mountpoint /mnt/recover

This is the FUSE-based browsing path. The mountpoint must be available, and the Linux system must support the required FUSE integration. The README does not state whether unmounting is automated, whether reports remain writable, or how errors are handled.

When copying selected recovered files, use the report-based recovery command.

digler recover dfrws-2006-challenge.raw report.xml --dir ./recover

The destination directory is where Digler is instructed to place recovered files. The documentation does not describe collision handling, partial recovery behavior, checksum verification, or whether recovered output preserves original names. Those points should be checked in the actual command output and test images before relying on the result in an evidence workflow.

Extending Digler with file scanner plugins

Digler exposes a plugin-oriented extension point for new or specialized file formats. The documented interface is `FileScanner`, with methods for an extension, description, byte signatures, and scanning through a `Reader`. A plugin therefore needs both identification metadata, such as `Ext`, `Description`, and `Signatures`, and a `ScanFile` implementation that returns a `ScanResult` or an error.

The README instructs developers to place the source file in `plugins/` and compile plugins with:

make plugins

The documentation states that the resulting `.so` files are placed in `bin/plugins/`. Plugin discovery can then be checked with:

digler formats --plugins ./bin/plugins

The same plugin directory is supplied during scanning:

digler scan <image_or_device> --plugins ./bin/plugins

This architecture is useful when a format needs special validation or carving logic, but it raises the technical cost of adopting a plugin. The implementation must agree with Digler’s `Reader` and `ScanResult` contracts, and the scanner must correctly interpret the target format. The README does not describe plugin versioning, ABI compatibility, loading order, sandboxing, or behavior when a plugin fails at runtime. The project is therefore easier to extend by a Go developer familiar with its interfaces than by a user expecting a stable public plugin API.

Digler’s limits and comparison with filesystem recovery tools

The clearest limitation is project maturity. The README labels Digler as being in early development and points to `v0.1.0`, warning that bugs may exist. The repository is not archived, and its last push was on 2026-08-14, which indicates recent development activity, but release history is still limited to `v0.0.1` and `v0.1.0`. Maintenance history does not remove the need to validate outputs.

Digler differs from ordinary filesystem recovery tools in its stated approach. A filesystem-oriented tool generally relies on surviving filesystem metadata and structures, whereas Digler emphasizes file-system-agnostic scanning and format carving. That can help when metadata is damaged or absent, but it also means that detection quality depends on file signatures and format-specific decoding. The project does not claim to reconstruct every possible deleted file.

Another practical boundary is the Linux-only FUSE mount. A Windows or macOS user cannot assume that the documented `digler mount` workflow is available there. The README does say precompiled binaries exist for all three operating systems, but binary availability is not the same as identical features.

The MIT license permits reuse and modification under its terms, subject to the license text. That is an important implication for organizations embedding Digler or distributing modified binaries, although this review does not provide legal advice. The README also links to DFRWS, Digital Corpora, and NIST CFReDS datasets. Those are appropriate test inputs, but using a public forensic image does not establish that Digler will handle a particular production image.

Editorial conclusion

Digler fits practitioners who need command-line disk carving, DFXML reporting, or plugin-based scanner development and can work within an early-stage project. It is less suitable for users who need a fully documented recovery workflow, a desktop-first deployment, or FUSE mounting on non-Linux systems. Verify the binary format, target image access, supported formats, and report contents before using Digler for a real recovery case.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. ostafen/digler on GitHub
4. README
5. Releases