Skip to content
BranchesTags

Repository files navigation

NVMe Driver Manager

A professional, open-source command-line tool for discovering, downloading, extracting, and organizing NVMe / storage / RAID / AHCI drivers from publicly available GitHub repositories and releases.

Built for IT technicians, system builders, and repair shops that need a clean, searchable, locally-hosted driver library instead of hunting for the same .inf files over and over.

nvme-driver-manager/
├── README.md
├── LICENSE
├── requirements.txt
├── config.yaml                 # sources, categories, output paths
├── start.bat                   # Windows one-click setup + launch
├── launcher.py                 # interactive menu (used by start.bat)
└── nvme_manager/
    ├── __init__.py
    ├── cli.py                  # command-line entry point
    ├── config.py                # config loading
    ├── logger.py                # logging setup
    ├── models.py                 # DriverPackage / DriverAsset / DriverFolderCandidate
    ├── github_source.py         # GitHub search + release + code-search + seed repos
    ├── ms_catalog.py             # Microsoft Update Catalog scraper
    ├── inf_parser.py              # .inf file parser (PCI IDs, version, driver model)
    ├── signature.py                # exact/loose file-set matching
    ├── classifier.py                # repo relevance scoring
    ├── downloader.py             # resumable/retrying download engine
    ├── extractor.py              # zip / cab / 7z / rar extraction
    ├── organizer.py               # folder structure + metadata writer
    └── indexer.py                 # SQLite driver index + search

Features

  • Manufacturer coverage — Intel RST, Samsung, WD/SanDisk, Kioxia (Toshiba), Micron/Crucial, SK Hynix, Phison (the reference controller behind many boutique brands like Corsair, Sabrent, ADATA), AMD RAID, plus a generic/Microsoft-inbox fallback. Run nvme-manager list-vendors to see the full list and each one's required file signature.
  • Exact file-signature matching — the core safety and correctness feature. A folder only counts as a real, installable driver package if it has exactly the right file types in the right quantities — e.g. Samsung/WD packages need exactly 1 .inf + 1 .cat + 1 .sys, while Intel RST needs those three plus its management service (.exe + .dll). Anything with a missing file, an extra unexplained file, or the wrong count is rejected automatically — this is what makes the difference between "Windows recognizes the NVMe controller" and "it doesn't." Signatures are fully configurable per-vendor in config.yaml under package_signature.
  • Two ways to find drivers:
    • scan-folders / download-folders — the strict, recommended path. Searches GitHub code search for driver files, checks each one's sibling files, and only reports/downloads folders that already exactly match the required signature before anything is downloaded.
    • scan / download — the broader path. Also checks packaged .zip/.exe releases, downloads and extracts them, then applies the same exact-signature check afterward — anything that doesn't match gets discarded automatically (--no-signature-check to disable this).
  • verify — re-checks anything already downloaded against the current required signature, and can --prune anything that doesn't match.
  • Relevance classifier — before spending API calls pulling a repo's releases, each candidate repo is scored by keyword relevance (name/description/topics), with stars/recency only used as tie-breakers among relevant repos — a popular-but-irrelevant repo never outranks a real driver mirror just because it has more stars.
  • Download engine — resumable downloads (HTTP Range requests), automatic retry with backoff, SHA-256 hashing of every downloaded file, and full logging.
  • Extraction engine — handles .zip, .7z, .cab (via expand/cabextract), will attempt silent-extraction flags on .exe installers where supported, and recognizes raw .inf/.sys/.cat files (from code search) as already-usable with no extraction step needed.
  • Organization & metadata — normalizes everything into Category/Vendor/DriverName/Version_Date/ with a metadata.json per package, and a local SQLite+FTS index for instant search.
  • CLI — list-vendors, scan, scan-folders, download, download-folders, build-index, search, export-driver-pack, verify, clean, set-token, token-status.

About safety (scams, trojans, malware)

There's no way to guarantee a random file on the internet is safe, so be realistic about what this tool does and doesn't protect against:

  • The exact-signature check is a real, meaningful filter: a scam repo would need to happen to contain the exact legitimate set of driver component types (including a .cat security catalog file) to pass — a bare trojan .exe sitting alone in a repo will never match and will never be downloaded or shown to you.
  • blocked_filename_patterns in config.yaml skips obviously malware-flavored filenames before they're ever downloaded.
  • This is filename/structure-based filtering, not virus scanning. It won't catch a well-disguised malicious file with an innocent name. Keep your antivirus active when installing anything, from this tool or anywhere else, and prefer a vendor's official download page when your exact drive model is listed there.

