DIY療法のためのリバースエンジニアリングインスリンポンプ

約3年前、私は自分の心に非常に近いことに対する報酬を提供するWebサイト、つまりインスリンポンプとのリバースエンジニアリング通信について聞いたことがあります。 私はすでに、Medtronicポンプを使用して、 Loopと呼ばれる娘用のシステムを作成するのを手伝いました。そのために、通信をリバースエンジニアリングします（メドトロニックの主要な通信プロトコルのほとんどは、Carelink USBデバイスを使用してBen Westによってデコードされ、無線周波数を見つけて、追加の作業を行いましたプロトコル）。 しかし、Medtronicポンプは、体操中に数時間停止する必要がありました。 このオムニポッドポンプのチューブレス設計は私にとって興味深いものであり、すべてのツールを使用できました。

Omnipodシステムは、モジュール（ポッド）と制御ユニット（PDM）と呼ばれる小型の使い捨てポンプで構成されています。



PDMは無線でモジュールと通信し、モジュールには組み込みのインターフェースがないため、これは完全に無線制御されていることを意味します。 RileyLinkまたはその修正バージョンのみを使用して、Loopと完全に統合する可能性があります。

ジェームス・ウェディングは報酬を指名し、それは多くの注目を集め、そして仕事を手伝ってくれた適切な人々が注目を集めました。

ソフトウェア無線

SDRは素晴らしいツールです 。 彼はラジオの隠された世界を目に見えるようにします。 さまざまな種類のメッセージが絶えず放送されており、これらのツールを使用すると、メッセージを表示したり、メッセージを表示したりできます。 特定のデバイスからのメッセージを探している場合は、検索を開始する領域を知る必要があります。 これは、FCCの公開文書が役立つ場所です。

PDMのFCC文書RBV-019には、デバイスは433 MHz帯域で送信すると書かれています。 433 MHzの範囲でリッスンするようにSDRソフトウェアを構成すると、PDMからステータスを発行するときに次の信号が表示されます。



最終的にわかったように、これらの2本の明るい線は、 周波数シフトキーイング 、またはFSKと呼ばれる特定のタイプの変調を示しています。 つまり、信号の周波数は、送信される情報によって異なります。 ビット1は高い周波数として送信され（上段）、0はわずかに低い周波数で送信されます（下段）。 inspectrumツールを使用して、データを分析して1と0をより明確に認識できます。最初のメッセージの拡大図を次に示します。



これらのビットを抽出して、パケット全体として見ることができるように、Pythonスクリプトを作成しました。



この繰り返しパターンはプリアンブルの一部であることがわかります。 エネルギーを節約するため、受信機は多くの場合スリープモードに入り、定期的に起動して信号を確認します。 送信機は、短いリスニング期間のいずれかで受信機がキャッチするのに十分な長さでプリアンブルを送信します。 受信機がプリアンブルを聞くと、実際のデータが表示されるまで起動します。

実際のバッチデータを取得する前に、別のレイヤーを通過する必要があります。 元のビットと同じ方法で無線を介してデータを送信することはできません。これは、レシーバーが遷移を使用して、次のビットを待つ時間に同期するためです。 ゼロまたは1の長いセットがある場合、レシーバーが同期しなくなる可能性があります。 したがって、無線通信では通常、エンコーディングを使用して、十分な遷移があることを確認します。 Omnipod通信は、いわゆるマンチェスターコーディングを使用します。 各ビットは2ビットでエンコードされます。 1は10としてエンコードされ、0は01としてエンコードされます。

見つけるのに長い時間を要し、 Slackのopenomniチャンネルには多くの理論があり 、元のビットを繰り返してみました。 Mark Brighton 、 Dan Caron、および@larsonlrは、 RFCatとTi Stickを使用してパケットをキャプチャすることである程度の成功を収めています。 Evarist Kourjoはついにrtlomniというツールを作成し、rtl-sdr USBレシーバーを使用してパケットをリッスンしてデコードします。これは、TI Stickに基づく方法よりも非常に便利で信頼性が高いことが判明しました。

パケットデコード

実際のビットを受け取ったので、パッケージの構造を調べ始めました。 異なるモジュールと異なるコマンド間でどのビットが変更されたかに基づいて、次のような構造を作成しました。

CRC8

無線は理想的な伝送媒体とはほど遠いものです。 0が送信されたときに受信者に1を聞かせ、またその逆の場合、多くの異なる干渉源があります。 これがいつ発生したかを知ることは重要です。そのため、ほとんどのプロトコルはCRCと呼ばれるチェックサムを使用します。 受信者はデータを受信するとCRCを計算し、パケットの最後のバイトには送信者が計算したCRCが含まれます。 一致しない場合、受信者はパケットを破棄し、再送信を待ちます。

