DeviceDriver 1.0.0 - Driver Safety Center ========================================= DRIVER STORE INTEGRITY SEALING DeviceDriver seals a driver store folder into a manifest of every file's SHA-256, and later proves that the folder on disk is still EXACTLY what you sealed - file by file, byte for byte. That is a different job from reading driver metadata. DriverPilot tells you what a driver package SAYS about itself (provider, class, DriverVer, hardware IDs). DeviceDriver proves the package on disk has not been tampered with, corrupted, or half-copied since the day you approved it. WHAT THIS TOOL DOES NOT DO - READ THIS FIRST -------------------------------------------- This tool verifies FILE INTEGRITY against a manifest that YOU created. That is its entire security model, and it has hard limits: * It does NOT verify Microsoft Authenticode signatures. * It does NOT verify .cat catalog signatures. A .cat file is hashed like any other file; its cryptographic contents are never checked or trusted. * It does NOT talk to the live Windows driver store (DriverStore\FileRepository, pnputil, SetupAPI or the registry). It reads a FOLDER of files, nothing more. * It does NOT install, remove, stage or roll back anything. * It CANNOT tell you whether a driver is trustworthy, correct, safe or signed by anyone. It can only tell you whether the bytes changed since you sealed them. If you seal a malicious driver, DeviceDriver will happily confirm forever that your malicious driver is unchanged. The seal is only as good as the moment you took it. Take the seal from a known-good source, and keep the manifest somewhere the driver store cannot be written from. READ-ONLY GUARANTEE ------------------- DeviceDriver never writes to the driver store it inspects. It opens files for reading only. The only file it ever writes is the manifest you name with --out. COMMANDS -------- devicedriver seal --out [--note "text"] [--json] Walks every file under the directory - not only .inf files - and records each file's relative path, size, modification time and SHA-256. It also records a summary: how many .inf packages are present, how many files, how many bytes in total, and one overall STORE DIGEST folded from the sorted per-file hashes. The store digest is independent of walk order and of file timestamps: it is computed from sorted "path + SHA-256" pairs only. Sealing an unchanged store twice gives the identical digest; changing any single byte of any single file changes it. --note records who approved this seal and why. It is stored verbatim in the manifest and shown again on every verify. devicedriver verify --manifest [--json] Re-walks the store and compares it against the seal. Every file is reported as one of: OK content hash matches the seal exactly MODIFIED the file is there but its content hash differs MISSING the file was sealed but is not on disk now ADDED the file is on disk now but was never sealed Each affected file is reported together with the .inf package it belongs to, so the operator knows which driver package to re-fetch. Detection is by CONTENT HASH, never by size or timestamp. A file whose contents were changed and whose size and mtime were then restored to the original values is still reported as MODIFIED, and the report says so explicitly. Exit code 2 if anything differs at all. devicedriver compare --before --after [--json] Diffs two seals directly, without the store being present. Useful for comparing a seal taken on the build server with one taken on a machine in the field, or last month's seal with today's. Reports the same MODIFIED / MISSING / ADDED vocabulary that verify does. Exit code 2 if they differ. devicedriver inspect [--json] Shows what is in the store: every .inf package with its provider, class, ClassGUID, DriverVer date and version, catalog file name and hardware IDs, plus the payload files each .inf names. It then lists STRAY FILES - files present in the store that no .inf accounts for. Stray files are a real signal: leftovers, dropped payloads and half-finished copies all show up here. devicedriver help | -h | --help Show help (exit 0). devicedriver version Print the version line. EXIT CODES ---------- 0 success, nothing differs 1 usage error, unreadable input, or a manifest that describes a different store 2 verify or compare found at least one difference DIFFERENT-STORE PROTECTION -------------------------- Verifying store B with store A's manifest is a mistake that would otherwise produce a wall of meaningless MISSING and ADDED lines. If none of a manifest's sealed paths exist in the store being checked, DeviceDriver refuses to compare them and says so, naming the root the manifest was sealed from. If the paths only partially line up, it prints an explicit warning with the overlap percentage before reporting the differences. FAULT ISOLATION --------------- A single unparseable .inf never stops a run. It is reported by name with the reason it could not be parsed, its files are still sealed and verified by hash like everything else, and the rest of the packages are processed normally. The same is true of files that cannot be read: they are listed and the run completes. TYPICAL WORKFLOW ---------------- 1. Get a driver set from a source you trust and stage it in a folder. 2. Review it: devicedriver inspect ./DriverStore 3. Approve and seal it: devicedriver seal ./DriverStore --out approved.json \ --note "approved by ops-desk, change CR-4471" 4. Store approved.json somewhere the driver folder cannot write to. 5. Before every deployment, or on a schedule: devicedriver verify ./DriverStore --manifest approved.json Exit code 0 means the folder is exactly what you approved. 6. To compare two points in time without the folder at hand: devicedriver compare --before approved.json --after today.json MANIFEST FORMAT --------------- The manifest is plain, indented JSON with a stable "format" number, so it can be read by other tools, diffed in version control and archived. Every command also accepts --json for machine-readable output on stdout. BUILDING -------- Go 1.24 or newer. Standard library only, no third-party dependencies. go build -o devicedriver . Cross-compiled binaries live in dist/: dist/devicedriver-windows-amd64.exe dist/devicedriver-darwin-arm64 dist/devicedriver-darwin-amd64 dist/devicedriver-linux-amd64 ROADMAP ------- * Real signature verification: parse the .cat catalog and check Authenticode signatures and certificate chains, so the tool can speak to a driver's provenance and not only to its stability. * Live driver-store enumeration: read the actual Windows driver store (DriverStore\FileRepository and the published oemNN.inf set) so the sealed set can be checked against what the machine really has staged. * Integration with a rollback tool: hand a failed verify straight to DriverRollback so an operator can restore the approved package in one step instead of re-fetching by hand.