Arsenal Image Mounter: disk images presented to Windows as real SCSI disks

Why an image mounted as a folder is not enough

Windows has several ways to look inside a disk image, and only one of them behaves like the disk an investigator or administrator expects. Opening an image as a folder gives you files. Attaching it as a disk gives you a device with partitions, a volume, a filesystem you can mount by letter and, in practice, the disk-level features Windows exposes to disk tools.

Arsenal Image Mounter takes the second route. Its description is that it mounts the contents of disk images as complete disks in Microsoft Windows. The mechanism is a virtual SCSI adapter implemented as a Storport miniport driver, and the result, as the project puts it, is that as far as Windows is concerned the contents of a mounted image are real SCSI disks.

That distinction is the whole value proposition. Disk Manager integration means the image shows up in the same place a physical drive would. Access to Volume Shadow Copies means the mounted disk can be snapshotted like any other volume, which is what makes it usable in imaging and backup workflows rather than only for file extraction.

The audience is Windows users who work with disk images professionally, and developers who want to build that capability into their own tools through the exposed APIs. The project describes full functionality as available through a monthly subscription, with a reduced Free Mode when no licence is present, which tells you how it is positioned in the market.

The Storport miniport driver is the core of the design

Almost every design decision follows from the driver choice. A Storport miniport driver is a specific Windows kernel extension point, and building one is a heavier commitment than using a filesystem filter or a user mode service.

The payoff is that Windows treats the mounted image through the normal storage stack. When a disk shows up as a SCSI disk, the things that are hard to emulate elsewhere start working: partitions are visible, volumes can be mounted, and disk-level tooling such as Disk Manager treats it as hardware. The same mechanism is what exposes Volume Shadow Copy support for the mounted contents.

The cost is operational rather than conceptual. A kernel driver has to be installed on the machine and, on a secured Windows configuration, has to pass the operating system's driver signing requirements before it will load. The repository reflects that cost directly: there is a DriverSetup directory alongside the source trees, and the driver is described as unique to this project rather than a generic component.

For an integrator, the practical consequence is that the value of the tool is concentrated in the parts that require the driver. A tool that only needs to read files out of an image does not need any of this, and paying the driver installation cost for that would be the wrong trade.

What the repository actually contains

The top-level layout shows a project that ships a driver, an application and a library at once. There are three parallel application areas, Command line applications, Graphical applications and MountTool, plus an API directory that exposes the functionality to other software.

The source is split by layer rather than by feature. Managed Source and Unmanaged Source sit side by side, which matches the split between C# code and the native code the driver and low level access need. The primary language of the repository is C#, and the managed tree is the natural entry point for anyone reading the code first.

Two more entries deserve attention. libewf is a bundled library directory, and Third-party-dependencies.txt alongside a Third-Party-Licenses directory records what is vendored and under which terms. For a tool that ships a kernel driver and links image parsing code, knowing exactly what is in the tree matters, and the presence of an explicit dependency inventory is a good sign on that front.

The documentation is equally concrete. There is a Directory_structure.md that describes the layout, a How-to-build.md for building from source, and News.md for release history. The project also hosts a local copy of the AGPL v3 text as agpl-3.0.html, next to the LICENSE.md file, which is consistent with the licensing model described below.

Building and running from the repository

The visible documentation does not list the individual build commands, so there is nothing to copy into a shell here. Building guidance lives in the How-to-build.md file at the repository root, and the source tree is split into managed and unmanaged parts with a separate driver setup path, so a build is expected to involve more than one toolchain and a driver installation step.

For end users, the route is different from the source route. The front page directs people to the product page at ArsenalRecon.com/weapons/image-mounter for details and downloads, and states that full functionality is available as part of a monthly subscription. Running without a licence puts the tool into Free Mode with core functionality.

For developers, there are three ways in, and the difference matters when you plan an integration. The Graphical applications give you an interactive tool for mounting and inspecting images by hand. The Command line applications give you the same operations in a form you can script, which is what an imaging pipeline or a triage script needs. The API directory exposes the source code and APIs themselves, so the capability can be embedded in another product rather than driven from outside.

That API is the interesting one for adoption, because it is the point where the driver and the mounting logic stop being a separate application and become a component of yours. The licensing terms for that path are different from the terms for the end user application, which is the subject of the next section.

Dual licensing: AGPL for open source, negotiation for commercial use

The licensing model is unusual enough that it deserves careful reading rather than a summary.

The source code and APIs are made available under the terms of the Affero General Public License v3. They may be used in projects licensed so as to be compatible with AGPL v3, royalty-free. Projects that are not AGPL v3 compatible and want to use the source code or APIs must contact the vendor to obtain alternative licensing. The project describes this as a deliberate dual-licence arrangement: royalty-free use by open source projects, with commercial projects providing financial support.

The stated reason is that commercial licensing revenue sustains ongoing development, and the project explicitly asks to be told about commercial projects using the source and APIs without a proper licence.

There is a second licensing layer for contributors. Contributions require signing the Arsenal Contributor Agreement, and the agreement gives Arsenal and the contributor joint copyright interests in the source code. That differs from the usual inbound=outbound assignment and it changes who owns what you contribute, so it belongs in the review checklist of any company considering a pull request rather than in a footnote.

This is not legal advice, and the practical reading is narrow: check the AGPL compatibility of your own project first, and if it is unclear, the contact page is the route the project itself points to.

Where this approach fits and where it does not

The obvious boundary is the platform. The tool is Windows specific, it relies on a Windows kernel driver interface, and it needs to install that driver. Running the same images on Linux or macOS means a different tool entirely.

The second boundary is the licence model, and it cuts in a way that surprises people. The source is open, so a team can build and study it, but a proprietary product that wants to embed the mounting capability is not covered by the open licence and needs a paid arrangement. The subscription mentioned for end users is separate from that commercial source licence, and the project treats the two as different products.

The third is release engineering. The repository has no GitHub releases at all, so there is no tagged artefact history to pin against, and the last push was on 2026-09-04 with News.md carrying the history instead. The repository is not archived, so work is still landing, but a consumer who wants versioned binaries is relying on the vendor's distribution rather than on GitHub.

Against that, the alternative approaches are worth naming precisely. Extracting an image with a general archive tool avoids the driver entirely and is the right answer when you only need files. Driving the command line applications gets you scripted mounting with the same driver-backed semantics. Embedding the API gets you the whole capability inside your own product, subject to the licence terms above. The choice is not about capability so much as about how much of the stack you want to own.

Editorial conclusion

Adopt Arsenal Image Mounter if your Windows workflow needs a forensic image attached as a full disk rather than opened as an archive, and if your project is licensed under AGPL v3 or is willing to arrange a commercial licence. Do not adopt it if you need a non-Windows host, if you need a stable tagged release history, since the repository has no GitHub releases, or if your organisation cannot run an installed kernel driver. Before you build anything against it, read LICENSE.md and the Arsenal Contributor Agreement, because contributions give Arsenal and the contributor joint copyright interests, and confirm with the vendor that your intended use falls under the royalty-free path or needs a negotiated licence.

Frequently asked questions

Official sources

1. ArsenalRecon/Arsenal-Image-Mounter on GitHub
2. Issues
3. README