Omnipodプロトコルは、標準の8ビットCRCを使用しました。 彼を見つけたとき、私たちはメッセージを非常に理解していると判断しました。 ほんの少ししか知りませんでした...

メッセージ、CRC16

一部のメッセージは大きすぎて1つのパッケージに収まらないため、複数のパッケージに分割されます。 メッセージフォーマットをつなぎ合わせると、各メッセージの最後に別のビットセットがあり、16ビットCRCのように見えました。 しかし奇妙なことに、16ビットのうち5ビットが設定されることはありませんでした。 これがどのようにエンコードされるかを理解するために多くの異なる方法を試しましたが、何も機能しませんでした。

これが最初の大きな問題でした：メッセージ内の他の部分で作業を続けることができましたが、送信されている内容を理解するのにあまり役立ちません。また、自分で新しいパケットを生成することもできないため、進行が遅くなりました。

数ヶ月が過ぎてほとんど役に立たなかった。 最後に、2016年の冬、 @ lorelaiというニックネームのグループのメンバーは、ファームウェアを大規模なARMチップからPDMに正常にコピーし、退屈な逆アセンブリプロセスを開始したことを報告しました。CPU命令を受け入れ、セマンティック変数と関数名を持つ人間が読み取れるコードに変換します。 彼女は、データを送信するために使用されたさまざまな方法を見つけるのに素晴らしい仕事をしました。

無題のルーチンの1つを見て、テーブルからのCRC計算の標準的な実装のように見えることに気付きました。 また、テーブルには標準の16ビットCRCの値が含まれていました。 テーブルに独自の実装を作成し、通常のCRCのようにテストしました。 次に、関数がどのように記述されているかを注意深く調べました。 通常のCRC実装は次のようになります。

while (len--) { crc = (crc << 8) ^ crctable[((crc >> 8) ^ *c++)]; } 

実装は次のようになりました::

 while (len--) { crc = (crc >> 8) ^ crctable[((crc >> 8) ^ *c++)]; } 

違いに気づきましたか？ ビット単位の左シフト演算子と想定されていたものは、何らかの方法で右シフトとしてエンコードされていました。 これは間違いです。 破損したメッセージを特定するのが難しくなるため、独自のCRCアルゴリズムを無効にする理由はありません。

稼働しました！ そして、彼らは、メッセージのデコード、ボーラス[薬物]の送達のためのPDMからのセッションの記録、一時的塩基[一時基礎レートは、インスリン送達の増加または減少を決定します。 per。]、ファイリングの停止など。

シングルユース番号

すべてのインスリン配達チームは、メッセージの冒頭に4バイトのデータを持ち、それは何らかの暗号化のように見えました。 繰り返しになりますが、送信されたメッセージのコンテキストで解釈および分析するさまざまな方法を試しましたが、CRCではありませんでした（異なるメッセージでも同じ4バイトが表示されることがありました）。 そして時々、写真が繰り返されるのを見ました。 おそらく、データの複製を防ぐためのプロトコルの一部と思われました。 他のプロトコルでは、同様の機能はnonce （使い捨ての番号）と呼ばれます。

検討したオプションの1つは、特定のコマンドを再生するためのメッセージベースを記録することでした。 各モジュールのアドレスが異なっていたとしても、CRCの生成方法がわかったため、コマンドの古いコピーを取得し、メッセージに新しいアドレスを追加してCRCを再カウントできます。 この一回だけが、この戦略の使用を妨げました。 コマンドに関係なく、モジュールはシーケンス内の次のナンスのみを受け入れ、次のナンスを生成する方法を知りませんでした。

しかし！ 結局、PDMファームウェアが逆コンパイルされているので、そこを見るだけです！ そこで、PDMファームウェアを調査し、コード内のメッセージの生成を追跡し、これらの4バイトがどこにあるべきかを見つけました。 しかし、暗号化ナンスを計算する方法の代わりに、4つのINS.文字を見つけましたINS. 。 なんてナンセンス？！？！ まあ、どういうわけか、このメッセージ領域はパイプラインの後半で更新する必要があります。

PDMには、無線に近い別のチップがありました。 これは、モジュールで使用されたものと同じチップで、識別子はSC9S08ER48でしたが、インターネット上では文書化されていませんでした。 おそらく、インシュレットの注文用に作られたのでしょう。 このチップからファームウェアを削除できるかもしれません。 残念ながら、チップはブロックされ、ファームウェアのコピーが妨げられました。



