Not a bug report — a policy proposal, from a downstream fork that has implemented it and would like to contribute it back if you want it. Everything below is source-level and public; no crash dumps, machine identifiers or user data are included or needed.
The problem in one line
Driver readiness is currently a boolean, and "installed and signed" is being treated as "safe to run".
Where that shows up today
ViiperSetupManager.GetStatus treats a driver file, an uninstall registry entry, or a service key as proof that usbip-win2 is installed.extras/install-viiper-backend.ps1 pins the 0.9.7.7 URL, then downloads and executes it with no SHA-256 check and no Authenticode check before running it silently.- The version gate is a floor (
>= 0.9.7.7), so a newer, unreviewed release is admitted automatically.
- The post-install check reads the FileVersion of
usbip2_ude.sys only. usbip2_filter.sys is never inspected, so a mixed package pair — one component from one release, one from another — passes.
Why it matters more than it looks
usbip-win2 0.9.7.8 carries a confirmed request-lifetime defect in usbip2_ude.sys: an audio endpoint purge can overlap successful ISO completions, and Windows later detects kernel heap corruption. It is reported upstream as vadimgrn/usbip-win2#181. Those packages are Microsoft-attestation-signed and pass every check listed above.
So: signature validity and a version floor are supply-chain gates, not safety gates. Neither one says anything about whether the kernel implementation is sound, and today a >= 0.9.7.7 comparison silently admits exactly the release with the known defect.
Reachability is narrow and worth stating precisely, because it makes a sane default possible: the defect is reached through virtual USB audio endpoint teardown. Controller-only emulation — Xbox 360, plain DualSense/DS4, Switch 2 Pro without the audio-duplex or audio-only device types — does not exercise it.
Proposal
Replace the boolean with four states:
- Missing — no package present.
- Detected, not validated — something is installed but its identity could not be confirmed: mixed pair, unknown version, test-signed, untrusted, or an inspection that failed. Fails closed; cannot be upgraded by user consent.
- Validated, experimental — both packages exactly match a known release identity, and that release is recorded as experimental. Usable, but never described as approved.
- Approved — a release explicitly accepted for production. Deliberately empty today, because no usbip-win2 release qualifies.
With, as policy rather than wording preference:
- No release enters state 4 merely because it is signed or newer.
- Nothing in the UI or the installer ever recommends installing a package the manifest does not list.
- Features that create virtual USB audio endpoints default off while the driver is below Approved, behind an explicit acknowledgement that names the defect. Controller features stay available, because they do not touch the affected path.
- An already-attached device is never torn down by a policy change — teardown is the trigger.
What we have implemented downstream, and can offer
A read-only validation layer: SetupAPI/CfgMgr package enumeration, WinVerifyTrust catalog and file trust verification, a versioned release manifest that both packages must match together, a report formatter with user-path redaction, and a diagnostic command with pass/fail/could-not-run exit codes. It never installs, elevates, attaches a device, starts the backend, or changes any setting. Decision logic is covered by unit tests against fake inspectors, so CI needs no driver present.
On top of that, the four-state gate wired into readiness, the audio-class default and disclosure, and installer hardening (pinned digest plus Authenticode verified before execution, post-install validation of the actual package pair, manifest-only version admission, and never repairing or downgrading a recognised newer release).
It has been exercised on Windows 11 25H2 with Secure Boot, VBS and Memory Integrity enabled, and on real hardware with a DualSense over Bluetooth: with the audio default off, the virtual pad enumerates with no audio interfaces and the backend confirms its speaker and microphone interfaces inactive, while input, rumble and adaptive triggers work normally.
What I would want from you before sending code
The implementation is portable, but the policy is yours to set:
- Should 0.9.7.7 and 0.9.7.8 both be experimental baselines, or should either be blocked outright?
- Should DS4Windows enforce the gate, VIIPER enforce it, or both independently?
- Should the manifest pin file hashes in addition to catalog and Authenticode trust?
- Is a signed, fixed usbip-win2 release the production gate, or would you rather pursue a different virtual-device strategy?
Happy to open this as a series of small PRs — starting with the read-only diagnostic, which changes no existing behaviour — or to leave it here if the direction is not one you want. Either is fine; the analysis is useful to you regardless.
Not a bug report — a policy proposal, from a downstream fork that has implemented it and would like to contribute it back if you want it. Everything below is source-level and public; no crash dumps, machine identifiers or user data are included or needed.
The problem in one line
Driver readiness is currently a boolean, and "installed and signed" is being treated as "safe to run".
Where that shows up today
ViiperSetupManager.GetStatustreats a driver file, an uninstall registry entry, or a service key as proof that usbip-win2 is installed.extras/install-viiper-backend.ps1pins the 0.9.7.7 URL, then downloads and executes it with no SHA-256 check and no Authenticode check before running it silently.>= 0.9.7.7), so a newer, unreviewed release is admitted automatically.usbip2_ude.sysonly.usbip2_filter.sysis never inspected, so a mixed package pair — one component from one release, one from another — passes.Why it matters more than it looks
usbip-win2 0.9.7.8 carries a confirmed request-lifetime defect in
usbip2_ude.sys: an audio endpoint purge can overlap successful ISO completions, and Windows later detects kernel heap corruption. It is reported upstream as vadimgrn/usbip-win2#181. Those packages are Microsoft-attestation-signed and pass every check listed above.So: signature validity and a version floor are supply-chain gates, not safety gates. Neither one says anything about whether the kernel implementation is sound, and today a
>= 0.9.7.7comparison silently admits exactly the release with the known defect.Reachability is narrow and worth stating precisely, because it makes a sane default possible: the defect is reached through virtual USB audio endpoint teardown. Controller-only emulation — Xbox 360, plain DualSense/DS4, Switch 2 Pro without the audio-duplex or audio-only device types — does not exercise it.
Proposal
Replace the boolean with four states:
With, as policy rather than wording preference:
What we have implemented downstream, and can offer
A read-only validation layer: SetupAPI/CfgMgr package enumeration, WinVerifyTrust catalog and file trust verification, a versioned release manifest that both packages must match together, a report formatter with user-path redaction, and a diagnostic command with pass/fail/could-not-run exit codes. It never installs, elevates, attaches a device, starts the backend, or changes any setting. Decision logic is covered by unit tests against fake inspectors, so CI needs no driver present.
On top of that, the four-state gate wired into readiness, the audio-class default and disclosure, and installer hardening (pinned digest plus Authenticode verified before execution, post-install validation of the actual package pair, manifest-only version admission, and never repairing or downgrading a recognised newer release).
It has been exercised on Windows 11 25H2 with Secure Boot, VBS and Memory Integrity enabled, and on real hardware with a DualSense over Bluetooth: with the audio default off, the virtual pad enumerates with no audio interfaces and the backend confirms its speaker and microphone interfaces inactive, while input, rumble and adaptive triggers work normally.
What I would want from you before sending code
The implementation is portable, but the policy is yours to set:
Happy to open this as a series of small PRs — starting with the read-only diagnostic, which changes no existing behaviour — or to leave it here if the direction is not one you want. Either is fine; the analysis is useful to you regardless.