Display-only KVM console: RFB protocol with Hermon (WPCM450) video
decoder, Slint framebuffer display, no keyboard/mouse input.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The qtbase setup hook sets QMAKE to a path inside the setup-hook
derivation that doesn't contain an actual qmake binary. Combined
with CRLF line endings injecting \r into shell variable values,
this caused qttypes to compile with cfg(no_qt), producing a Slint
binary with no functional Qt backend.
Fix by overriding QMAKE in preBuild (nix build) and shellHook
(devShell), and converting flake.nix to Unix line endings.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The server could not open the virtual CD-ROM block device because the
Linux kernel sends READ TRACK INFORMATION during device enumeration and
our client was returning ILLEGAL REQUEST instead of track data.
Implemented the 0x52 handler by decompiling the firmware's ReadTrackInfo
function (at 0x00128bea). Returns a 28-byte Track Information Block
describing a single Mode 1 data track covering the full disc.
Also fixed the default SCSI opcode handler to match firmware behavior:
the original IsoCommand default case returns no data with status PASS
(no error sense), but we were returning ILLEGAL REQUEST with FAILED
status, which could cause the host OS to reject the device.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Remove panics from build_plugin_packet (return io::Result)
- Drain unknown PDU payloads to prevent stream desync
- Use overflow-safe LBA bounds check in READ(10)/READ(12)
- Move set_nodelay before initial packet exchange
- Move set_read_timeout out of command loop
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add SCSI READ DISC INFORMATION command handler matching the ATEN
firmware response (verified via Ghidra decompilation). Returns a
34-byte Disc Information Block describing a finalized CD-ROM with
1 session and 1 track. Also silence the benign PDU type 0x00000000
the BMC sends after SetEP.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The PlugIn packet was getting auth failure (status 0x01) from the BMC.
Root cause: device config byte was 0x02 (no SID auth, no descriptor mode)
when BMC expects 0x83 (SID auth ON, descriptor mode ON, device index 2),
and SID bytes were all zeros instead of random values.
Additional corrections from reverse engineering findings:
- idProduct: 0x2222 -> 0x1111 (descriptor_mode=1, always true)
- Interface SubClass: 0x06 -> 0x05 (SFF-8070i, matching original template)
- SetEP subclass: 0x06 -> 0x05 (override to 0x06 only when template=0x02)
- Add missing USB descriptor entries 5-7 from vuDevRespData table
- Mount status >= 0x07 treated as success (original binary quirk)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Move protocol and SCSI code into importable mount/ package with a
single public API (Config + Run). Restructure as multi-binary repo
with cmd/aten-mount/ CLI wrapper using context-based cancellation.
Add Nix flake with go_1_26 for builds and devshell.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Round 4 findings: vuDevRespData table layout, st_VSDevConfigDescriptor
structure, RX_BULK_OUT_DATA state handling, connection type detection
(IPv4/IPv6/OEM), VMCFGTable_Init function pointer setup, and minimal
ISO mount pseudocode reference.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Corrected mount sequence diagram: document pre-mount status query
(type=0x08), HTTP port query (type=0x0A), and connection lifecycle
(temporary vs persistent TCP connections)
- Added SID generation details (rand() seeded with time(), weak)
- Documented credential pre-verification path (UI_PreVerifyVMInfo,
device config bit 6 = verify-only flag)
- Clarified PlugIn packet header: offset 4 is base credential length
(0x2C), not total packet length
- Noted status code quirk: values >= 0x07 fall through to success
- Added that RC4 and SID auth are always hardcoded ON in JASWInit
- Updated REVERSING.md with new function addresses and SID globals
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Key changes to KVM_PROTOCOL.md:
- CursorPosition (type 0x04): cursor_extra is actually compositing_mode
(0=XOR/overlay, 1=alpha-blend), not just metadata
- Documented ARGB4444 cursor pixel format with full compositing logic:
mode 0 has three sub-cases (direct color, transparent, XOR-invert),
mode 1 has true 4-bit alpha blending
- Only ASTVideoDecoder implements MixedCursor; others are stubs
- CORRECTED field order in ProcMouseInfo: byte1=encryption_enabled (0x18),
byte2=mouse_mode (0x14), byte3=additional_config (0x1c). Previous docs
had mouse_mode and encryption_enabled swapped.
- Updated type 0x35 and 0x37 wire formats with corrected field names
- Fixed AES encryption section to reference encryption_enabled, not
mouse_mode
Key changes to REVERSING.md:
- Updated RFBMouse object layout with correct field names and order
- Fixed constructor address (0x001193F0 not 0x00119350)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Verified RFBProtocol::Authenticate at 0x00118190 against documentation.
Key findings:
- Auth flow is largely correct but added important nuances
- ClientInit/ServerInit run inside Authenticate on success, not as
separate steps from Java's perspective
- Username and password are sent atomically (single buffered write)
- Challenge is genuinely discarded (confirmed no DES/XOR/hash usage)
- Error message on failure is read but discarded by native code
- Added explicit big-endian annotations for auth_result and error_len
- Documented Userinfo_t struct layout (48 bytes)
- Noted JNI password buffer is 96 bytes but only 24 sent on wire
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Fixed overview to correctly state mouse-only AES encryption
- Added ScreenCalibration to wire format quick reference
- Fixed stale "keyboard/mouse" encryption refs in REVERSING.md
- Completed client message senders table (13->19 entries)
- Cross-verified all wire formats between sections for consistency
- Added minimal client implementation guide section
- Verified KeepAlive reads 1 status byte (discarded), ACK is always 0x01
- All 19 client-to-server and 7 server-to-client types documented
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
