Add experimental on-printer HID erase-fix installer

[phryneas]

A CC2 with a printer shell can reach its attached camera through USB, but the printer has neither ADB/Python nor hidraw. This adds a separate dependency-free Rust tool using Linux usbfs to install the existing canonical erase-fix hooks without unplugging the camera.

The tool builds as a small static ARMv7 executable. CI builds it with checksums, and manually published releases receive the same asset. No releases are created automatically.

Behavior and risk

• inspect recognizes the observed 30D signature from sysfs and explains that the patch does not apply, without opening the USB device or sending commands. Shared USB IDs alone are insufficient. For a supported HID camera, it queries the version without uploading files.
• install --accept-no-backup-space-risk installs the canonical erase-fix hook and runner, with camera-side checks and file comparisons.
• verify runs a temporary post-restart probe that checks installed bytes and the live RAM correction without applying it.

The requested experimental route has no exported backup or clean-space admission check. A failed write can require programmer recovery, which is not guaranteed without readable same-camera identity data. Kernel/updater fingerprints, partition/mount checks, default differing-content refusal, configuration stability checks, and file comparisons remain. The existing backup-based tools are unchanged.

Only the selected HID interface is claimed; no video-interface detachment, USB reset, firmware-image write, identity replacement, or live RAM correction occurs during installation. A session-specific RAM status channel avoids treating the expected failed command-launch commit as success. That mechanism temporarily changes the version response and leaves the HID uploader unavailable until restart. There are no upload retries.

The developer-confirmed 30D descriptors have two UVC functions and neither HID nor ADB interfaces. The classifier checks revision, strings and standard USB topology; install/verify refuse a recognized 30D before USB access. Synthetic tests cover partial signatures, malformed lengths, ambiguity and absence of side effects. This does not establish recognition of every 30D firmware version.

The usage guide includes prerequisites, exact commands, failure handling, post-restart verification and the accepted risk. Research documentation distinguishes static evidence from remaining hardware unknowns.

Validation

• 171 Python tests pass locally, including eighteen generation/shell tests covering partial writes, readback corruption, firmware refusal, unknown paths, changing config, idempotency and read-only live verification.
• Seventeen Rust tests pass on x86-64 and under ARM QEMU; Clippy passes.
• CI verifies static ELF linking, runs ARM executable smoke checks and publishes a checksummed binary artifact.
• Zizmor workflow audit passes.
• Physical 30B inspection selected the expected HID endpoints and received a matching-command, CRC-valid reply, but version status/content failed validation. The detailed physical response was status 1 with no payload, matching the firmware's failure to open/read its temporary version file. The developer-approved exception accepts only this exact reply as unavailable metadata. Inspection sends only one version query and does not create the file. Other invalid replies still fail before upload. The worker creates a missing RAM status file, restores an existing regular file or removes the created file after two minutes, and refuses unsafe file types. Complete status records are published by rename; bounded polling tolerates unavailable metadata while the worker starts, without retrying uploads or treating missing metadata as success. Physical installation testing subsequently launched the worker and returned a session-matched FAIL before persistent writes. The status channel is therefore physically observed; installation with managed-script replacement and subsequent live verification have now passed on the tested 30B. That generic reply cannot identify the failed check.

No supplied dumps, proprietary binaries, or device-specific identity fixtures are included.

Failure diagnostics

--verbose logs complete outgoing and incoming HID reports (including padding and upload payloads) and transport errors on stderr, before reply validation. It adds no exchanges or retries. Named worker failures use compact Fnn/Pnn codes from a shared catalog, preserving the distinction between refusal before persistent writes and failure after writes began. Offline tests cover logging disabled/enabled, malformed replies, transport failure, argument/consent validation, stale-session refusal and error-stage reporting. Camera checks and canonical installed hooks are unchanged.

Managed-file diagnostics now distinguish starter versus erase hook and file type, stat failure, permission mismatch, content mismatch and comparison-command failure. Tests cover preserving an existing canonical starter while installing a missing erase hook. After a physical power cycle the developer observed F33 before writes; the supplied ADB-repaired image is not current and cannot identify the live conflicting file. The developer subsequently authorized explicit replacement of both managed scripts.

Optional managed-script replacement

install --accept-no-backup-space-risk --overwrite-managed-scripts permits replacement of differing system.sh and enabled/10-erase-fix.sh contents, including earlier tool-generated versions. Default installation still refuses differences. The flag is rejected for inspect/verify and never bypasses firmware, identity, file type, permissions, stability or readback checks. Existing originals are copied to camera RAM outside worker cleanup and rechecked before replacement; these copies are lost on reboot and are not exported backups. Other enabled scripts are preserved. Final checks and verify require exact expected bytes. Tests cover both replacements, original preservation, other-hook preservation, partial-copy refusal, idempotency, strict verification and CLI consent.

Physical installation and verification confirmed

The supplied installation log reports current-session DONE after both scripts were written and checked. The subsequent verification log reports fresh-session LIVE, confirming expected installed bytes and the active 0x1000 erase-size correction; verify does not apply that correction. Tested binary: ce33161. This establishes the replacement route on the developer's previously modified 30B, not a pristine-stock installation or independent full-flash readback. The developer also confirmed normal camera-feed operation after installation and verification. Status cleanup timing has not been separately confirmed. Documentation and console guidance now require a full printer power cycle; a shell reboot may leave the camera powered. No attached logs or firmware were uploaded to the repository.