HID++ dans Logitech : stockage de 2 octets dans le registre DPI

Stockage de données dans les registres de souris Logitech via HID++

La souris Logitech MX Vertical utilise une mémoire flash pour sauvegarder les paramètres DPI entre les appareils. Cela a ouvert la possibilité de la transformer en un dispositif de stockage de données de 2 octets. Un outil basé sur Rust a permis d'énumérer 33 propriétés de l'appareil via le protocole HID++ 2.0, construit au-dessus de USB HID.

Le protocole fonctionne avec une table de propriétés : un identifiant de propriété stable (par exemple, 0x2201) est lié à un index de modèle de souris (par exemple, 0x12). Les requêtes sont formées sous forme de paquets : ID de rapport, index de l'appareil, index de la propriété, ID de fonction et paramètres (jusqu'à 3 octets). Les réponses arrivent dans un format similaire.

La plupart des propriétés ne sont pas documentées. Les plus prometteuses étaient TemplateBytesNVS (0x1eb0) et PersistentRemappableAction (0x1c00), mais elles ne répondaient pas aux requêtes ou étaient bloquées par IOHIDManager sous macOS. Ce dernier rejette silencieusement les rapports longs sans erreur, nécessitant un contournement via IOKit.

Analyse des registres et recherche de stockage

Le registre du nom de l'appareil accepte les écritures mais les ignore, renvoyant "MX Vertical". Le registre DPI (u16) s'est avéré fonctionnel : il accepte n'importe quelle valeur sans validation. L'écriture de 0x6869 persiste lors du passage d'un ordinateur à un autre au sein d'une même session.

Lorsque la souris est éteinte/allumée, la valeur revient à celle par défaut. L'écriture n'affecte que le DPI actif, pas la valeur par défaut.

Le test d'autres registres (0x1e, 0x1f, 0x18xx) n'a pas donné de stockage persistant. Le DPI par défaut est probablement stocké dans une partie fermée du firmware ou n'est accessible que via les outils propriétaires de Logitech.

Caractéristiques clés du stockage de session :

• Fonctionne uniquement lorsque la souris est sous tension.
• Inter-ordinateurs : déplacer le récepteur Unifying préserve les données.
• Capacité : strictement 2 octets (u16).
• Aucune validation : toute valeur de 0 à 65535.

Leçons du reverse engineering HID++

L'enquête a révélé des différences entre la table de fonctionnalités et l'index de fonctionnalité. La recherche inverse de IFeatureSet chez Logitech est défectueuse. La documentation couvre la moitié des propriétés ; le reste est exploré par expérimentation.

macOS IOHIDManager bloque silencieusement les rapports non standard. L'écriture dans PersistentRemappableAction nécessite des notifications ou un accès bas niveau.

Avantages de l'approche Rust :

• Dump complet des propriétés sans dépendances au SDK Logitech.
• Prise en charge de toutes les souris avec récepteur Unifying.
• Échange par lots pour le débogage : requête/réponse en temps réel.

L'objectif—stockage persistant—n'a pas été atteint, mais des connaissances sur les protocoles et le comportement du système d'exploitation ont été acquises.

Points clés à retenir

• HID++ 2.0 utilise des indices de propriétés dynamiques liés au modèle de l'appareil.
• Le registre DPI est le seul stockage de session de 2 octets accessible sans validation.
• macOS bloque les rapports HID longs via IOHIDManager ; contournement via IOKit.
• 33 propriétés dans la MX Vertical, la moitié non documentées.
• Le code de l'outil est universel pour les souris Logitech Unifying.

— Editorial Team