The complete Flint manual

1. Introduction

Flint is a Windows-native utility for writing ISO and DD disk images to USB drives. It writes raw images directly to the physical disk — \\.\PHYSICALDRIVEn — not through a mounted volume, so hybrid images, hidden partitions and boot structures survive intact.

The app is built around one position: flashing erases drives, and mistakes are permanent. Every destructive operation requires a typed confirmation, the target drive is re-detected immediately before writing, writes are verified by reading the drive back, and wipes are verified by confirming the final pattern. There is no silent failure path.

Requirements: Windows 10/11 64-bit. Flashing, wiping, backup and clone require administrator rights; Flint requests elevation when it needs it.

2. Install & updates

Installing

There is nothing to install.

1. Download flint.exe from the download page.
2. Verify the SHA-256 checksum against the value published on the release page.
3. Run it. That's it — no installer, no dependencies, no telemetry.

To uninstall, delete the file. Settings and history live in your user profile, not next to the executable (see Where data lives).

Updating

Flint checks the GitHub release feed about once a week in the background. When a new release is found it offers to download flint.exe plus its bare-hex flint.exe.sha256 sidecar, verifies the download's SHA-256 against the published digest, and saves the new executable to ~/Downloads/flint-<version>.exe — checksum failures discard the file. You can also trigger a check manually from the ⋮ menu (Check for updates…). If the release feed is unreachable, the check is reported as unavailable — it never blocks the app. Advanced users can point the feed elsewhere with the FLINT_UPDATE_URL environment variable.

3. Quick start

4. The interface

Flint's window has a slim left navigation with five screens:

Keyboard shortcuts: F5 rescan drives; Ctrl+O browse for an image. The ⋮ (dots) menu in the top-right offers Check for updates… and other context actions. Every (?) button shows a short explanation bubble — hover to read it.

5. Flashing

Image selection

• Drag & drop an ISO/DD file, or browse with Ctrl+O.
• A SHA-256 hash is computed immediately — this is the digest used to verify the write afterwards. Large images take a moment.
• A sidecar file (image.iso.sha256) next to the image is read and validated first; mismatched sidecars are reported before anything is written.
• Windows and Linux media are recognized automatically, which decides which expert options apply (see below).

Drive selection

• Detected removable drives appear as cards with model, size and serial number.
• Press F5 or refresh to re-enumerate after inserting a stick.
• Immediately before writing, Flint re-detects the drive; if it changed or disappeared, the flash is blocked. A stick swapped at the last second can never receive your image by accident.

Typed confirmation

Destructive actions are armed by typing the required text — not by clicking OK. This is the headless equivalent of the CLI's --confirm, and it is what makes accidental double-clicks harmless.

Progress

During a write, the progress panel shows phase (hashing, locking, flashing, verifying…), live speed in MB/s, bytes written vs. total, ETA and percentage — mirrored on the Windows taskbar progress overlay. The tray icon stays updated; the working state also blocks quit-without-warning if you try to close mid-write.

6. Verification

After a raw write, Flint reads the whole drive back and compares its SHA-256 against the image hash. Mismatched offsets are reported exactly — a bad flash is a located, reported event.

• Enabled by default (Verify after write). Takes about as long as the write itself.
• Verification runs sector-aligned reads; the digest covers exactly the image byte range, so whole-drive size differences don't cause false mismatches.
• After file-copy writes (which repartition and reformat the drive) direct digest comparison is skipped — the layout was rebuilt by design. This is reported, never silent.

7. Bad-block scan

The Verify screen can scan the whole drive as a read-only health check: every sector is read, unreadable ones are retried (1–10 retries, default 3) and reported at 4 KiB-aligned offsets. This is exactly the test that exposes counterfeit “fake capacity” flash drives that read fine until the sectors that don't exist are touched.

8. Expert mode

Expert mode (on by default) exposes the imager's full options. They persist in settings between sessions.

9. Persistence

For Linux live images (Ubuntu casper-rw, Debian live persistence.conf), persistence keeps your changes across reboots — settings, installed packages, saved files. Pick a size in MB or GB; the space is carved out when the drive is prepared.

10. Windows To Go

Applying a Windows ISO can build a portable Windows stick that boots as its own mini-PC: Flint applies the image with dism and installs boot files for both UEFI and legacy BIOS.

• Requires NTFS filesystem and file-copy write mode, plus elevation.
• Mutually exclusive with persistence (the builder reverts one when the other is chosen).
• The choice is offered only for recognized Windows media.

11. Wiping

A wipe overwrites the entire drive. Volume locks are taken during the operation so no mounted filesystem can be left half-written. As with flashing, typed confirmation is required.

Wipe verification. Every wipe ends with a read-back pass: Flint reads the drive back and confirms the final pattern — zeros for zero, or the exact reproducible random stream for nist/dod. A wipe that can't be verified is reported as failed, never as success. The result (method and verification outcome) is recorded in history and on the report.

12. Backup & clone

• Backup images a drive to a file on another disk (requires --out) and verifies the backup by reading it back.
• Clone copies one drive onto another drive; the target must be at least as large as the source, and it is destroyed — confirmation is required for the target's serial.

Both need administrator rights. Clone is how you roll out an imaged fleet after a single golden-stick setup — and it is verified afterwards, like everything else.

13. Flash queue

The Flash screen can stage multiple images in a queue and flash them one after another to the same drive — ideal for producing a batch of identical sticks. Each entry is marked pending → flashing → done, and the queue stops on the first failure so a bad image can't silently poison the rest of the batch. The CLI's queue command is the scriptable twin of this feature.

