HID++ bei Logitech: Speichern von 2 Bytes im DPI-Register

Datenspeicherung in Logitech-Mausregistern über HID++

Die Logitech MX Vertical Maus nutzt Flash-Speicher, um DPI-Einstellungen zwischen Geräten zu speichern. Dies eröffnete die Möglichkeit, sie in ein 2-Byte-Datenspeichergerät zu verwandeln. Ein Rust-basiertes Tool ermöglichte die Auflistung von 33 Geräteeigenschaften über das HID++ 2.0-Protokoll, das auf USB HID aufbaut.

Das Protokoll arbeitet mit einer Eigenschaftstabelle: Eine stabile Eigenschafts-ID (z.B. 0x2201) ist mit einem Mausmodell-Index (z.B. 0x12) verknüpft. Anfragen werden als Pakete formatiert: Report-ID, Geräteindex, Eigenschaftsindex, Funktions-ID und Parameter (bis zu 3 Bytes). Antworten folgen einem ähnlichen Format.

Die meisten Eigenschaften sind undokumentiert. Vielversprechend waren TemplateBytesNVS (0x1eb0) und PersistentRemappableAction (0x1c00), aber sie reagierten entweder nicht auf Anfragen oder wurden von IOHIDManager in macOS blockiert. Letzteres verwirft lange Reports stillschweigend ohne Fehler, was eine Umgehung über IOKit erfordert.

Analyse von Registern und Suche nach Speicher

Das Gerätenamenregister akzeptiert Schreibvorgänge, ignoriert sie aber und gibt "MX Vertical" zurück. Das DPI-Register (u16) erwies sich als funktionsfähig: Es akzeptiert beliebige Werte ohne Validierung. Das Schreiben von 0x6869 bleibt beim Wechsel zwischen Computern innerhalb einer Sitzung erhalten.

Wenn die Maus aus- und wieder eingeschaltet wird, setzt sich der Wert auf den Standard zurück. Schreibvorgänge beeinflussen nur den aktiven DPI, nicht den Standardwert.

Tests mit anderen Registern (0x1e, 0x1f, 0x18xx) ergaben keinen persistenten Speicher. Der Standard-DPI wird wahrscheinlich in einem geschlossenen Teil der Firmware gespeichert oder ist nur über Logitechs proprietäre Tools zugänglich.

Wichtige Merkmale des Sitzungsspeichers:

• Funktioniert nur, solange die Maus eingeschaltet ist.
• Computerübergreifend: Das Verschieben des Unifying-Empfängers bewahrt Daten.
• Kapazität: streng 2 Bytes (u16).
• Keine Validierung: Jeder Wert von 0 bis 65535.

Erkenntnisse aus dem HID++-Reverse-Engineering

Die Untersuchung zeigte Unterschiede zwischen der Funktionstabelle und dem Funktionsindex. Die Rückwärtssuche von IFeatureSet in Logitech ist fehlerhaft. Die Dokumentation deckt die Hälfte der Eigenschaften ab; der Rest wird durch Experimente ermittelt.

macOS IOHIDManager blockiert nicht standardkonforme Reports stillschweigend. Das Schreiben in PersistentRemappableAction erfordert Benachrichtigungen oder Low-Level-Zugriff.

Vorteile des Rust-Ansatzes:

• Vollständiger Eigenschaftsdump ohne Abhängigkeiten vom Logitech SDK.
• Unterstützung für alle Mäuse mit Unifying-Empfänger.
• Batch-Austausch für Debugging: Anfrage/Antwort in Echtzeit.

Das Ziel – persistenter Speicher – wurde nicht erreicht, aber Wissen über Protokolle und OS-Verhalten wurde gewonnen.

Wichtige Erkenntnisse

• HID++ 2.0 verwendet dynamische Eigenschaftsindizes, die an das Gerätemodell gebunden sind.
• Das DPI-Register ist der einzige zugängliche 2-Byte-Sitzungsspeicher ohne Validierung.
• macOS blockiert lange HID-Reports über IOHIDManager; Umgehung über IOKit.
• 33 Eigenschaften in der MX Vertical, die Hälfte undokumentiert.
• Der Code des Tools ist universell für Logitech Unifying-Mäuse.

— Editorial Team