ハクソク

世界を動かす技術を、日本語で。

コーデックスがSamsungテレビをハッキングした

概要

  • 本記事はAI(Codex)を使ったSamsung TVのハードウェアハッキング研究の記録
  • 既存のブラウザシェル権限からroot権限への昇格をAIが自動で達成するかを検証
  • 研究環境・制約・攻撃手法・AIとのやりとりを詳細に解説
  • 物理メモリアクセスを利用した権限昇格の実例を紹介
  • AIによる自律的な脆弱性発見とエクスプロイト実行の可能性を示唆

AIによるSamsung TVハッキング研究

  • OpenAIとの協力によるAIを活用したハードウェアデバイスハッキングの実験
  • TV本体や周辺機器に重大な損傷は発生せず、リモート再起動程度の影響のみ
  • ブラウザアプリ内のシェル権限からroot権限獲得までのプロセスをAI(Codex)に委任
  • Codexが行った主なタスク
    • ターゲットデバイスの列挙・攻撃面の特定
    • ベンダードライバソースの監査
    • 物理メモリプリミティブの検証
    • Samsung独自制約への対応
    • root化成功までの繰り返し自動化

実験環境構成

  • ブラウザシェル:TV上のブラウザアプリ権限で既にコード実行可能
  • コントローラーホスト:ARMバイナリビルド・ファイルサーバ・シェルセッション制御
  • シェルリスナー:tmux経由でコマンド注入・ログから結果取得
  • 一致するソースコード:KantS2ファームウェアのソースツリー
  • 実行制約:静的ARMv7バイナリ必須、未署名バイナリは直接実行不可(Tizen UEP制約)
  • memfdラッパー:UEP回避のため、メモリ上の匿名ファイルとして実行

Codexの操作ループ

  • ソースコードとセッションログの調査
  • コントローラー経由でTVへコマンド送信
  • ログから結果取得
  • 必要に応じてヘルパーバイナリをビルド→TVへ転送→memfd経由で実行

権限昇格のアプローチ

  • 目標:「ブラウザアプリ権限」から「root権限」への昇格
  • 脆弱性の発見と検証はAIに一任、具体的なバグやエクスプロイト手法の指示は無し
  • 脆弱性要件
    • ソースに存在し、デバイス上でも確認可能
    • ブラウザシェルから到達可能な攻撃面であること

重要な発見とエクスプロイト

  • /dev/ntksys:物理アドレスとサイズをユーザ空間から受け取り、物理メモリをmmapでマッピング可能なカーネルドライバ
  • /dev/ntkhdma:DMAバッファの物理アドレスを非特権プロセスに返却する補助プリミティブ
  • udevルールにより/dev/ntksysがworld-writableとなっている重大設計ミス
  • Codexによる手順
    • ntkhdmaで物理アドレス取得→ntksysでマッピング→ユーザ空間から物理メモリ読み書き検証
    • カーネルのcred構造体(プロセスの権限情報)をRAMスキャンで特定し、IDフィールドをゼロクリア
    • シェル再起動でroot権限化を達成

AIとのリアルなやりとり例

  • コマンド引数の扱いや、ビルド・デプロイ・実行パスの混乱
  • tmuxセッションやサーバIPの誤認識
  • 操作ミスによるTVフリーズ・再現要求
  • 人間らしいフィードバックや修正指示

実験の意義

  • コントロールパスとソースツリー、ビルド環境をAIに提供し、AI自身が調査・検証・攻撃を反復
  • 既存のシェル権限(初期侵入済み)からrootまでAIが自律的に到達可能かを検証
  • 次のステップとして、AIによるさらなる自動化攻撃の可能性を示唆

まとめ

  • AI(Codex)は、限定された権限(ブラウザシェル)からroot権限昇格までの一連の攻撃チェーンを自律的に構築・実行
  • ソースコード監査・物理メモリアクセス・カーネル構造体の特定・権限改竄までを自動化
  • セキュリティ設計ミス(world-writableな物理メモリマッピングドライバ)が重大なリスクとなり得る事例
  • AIによる自動脆弱性発見・エクスプロイトの現実的な脅威を示唆
  • 今後はAIによるさらなる自動化・攻撃の進化が懸念される

