In the disaster recovery space, “Instant Mount” is a standard feature. The ability to take a remote backup stream and instantly expose it as a local drive letter on a Windows machine is critical for bringing a business back online and minimizing RTO (Recovery Time Objective).
Most backup vendors solve this by bundling third-party virtual disk drivers — like ImDisk or WNBD — into their agents. These are kernel-mode drivers (sys files) that hook deeply into the Windows storage stack.
At StateWarden, our architecture is governed by a strict mandate: Zero External Dependencies. We refuse to pollute the host kernel with third-party drivers. Installing external kernel modules introduces significant security risks, deployment friction, and potential system instability (BSODs).
More importantly, StateWarden is a 100% zero-knowledge system. Backups are heavily deduplicated and encrypted (AES-256-GCM) at the block level before they ever leave the client. The decryption keys never leave the host machine. If we want to instantly mount a 2TB remote backup, we cannot download it and decrypt it to a temporary file — that defeats the purpose of zero-knowledge and destroys performance.
The plaintext must exist only in memory, exactly at the moment the operating system requests a specific sector.
To achieve this without custom drivers, we chose the hardest, but architecturally purest path: We built a fully compliant iSCSI Target Server from scratch, written entirely in Rust, embedded directly within the StateWarden Agent.
Windows has a native, built-in iSCSI Initiator. By speaking its language over a local loopback interface, we could stream blocks from our cloud storage, decrypt them in RAM on the fly, and serve them to the Windows storage stack natively.
Technically, Windows server distributions have their own iSCSI server, but our product is aimed at everyone, so we couldn’t put desktop support on the back burner.
Here is what it takes to build a block storage target from scratch and tame the notoriously unforgiving Windows storage stack.
Navigating Windows iSCSI strictness
The iSCSI protocol (RFC 3720) encapsulates complex SCSI commands inside Protocol Data Units (PDUs) over TCP. The Windows iSCSI Initiator is exceptionally good at its job, but it is incredibly strict. A single misplaced byte or a slight deviation from the state machine results in a silent failure: the initiator simply drops the TCP connection (os error 10054) with zero explanation.
During our initial implementation, the Windows initiator would successfully complete the complex login handshake and discover our virtual target. But the moment it tried to query the disk, the connection would violently die.
Packet tracing revealed the exact moment of failure: Windows was sending a REPORT LUNS (0xA0) command. Our Rust server processed it perfectly and attached the payload data directly to the SCSI Response PDU (0x21).
According to the RFC, a SCSI Response PDU must only contain status codes (like SUCCESS or CHECK CONDITION). It cannot carry read data. Any actual data must be sent via a dedicated SCSI Data-In PDU (0x25). The Windows initiator saw payload bytes attached to a status frame, classified it as a fatal protocol corruption, and instantly fired a TCP RST (Reset).
Refactoring our packet builder to separate the data stream and correctly set the F (Final) and S (Status present) flags on the Data-In frame stabilized the connection.
Handling PDU fragmentation
Even with the protocol compliant, deep filesystem scans caused intermittent connection drops. The breakthrough came when analyzing the iSCSI login parameters.
During the handshake, Windows negotiates a MaxRecvDataSegmentLength (typically 256 KB). However, when reading large Master File Table (MFT) structures, Windows issues SCSI reads for 512 KB or more. Our initial implementation attempted to send the entire 512 KB payload in a single Data-In PDU. Windows saw the oversized packet, realized it exceeded the negotiated limits, and instantly tore down the socket.
We had to rewrite our Data-In streaming logic to automatically fragment massive SCSI read requests into a sequence of smaller, compliant PDUs, chunked precisely to the initiator's negotiated limits, performing the decryption and deduplication mapping on the fly across multiple packets.
Faking NTFS geometry in memory
With the network protocol solid, the Windows Initiator finally connected smoothly. A new disk appeared in Windows Disk Management. But Windows Explorer refused to open it, labeling the filesystem as “RAW”.
Our target was serving the exact decrypted bytes of the backed-up NTFS partition. Why couldn’t Windows read it?
The issue lay in the physical geometry of the original backup. When the StateWarden Agent backs up a live Windows drive, it queries the FSCTL_GET_NTFS_VOLUME_DATA API to determine the exact size of the filesystem.
However, this Windows API reports the volume size excluding the final sector. That final sector contains the Backup Volume Boot Record (VBR). A live running Windows system doesn’t mind this truncation, but the ntfs.sys driver validating a newly mounted disk absolutely requires the Main VBR (at LBA 0) and the Backup VBR (at the end of the disk) to match perfectly. Because our backup stream lacked that final sector, Windows rejected the entire filesystem as corrupt.
We engineered a real-time fix in our streaming backend. Our MbrWrapperBackend now caches the Main VBR on the fly, calculates the true physical boundaries of the partition, and dynamically injects a synthetic Backup VBR at the exact tail end of the stream in memory. We effectively pad the geometry perfectly before presenting it to the iSCSI initiator.
The architectural payoff
With the exact NTFS geometry restored and network payloads perfectly fragmented, the virtual disk mounts instantly. The “RAW” error is gone, and gigabytes of heavily encrypted, deduplicated cloud data are immediately browsable in Windows Explorer.
Every time you double-click a file, the StateWarden Agent fetches the exact deduplicated chunks from the remote storage node, decrypts them in RAM using the locally held keys, and feeds them through the loopback iSCSI connection to the OS.
Building a block storage target from scratch is painful, but the architectural payoff is massive. We deliver enterprise-grade “Instant Mount” bare-metal capabilities natively, with absolute zero-knowledge security, and without polluting the user’s kernel with third-party drivers. We don’t take shortcuts when it comes to the integrity of the host system.
We fully expect legacy vendors to attempt to reverse-engineer and replicate this driverless architecture after reading this. They are welcome to try. But a native iSCSI implementation is merely a single component of the StateWarden engine. It is just one of dozens of proprietary architectural decisions — from our PrimeCrypt onion-cryptography to our Vigil active-defense heuristics — that fundamentally outclass current market offerings. We are not just building a backup tool; we are engineering the new standard for data resilience.
Why we built a native Windows iSCSI target in Rust for zero-knowledge restores was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
