QuantumVault: A Bootloader-Level Demo of Cold Storage Control

1. Project Motivation and Personal Backstory

QuantumVault isn’t the result of a corporate spec or a VC pitch deck. It started with something far simpler — a university course and a personal regret.

During an x86 assembly course at the University of the Fraser Valley (UFV), taught by Professor Talia Q, I was reintroduced to low-level system design. That meant working with BIOS interrupts, 16-bit memory segmentation, and even boot sector handoffs — things that most developers today will never touch.

At the same time, the cryptocurrency market was heating up again. Bitcoin was back in the news, and with it came a memory: I had lost access to a small BTC wallet years ago due to a failed disk and poor key management. No backup, no recovery, no happy ending.

Those two things came together: Could I build a cold-storage decryption system that runs without any operating system at all? Could I reclaim complete control — from BIOS upward — using only FreeDOS, hand-written C, and a custom-built AES unlocker?

That became the goal. Not to create a commercial wallet, but to build a working, minimal, and transparent cold-storage demo — from the bootloader up.

2. Philosophy: What QuantumVault Is (and Isn’t)

QuantumVault is designed to demonstrate total data control outside of traditional OS environments. It doesn’t rely on Linux, Windows, or even a protected-mode kernel.

This is a dual-environment model:

• Encryption happens on Linux using hardened OpenSSL routines
• Decryption occurs in an air-gapped FreeDOS session, using a C program compiled with DJGPP

The two halves never share RAM or runtime — they only connect via files moved through USB. That physical barrier, plus the simplicity of each component, is the core of the design.

QuantumVault is not meant to replace hardware wallets or enterprise-grade HSMs. It exists to show what’s possible when you strip away everything and go back to the boot sector.

3. System Architecture

The architecture is deliberately minimal but tightly scoped. It includes:

• 🔒 Encryption Module (Linux)
  • AES-256-CBC encryption via OpenSSL (encrypt_file.c)
  • Key derived using PBKDF2-HMAC-SHA256 with 10,000 iterations (generate_key.c)
  • Auto-cleanup of plaintext
  • Command-line workflow for predictability
• 🖥 Decryption Module (FreeDOS)
  • Compiled with DJGPP, runs in 16-bit DOS
  • Reads encrypted blob + IV + salt from USB
  • Prompts for password or accepts a key file
  • Outputs decrypted file to disk or screen
• 📀 SentinelDOS Bootloader
  • stage1.asm loads a minimal stage2 in 16-bit real mode
  • stage2.asm includes password validation and lockout logic
  • Real-mode security checks: memory signatures, vector table inspection, timer hook monitoring

🔗 Data Flow Diagram

[Linux Host]
    ↓
 encrypt_file.c → encrypted_wallet.bin + IV + salt
    ↓
     USB Transfer
    ↓
[FreeDOS Boot]
    ↓
 vault.exe → decrypts using password/key → wallet.dat

No network stack, no modern OS, no runtime dependencies.

4. Why FreeDOS?

FreeDOS is an ideal environment for this project for several reasons:

• ✅ Instant boot: BIOS → FAT16 → autoexec.bat in <2 seconds
• ✅ Stable hardware I/O: Keyboard, screen, file reads
• ✅ No background services: Fully audit-friendly
• ✅ No drivers or kernel: Attack surface is near-zero

Using DOS instead of Linux also makes it easier to run on very old systems, virtual machines, or tightly controlled embedded environments.

FreeDOS enables total air-gap execution — even the idea of “update” or “internet” doesn’t exist.

5. Cryptography Choices and Quantum Resistance

Why AES-256 and not elliptic curves?

Elliptic Curve Cryptography (ECC) is widely used in cryptocurrency wallets (like Bitcoin), but its long-term security is challenged by the future of quantum computing. Shor’s algorithm could theoretically break ECC once sufficiently powerful quantum systems are built.

QuantumVault avoids that altogether:

• Uses AES-256-CBC, symmetric encryption
• With Grover’s algorithm, the effective security is halved to 128 bits
• That’s still strong enough to resist any practical quantum threat

In addition, QuantumVault implements several layers of protection to avoid common attack vectors against symmetric ciphers:

🔹 Salting and Rainbow Table Resistance

To protect against dictionary and rainbow table attacks, the encryption tool generates a unique random salt for each encryption operation. The salt is combined with the user password using PBKDF2-HMAC-SHA256, with 10,000 iterations, to derive the actual encryption key.

This technique ensures that the same password will produce different keys when used with different salts — greatly reducing the risk of precomputed attack success.

🔹 AES Debugging in a DOS Environment

AES decryption inside DOS was not a copy-paste task. In fact, debugging the DJGPP-compiled AES routines consumed a significant portion of the project timeline.

Since DOS doesn’t provide dynamic memory management or OS-level crypto libraries, I had to ensure that:

• All AES operations ran in flat memory
• Key length, IV, and buffer alignment were all correct
• No residual memory leaked plaintext after execution

The decryption process is handled by combined_decrypt.c, which relies on the OpenSSL-compatible implementation in aes.c. The encryption counterpart, located in the Encryption/ folder (encrypt_file.c, generate_key.c), uses the same logic.

