DRIFT Linux: project structure, technical choices, and design philosophy
DRIFT Linux was created with a precise goal: to offer a DFIR environment that is more than just a collection of tools bundled into an ISO, but a system built around a coherent logic focused on preservation, operational practicality, and the ability to evolve over time.
The guiding philosophy is clear: in digital forensics and incident response, having “many tools” is not enough. What is needed is an environment built on solid foundations, shaped by deliberate technical choices, and designed to reduce friction, noise, and unwanted behaviour precisely when control and reliability matter most.
That is the direction DRIFT aims to follow.
Built as a system, not as a simple bundle of tools
One of the guiding principles behind the project from the beginning was to avoid the easiest, and often weakest, approach: taking a generic base, adding useful software, and stopping there.
DRIFT Linux was not designed that way.
The goal is to build a DFIR environment with its own technical identity. That means working not only on tool selection, but also on system structure, package management, boot behaviour, connected-device safety, updatability, and the overall consistency of the operational experience.
In other words, the value of the project does not lie only in the programs included, but in the way the entire system has been designed to behave.
A live ISO first
DRIFT Linux was conceived first and foremost as a live ISO. This was not a nostalgic or stylistic choice, but a precise technical decision.
In many forensic and incident response contexts, what is needed is a portable tool, quick to boot, predictable in its behaviour, and able to minimise impact on the environment being observed or acquired. That is why DRIFT was designed as a system to be used immediately, while maintaining a strongly preservation-oriented philosophy.
At the same time, the project was not built only for comfortable or desktop-centric scenarios. There are situations in which a graphical interface is unavailable, cannot be started, or is simply not appropriate. For that reason, DRIFT can also be used through a pure text-based environment, supported by a set of purpose-built TUIs created specifically to facilitate operational tasks even without a traditional GUI.
Why Ubuntu 24.04 LTS was chosen
The starting point for the project is Ubuntu 24.04 LTS, in its most minimal possible form.
This choice was not made to chase the newest release, but for a much more pragmatic reason: providing a base that is as stable, solid, and predictable as possible. In a project that aims to be a DFIR distribution, the priority is not to be the first to adopt every change introduced by the newest available release, but to build something that can be reliable and governable.
For that reason, DRIFT did not start directly from the upcoming Ubuntu 26.04 LTS, since that release will bring many changes that will take time to adapt, integrate, and, where necessary, correct or contain. All of that certainly has its value, but it will inevitably require a maturation phase.
Since the goal of DRIFT Linux is to provide a professional and stable DFIR platform, it made more sense to give up the newest layer of novelty in favour of a more mature base, one capable of providing a robust framework on top of which to build progressively.
An official repository to build better and update later
Another important part of the project is the presence of an official repository.
This choice also draws inspiration from the model adopted by well-known projects such as Kali Linux and ParrotOS, where the repository is not just a distribution channel, but a central element for maintenance, growth, and long-term system coherence.
In DRIFT’s case, the official repository serves a double purpose.
On one side, it improves and simplifies the building phase, making it possible to orchestrate components in a cleaner, hierarchical, and more structured way through packages. On the other side, it provides the clear advantage of delivering updates, improvements, and new features even after the ISO has been released, avoiding the idea of the release as a static and isolated object.
This matters a great deal, because a DFIR system does not age well if every meaningful change requires a brand-new full image. Having a dedicated repository makes it possible to correct, improve, and evolve the project in a far more natural and continuous way.
Not a fully closed full-repository model, but a layered approach on Ubuntu
While DRIFT takes inspiration from models seen in other projects, it does not adopt a 100% full-repository approach.
Its repository is designed to sit on top of Ubuntu’s repositories, not to replace them entirely. This is a deliberate decision.
The idea is to continue relying on a broad, stable, and well-maintained ecosystem such as Ubuntu, using that solidity as a foundation, while building on top of it to add, customise, and govern the project-specific parts. In this way, there is no need to reinvent what is already reliable. Effort and complexity can instead be focused where they actually make sense.
It may sound less dramatic than telling the story of a fully autonomous stack, but from a project perspective it is the more sensible choice. It preserves a strong and well-supported base while allowing DRIFT Linux to build its distinctive layer where it really matters.
Deep customisation, not just configuration
Another relevant aspect is that the work done on DRIFT Linux has not been limited to simple configuration changes.
There has been, and continues to be, significant work in terms of deep system customisation, both during the earliest boot phases and in later operational layers. This affects, on one side, the safety and handling of connected devices and, on the other, the development of internal tools as well as the adaptation of existing software to better fit forensic needs.
This matters because people often underestimate the difference between “assembling an environment” and “shaping a system.” DRIFT aims to belong to the second category.
Handling connected devices from the earliest boot phase
One of the most sensitive areas is the handling of connected devices.
In a DFIR context, it is not enough for a system to be convenient. It must also try to reduce as much as possible the risk of unwanted alterations, especially when it comes into contact with media or environments that may have evidentiary relevance.
For that reason, DRIFT Linux includes a substantial amount of work not only on general configuration, but also on the early behaviour of the system, with specific attention to the safety and management of devices from the very first phase of boot.
The core of this approach lies in the customisation of the system from the very earliest phases of kernel boot, with the aim of providing stronger guarantees regarding the integrity of connected evidence. This led to work not only on device buses such as SATA, USB, and other storage-related channels, but also on additional areas of the underlying hardware that, in a forensic context, cannot be treated as secondary details.
Among these, special attention is also given to the system clock, which in many activities can have concrete evidentiary relevance and therefore must be preserved with particular care.
This fits into the broader philosophy of the project: preserving the context before interacting with it. That principle influences multiple parts of the system and remains one of the defining traits of the distribution.
Radio and wired isolation
Another relevant technical aspect concerns the isolation of connectivity, both wireless and wired.
In some investigative or incident-related scenarios, simply powering on a system and letting it behave in a standard way can generate unwanted events, expose the analyst’s presence, or alter the environment under observation. For that reason, DRIFT Linux was designed to remain as quiet and discreet as possible at boot.
To achieve this, Ethernet, Wi-Fi, and Bluetooth are neutralised from startup, leaving the analyst free to re-enable them later in a deliberate and controlled way, through dedicated interfaces created specifically to simplify that orchestration.
This is a very deliberate design choice: moving control away from the system’s default behaviour and back into the hands of the operator, who in sensitive situations must be able to decide when, how, and whether connectivity should be exposed.
Internal tools and customised software
Alongside the work on the overall system structure, DRIFT Linux also includes the development of internal tools and customisation work on existing software.
This part may be less immediately visible, but it is central to giving the project a real identity. In some cases, the work involves creating dedicated components. In others, it means adapting existing tools so that they behave in a way that is more coherent with a forensic perspective.
The clearest and easiest example to notice is Thunar, which has been customised to be more forensically oriented in the way it handles devices to be mounted. It is a visible detail, but it also reflects the broader DRIFT approach: taking concrete parts of the user experience and aligning them with a specific operational context, instead of simply leaving them in their default state.
Designed to evolve after release
One of the most relevant characteristics of DRIFT Linux is that it was never meant to be an immobile release.
The official repository, the choice of base system, the modular approach to package work, and the customisations developed all belong to a vision that looks beyond the first ISO. The goal is not only to release a working image, but to build a project that can receive updates, refinements, fixes, and new capabilities in an orderly way.
In that sense, DRIFT Linux aims to be not only a distribution, but a platform capable of growing without having to restart from zero at every step.
Future variants and development directions
DRIFT Linux was not conceived as a static object, but as a project meant to expand in multiple forms.
Alongside the current live ISO, there are plans for a future installable box-like variant, with different characteristics but still aligned with the same preservation-oriented philosophy that defines the project.
Additional distribution variants are also planned, including a micro edition designed to be extremely minimalist, especially lightweight, and suitable for more constrained environments or scenarios where maximum essentiality is required.
Likewise, the roadmap also includes versions specifically aimed at the cloud world, targeting environments such as Azure, AWS, Google Cloud, and similar scenarios. This is a natural evolution, because DFIR work no longer involves only physical machines and local media, but increasingly touches distributed environments, hybrid infrastructures, and remote services.
A clear technical direction
Looking at the project as a whole, DRIFT Linux is built around a number of very clear choices:
- a minimal and stable Ubuntu 24.04 LTS base
- a live-first philosophy, with the possibility of operating even in a pure text-based environment
- an official repository for building, maintenance, and post-release updates
- a layered approach on top of Ubuntu repositories rather than full replacement
- extensive technical customisation
- specific attention to preservation-oriented device handling from boot
- early intervention on the system already in the first phases of kernel boot
- attention to sensitive hardware aspects, including the system clock
- Ethernet, Wi-Fi, and Bluetooth isolation from startup
- development of internal tools and adaptation of existing software for forensic use
- planned evolution through multiple variants, including micro, installable box, and cloud-oriented scenarios
Taken individually, these may look like straightforward technical decisions. Taken together, they define a precise design philosophy: building a DFIR system that tries to be concrete, updateable, coherent, and genuinely useful.
Conclusion
DRIFT Linux was therefore conceived as a technical project before being a thematic distribution.
Its structure is based on a combination of pragmatism and customisation: a solid base, an official repository, a post-release evolution model, attention to context preservation, controlled connectivity isolation, the possibility of operating in text mode, and a series of targeted interventions aimed at making the system more coherent with real forensic use.
The result is not meant to be just a toolbox, but an environment built with intention, capable of growing over time and of offering analysts a starting point that is more organised, more controllable, and closer to the real needs of DFIR work.