Installing Drivers From Official Sources Only: Allow-Lists, Catalogue Hashes and Authenticode

A refurbished laptop leaves the line with Windows reinstalled, and the step that used to depend on a technician's memory was drivers: which device is missing one, which is running on Microsoft's generic driver, where the right package lives, and whether the install actually took. Searching the web for a driver by name is how a line ends up installing a wrapper from a download site. The BBTech Laptop Inspection Tool was built so that the only drivers it installs automatically come from the laptop manufacturer, the hardware manufacturer or Microsoft, and so that it never reports a success it did not see.

It is an inspection tool first. One read-only PowerShell and WMI pass, about six to twelve seconds without administrator rights, collects every Plug and Play device with its hardware and compatible IDs, problem code and bound driver. A status rule turns that into a vocabulary: Code 28 is driver missing, codes 22, 29 and 32 are disabled, any other problem code is a driver error with Microsoft's description shown, a GPU on Microsoft Basic Display Adapter is missing, a touchpad on the PS/2 mouse driver is generic, and a device with no problem code and no driver bound is unknown, never a false missing.

The search never uses generic text like Wi-Fi driver when a hardware ID exists. Three manufacturers publish machine-readable catalogues that their own update tools use, and the resolver parses those: Lenovo's System Update catalogue, which lists PnP IDs, the expected driver version per hardware ID, a SHA-256 and the silent install command; Dell's Command Update catalogue, with PCI vendor and device IDs per system, MD5 and size; and HP's Image Assistant reference, mapping device IDs to SoftPaqs with URL, SHA-256 and silent switches. Windows Update is queried through the Windows Update Agent API, which only returns drivers applicable to this PC.

Manufacturers without a stable catalogue, Acer, ASUS, MSI, Intel, AMD and NVIDIA among them, are not scraped and no API is invented for them; the tool opens their official page instead. Candidates are ranked by official source first with firmware last, then by match quality from exact hardware ID down to a mere model match, then laptop manufacturer over Microsoft over hardware manufacturer, then auto-installable before newest. A device is marked update available only when an official candidate's expected installed version for that specific hardware ID is newer than what is installed; an unknown target version is never reported as an update. Catalogue XML that declares a DTD or entities is rejected before parsing.

A download passes a URL check before a byte moves: HTTPS only, a host on the official allow-list, no credentials embedded in the URL, and the allow-list is applied again on every redirect so a catalogue link that bounces through an unofficial host is refused. The file streams with progress and a cancel, then its SHA-256 or MD5 and size are compared with the catalogue; a mismatch deletes the file and reports download failed. Failures are classified, no internet, server unavailable, URL expired, interrupted, and each offers retry, open the official source, or skip.

• Packages are saved under the technician's chosen download folder as manufacturer, category, package; an identical file is reused and a different one never overwritten.
• The USB the tool ships on is not a driver repository: nothing is bundled, and downloaded packages are never deleted by the tool or its uninstaller.
• Without internet, inspection and reports still work, and official links are still listed.

Installation has preconditions: administrator rights, an official source, not firmware, and a valid Authenticode signature. For an INF package that means its catalogue files; a package with no .cat file is unsigned and is blocked. Commands outside the package are refused, archives are checked for zip-slip paths, and the install method follows the package: pnputil for INF packages, the vendor's documented silent switches, MSI, or the Windows Update API. Exit codes are mapped as they are: 0 is installed, 3010 is restart pending, anything else is a failure with the code shown.

Verification is a fresh re-query of the device, not a reading of the installer's output. It reports verified, still broken, wrong version, device gone or restart pending, and only verified counts. The rule runs through the whole tool: Installed only when Windows or the installer confirms it, Verified only after a fresh check passes every condition, and a driver result is never presented as a hardware test, because BBTech tests hardware in a separate process.