WiFiの秘密、UARTロックダウン、そして破損したフラッシュメモリチップの物語

親愛なる仲間の皆さん、前回の投稿で発表したように、私たちの愛する神デバッガーは、光を帯びたオペコードをその謙虚な僕に投げかけ、私たちの寺院に新しい説教をもたらしました。どうぞ、座って、私たちのフクロウの一羽が、その義理の兄弟と共に、Eufyエコシステムの次のコンポーネント、すなわちEufy HomeBase 2を解剖するために進んだ物語を聞いてください。 免責事項という名の祭壇の足元での祈り Homebase3ではなくHomebase2に分析を集中したのは、前回の記事「From your doorbell to your home network」で説明したように、私の街で展開されているバージョンであり、購入するのが最も簡単だったからです。ここで分析するファームウェアバージョンは3.4.2.2h（2026-06-05 18:45:48）です。 私が「ハードウェア」に関連するものを触るのはこれが初めてです。私は常にインターネットからダウンロードできるファームウェアで脆弱性検索を行ってきましたので、私が犯した罪はご容赦ください。 重要!!! この記事を読む前に、必ず前回の記事をお読みください。 目次 前回の記事と同様に、ここではさまざまなトピックを扱います。そのため、この仲間のメンバーの中には、特定のセクションに興味がなく、興味のある部分に直接スキップしたい人もいるかもしれません。そのため、この祝福された提供物、目次を提示します。 0x00 ファームウェア抽出。 ファームウェアがどのように抽出されたか（そしてフラッシュメモリの一部をどのように損傷させたか）の説明。 0x01 WiFi認証情報生成アルゴリズムの特定。 OCEAN_XXXXXX管理Wi-FiのWi-Fi認証情報を生成するために使用されるアルゴリズムの逆エンジニアリング。 0x02 UARTロックダウンへのゴムホース処理。 UART経由でシェルを取得するために、バックドア化されたU-Bootイメージを再フラッシュする。 0x03 デバッグ目的のファイルシステム管理。 リカバリイメージは限られているため、メインバイナリを実行するにはいくつかのファイルシステムの工夫が必要です。 0x04 最終的な言葉。 AI時代の記事執筆に対する熱意の欠如を共有します。 0x00 ファームウェア抽出 この物語の前章で、Homebaseのフラッシュメモリがボードに直接はんだ付けされており、ファームウェアをダンプするためにテストフックを取り付けるためのピンが露出していなかったため、ドアベルのファームウェアしか抽出できなかったと述べました。 当初、それをはんだ付けしないつもりでした（最終的には説明するように必要になりました）ので、追加のハードウェアを入手するまで待たなければなりませんでした。 Craig S. Blackie氏が、Winbond 25Q256JWEQ（WSON8 8.6mm）に必要なサイズのバネクリップを教えてくれました。 クリップが届いた後、私は想像できる限り最も場当たり的なセットアップを作成しました。ラバーバンドを使用してクリップを固定しながら、ドアベルで行ったのと同じように、Raspberry PiのSPI0インターフェースを使用して読み取りを行いました。 読み取りを3回実行しましたが、3回ともチェックサムが異なり、通常は問題があることを示します。 ダンプを検査した後、それらがゴミであり完全に役に立たないことにすぐに気づきました。 ドアベルとは異なり、この場合、読み取り操作に供給された電力は、メモリと相互作用するボード上の他のコンポーネントもアクティブにしたため、ファームウェアを抽出するには、チップをはんだ付けで取り外し、オフボードで読み取る必要がありました。 私の義理の兄弟（Óscar Lestón）が、フラッシュメモリをはんだ付けで取り外す勇敢な魂でした（私はそれを試すことさえ怖かったです）。 メモリモジュールが取り外された後、ひどい見た目でしたが、ほとんど損傷していませんでした。 そして最終的に、Raspberry Pi SPI 0を使用して同じセットアップを複製してファームウェアをダンプしました。 今回は3つのダンプすべてに同じチェックサムがあり、「興味深いデータ」が含まれていました。 唯一の問題は… 64kbのブロックが消去されているか、読み取れないことでした。チップの抽出中に損傷した可能性が非常に高いです。 ほとんどのファームウェアはBinwalkを使用して抽出できました。 XZストリームが多かったため、7zを使用してすべてを大きなブロブに直接抽出するという愚かな（あるいはそうではないかもしれない）アイデアを使用しました（そして、そこでニードルを探してファイルをカービングすることを期待しました）。 0x01 WiFi認証情報生成アルゴリズムの特定 ファームウェアを通じて調査したかった主要な質問の1つは、OCEAN_XXXXXX管理Wi-Fiの認証情報を生成するための新しいアルゴリズムでした。なぜなら、2024年の論文に基づいた予想とは完全に異なっていたことに気づいたからです。特に、アルゴリズムが以前のように弱いかどうかを知ることに興味がありました。 前回の記事を書いた後、私はメンターとして義理の兄弟を失望させたことに気づきました。私は彼にGhidraと疑似Cの使い方を示しましたが、光と理性の道に導く代わりに。 私は罪を償い、radare2を描きました。 最初に、ファームウェアのどこにWi-FiネットワークのESSIDとパスワードが見つかるかを確認しました。 単純なgrepで、Wi-Fi名と認証情報（ドアベルの登録に使用されるアドホックWi-Fiと管理Wi-Fi）を含むNVRAM変数を特定するのに十分でした。