Excluding companion tools (patchers, dashboards, management software)

The same blocked_filename_patterns list also filters out things that aren't malicious but aren't driver files either — registry patchers, vendor management dashboards, benchmarking utilities — so scans only surface actual driver folders. If a matching folder has one of these bundled alongside the real driver files (e.g. a repo shipping iaStorVD.inf/.cat/.sys plus an unrelated NVMeDriverPatcher-5.0.0.msi), the whole folder is skipped, not just that one file — even in --loose mode. If you spot a non-driver tool slipping through, add a fragment of its filename to blocked_filename_patterns in config.yaml and it'll be excluded from then on.

Windows: one-click launcher

Just double-click start.bat. It will:

  1. Look for a working Python install (python or the py launcher) on your system.
  2. If none is found, silently download the official Python 3.12 installer from python.org and install it for the current user (no admin rights needed).
  3. Install/upgrade the required packages (requests, PyYAML, py7zr, tqdm).
  4. Launch an interactive menu (launcher.py) that wraps every CLI command — scan, download, search, export, clean — so you never have to type a command by hand.

If Python was just installed for the first time and start.bat can't find it right away (this happens if Windows hasn't refreshed PATH yet), just close the window, open a new one, and double-click start.bat again — it only has to do the install once.

Everything downloads/installs into your own user profile (%LOCALAPPDATA%) and this project's own folder — nothing is written to C:\Windows or system locations, and no admin prompt should appear.

Manual installation (macOS / Linux / advanced users)

git clone https://github.com/<you>/nvme-driver-manager.git
cd nvme-driver-manager
python3 -m venv .venv && source .venv/bin/activate      # optional but recommended
pip install -r requirements.txt

Microsoft Update Catalog

In addition to GitHub, this tool searches catalog.update.microsoft.com — Microsoft's own repository of signed driver packages, including ones OEMs like Intel submit directly. These are the same .cab files Windows Update itself would install, so they're about as official and complete as an NVMe driver package gets.

There's no public API for this catalog, so it's scraped using the same two-step method long-running open-source tools for this exact purpose use (e.g. the MSCatalog PowerShell module): search the results page for each result's hidden GUID, then POST that GUID to a second endpoint that resolves the actual .cab download URL. See nvme_manager/ms_catalog.py.

Each vendor profile in config.yaml has an ms_catalog_queries list — the search terms used against the catalog. Only the Intel RST query has been directly verified (built from a real, working URL, confirmed to return current 2025/2026-dated Intel driver entries). The other vendors' queries are reasonable starting points, not individually confirmed — if one returns nothing useful, check https://www.catalog.update.microsoft.com/Search.aspx?q=<your terms> in a browser yourself and adjust the query in config.yaml.

Honesty about testing limits: this scraper's parsing logic is unit-tested against the documented real structure of the catalog's HTML (verified via a live fetch of your Intel query), but I could not run it against the live site end-to-end from the environment I built it in — that domain isn't reachable from there. It should work fine from a normal machine with internet access; if a search comes back with a warning that zero result rows were found even though the catalog clearly has matches in a browser, the site's markup likely changed and the regexes in ms_catalog.py need a small update.

Downloaded .cab files go through the exact same signature-verification pipeline as everything else — --no-ms-catalog skips this source entirely if you don't want it.

What's inside every driver — extracted from the .inf itself

Every downloaded package's real .inf file gets parsed automatically the moment it's downloaded (nvme_manager/inf_parser.py). Real Windows .inf files are almost always UTF-16LE-encoded, not plain text — this handles that along with the other encodings that show up in the wild — then extracts, straight from the driver's own install instructions:

  • Manufacturer (resolved from the [Version]/[Strings] sections)
  • Driver version and build date (DriverVer=MM/DD/YYYY,x.x.x.x)
  • Device class (SCSIAdapter, HDC, etc.)
  • Exact PCI hardware IDs it supports (PCI\VEN_xxxx&DEV_yyyy) — the real list of SSD controllers this specific driver was built for, not a guess
  • Windows driver model — detects StorPort miniport, filter driver, KMDF, or UMDF based on what the .inf actually declares (LoadOrderGroup, KmdfLibraryVersion, etc.)