仕事は再び遅くなりました...それは本当の行き止まりのようでした。 私たちはすべての精神的な努力をこのノンスに向けましたが、その背後にある数学には良い手がかりがありませんでした。 そして、（おそらく）秘密を保持していたER48チップはブロックされており、クラックに役立つ公開情報を見つけることは困難です。

X線写真

ER48を理解しようとして、Slackコミュニティの一部のメンバーは、X線撮影を提案しました。 それは本当にクールでしたが、残念ながら、新しい機会を開くことはできませんでした。


一般的なショット


詳細ショット

検死と射撃

ダン・キャロンは、英国ケンブリッジ大学の研究者であるセルゲイ・スコロボガトフ博士に頼ることに決めました。 Danは、ブロックされたチップからコードを抽出した経験があることを読み、私たちの問題を調べるように説得しました。 Skorobogatov博士は、超小型回路のリバースエンジニアリングにSEM（走査型電子顕微鏡）を使用する分野で研究を行いました。 彼はこれが可能であると示唆したが、それは高価であり、高価な機器を必要とし、結果を保証しない。 2016年の秋にNightscoutハッカソンで出会った後、最近Loopの使用を開始したJoe Moranは、プロジェクトの支援に同意しました。 彼は、シリコンバレーの会社であるNanolab Technologiesとチップを開いて写真を撮ることに同意し、NanolabとDr. Skorobogatovの仕事（および彼の個人的なモジュール）にも親切に資金を提供しました。

Skorobogatov博士は、Nanolabにさまざまな画像技術を適用して、既知の非侵襲的または半侵襲的方法で保護を破ることができるかどうかを調べるよう依頼しました。 その結果、多くの画像が表示され、その一部は非常に美しいものでした。 これらは、シリコンマトリックスの光学顕微鏡画像です。


光学顕微鏡下のマイクロ回路の一般的なビュー


光学顕微鏡下のマイクロ回路の一般的なビュー

走査電子顕微鏡を使用して、マトリックスの特定の領域の画像も撮影しました。 さまざまな電圧、さまざまな表面処理、さまざまな機器を使用します。


フラッシュセルのSEM画像。 データを表示しません

残念ながら、これらの画像はいずれもフラッシュメモリの実際の内容を示していません。

Dr. Skorobogatovには最後の1つの方法があり、失敗した場合にのみ使用できます。 これは特許取得済みの方法であり、その使用には大学の許可が必要でした。 Skorobogatov博士は最初のテストを行い、このチップのデータを読み取れることを確認しました。 しかし、続行する前に、NDAに署名する必要があったため、抽出されたファームウェアの内容を誰が受け取るかについて交渉が行われました。

最終的に、NDAはNightscout財団に署名し、メソッドおよびメモリ抽出の結果の不正開示を防止する責任を負いました。

この合意と作業の結果は、 Sergey Skorobogatov博士によって書かれた素晴らしい記事とファームウェアコードでした。 初めてコードにかなりの数のエラーがありましたが、開始するにはこれで十分でした。 ナイトスカウトの春のハッカソンで、誰かが解体を希望する場合、ジョーはみんなに目を向けました。 誰も手を挙げませんでした。 プロセッサの命令を理解可能なものに変えることは骨の折れる作業であり、その方法を知っている人はほとんどいません。 CPUのドキュメントを使用してアセンブラーを掘り下げようとしましたが、達成したことはほとんどなく、失望しました。 他の人々は、急速な進歩を期待して楽観的にファームウェアコードを要求し、タスクの規模と複雑さを認識し、静かに落ちました。


SC908命令の逆アセンブリの例

ジョーはアセンブラーでの幅広い経験もあり、この困難なタスクを実行し始めたことがわかりました。 7月、Skorobogatov博士は2回目のメモリ抽出操作を完了し、エラーは大幅に減少しました。 夏の間、Joe Moranは精力的に作業して膨大な数のプロセッサ命令を表示し、それらをモジュールの擬似コードの全体像に徐々に統合しました。

最後に、ハードウェアリバースエンジニアリングの専門家であるKen Shirriffが加わり、プロセスを大幅に加速しました。 ジョーとケンは一緒になって、ノンスをエンコードする関数を見つけるのに十分なコードを翻訳することになりました。 これは2017年9月に起こりました。

RileyLinkとループ

