Wie Claude dabei half, Garmins BLE-Protokolle zu dekompilieren, um einen nativen Laufsensor zu fälschen

Ein Reddit-Nutzer dokumentierte, wie er Claude nutzte, um zwei schwierige Garmin-Integrationsprobleme zu lösen: einen Nicht-Garmin-Brustsensor als natives Garmin-Band auf einer Fenix-Uhr erscheinen zu lassen und einen einzelnen BLE-Chip als zwei Geräte gleichzeitig auftreten zu lassen. Der Quellbeitrag beschreibt den Prozess, die Stärken und Schwächen der KI und verlinkt auf zwei ausführliche Blogbeiträge.

Problem 1: Gefälschte Laufdynamik auf einer Garmin-Uhr

Garmin sperrt Laufdynamikmetriken (vertikale Oszillation, Bodenkontaktzeit) über undokumentierte Protokolle auf seine eigenen Gurte. Der Entwickler setzte Claude ein, um das Protokoll zu reverse-engineeren, indem er:

• Einen Bluetooth-Sniffer und bereits besitzte ESP32-Boards einrichtete
• Einen echten Garmin-HRM-Gurt abhörte und ihn dann mit einem ESP32 emulierte
• Hunderte Logzeilen verglich, um das einzelne Byte zu finden, das funktionierende von nicht funktionierenden Zuständen unterscheidet
• Gadgetbridges Prüfsummen- und Framing-Code portierte
• 57.000 dekompilierte Dateien durchsuchte, um die Feldnummer zu finden, die das Protokoll knackte

Claude schrieb den Code und führte die Analyse durch, aber der Benutzer musste die Richtung korrigieren, als Claude das Protokoll umdrehte (welche Seite was sendet) und tagelang falschen Annahmen nachging. Das Ergebnis: Ein nackter ESP32 mit Zufallsdaten bringt eine Fenix dazu, Laufdynamik anzuzeigen, als käme sie von einem nativen Gurt.

Problem 2: Dual-BLE-Identitätswechsel

Auf Garmin-Uhren kann ein einzelner BLE-Sensor oft nicht gleichzeitig die native HRM- und Garmin Connect IQ-App der Uhr bedienen – Verbindungen kämpfen und flippen. Claude schlug einen Trick aus den BLE-Standards vor: Zwei verschiedene MAC-Adressen vom selben Chip präsentieren, indem die Adressen mitten in der Verbindung gewechselt werden. Der Blogbeitrag des Entwicklers erklärt, wie er einen nRF52832 zwischen zwei Identitäten wechseln ließ, ohne die Live-Verbindung zu unterbrechen, obwohl die Chip-Dokumentation davor warnt. Dies löste ein jahrelanges Problem für viele Connect-IQ-Entwickler.

Claudes Rolle: Stärken und Schwächen

Der Benutzer bemerkt, dass Claude in zwei Dingen herausragend war:

• Suchaggregation: Es wusste über Dual-Identity-Switching Bescheid, obwohl der Benutzer es nicht tat, und schlug die Technik vor.
• Schwerstarbeit: Den Diff durchführen, Code portieren und dekompilierte Dateien durchsuchen.

Aber es hatte Probleme mit der Richtung – es hatte das Protokoll rückwärts und baute tagelang auf falschen Annahmen auf. Der Benutzer betont, dass Tests, statische Daten und Validierung unerlässlich waren, um Halluzinationen zu erkennen.

Mehr erfahren

Der Benutzer veröffentlichte zwei detaillierte Berichte mit vollständigen Protokoll- und Implementierungsdetails:

• BLE-Identitätswechsel: Two BLE identities, one nRF52832
• Garmin Laufdynamik RE: Reverse-engineering Garmin HRM600 running dynamics