🔹 Temporary Key Wipe

After generating the key from a password using generate_key, the key is stored in a binary file (keyfile.bin) that is used for encryption.

Immediately after encrypting the target wallet file, the script securely deletes this key file using system-level overwrite calls. This ensures that the derived key never persists on disk longer than necessary.

This flow reinforces the philosophy of QuantumVault: no lingering artifacts, no unnecessary exposure, no implicit trust.

Why AES-256 and not elliptic curves?

• Uses AES-256-CBC, symmetric encryption
• With Grover’s algorithm, the effective security is halved to 128 bits
• That’s still strong enough to resist any practical quantum threat

By focusing on symmetric crypto and manual key management, QuantumVault preempts a whole class of theoretical attacks.

6. Usage: Encryption, Decryption, and Demo Walkthrough

The project follows a straightforward two-phase model: encrypt data on Linux, decrypt it offline using FreeDOS.

🔹 Step 1: Encrypt on Linux

cd Encryption
gcc -o generate_key generate_key.c -lssl -lcrypto
gcc -o encrypt_file encrypt_file.c -lssl -lcrypto

./generate_key "your_secure_password"
./encrypt_file wallet.dat encrypted_wallet.bin

This process derives a strong 256-bit AES key using PBKDF2 with a unique salt for each encryption, ensuring rainbow table resistance. The IV and salt are embedded in the encrypted file header.

Immediately after encryption, the keyfile.bin (temporary key output from generate_key) is securely deleted using a system overwrite call to prevent any post-process key leakage. This workflow demonstrates QuantumVault’s commitment to reducing key exposure windows.

🖥 Step 2: Decrypt on FreeDOS

Decryption is performed by the combined_decrypt.exe binary under FreeDOS. Internally, this tool:

• Parses the encrypted file format, extracting salt and IV
• Regenerates the encryption key using PBKDF2-HMAC-SHA256
• Performs AES-256-CBC decryption using the included aes.c implementation
• Writes the decrypted output to disk (or stdout)

combined_decrypt.exe -p your_secure_password encrypted_wallet.bin wallet.dat

Alternatively:

combined_decrypt.exe -k keyfile.bin encrypted_wallet.bin wallet.dat

The decryption process was non-trivial. Debugging AES on a 16-bit DOS platform meant verifying memory boundaries, managing alignment manually, and preventing memory leaks in an environment without dynamic memory allocation.

In addition to standard AES routines, security_check.c adds runtime validation — checking for unauthorized tampering or memory corruption. This includes monitoring interrupt vectors, checking memory signatures, and validating the decryption process hasn’t been altered at runtime.

The combined result is a minimalist but resilient decryption toolchain that runs completely outside of modern OS contexts.

7. Comparison: How It Stacks Up

While not a full replacement for hardware wallets in production finance, QuantumVault provides an open, minimal, and testable reference architecture for cold storage.

8. Who Should Use This

QuantumVault is designed for:

• 🔧 Developers learning x86 real mode
• 🔒 Security engineers experimenting with bare-metal systems
• 🧠 Educators looking for demonstrable air-gap architectures
• 💡 Individuals curious about nontraditional wallet models

It’s not for everyone. If you want GUI wizards, QR-code support, or USB signing — this isn’t it. But if you want to trace the entire execution path from boot to decryption with your own eyes, it’s hard to beat.

9. Lessons from the Bootloader: Real-World Assembly Problems

Developing the bootloader component of QuantumVault exposed me to several classic and painful realities of real-mode x86 assembly programming.

🔹 Why Two Stages?

The BIOS boot sector is limited to 512 bytes — and that includes your code, stack, data, and the mandatory boot signature (0xAA55). There’s simply not enough room to do anything meaningful beyond the most minimal disk read.

To go further, I had to implement a Stage 1 / Stage 2 split:

• Stage 1 fits entirely in the first 512 bytes, whose sole job is to load more data.
• Stage 2 occupies additional sectors on disk. It loads into RAM, verifies integrity, and handles the core logic like password prompting and AES handling.

This split allows full control over memory layout and avoids depending on any prewritten loader — the loader is mine.

🔹 Parameter Passing in Real Mode

In protected mode you have registers, arguments, and calling conventions. In real-mode assembly under DOS, it’s… different. I needed to pass control and configuration data between stage 1, stage 2, and finally the FreeDOS environment.

I tried several methods: BIOS registers, stack, inline memory blocks. The one that proved most reliable and deterministic was simply reserving a known segment:offset region in memory and writing the values there directly. Old school, but rock solid.

🔹 Subtle Bug: The EDX Failure

At one point, my bootloader failed to jump into the OS loader correctly. After hours of debugging, I discovered the issue: an incorrect EDX value being passed during the INT 0x13 call sequence. That small mistake caused the disk read to silently fail.

These are the kind of issues that modern developers never face — but in bootloader land, they make or break your build.

🔹 SentinelDOS: Exploring DOS-Level Security