openomniのPythonスクリプトを更新しましたが、今度はRileyLink + iOSに焦点を合わせるため、OmniKitとRileyLinkのファームウェアアップデートに取り組み始めました。 私たちはプロトコルの基本を持っていると信じていましたが、残りは単なる詳細でした。 繰り返しになりますが、これからの金額を完全に過小評価します。



モジュールの変調とコーディングを処理する新しいファームウェアを作成する必要がありました。 また、メドトロニックではゼロがパケットマーカーの特別な終端であったため、ゼロを処理するためにRLの2つのチップが互いに通信する方法を書き直す必要がありました。 複数のポンプをサポートするためにループの多くを作り直さなければならず、ペアリング、非アクティブ化、およびエラー処理をサポートするための新しいインターフェイスも必要でした。 幸いなことに、 Nate Rackliftはこれをすべて可能にするためにLoopに強固な基盤を築きました。

その間、チームの形式を理解する作業が続けられました。 プロトコルの最も包括的な文書であるopenomni wikiにすべてが注意深く文書化されました。 Joe、Evarist、およびElkeJägerは、メッセージのデコードとページの更新において、長い間本当に素晴らしい仕事をしてきました。 SlackチャネルのさまざまなメンバーがPDMパケットとモジュールのキャプチャに貢献し、全体的なデコード作業を支援しました。

各チームの各コンポーネントが復号化するので、デコードは楽しい仕事で、多くの小さな勝利がありました。私はこの部分に取り組んで、ループにコードを徐々に追加するのが本当に好きでした。 2018年4月、私はSlackで、「プログラムされた基本スケジュールに従ってiPhone + RLを介してペアリングされたプライマリカニューレ挿入を行い、その後5台が病気になった」ことを共有しました。

RL 2.0ファームウェアは2018年7月に完成し、新しい配信がすでに行われています。 これらのボードをループおよびオムニポッドで使用できることが期待されていましたが、既存の915 MHzアンテナはあまりにも悪く、433 MHzで効果的に動作しませんでした。

夏の間、デコードと実装は大幅に進歩し、ループは徐々にパフォーマンスに近づいています。 ジョーは私に資金を提供して驚くべきことをしたので、私は仕事を辞めてこのプロジェクトに集中し、最終的に素晴らしいTidepoolチームに参加しました。 もちろん、DIYと医療技術の立法規制の分野では、私が取り上げないイベントがさらにありましたが、それは非常に興味深い夏でした！

スクリーマー

さらに多くの機能がドライバーに表示されたら、ループに接続し、時間通りに配信を自動的に構成する機能をオンにしました。 この段階では、内部モジュールチェックの一部で問題が見つかり、インスリンの供給を停止したときに、「派手な」モジュールがしばしば得られました。

しかし、これは解決可能な問題のようです。手動でコマンドを送信するときにループパッケージと元のPDMの小さな不一致を見つけ続けたため、すべてを修正すると「悲鳴」が止まることを提案しました。

ワークループ！

2018年10月3日に、JoeはLoopを実行するマネージドモジュールを導入し、最初のLoop Omnipodユーザーになりましたが、心配することを知っていたのですぐには教えませんでした。 彼が私に言ったとき、私はまだ心配していました。 モジュールがどのように機能するかを見て、機能を理解し、基本的なアルゴリズムは長い間テストされましたが、それでも...



1か月後、2018年11月のNightscoutハッカソンで、さらに数人の冒険者が自分で試してみることにし、コードが公開される前に30人以上に成長する小さな閉鎖テストグループの一部になりました。

残念ながら、3日間の使用が完了する前に発生することが多いモジュールの「悲鳴」に遭遇し、ループコマンドとPDMサンプルを慎重に比較しました。 このプロセスで、Elkeは特に役に立ちました。元のバージョンのコマンドを自動的にチェックするスクリプトを作成しました。 モジュールの断続的な動作は、5分ごとの通信に必要なバッテリーの増加に起因するのではないかと心配し始めました。


モジュールの電圧調整器のタップ、背面パネルのプラスチックに穴を開け、接着剤で

そのため、Arduinoを使用してモジュールの電源電圧を測定し、データを書き込み、視覚化のためにローカルデータベースに保存し始めました。 PDMとループを比較しました。


モジュールの供給電圧の長期的な変化

残念ながら、これも行き止まりになりました。 PDMを使用して大量のインスリンを注入すると、ループモジュールの寿命全体よりもモジュールの電圧を低くすることができ、モジュールを「叫ぶ」ことができませんでした。 ストレスは問題ではなく、何か他のものがあるはずです。