Hackerたちの意見

ちょっとクールで少し怖いニュースだね。サムスンのテレビは過去10年間、めちゃくちゃハッキングしやすかったから、ブラウザにアクセスできるGPT-2がサムスンをハッキングしても全然驚かないよ!
これはかなりの歴史修正だね。GPT-2は指示に従ったり、会話ができるわけじゃなかったし。
ここでのポイントは、ファームウェアのソースコードを提供することで、脆弱性を見つけられるってことだね。
それはかなり大きなチャンスだね!
マシンコードを読むのはどれくらい難しいんだろう?これらのモデルはヒントとして人間の言語にかなり依存してるのかな?
ファームウェアのバイナリを持ってて、ghidraとかで分析するのはそんなに遠いステップじゃないよね。
Codexを使って本当に楽しい「ハッキング」セッションをしたよ。ハッキングって言うほどのことじゃなくて、ただTP-Linkが設けたフェンスを飛び越えて、ルーターを所有して、ネットワーク内で管理者パスワードを知ってただけなんだ。でもTP-Linkは本当に色々試して、APIを通じて自分のルーターにアクセスできないようにしてた。すごく壊れたカスタム認証と暗号化スキームで賢くなろうとしてたみたい。Codexを使って半日くらいかかったけど、最終的には自分のルーターにアクセスするためのきれいなPython APIができたよ。テスト済みで信頼性もあって、美しいPrometheusメトリクスも出力できる。こういう会社には、顧客と企業セクションを分けようとする意欲的なプロダクトマネージャーがいると思う。人間が使えないAPIを作って、200%無駄な「セキュリティ・バイ・オブスキュリティ」を追加することでね。
何かアドバイスある?似たようなことを試したけど失敗したんだ。私のルーターにはバックアップ/リストア機能があって、暗号化されたエクスポートがあるから、それを使って全ての状態を制御したり、少なくとも確認できると思ったんだけど、私もCodexも暗号化を解読できなかったんだ。
これはいいブログや要約になりそうだね。
これには絶対興味あるな。年始にTP Linkに移行したけど、全体的には満足してる。ただ、ルーターとアプリ以外でやり取りできるようになりたいんだよね。
ずいぶん前に、同じ理由でtmpcliのPython版を書いたことがあるんだ。数年前にちょっと改善したけど、それ以来触ってない。Codexがどんな方法論を考えたのか気になるな。モデルが本当に良くなってからは再訪してないし。アイデアとしては、tmpServerがlocalhostで待ち受けてて、dropbearが管理者権限でポートフォワーディングを許可するって感じ(-Nを指定する必要があるよ)。そのプログラムはデバイスに完全にアクセスできて、Tetherアプリが主にデバイスとやり取りするために使ってるAPIなんだ。https://github.com/ropbear/tmpcli
似たようなことをやって成功したことがあるよ。ウェブUIを使ってリクエストを.harファイルに記録して、それを分析用に提供するのは、僕にとっていいスタートポイントだった。アシスタントなしだと比べ物にならないくらい速かったよ。
興味があれば、TP-Linkのハードウェアにオープンソースのファームウェアを再フラッシュするのもアリだよ。もっと自動化に優しいやつね。最初はちょっと怖かったけど、友達がやり方を教えてくれて、意外と簡単でストレスフリーだったよ(もちろん、一般的にサポートされてるルーターの場合ね)。
これ、Smiirlのフリップカウンターを持ってるんだ。ウェブUIなしのOpenWrtのバージョンが動いてるけど、APIを提供するためのuhttpdがあるんだ。Mythosがエクスプロイトを見つけて、SSHを有効にするのを手伝ってくれるといいな。今は簡単なAPIスイッチが無効になってるから、オンにできないんだ。 https://www.smiirl.com/en/counter/facebook/5d/
それをどうやってやったかを共有できないのは残念だね。DMCAのセクション1201に引っかかって、連邦刑務所で何年も過ごすリスクがあるから。
> 「それはハッキングじゃない、何も壊してない」 それは「ハッキング」という言葉の狭い解釈だね。私たちは「Hacker News」っていうサイトにいるんだから。みんなが壊そうとしてるわけじゃないよ。
これほどクールではないけど、Claude CodeにBluetoothデバイスを見て「楽しいこと」をしてくれって頼んだ時は楽しかったよ。娘の部屋にある安いRGBライトを見つけて(リモコンにBluetoothを使ってるなんて全然知らなかったし、全くセキュリティもなかった)、虹色のエフェクトを作ってくれた。それからプロトコルを文書化してくれたから、必要なら自分でリモコンを作れるようになったよ。
ここで「楽しい」って言葉が適切かどうかはわからないな!
Claude Opus 4.5に、エンドポイント管理ソフトのために未文書のAPIを探してもらうよう頼んだんだ。自動修正をして、サービスデスクへの呼び出しを減らしたかったから。1時間試したら、今まで見たことないのが2つ見つかったよ。これが.netで書かれてるから、デコンパイルしてもっと見つけるのも簡単にできそうだな。
Opus 4.7がやっとLogitechのマウスをレシーバーと正しくペアリングする方法を見つけてくれたよ。4.6やGemini 3.1ではできなかったのに、笑っちゃうね。
弱いTVのOSをフルソースでハックしたんだ。次のレベル、つまりメインコントロール(音量、入力、色合い、アスペクト、ファームウェアなど)へのフルアクセスは、LLMにはまだ理解が難しすぎるね。
もしかしたら、CodexにスマートTVから広告や電話ホーム機能を取り除いてもらえるかも?
Codexがソースコードにアクセスできたことは重要だね。現在フロントページにある別のコメントスレッドでは(https://news.ycombinator.com/item?id=47780456)、クローズドソースであることがAIを使った脆弱性の発見や悪用に対して実質的な利益を提供しないという意見が繰り返し述べられている。だから、Codexがソースコードにアクセスできない状態でどうなるかを見るのは面白いと思う。
ソースコードを持ってるのよりも、さらに2つのレベルがあるんだ。1つはファームウェアのバイナリを持ってることで、AIがデコンパイルして理解できる。最悪なのは、今私が直面してる状況で、ファームウェアのバイナリにアクセスできなくて、ファームウェアがPCBに保存されてて、チップクリップを使って強制的に取り出すのを防いでるから、完全に盲目なんだ。(完全にリモートで試みるのと同じようにね)
> [1] ブラウザの足場: すでにテレビのブラウザアプリのセキュリティコンテキスト内でコード実行ができてたんだけど、これって著者が言ってるのは何を意味してるの?テレビ上で動いてるウェブブラウザのことを言ってるのかな?
そうだね。歴史的に見ても、ブラウザはロックされたデバイスを制御する手段になってきた。ゲーム機にとっては特に役立ってるよね。PSP、Vita、Switch、Wii、DSはみんなブラウザの脆弱性を利用して、より恒久的でシステム全体に影響を与えるエクスプロイトを実行してきた。
Samsungのスマートテレビをダムテレビに変えられるなら、あるいは入力選択と基本的な音量調整ができるモニターにするだけでも、絶対やりたいな。
新しく手に入れたLGのスマートテレビも同じ感じだよ。webOSが好きかもって思ったけど、実際は全然ダメだった。だから、ネットに繋がないことにしたし、WiFiのパスワードも教えないことにした。
そうなんだ。最近、ソニーのブラビアスマートテレビが壊れちゃった。ホームページに入るとすぐにクラッシュするから、OSが動かせない。入力遅延がすごくて、2000年代初頭の古いハードウェアを使ってるみたい。画質設定をいじってるとクラッシュして、勝手にデフォルトに戻されちゃうから、実質的に設定を変えられない。これをモニターとスピーカーに分解できたらいいのに…画面自体は完璧なのに、OSのせいで廃棄物になっちゃった。