Originally, QuantumVault included a dedicated directory called SentinelDOS, which housed early attempts to implement security checks at the assembly level. The idea was to hook into key interrupt vectors, scan the system for tampering, and perform runtime validation before any decryption.

These early implementations included:

• Interrupt vector table scans
• Timer interrupt (INT 08h) integrity validation
• Keyboard hook detection
• Assembly-based crypto routines

However, these experiments led to frequent system crashes. Real-mode DOS isn’t particularly forgiving when it comes to dynamic interrupt manipulation — especially when running under emulation or on diverse hardware.

Eventually, I moved most of the logic to C (security_check.c) where it could be safely performed post-boot, within FreeDOS.

Still, SentinelDOS remains an archive of raw, low-level exploration — useful for anyone seriously investigating DOS-era security modeling or exploit detection under minimal systems.

10. Practical Installation & Debug Workflow

If you want to reproduce QuantumVault or build upon it, here’s how you can prepare your own DOS-based boot image, inject custom bootloader stages, and copy files in/out from a host system.

🔹 Step 1: Convert and Write FreeDOS Image

qemu-img convert -f qcow2 -O raw FD13FULL.qcow2 freedos.img

This converts the official FreeDOS QCOW2 image into a raw format suitable for low-level manipulation.

🔹 Step 2: Assemble Bootloader

nasm -f bin stage1.asm -o stage1.bin
nasm -f bin stage2.asm -o stage2.bin

stage1.asm is the boot sector code. stage2.asm loads multiple sectors and expands functionality.

🔹 Step 3: Inject Bootloader into FreeDOS

dd if=stage1.bin of=freedos.img bs=446 count=1 conv=notrunc
# This avoids overwriting the partition table (first 446 bytes only)

dd if=stage2.bin of=freedos.img bs=512 seek=1 count=3 conv=notrunc

This places the bootloader and stage 2 in sectors following the MBR.

🔹 Step 4: Run FreeDOS with Bootloader

qemu-system-i386 -drive file=freedos.img,format=raw

11. Debugging the Bootloader

To step through bootloader execution:

qemu-system-i386 -drive file=freedos.img,format=raw -s -S

Then in gdb:

set architecture i8086
add-symbol-file freedos.img 0x7c00
target remote localhost:1234

This allows full-symbol debugging of your stage1 bootloader.

12. Transferring Files In and Out of DOS

🔸 Write Files from Host into DOS ISO

nasm -f bin attack.s -o attack.com
nasm -f bin guard.s -o guard.com

mv attack.com swp/
mv guard.com swp/
mkisofs -o shared.iso -R -J swp/
qemu-system-i386 -hda freedos.img -cdrom shared.iso -boot d

This mounts your shared files to a DOS drive (usually D: or E:).

🔸 Copy Files from DOS to Host (macOS example)

qemu-img create -f raw shared.img 100M
mformat -F -i shared.img ::
qemu-system-i386 -hda freedos.img -hdb shared.img

Inside DOS, copy desired files to D: (hdb). Then on the host:

hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount shared.img
sudo mount -t msdos /dev/disk25 swp
cp swp/OUTPUT.WEB output.webp
sudo umount swp
hdiutil detach /dev/disk25

This setup enables a fully functional round-trip: host → DOS → back to host.

13. Limitations and Future Plans

This is not a commercial wallet. That means:

• No tamper-proof hardware
• No built-in seed phrase recovery
• No quantum-safe signatures

That said, future expansions may include:

• ✅ TPM binding for key unlocking
• ✅ Integration with USB biometric devices
• ✅ Shamir Secret Sharing for key splitting
• ✅ Expanded cryptocurrency format support

For now, QuantumVault remains what it was meant to be: an educational proof-of-concept that demonstrates what secure cold storage can look like when you build it yourself.

FreeDOS Introduction and External Links

FreeDOS is an open source, MS-DOS compatible operating system. You can use it to run classic DOS games, legacy business software, or develop new DOS programs. FreeDOS supports most programs that originally ran on MS-DOS.

• Official website: https://www.freedos.org/
• Download page: https://www.freedos.org/download/
• About FreeDOS: https://www.freedos.org/about/

The FreeDOS project started in 1994 with the goal of providing a free, open source DOS alternative for PC platforms. It is suitable for use in virtual machines, legacy hardware, or embedded environments.

QEMU Introduction and External Links

QEMU is a generic and open source machine emulator and virtualizer. It can emulate various hardware platforms, allowing you to run different operating systems on any supported architecture.

• Official website: https://www.qemu.org/
• Official documentation: https://www.qemu.org/docs/master/system/introduction.html

Main features of QEMU:

• Full system emulation: Fully emulates a computer (CPU, memory, peripherals, etc.) to run operating systems of different architectures.
• User mode emulation: Runs single programs compiled for other CPU architectures on your local system.
• Virtualization support: With accelerators like KVM and Xen, QEMU can achieve near-native performance for virtual machines.
• Rich command-line tools: Tools like qemu-img are used for creating, converting, and managing disk images.

QEMU is one of the recommended virtual machine environments for this project, suitable for quickly testing and debugging FreeDOS images.