955 MHz（左）と433 MHzコイルアンテナ（右）を備えたRileyLinks

ある時点で、モジュールとのメッセージの交換に失敗した場合、モジュールはパケットを何度も再送して交換を終了しようとすることがあることに気付きました。 テスターのログにも多くの不具合があったため、アンテナの実験を開始しました。 両方の問題は、通信の品質に関連する必要があります。 さまざまなアンテナを試してインターネット上のさまざまな場所で注文することを計画しましたが、これが優先事項になるまでテストする時間はありませんでした。

RLエンクロージャーの内側に接続できる433 MHzの柔軟なアンテナがいくつかありました。 多くの場合、一部のシナリオではパフォーマンスが向上しますが、他のシナリオでは向上しません。 信頼性が低すぎます。 私がリールに着いたとき、それは非常に一貫して非常に驚くべき範囲で良いパフォーマンスを示しました。 RileyLinkの新しいケースを作成する時間です。

5分ごとに調整を行いながらメッセージングを削減する新しいアンテナといくつかの最適化により、悲鳴は非常にまれになりました。 おそらくPDMでのモジュールの通常の使用に匹敵します。 過去7,500時間のリアルタイムテストで、モジュールの94％が確実に完了しました。

テストとドキュメント

テストグループはゆっくりと成長してきました。新しいユーザーが絶えずシステムに参加し、見た目を変えてどの部分が混乱しているかを評価できました。 これらのテスターは多くの派手なモジュールに耐えて、Omnipodでループのパフォーマンスを改善するのに非常に大きな貢献をしました。 基本的に、彼らは問題報告と作業ログを送りました。

これらのレポートには、Elkeが作成したツールを使用して分析できるメッセージのログがあります。 歪んだコマンドを受け取った場合のアイデアを示し、ループとモジュールの相互作用の特定の部分に関する統計を収集することもできます。

Marion Barkerはテストグループに参加し、テストの進捗状況に関する特別なレポートと追加の統計情報を追加しました。また、高レベルの進捗状況を把握するために、失敗に対する成功モジュールの統計情報を使用することができました。

最後に、 Katie DiSimoneがテストグループに参加しました。 彼女は、複数のデバイスでLoopを使用するためのドキュメントでloopdocs.orgの大規模な再構築を開始しました。 Omnipodで動作するLoopのバージョンの待機は非常に長く、適切なドキュメントがなければ、同じ質問に圧倒されることは明らかでした。

新しいループ機能

Omnipodとの統合には、いくつかのインターフェース要素の再考と新しいコントロールの追加が必要でした。 モジュールはバッテリーを報告せず、これが発生した場合、ユーザーは低充電でほとんど何もできません。そのため、バッテリーレベルウィジェットを表示しても意味がありません。 さらに、ポンプのユーザーインターフェイスがなくても、ユーザーはボーラスをすばやくキャンセルできる必要があります。 戦車アイコンはメドトロニック戦車を描いていたので、リメイクしたかったのです。 タンクのレベルを示すモジュールのロゴを開発してくれたPaul Forgioneに感謝します。

謝辞

私たちがずっと前に設定した目標を実現するために、私たちがこの長い道のりを進んでくれたすべての人々に感謝します。 関係するすべてのイベントではなく、すべてのイベントに言及したわけではないことを知っています。 これは1つの記事では不可能であり、個人的な経験しかありません。 何時間かかったか想像するのは難しいです。 それらをすべて追加すると、衝撃的な数字になると確信しています。 Omnipod自体の作成に関する作業は言うまでもありませんが、これらはすべての努力を覆い隠しているようです。 みなさんありがとう。 さらに、これらの時間の多くは、そうでなければ家族と過ごすことになっていたでしょう。 妻と子供たちに時間を割いて理解してくれたことに本当に感謝しており、彼らにも感謝したいと思います。

注釈

Joachim Ornstedtは、openomniデコードへの貢献者の1人であり、おそらくomnipodとの最初の統合の作成者として言及する必要があります。 彼は、光学式文字認識（OCR）を使用してPDMからデータを抽出するデバイスを構築し、別のマイクロコントローラーを介して数字ボタンを物理PDMに接続しました。 このアプローチは拡張が困難ですが、非常にスマートであり、REに基づくソリューションで対処しなければならなかった多くの問題を回避します。 彼がどのように問題に対処し、デバイスをループで動作させるのにかかった時間のほんの一部で作業をセットアップしたかを本当に賞賛します。