-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Universal low-level hardware access for non-admin applications — the secure, auditable replacement for the WinRing0 / per-app-elevation model.
Register Broker is a framework, not an app — the core is two background services plus a contract, with no GUI of its own. It exposes PC sensor data and RGB hardware control to ordinary, non-administrator client programs through a tightly structured, kernel-enforced contract — preserving the kind of deep data and control that tools like WinRing0 gave you, but without handing every application raw ring-0 access to your machine.
It does ship a first-party Reference Console — an ordinary, non-admin desktop app that reads every sensor and drives every supported RGB device through nothing but the public pipe protocol. It's a demonstrator (proof the model works end to end), not the product.
Quick links: Getting Started · Client Protocol · Architecture & Security
For years, the only way for a Windows app to read motherboard sensors or drive RGB lighting was to ship a driver like WinRing0 — a generic kernel driver that grants arbitrary port I/O, physical memory, and MSR access to whatever process loads it. That model has two fatal flaws:
- Every app needs admin / elevation, or bundles its own kernel driver.
- Those drivers are unbounded. A signed WinRing0 is a signed skeleton key — it can read or write any hardware register, which is exactly why it keeps showing up in malware and BYOVD (bring-your-own-vulnerable-driver) attacks.
Register Broker keeps the capability — genuine low-level sensor and RGB access — while removing the blast radius.
The framework is two narrow components plus a hardened client protocol:
| Component | Role |
|---|---|
BrokerSmbus (KMDF kernel driver) |
One small, signed driver. Exposes only bounded, validated, named-register IOCTLs — never physical memory, MSRs, or arbitrary port I/O. Every read/write is checked in-kernel against a baked address allow-list. |
BrokerSensorBridge (LocalSystem broker) |
Runs as the SensorBroker + BrokerControl services. Owns the control plane: authentication, scopes, policy, rate-limiting, and the audit log. Maps logical ids to hardware. |
| Client protocol (v2) | Non-admin apps connect over fixed well-known named pipes, authenticated by pipe DACL + peer-process identity + Authenticode signer-thumbprint pin (no shared secrets). |
Clients name logical ids — smu.cpu.temp, ram0, nct6687d.* — and never addresses. They cannot scan the bus and cannot read or write outside the baked, kernel-enforced register map. The map lives in signed code, never in data: configuration JSON can relabel, rescale, or hide a channel, but it can never point the hardware at a new address. SPD ranges and the JC42 thermal window are refused in-kernel; RGB writes are confined to a brick-guarded address allow-list.
The result: a non-admin client gets exactly the sensor catalog and RGB zones the broker chooses to expose, every operation is rate-limited and written to an audit log, and there is no general-purpose hardware primitive for anything — including malware — to abuse.
-
Non-admin sensor catalog — around 60 sensors on a typical board (including read-only fan-PWM duty telemetry) served to unprivileged clients via a single rate-limited
sensor.readallpoll. Backends auto-detect and stay inert when their hardware is absent:- AMD SMU (Tctl + per-CCD temps, and CPU core/SoC voltage via SVI2 on Matisse/Vermeer)
- Nuvoton NCT668x EC family (NCT6683 / 6686 / 6687D), incl. read-only fan-PWM duty (
nct6687d.pwm.0–.7) — telemetry only, no fan-write path - Nuvoton NCT6775 bank-select family (6779–6798)
- JC42 DIMM temperatures
- AMD FCH SMBus (Intel i801 path written, pending validation)
-
GPU sensors (
gpu.*) — read-only, opt-in: temp / hotspot / mem, fan RPM & %, power, core/mem clock, usage, and core voltage (AMD ADL; NVIDIA NVML and Intel Level Zero providers built behind the same seam) -
Aquacomputer liquid-cooling sensors (
aqua.*) — read-only, opt-in: water temps, flow rate, and fan RPMs (first device: Aquacomputer Quadro); hot-pluggable
-
Non-admin RGB control — board-aware, multi-transport, DMI-matched board profiles:
- ENE DRAM RGB over SMBus (per-LED, hardware-validated)
- MSI Mystic Light motherboard RGB over USB-HID (per-LED, hardware-validated)
- Razer Chroma keyboards/mice over USB-HID (per-LED, hardware-validated; opt-in)
- NCT6687 EC 12V header path (wired, kept deliberately inert pending register bring-up)
- Diagnostics & integrity — backend enumeration, a full self-test suite (signature checks, calibration regression, chipset gates, scope enforcement, rate-limit checks), and signed-code register maps throughout.
- The driver stays narrow. New capability means a new specific, bounded, in-kernel-validated IOCTL gated by broker scopes — never a generic primitive.
- No bricking. Hardware sequences are ported from proven references (Linux hwmon/i2c drivers) as register facts, cross-checked against a second source, and brought up read-only first. Fragile, high-risk hardware families are deliberately left out rather than half-supported.
- Ids are forever. Sensor ids are persistence keys that consumer apps save against, so they stay stable; renames route through an alias map.
- Auditable by construction. Identity-pinned auth, always-on rate limiting and session caps, and a persistent audit log mean every privileged action has a name attached to it.
Register Broker is functional and live-validated on the developer's hardware (an MSI MPG B550I GAMING EDGE MAX WIFI) — sensors (including fan-PWM duty telemetry and read-only AMD GPU telemetry), DRAM RGB, MSI Mystic Light motherboard RGB (per-LED), and Razer Chroma peripherals are all confirmed working from a non-admin client, including end-to-end through the first-party Reference Console. Several additional chipset backends are built and code-complete but awaiting community hardware validation (Intel i801 SMBus, the NCT6775 family, NCT6683/6686, the NVIDIA/Intel GPU providers, and Aquacomputer devices beyond the Quadro).
AGPL-3.0 with a Commercial Exception. Provenance and third-party reference attributions are documented in THIRD-PARTY-NOTICES.md (Linux-kernel reference drivers are used as register facts; the ENE/Aura RGB protocol is treated as a publicly documented protocol).