14. History & reports

Every operation — flash, wipe, backup, clone — is recorded with timestamp, image, drive model and serial, duration, average speed, verification outcome, boot signature (for flashes) and, for wipes, the verification result of the final pattern. From the History screen you can:

• View the detailed report of any entry.
• Export history to JSON or import a previously exported file (import replaces the current history, with a warning).
• Clear history.
• Export diagnostics… — one click bundles the app version, drive list, recent history and log tail into a single text file. Attach it to bug reports; it makes debugging dramatically faster.

15. Settings

16. Tray & taskbar

• A tray icon with a menu: Show Flint and Quit; clicking the icon restores the window. Completion notifications appear via balloon messages.
• Quitting while a write or verification is in progress asks for confirmation — interrupting a write can leave the drive unusable.
• Close to tray (settings) keeps Flint running in the tray when the window is closed.
• Writes show taskbar progress on Windows, tinted red on failure.

17. Updates

See Install & updates. Automatic checks run weekly; manual checks run from the ⋮ menu. Downloads are verified against the published SHA-256 before they're kept, and a failed checksum discards the file immediately.

18. Where data lives

All local. Flint phones home for nothing except an optional weekly update check against the GitHub release feed.

19. CLI reference

Every feature is available headless — flint list, flint flash, flint verify and so on — with a machine-readable RESULT line and documented exit codes, for imaging labs, scripts and CI. Commands that need it relaunch elevated automatically (one UAC prompt); list, doctor and completions need no privileges at all. The older --cli prefix is still accepted as a compatibility alias.

Safety works exactly like the GUI: --confirm must equal the full serial of the drive being destroyed, validated against the live drive list — a wrong serial can never match another drive. Fleet mode (flash-all) requires the literal word ARM. When --confirm is omitted and the terminal is interactive, the serial is prompted for instead; a piped command without --confirm is refused, never guessed.

Running the CLI

flint in the examples below is the flint.exe you downloaded. After the default one-liner install it lives at %LOCALAPPDATA%\Flint\bin\flint.exe but is not added to your PATH — either call it by full path:

& "$env:LOCALAPPDATA\Flint\bin\flint.exe" list

or re-run the installer with -AddToPath to make the bare flint command work (new terminals only): .\install.ps1 -OutDir "$HOME\Downloads" -AddToPath. For scripting, prefer the full path — it never depends on the caller's PATH. Every command also answers flint help, flint help <command> and flint <command> --help.

Command reference

flint list

flint flash --image C:\images\ubuntu.iso --drive E: --confirm 4C530001270509112345 [--verify]

flint verify --drive E: [--sha256 0a4b8c… --image C:\images\ubuntu.iso]

flint wipe --drive E: --confirm 4C530001270509112345 [--method zero|random|nist|dod]

flint backup --drive E: --out C:\images\backup.img [--confirm 4C530001270509112345]

flint clone --from E: --to F: --confirm 4C530001270509112346

flint queue --file queue.txt --drive E: --confirm 4C530001270509112345

flint flash-all --image C:\images\ubuntu.iso --confirm ARM [--timeout 3600]

flint doctor

flint completions | Out-File -Append $PROFILE

Options

Finding a drive's serial

You need a drive's full serial for every --confirm. Get it from the app, or on the command line:

flint list
DRIVE 1 USB Stick serial='4C530001270509112345' size=16GB letters=E path=\\.\PHYSICALDRIVE3
RESULT ok: 1 drive(s) listed

Each line's serial= value is exactly what the matching --confirm must contain. --drive accepts the same drive by serial, volume letter (E:) or physical path — it just selects the drive; --confirm is the safety check, and must match that same drive's serial.

Streams, JSON & exit codes

Streams are split. Data and the final RESULT ok|fail|canceled: … line go to stdout; FLINT <pct> <speed>MB/s ETA <sec>s progress (throttled to ~4 per second) and informational notes go to stderr — so scripts capture stdout as pure data without 2>&1 noise.

With --json every line becomes one JSON object — progress, results, drive lists and doctor reports — each tagged with a type field:

{"type":"drives","drives":[{"index":1,"name":"USB Stick","serial":"4C530001270509112345","size_gb":16,"letters":["E"],"path":"\\\\.\\PHYSICALDRIVE3"}]}
{"type":"result","status":"ok","message":"1 drive(s) listed","exit":0}

Unknown commands and options print the usage text on stderr; internal errors always end with RESULT fail: internal error: … so scripts get a machine-readable line in every case. --version prints the version. See the CLI examples on the features page for the complete flow.

20. Safety model

The mechanisms, end to end:

1. Physical-disk paths only. Destructive operations accept \\.\PHYSICALDRIVEn paths exclusively — volume handles like E: are refused, so a raw write can never land inside a single partition by mistake.
2. Typed confirmation. Flash and wipe require typing the confirmation text; the CLI requires the drive's full serial (--confirm) and validates it against the live drive list.
3. Recheck before write. The target drive is re-detected immediately before writing; a changed or missing drive blocks the operation.
4. Post-write verification. Raw flashes are read back and digest-compared with exact mismatch offsets.
5. Wipe verification. The final pattern is confirmed by read-back; unverifiable wipes fail.
6. Volume locking. Wipes take volume locks so mounted filesystems aren't left half-written.
7. Audit trail. Every operation is recorded in history with verification outcomes and drive serials.

21. Troubleshooting