- Nest Thermostatの第1・第2世代機器向けカスタムファームウェアで、OMAP DFUインターフェースを通じてブートローダーとカーネルを置き換える構成
- フラッシュ後、機器はNest/Googleサーバーとの接続を停止し、独立したNoLongerEvilプラットフォームと通信するように切り替わる
- ネットワークトラフィックをリバースエンジニアリングされたAPIサーバーへリダイレクトし、既存機能を維持しながらユーザーデータと設定を完全に制御可能
- インストール手順は、DFUモード移行、ブートローダー（x-load、u-boot）およびカーネル（uImage）のフラッシュ、アカウント登録と機器連携の段階で構成
- クラウド依存からの解放と機器の所有権回復を目標とし、オープンソース公開とright-to-repair運動への支持を明示
概要
- このプロジェクトは、Nest Thermostatにカスタムファームウェアをインストールするためのツールとイメージを提供
- OMAP DFU（Device Firmware Update）インターフェースを使ってブートローダーとカーネルを置き換える
- DFUモードでのみ新しいファームウェアを受け入れ可能
- フラッシュ後、機器はNest/Googleサーバーと通信せず、NoLongerEvilプラットフォームに接続
- これにより、ユーザーはサーモスタットの動作とデータを完全に制御できる
動作方式
- カスタムファームウェアはブートローダーとカーネルの構成要素を変更し、ネットワークトラフィックを指定サーバーへリダイレクト
- そのサーバーはNest APIをリバースエンジニアリングした複製サーバーで、機器を独立動作させられる
- 通信レイヤーを横取りし、機器が公式のNestインフラに接続されているかのように認識させる
- この方式により、既存ソフトウェアとの互換性を維持しつつ、Googleクラウドへの依存を排除
インストール手順
- リポジトリをクローンした後、OSごとに**必須パッケージ（libusbなど）**をインストール
- Linux:
build-essential, libusb-1.0-0-dev, gcc, pkg-config
- macOS: Xcode Command Line ToolsおよびHomebrewベースのlibusbをインストール
build.sh を実行するとOSを自動判別し、omap_loaderツールをビルドinstall.sh 実行前に機器をDFUモードへ移行する必要あり
- 充電状態を確認（50%以上）、壁面から取り外し、USB接続、再起動（10〜15秒長押し）
- DFUモード移行時に自動でx-load、u-boot、uImageをフラッシュ
- 起動完了後、NoLongerEvilロゴが表示され、約3〜4分かかる
- Webサイト nolongerevil.com でアカウント登録後、機器を連携
- Nest機器でSettings → Nest App → Get Entry Codeからコードを確認
- ダッシュボードにコードを入力すると機器接続が完了
フラッシュされる構成要素
- インストール時に3つの主要バイナリをフラッシュ
- x-load.bin – 第1段ブートローダー（X-Loader for OMAP）
- u-boot.bin – 第2段ブートローダー（Das U-Boot、アドレス 0x80100000）
- uImage – Linuxカーネルイメージ（アドレス 0x80A00000）
- フラッシュ後、機器は0x80100000（u-boot）から実行を開始
セキュリティと注意事項
- このツールは機器のブートプロセスに対する低レベルアクセスを提供
- ユーザー所有の機器でのみ使用を推奨
- 誤ったファームウェアは機器破損（文鎮化）のリスクあり
- 実験的ソフトウェアのため、暖房・冷房に不可欠な機器では使用しないことを推奨
クレジットとオープンソースの約束
- 基盤技術は複数のセキュリティ研究者の研究に依存
- grant-h / ajb142: OMAP USBブートローダーツール
omap_loader
- exploiteers (GTVHacker): Nest DFU Attack研究により第1・第2世代機器でのカスタムファームウェアの可能性を実証
- FULU および支援者たち: Nest Learning Thermostat Gen 1/2 バグバウンティを支援
- プロジェクトは透明性とright-to-repair運動を支持
- ファームウェアイメージとバックエンドAPIサーバーコードは近日中にオープンソースとして公開予定
- コミュニティが独自インフラを監査・改善・ホスティングできるよう支援
参考資料
1件のコメント
Hacker Newsの意見
ボイラーが OpenTherm をサポートしているなら、SAT温度調節器プロジェクト を試してみることを勧める
天候補正、低負荷補正、PID制御が可能で、温度センサーが対応する精度（私の場合 ±0.02°C）で制御できる
Home Assistant で操作しつつ、省エネと快適さを同時に得られる
リアルタイムデータは Grafanaダッシュボード や Emoncms で見られる
たとえば Ecobee はボイラーの多段制御をサポートしておらず、ヒートポンプとも連携されないため、部屋ごとの温度の偏りが生じる
いつか家全体に HA温度センサー を設置して、時間帯ごとにどのシステムを優先して動かすかを自動で判断させたい
結局、OpenTherm の試みはそこで終わった
これは単に Google の代わりに NoLongerEvil という別のクローズドサービスを使っているように見える
名前が何であれ、彼らが信頼できるかどうかは分からない。
本当に信頼できるようにするには、完全なオープンソースのファームウェアとバックエンド が必要だと思う
現状は Google ファームウェアをハックしてトラフィックを別サーバーに向けているレベルなので、セルフホスト可能なバックエンド とビルドプロセスが公開されることを望む
修正: 近いうちにバックエンドもオープンソースとして公開予定とのことで期待している
完璧ではなくても、死んだ機器を再び使えるようにするのは意味がある
Nest コントローラーから Minecraft サーバーまで 軽量 Kubernetes で管理し、必要なときにノードを差し替えるような運用をしたい
現時点では単に クローズドサービスに接続されるファームウェアイメージ にすぎない
どこに接続するかも変更できず、プライバシーポリシー もない
ログインは Microsoft 傘下の GitHub アカウントで行い、認証は clerk.com が処理する
近いうちにオープンソース化される予定とのことなので待ってみる
まだプライバシーポリシーがないのは初期段階だから理解できる
ダッシュボードサイトの "Open Source" ページ にはファームウェアしかなく、サーバー側コード はない
ファームウェアだけでは完全なフリーソフトウェアとは言いがたい
修正: よく見ると、近いうちにバックエンドもオープンソースとして公開されると書かれている
関連GitHubイシュー
「このファームウェアを暖房・冷房に必須の温度調節器に使わないこと」という警告がある
以前、温度調節器の故障で 室内温度が危険なレベルまで上がった経験 があるので、こういう警告は真剣に受け止めるべきだ
私は何十年も問題なく動いている アナログの Honeywell 丸形温度調節器 を使い続けるつもりだ
私は別のアプローチを取って、新しいPCBを自分で設計 した
100% ファームウェア制御できるように作ってあり、LCDインターフェースのリバースエンジニアリング過程 を共有した
Cody のエクスプロイトによって完全に新しいファームウェアを書き込めるようになることを期待している
このプロジェクトにはぜひ成功してほしい
以前 Nest 1世代・2世代の開発チーム と一緒に働いていたが、そのチームは製品に本気だった
彼らがこんな形でサービス終了を決めたはずはない
私たちがいた頃ですら 意見は反映されなかった
「私たちは 透明性と修理する権利の運動 に尽力している」という文言を見て期待している
環境を大事にすると言っていた会社が、こんな形で ユーザーの機器をゴミにしたこと には本当に呆れる
単にクラウド費用を節約するか、新製品を売るための決定にしか見えない
こうした企業は環境より利益しか追わない。
しかも一部は 国際紛争や人権問題 にも関与している
UN報告書リンク
クラウド依存の少ない温度調節器 を探している
Nest を2台使っているが、あまりに不便なので、Home Assistant と直接連携できる製品が欲しい
WiFi + API の両方をサポートする製品はほとんどなく、Venstar だけが一応可能だが、不安定な WiFi モジュール のせいで諦めた
ファームウェア構造も独特なので、もうこれ以上試していない
Home Assistant でも HomeKit 連携で問題なく動作する