クロードがガーミンのBLEプロトコルをリバースエンジニアリングし、ネイティブランニングセンサーを偽装するのにどう役立ったか

Redditユーザーが、Claudeを使ってGarmin統合における2つの難題を解決した方法を公開しました。1つは、非Garmin胸部センサーをFenixウォッチでネイティブのGarminストラップとして認識させること、もう1つは、単一のBLEチップを2つのデバイスとして同時に認識させることです。元の投稿では、プロセス、AIの強みと弱み、そして2つの詳細なブログ記事へのリンクが紹介されています。

問題1: Garminウォッチでランニングダイナミクスを偽装

Garminは、ランニングダイナミクス（上下動、接地時間）の計測を、非公開プロトコルを介して自社ストラップに限定しています。開発者はClaudeを使い、以下の手順でプロトコルをリバースエンジニアリングしました。

• 所有していたBluetoothスニファとESP32ボードをセットアップ
• 実際のGarmin HRMストラップをスニフし、ESP32でエミュレート
• 数百行のログを比較し、動作状態と非動作状態の1バイトの違いを特定
• Gadgetbridgeのチェックサムおよびフレーミングコードを移植
• 57,000の逆コンパイルファイルをgrepし、プロトコルを解読するフィールド番号を発見

Claudeはコード作成と分析を担当しましたが、プロトコルの方向（どちら側が何を送るか）を逆に解釈し、誤った仮定で数日間進んでしまい、ユーザーが修正を余儀なくされました。結果として、ランダムデータを送信するだけのESP32でも、Fenixウォッチはネイティブストラップと同様にランニングダイナミクスを表示するようになりました。

問題2: デュアルBLE ID切り替え

Garminウォッチでは、単一のBLEセンサーがウォッチのネイティブHRMとGarmin Connect IQアプリの両方に同時にサービスを提供できないことが多く、接続が競合して切り替わりが発生します。ClaudeはBLE規格のトリックを提案しました。同一チップから2つの異なるMACアドレスを提示し、接続中にアドレスを切り替える方法です。開発者のブログ記事では、nRF52832がチップのドキュメントで禁止されているにもかかわらず、ライブリンクを切断せずに2つのIDを切り替える方法が説明されています。これにより、多くのConnect IQ開発者が長年悩まされてきた問題が解決されました。

Claudeの役割: 強みと弱み

ユーザーは、Claudeが以下の2点で優れていたと述べています。

• 検索の集約: ユーザーが知らなかったデュアルID切り替えを知識として持ち、その手法を提案した。
• 単純作業: diffの実行、コードの移植、逆コンパイルファイルのgrepなど。

しかし、方向性に関しては苦戦し、プロトコルを逆に解釈して誤った仮定で数日間進みました。ユーザーは、幻覚を防ぐためにテストや静的データ、検証が不可欠であると強調しています。

詳細情報

ユーザーは、プロトコルと実装の詳細を含む2つの詳細な記事を公開しています。

• BLE ID切り替え: Two BLE identities, one nRF52832
• Garminランニングダイナミクスのリバースエンジニアリング: Reverse-engineering Garmin HRM600 running dynamics