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

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

2026年4月16日原文(blog.calif.io)

概要

  • 本記事は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ファイルに記録して、それを分析用に提供するのは、僕にとっていいスタートポイントだった。アシスタントなしだと比べ物にならないくらい速かったよ。

Hacker Newsで議論の続きを見る