Windows-GPU-UNLOCK
RTX3090 UEFI 포트, 한국어 무리셋 윈도우 부팅 가이드, 검증된 소스와 벤치마크 제공
A KVM for the machine that has nothing on it yet.
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
A KVM for the machine that has nothing on it yet.
See it. Type at it. Install it. No software on the target, no network, no hundred-dollar IP-KVM: an ESP32-S3 dev board (~$10), a cheap
HDMI capture card, and one app.
The real app (0.4.0, Windows 11). The picture is a synthetic demo target, never a real machine.README 전문 보기 ↗A KVM for the machine that has nothing on it yet.
See it. Type at it. Install it. No software on the target, no network, no hundred-dollar IP-KVM: an ESP32-S3 dev board (~$10), a cheap HDMI capture card, and one app.
.msi/.zip for Windows 11, an
.AppImage for Linux. Double-click or chmod +x. That is the whole "dev environment": no Rust, no Docker, no drivers, no DLLs to hunt down.The target needs no software, drivers, network or Bluetooth.
Target HDMI out ──► USB capture card ──► your PC ──► kvm-it (live video)
Your keyboard/mouse ──► kvm-it ──► Bluetooth LE ──► ESP32-S3 ──► USB HID ──► target PC
Everything the app does is also on the command line:
kvmit scan | status | type "text" | key ctrl alt delete | run script.toml [--dry-run] | import payload.txt | flash.
Full walkthrough on the docs site or docs/getting-started.md. Read the hardware guide once: which USB-C port goes where, what the LED and BOOT button mean.
Hacking on it? Building from source (that is where Rust and Docker live): docs/developing.md.
Labels are strict: built = compiles; host-tested = automated tests pass in CI/containers; hardware-verified = run on a physical board; VM-verified = run in a Windows 11 virtual machine on a Linux host with the Bluetooth adapter and the capture card passed through over USB (the real radio and the real card, but not bare-metal Windows).
| Area | State |
|---|---|
| Firmware: USB keyboard + mouse (boot HID) | hardware-verified (enumeration via lsusb; self-test typed) |
| Firmware: protocol dispatcher, dedup, keepalive, LED language, BOOT gestures | host-tested |
| Firmware: BLE (bonding, pairing window, GATT), BOOT GPIO | hardware-verified (BOOT opens the window; LE SC bond; HELLO/STATUS over GATT; bonded reconnect) |
| Firmware: LED driver (GPIO48), BOOT gestures | hardware-verified (fast blue while pairing; 10 s BOOT hold: yellow ramp, three red flashes, fast blue, bond erased) |
| Protocol v1 spec + shared vectors (C and Rust) | host-tested |
| Desktop: client (ack/retry/keepalive), script engine, DuckyScript import, layout | host-tested |
| Desktop: BLE transport + BlueZ pairing | hardware-verified on Linux/BlueZ (Intel AX201): scan, pair, status (90 ms RTT); type/key hardware-verified into a Windows 11 target (every printable US-ASCII character, checked on screen through the capture card) |
Desktop: BLE on Windows (WinRT pairing, scan, status, unpair, faster-connection request) | VM-verified: pairing with no system dialog, status (30 ms RTT with the fast connection, 120 ms without), key --hold; sustained mouse motion at 60 and 125 frames/s no longer collapses the link. kvmit type was not run from Windows. Bare-metal Windows: not tested |
| Desktop: V4L2 capture | hardware-verified with an HDMI capture card (MacroSilicon 345f:2109): 1920x1080 frame of a live Windows 11 desktop via kvmit video snap |
| Desktop: Media Foundation capture (Windows) | VM-verified with the same MacroSilicon card: video list, a 1920x1080 MJPEG video snap, live video in the GUI, and a notice (not a frozen frame) when the card is unplugged mid-stream. The YUY2 path is untested |
| Desktop: egui GUI, v0.1.0 layout (left panel) | maintainer-checked on Linux with an adapter and a target (2026-10-03), including the input-ownership changes |
kvm-it types credentials into other machines. Secrets are never logged and never persisted by default. Read docs/security.md before using it for anything you care about.
| Path | Purpose |
|---|---|
firmware/ | ESP-IDF project (ESP32-S3, TinyUSB HID, NimBLE) |
protocol/ | Wire protocol v1 and generated golden vectors |
desktop/ | Rust workspace: kvmit app (CLI + GUI) and its library crates |
docs/ | The docs site source: UX and scripting, architecture, hardware, security, roadmap, review log |
scripts/ | Containerised build, test and flash helpers |
MIT. See LICENSE.
| Desktop: egui GUI, v0.2.0 layout (top-bar status chips, popups, run-log strip) | VM-verified on Windows (chips, popups, capture, error dialog). Not yet checked on Linux since the redesign; exposes a UI Automation tree for screen readers and tests. No automated GUI tests |
| Desktop: Windows keyboard grab (Win, Alt+Tab, ... go to the target while captured) | VM-verified: Win and Alt+Tab never reach the controller while captured, a held key reaches the adapter, Ctrl+Alt+Esc releases and the keyboard returns, and a hung GUI cannot trap the keyboard (the helper stops swallowing after 3 s). Not verified: non-US layouts and IMEs, bare metal. Linux has no equivalent |
| Desktop: shared client change (mouse motion split into 127-unit frames, ordered before clicks) | host-tested; not re-run on a Linux board yet |
| Windows as the controller (app) | hardware-verified on bare-metal Windows (0.4.6, 2026-10-08, maintainer): with an adapter and a capture card, every button in the app's menu clicked through, and two boards reflashed from Windows and working afterwards. Earlier VM-verified detail is in the rows above; what those rows call untested on bare metal and was not part of this pass (the keyboard grab's edge cases, YUY2, non-US layouts) is still untested. Windows as the target sees a USB keyboard and mouse, and since firmware 0.2.0 also a small read-only drive (a drive letter and possibly an AutoPlay prompt); a Windows target seeing the drive has not been exercised |
Desktop: flash the adapter (kvmit flash, GUI Flash adapter…) | hardware-verified on Linux with a physical board over its COM port (kvmit flash): verified write of bootloader, partition table, app and (firmware 0.2.0) the boot-drive image; the pairing survives a default flash and is wiped by --erase-all; refuses while the adapter's own USB port is plugged in (also with --any-port). VM-verified on Windows 11 (board's COM bridge passed through): the same CLI and the GUI wizard, end to end. an interrupted write was recovered by flashing again. Hardware-verified from bare-metal Windows and from macOS (2026-10-08): two boards reflashed from each and working afterwards. Not exercised: the Linux GUI wizard, a factory-fresh board (the full-erase path, run only on boards that already had firmware) |
Firmware 0.2.0: read-only USB boot drive carrying iPXE, off until turned on (Adapter popup / kvmit boot-drive) | Protocol/dispatcher/config: host-tested (firmware logic tests, shared vectors, Rust parsing). Hardware-verified with the real adapter on a Linux host, the toggle driven from the Windows 11 VM over Bluetooth (kvmit boot-drive): the final firmware (app sha256 6a5d0525… (the v0.4.0 release build; later bundles are the same firmware source rebuilt, which changes the timestamp inside)) flashed over COM as four images with the pairing kept, booting with the drive off; kvmit boot-drive on over Bluetooth from the Windows 11 VM re-enumerated it with a read-only disk (3 interfaces) whose contents read back identical to the shipped image, a raw SCSI WRITE(10) sent at it was refused (DATA PROTECT) and the disk was unchanged; off returned it to two interfaces; the firmware then reports 0.2.0 (2026-10-05). Not exercised on hardware: the GUI button. Earlier hardware checks on a first build of the image (drive always on): enumerates beside the keyboard and mouse as a 4 MiB write-protected disk; the whole disk reads back byte-identical; mounts read-only; raw SCSI writes sent straight at the device (WRITE(10) as DATA PROTECT; WRITE(6)/(12), FORMAT UNIT, WRITE SAME, UNMAP as invalid commands) are refused and the disk is unchanged; pairing survived the new partition table. VM-verified (UEFI VM, Secure Boot off): the final image as a USB disk falls through when no key is pressed, and with a key gets an address, fetches the demo over HTTPS and boots a network Linux; and a private script on it chained to a Windows PE over HTTPS and brought it to its prompt. Secure Boot: the drive now carries the iPXE project's signed shim and iPXE; in a UEFI VM with the stock Microsoft keys it starts with Secure Boot on or off, runs our script, fetches over HTTPS and refuses an unsigned kernel; no real PC with Secure Boot on has been tried, and this image has not been flashed to the adapter yet. Not exercised: the GUI button and the packaged app's four-image flash (the CLI flasher was used), a real PC booting from the drive, a Windows host seeing it, legacy BIOS (unsupported) |
| Built-in OOBE script | template only, never run on a real OOBE |
| macOS as the controller (Apple silicon; AVFoundation capture, CoreBluetooth link and pairing, Quartz keyboard grab, flasher, recording) | hardware-verified on a real Mac (0.4.6, 2026-10-08, maintainer): an adapter and a live picture from an HDMI capture card, every button in the app's menu clicked through, and two boards reflashed from the Mac and working afterwards. Not exercised: recording with sound, the YUYV colour and capture-card-unplug cases, wheel/touchpad on a target (issues #31-#34), ISO Apple keyboards. Shipped as kvm-it-X.Y.Z-macos-arm64.dmg (named -preview up to 0.4.6); ad-hoc signed, not notarized: macOS asks you to allow it |
Session recording (GIF / WebM through ffmpeg, sound opt-in) | host-tested only (v0.4.4: unit tests plus the encoder against a real ffmpeg on synthetic frames); not run with a real capture card, the capture card's audio, or the GUI button on hardware |