A package can ship more than one .inf (Intel RST's AHCI+VMD bundle has two, covering different device classes) — in that case everything is pooled: all hardware IDs combined, all device classes joined.

This shows up in search results automatically, and you can search by exact hardware support instead of guessing keywords:

# Find whatever driver in your library actually supports this specific controller
nvme-manager search --pci-id "VEN_144D&DEV_A808"

# Or just the vendor ID, to see everything for that manufacturer's controllers
nvme-manager search --pci-id "144D"

Verified against the real Intel RST .inf files: correctly extracted the manufacturer, version, date, device class, StorPort detection, and all 5 (or pooled 17, for the AHCI+VMD bundle) PCI hardware IDs, cross-checked line-by-line against the actual file content. Also tested against garbage/empty/missing files to confirm it fails gracefully (returns nothing) rather than crashing, since it runs automatically on every download.

Every downloaded driver's metadata.json now records exactly which discovery path found it, and search --source <name> filters by it. The possible values:

Source label What it means
github-release Attached to a GitHub repo's Releases page
github-code-search A loose .inf/.sys/.cat file found via GitHub code search
github-folder-search A whole folder found via GitHub code search that exactly matched the signature
github-folder-search-loose Same, but found via --loose (extras allowed)
github-seed-repo From a seed_repos entry — a specific repo checked directly
ms-catalog From Microsoft Update Catalog

nvme-manager scan also prints a live "By source" breakdown before you download anything, and list-vendors shows a [MS Catalog] / [+N seed repo(s)] tag next to each vendor that has those sources configured.

Other legitimate sources — what's actually out there

Researched for this: the honest picture is that most of the good options are OEM "driver pack" catalogs, not per-component NVMe downloads, and each one is a genuinely separate integration to build, not just a config tweak like adding a GitHub keyword.

Real, legitimate, and not yet integrated:

  • Dell's Driver Pack Catalog (downloads.dell.com/catalog/DriverPackCatalog.cab) — official, publicly documented, machine-readable XML listing every Dell system driver pack. Used for years by IT admins for SCCM/MDT automation. The catch: it's organized by system model (a whole laptop's driver bundle), not by component, so pulling "just the NVMe driver" means downloading a model's full pack and filtering inside it — a bigger scope than what MS Catalog needed.
  • Lenovo and HP have equivalent official catalog systems (Lenovo System Update catalog XML, HP Image Assistant / HPCMSL) with the same model-bundle characteristic.

Deliberately not recommending:

  • Sites like station-drivers.com or forum-hosted "modded" Intel RST/VROC drivers (common on enthusiast forums) are often patched to remove platform-ID restrictions — exactly the kind of unofficial modification this tool's signature system and blocklist are built to steer away from. Popular, but not the vendor's actual signed driver.
  • Generic "driver download" sites (driver-finder tools, driver pack mirrors) routinely bundle adware/PUP installers and aren't meaningfully more trustworthy than a random GitHub repo, just less transparent about it.

On "one day have everything compiled so I never have to search again": reasonable long-term goal, but worth being honest about the shape of it — it's less "add one more source" and more "build N source-specific integrations, one at a time," since Dell, Lenovo, HP, GitHub, and MS Catalog each have a genuinely different API shape. If you want to keep going, Dell's catalog is the most well-documented next candidate — built and verified against real data the same way MS Catalog was, wired into the same signature-check pipeline as everything else.

Be aware going in: most vendors don't publish NVMe drivers on GitHub at all. Samsung, WD, Kioxia, Micron, SK Hynix, and Phison distribute drivers as signed installers from their own support sites, not as raw files in public repos. What you'll find on GitHub is mostly community mirrors, driver-pack collections, and the occasional enthusiast backup — coverage is real but genuinely spotty per model. GitHub's code search also has real limits: it only indexes each repo's default branch, skips very large files, and excludes forks by default.

To get the best odds:

  • Use scan-folders, not just scan. It searches for real PCI vendor ID strings (like VEN_144D for Samsung) that literally appear inside .inf files, which matches far more reliably than a descriptive phrase search.
  • Add known-good repos as seed_repos. If you find a repo yourself (like this project's own Intel_RST config, seeded with arakium/IRST-VMD-Drivers), add its owner/repo to that vendor's seed_repos list in config.yaml. Seed repos are checked directly via GitHub's file-tree API — one call gets every file in the whole repo — so they're immune to code search's indexing quirks (default-branch-only, no forks, size limits) and will be found every single time, guaranteed.
  • Set a GitHub token (below) — the free tier's 60 requests/hour runs out fast once you're scanning several manufacturers.
  • If a strict scan finds nothing, try --loose (or the "y" prompt in the manufacturer-picker menu) — it shows folders with at least the required files, even if there's an extra file or an extra copy of something. These aren't guaranteed-clean the way an exact match is, so inspect them before trusting them; download-folders --no-verify is how you keep one that the strict re-check would otherwise discard.
  • For a specific drive model, check the manufacturer's own download page first. This tool is best used as a supplementary/backup search, not a replacement for the vendor's official driver for your exact SSD.

A vendor can have more than one valid file signature

Some vendors legitimately ship more than one correct package shape. Intel RST is the confirmed example: its VMD-only driver is 5 files (iaStorVD.inf/.cat/.sys + RstMwService.exe + RstMwEventLogMsg.dll), but its full AHCI+Optane+VMD bundle (used on some CPU generations) is a completely different 13-file set — 2 of each .inf/.cat/.sys, 4 .exe, 3 .dll. Both are real, correct Intel packages.

package_signature overrides support a list of named variants instead of a single file set — a folder is accepted if it matches any variant exactly:

package_signature:
  overrides:
    Intel_RST:
      - name: "VMD-only (iaStorVD)"
        files:
          ".inf": 1
          ".cat": 1
          ".sys": 1
          ".exe": 1
          ".dll": 1
      - name: "Full AHCI+Optane+VMD bundle"
        files:
          ".inf": 2
          ".cat": 2
          ".sys": 2
          ".exe": 4
          ".dll": 3

nvme-manager list-vendors shows all accepted variants per vendor, joined with "OR".

GitHub API token (required for full functionality — not just "recommended")

Without a token, GitHub's public API caps you at 60 requests/hour — you'll hit that fast if you're scanning several vendors or doing back-to-back downloads. With a free personal access token, that jumps to 5,000/hour.

More importantly: GitHub's code search endpoint requires a token, period. This is a GitHub platform rule (in effect since April 2023), not a limit this tool imposes. Without a token, scan-folders and the code-search portion of scan will silently return zero results — every time, no matter how the search terms or filters are set. The tool now detects this and tells you plainly when it happens, but the practical fix is the same either way: set a token. (seed_repos — known-good repos checked directly — uses a different, non-code-search API endpoint and works fine without a token, just subject to the standard 60/hour limit.)

This needs a GitHub Personal Access Token (PAT) — not an SSH key, not a GPG key. Those are unrelated things GitHub also calls "keys"/"tokens" but for different jobs:

Type What it's for Does this tool need it?
SSH key git clone/git push over SSH No
GPG key Signing commits so they show "Verified" No
Personal Access Token (PAT) Authenticating REST API requests Yes — this one

How to get a PAT

  1. Go to https://github.com/settings/tokens
  2. Click "Generate new token" → "Generate new token (classic)"
  3. Give it any name, e.g. nvme-driver-manager
  4. Pick an expiration (or "No expiration" if you don't want to redo this later)
  5. Leave every scope checkbox unchecked — this tool only reads public repos, so no permissions need to be granted
  6. Click "Generate token" at the bottom
  7. Copy it immediately — it starts with ghp_ and GitHub only shows it once

Three ways to set it, all equivalent:

# 1) One-time CLI command — saved to .github_token (gitignored) next to config.yaml,
#    so it's picked up automatically on every future run:
python -m nvme_manager set-token ghp_xxxxxxxxxxxxxxxxxxxx

# 2) From the interactive menu (launcher.py / start.bat): option "T"

# 3) Environment variable — session-only, and takes priority over the saved file
#    if both are set:
export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx        # macOS/Linux
setx GITHUB_TOKEN "ghp_xxxxxxxxxxxxxxxxxxxx"         # Windows (persists across sessions)

Check what's currently configured with:

python -m nvme_manager token-status

start.bat will also prompt you for a token the first time you run it if none is configured yet (you can skip and set it later).

For .cab extraction on Linux, install cabextract. On Windows, expand.exe is built in. For .7z/.rar support, the tool uses the bundled py7zr package for 7z and will use the unrar/7z CLI if present on the system for .rar.

Usage

# See every configured manufacturer and its exact required file signature
python -m nvme_manager list-vendors

# --- Everything at once: scan + download for every manufacturer -----------

# Does both the strict folder-match path and the release-asset path for
# every configured manufacturer, keeping only what passes the exact
# signature check and blocklist — everything else is discarded automatically.
python -m nvme_manager grab-all

# Just a subset of manufacturers, and fall back to --loose per-vendor if a
# strict scan for that vendor finds nothing:
python -m nvme_manager grab-all --only-vendor Intel_RST --only-vendor Samsung_NVMe --loose

# Only the strict folder path (skip release-asset scanning), or vice versa:
python -m nvme_manager grab-all --folders-only
python -m nvme_manager grab-all --releases-only

# --- Recommended: strict exact-match folder discovery ---------------------

# Only reports folders whose files EXACTLY match what's required (nothing
# downloaded yet, just a report). Also checks any configured seed_repos
# directly (e.g. Intel_RST -> arakium/IRST-VMD-Drivers), guaranteed to be
# found every time regardless of GitHub search indexing.
python -m nvme_manager scan-folders --only-vendor Samsung_NVMe
python -m nvme_manager scan-folders            # all configured manufacturers

# If a strict scan finds nothing, see near-matches instead (extra files
# allowed) — inspect before trusting, then keep one with --no-verify
python -m nvme_manager scan-folders --only-vendor WD_NVMe --loose
python -m nvme_manager download-folders wd --no-verify

# Download the folders found above — anything that doesn't re-verify gets
# discarded automatically
python -m nvme_manager download-folders samsung
python -m nvme_manager download-folders all

# --- Broader: also checks packaged .zip/.exe releases + Microsoft Update Catalog --

python -m nvme_manager scan --only-vendor Intel_RST     # includes MS Catalog automatically
python -m nvme_manager scan --only-vendor Intel_RST --no-ms-catalog   # GitHub only
python -m nvme_manager download intel          # non-matching packages auto-discarded
python -m nvme_manager download intel --no-signature-check   # keep everything anyway

# --- Everyday commands ------------------------------------------------------

# Re-check what's already downloaded against the current required signature
python -m nvme_manager verify
python -m nvme_manager verify --prune          # and delete anything that doesn't match

# Rebuild the searchable index from everything currently on disk
python -m nvme_manager build-index

# Search your local collection
python -m nvme_manager search "samsung nvme"
python -m nvme_manager search --vendor amd --type RAID

# Bundle a specific driver set into a single zip for USB deployment
python -m nvme_manager export-driver-pack "Samsung_NVMe" --out ./SamsungNVMe_pack.zip

# Remove failed/incomplete downloads and empty folders
python -m nvme_manager clean

Resulting folder layout on disk (default: ~/Downloads/Drivers, configurable in config.yaml):

Drivers/
  NVMe/
    Intel_RST/
      RST_Driver/
        20.2.6.1025_2026-07-01/
          metadata.json
          <extracted files>
  Storage_Controller/
  Chipset/
  AHCI/
driver_index.db          # SQLite index
logs/
  nvme_manager.log

Configuration

All behavior is controlled by config.yaml: output directory, GitHub search keywords per category/vendor, allowed file extensions, request timeouts/retries, and rate-limit handling. Edit it to add new vendors or narrow/broaden the search terms — no code changes needed for that.

Safety / scope notes

  • Only queries GitHub's public search & releases API and downloads whatever asset URLs that API returns — it does not scrape arbitrary sites or bypass any authentication.
  • Executables are never auto-run. .exe installers are downloaded and, where 7-Zip can read them as an archive, extracted as an archive; otherwise they're left intact for you to run manually.
  • Every file gets a SHA-256 hash recorded in its metadata so you can verify integrity later or diff against vendor-published hashes yourself.
  • No empty folders. Running the tool never pre-creates a folder for a manufacturer before something real is actually found for it, and a rejected download automatically removes not just the file it downloaded but every now-empty parent folder up to the drivers root — so browsing your drivers folder only ever shows things that actually passed the signature check, never a dead end.

Extending

  • Add new vendors/keywords: edit config.yaml, no code changes required.
  • Add a new source type (e.g. a specific vendor's public driver-catalog API): implement a class with a .search(keyword) -> list[DriverPackage] method next to github_source.py and register it in cli.py.
  • Swap SQLite for Postgres/etc.: indexer.py is a thin wrapper — swap the connection logic only.

Future expansion ideas

  • Optional PySide6/Tk GUI front-end over the same nvme_manager package
  • Scheduled re-scan (cron / Task Scheduler) with "what's new since last run" diffing
  • Direct integration with DISM (Add-WindowsDriver) to inject discovered drivers into a mounted WIM/VHD
  • Vendor-published checksum verification where hashes are published on release pages
  • Web UI for browsing the local index

License

MIT — see LICENSE.

About

No description, website, or topics provided.

Resources

Readme
MIT license
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages