【徹底解説】TCL TV 32S5400のroot化はなぜ難しい？USB接続・ブートループ復旧の罠と裏側

最近のテレビは「スマートテレビ」と呼ばれ、中身は巨大なAndroidスマートフォンとも言える構造を持っています。YouTubeやNetflixを見るだけでなく、有志が開発した非公式アプリを入れたり、システムを極限まで軽量化したり、不要なプリインストールアプリを消し去りたいと考えるギークなユーザーにとって、「root化（システムへの最高権限の取得）」は非常に魅力的なカスタマイズです。

しかし、安価で高性能なスマートテレビとして人気の高い「TCL TV 32S5400」などの機種において、root化は決して生半可な知識で手を出してはいけない茨の道です。「スマホでroot化できたからテレビでも簡単だろう」と高を括ると、文字通りテレビが「ただの黒い板（文鎮）」と化してしまいます。

今回は、TCL 32S5400のroot化がなぜこれほどまでに「難しい」のか、そして一度失敗した際に待ち受けるUSB接続経由での過酷な復旧作業について、システムの裏側を覗きながら誰にでも分かりやすく徹底的に解説していきます。

追記（2026年10月25日）：TWRPからMagisk.zipをインストールする方法（未検証）
1. もしできなかったら、ログ付きで教えてください
Android TVと強固なセキュリティ機構「AVB」の壁
恐怖の「ブートループ」とロゴマークの無限地獄
BROMモードとPreloaderの刹那
アナログな物理操作とタイミングの神業
最終手段の「UART接続」とターミナルソフトの罠
ファームウェアの入手性の悪さ＋暗号化
root化は「自己責任」という重い言葉の意味

追記（2026年10月25日）：TWRPからMagisk.zipをインストールする方法（未検証）

以下の本文は、root化・復旧に難航していた時点の記録です。

その後の調査では、32bit／64bitの実行形式の不一致やMagiskのバージョン差を確認し、MBOOT経由でのroot化に成功しました。

当時の原因の見立てと、後から確認できた結果については、後日の成功記事も合わせて参照してください。

TWRPを導入済みであれば、MagiskのAPKをMagisk.zipへリネームし、TWRPの「Install」からZIPとしてインストールする方法もあります。

ただし、TCL 32S5400（G06／MT5867）で、このZIP経由のインストールからroot化まで成功するかは未検証です。

後日、Magisk v25.2の32bit版で作成したbootイメージをMBOOTから書き込む方法では、root化に成功しています。確認済みの手順は32S5400のMagisk root化手順を参照してください。

この成功例と、TWRP経由でのZIPインストールは別の確認です。

この機種向けの非公式TWRPは、起動・USB ADB接続・ADB経由のカーソル移動まで確認しています。

導入手順と制限事項は、GitHubのREADME、イメージはReleasesを参照してください。TWRPが起動することと、Magisk.zipのインストーラーが本機で正常に動くことは、別の確認です。

Magisk v25.2の公式リリースからAPKを入手し、ファイル名をMagisk.zipへ変更する。これはAPK内のZIP形式のインストーラーを利用する方法で、ファイルを別形式へ変換するわけではありません。
TWRPから参照できる場所へMagisk.zipを保存し、TWRPを起動する。
「Install」→「Magisk.zip」を選択→スワイプしてインストール、という流れで実行する。「Install Image」ではなく、ZIPを選ぶ通常の「Install」を使います。
完了後、再起動する前に下記の方法でTWRPログを保存する。その後「Reboot System」でAndroidを起動し、Magiskアプリで状態を確認する。アプリが入っていなければ、元のAPKをAndroid側へインストールする。

現状、このTWRPでは/dataのマウント・復号に未解決の点があります。

内部ストレージが見えない場合は、ADBでRAM上の/tmpへ転送し、TWRPのファイル選択から/tmp/Magisk.zipを指定する方法が考えられます。

内部ストレージを見えるようにするための「Format Data」は、この補足手順には含めていません。

adb push Magisk.zip /tmp/Magisk.zip

なお、Magisk公式のインストール説明では、カスタムリカバリー経由の導入は現在非推奨とされています。

ここでは本機での動作保証ではなく、未検証の代替方法として記載しています。

上記で確認できたバージョンはv25.2であり、新しいMagiskなら同じように動く、という意味でもありません。

もしできなかったら、ログ付きで教えてください

もしこの方法でインストールできなかったり、再起動後にrootが有効にならなかったりした場合は、使ったMagisk・TWRPのバージョン、どの段階で失敗したか、画面に出たエラーと、TWRPのログを添えてコメントなどで教えてください。

起動しない場合は、取得できればUARTの起動ログもあると助かります。

TWRPのログは、TWRPを再起動する前にPC側で次を実行して保存できます。

/tmp内のファイルは再起動すると消えるため、先に回収してください。

公開するログに端末のシリアル番号や個人情報が含まれている場合は、その部分を伏せてください。

adb pull /tmp/recovery.log recovery-magisk-install.log

Android TVと強固なセキュリティ機構「AVB」の壁

TCL 32S5400をはじめとする多くのスマートテレビは、内部にMediaTek（メディアテック）製のSoC（システム・オン・チップ）を搭載しています。

スマートフォンでもおなじみのこのチップは、コストパフォーマンスに優れていますが、システムのセキュリティに関しては非常に厳格な仕組みを持っています。

root化を行うための第一歩は「ブートローダーのアンロック（解放）」です。

これは、メーカーが施した「公式のシステムしか起動させない」という鍵を開ける作業であり、TCL TV 32S5400ではブートローダーを解放すること自体は可能です。

しかし、本当の地獄はここから始まります。Androidシステムには「Android Verified Boot（AVB）」という強力な改ざん防止機能が組み込まれています。

これは、システムの心臓部である「boot.img」やその他の重要なファイルが少しでも書き換えられていないかを、起動時に毎回暗号技術を用いて検証する仕組みです。

root化の定番ツールである「Magisk（マジスク）」を使う場合、元のシステムの「boot.img」を取り出し、Magiskアプリでパッチを当てて（改造して）、再びテレビに書き込む必要があります。

ここで絶対に忘れてはならないのが、「vbmeta（ブイビーメタ）」と呼ばれる検証用のファイルも同時に書き換え、改ざんチェック機能を無効化（特定のフラグをいじる）することです。

恐怖の「ブートループ」とロゴマークの無限地獄

もし、この「vbmetaの検証無効化」を忘れたまま、パッチ済みのboot.imgだけをテレビに書き込んで（焼いて）しまったらどうなるのでしょうか。

テレビの電源を入れると、TCLのロゴが表示されます。

しかし、システムの裏側ではAVB機能が「心臓部（boot.img）が改造されている！危険だ！」と判断し、安全のためにシステムを強制的に再起動させます。

するとまたロゴが表示され、再び再起動がかかる……。

これが、カスタマイズ界隈で最も恐れられている「ブートループ」と呼ばれる現象です。画面にはロゴが出続けるだけで、永遠にホーム画面に進むことはありません。

テレビのリモコンは一切効かなくなり、初期化モードにも入れない。ただ再起動を繰り返すだけの巨大な置物になってしまいます。この絶望的な状況から抜け出すためには、「PCとテレビをUSBケーブルで接続し、システムのごく浅い部分に無理やりアクセスして正常なファイルを書き込み直す」という、まるで心臓マッサージのような荒療治が必要になります。

BROMモードとPreloaderの刹那

MediaTek製のチップを搭載した機器には、システムが完全に起動する前の、いわばBIOSのような極めて低レベルな動作モードが用意されています。

それが「BROM（Boot Read-Only Memory）モード」や「Preloader」と呼ばれる状態です。

ブートループに陥ったTCL 32S5400を復旧させるためには、PC側で「mtkclient」というMediaTek専用のリバースエンジニアリングツールを待機させておき、テレビをこのBROMモードでUSB接続する必要があります。

目的は、無効化フラグを立てた「vbmeta_disabled.img」などの修正ファイルを、強制的にテレビのチップへ流し込むことです。

しかし、ここが最大の難所です。正常なスマートフォンであれば、電源を切った状態でボリュームボタンを押しながらPCに繋ぐといった操作で比較的簡単にこのモードに入れます。

しかし、テレビにはボリュームボタンなどの物理キーがほとんどありません。

さらに悪いことに、ブートループに陥っているテレビは「起動→エラー→再起動」を高速で繰り返しているため、PCのデバイスマネージャー上にMediaTekのBROMモードやPreloaderが「一瞬」しか表示されません。 mtkclientがこの一瞬の隙を突いてテレビのチップを検出しようとしても、通信の確立（ハンドシェイク）に失敗し、再び待機状態に戻ってしまうことが頻発します。

アナログな物理操作とタイミングの神業

この一瞬の通信を成功させるため、作業者は非常にアナログかつシビアな物理操作を強いられます。

PC側でmtkclientをBROM待機状態（書き込みコマンドを実行して待たせる状態）にする。
テレビのAC電源（コンセント）を物理的に引き抜いて完全に電源を落とす。
テレビとPCをデータ通信対応の確実なUSBケーブルで接続する。
テレビ本体の裏側などにある物理的な電源ボタンを押したまま、ACコンセントを再び挿し込む。

この「ボタンを押しながらコンセントを挿す」という動作によって、チップが「あ、今は通常の起動ではなく保守モードに入りたいんだな」と認識し、BROMモードが通常よりも少しだけ長く維持される可能性に賭けるのです。

それでも失敗することは多く、AC電源の抜き差しとUSBポートの変更を何度も何度も繰り返す、体力と精神力を削る作業となります。

また、PC側にMediaTek用の特殊なUSBドライバ（libusb-win32フィルタやMTK VCOMドライバなど）が正しくインストールされていなければ、そもそもテレビが一瞬発するSOSの信号をPCが受信することすらできません。

mtkclient自体もPythonベースのツールであり、依存関係のインストール（仮想環境の構築など）が必要となるため、PC側の準備だけでも一苦労です。

最終手段の「UART接続」とターミナルソフトの罠

UART_115200

AC_ON
01-2L-SM-02-20210518
7TH
MIU0_DQS-OK
BIST0-OK
BAP=1
BAP=1
optee teeloader entry
MultiOptee image detected, ModelID=00000001
MultiOptee image detected, ModelID=00000001
CusConfig
eMMC_RPMB_Check_Program_Key
BAP=1
BAP=1
ree_opt=0000007B
BAP=1
Auth reeloader...
Decrypt reeloader...
Check reeloader magic ID...
Version check on reeloader...
BAP=1
BAP=1
Auth CKB...
Decrypt CKB...
Check CKB magic ID...
ns_uboot_boot
MASK_DEVICELOCKMASK is ON
NOTICE:  BL3-1: v1.1(debug):5cad1e05
NOTICE:  BL3-1: Built : 00:32:18, Jul 18 2024
INFO:    BL3-1: Initializing runtime services
INFO:     [Booting] mstar_send_magic_ATF 496
INFO:    BL3-1: Initializing BL3-2
[Ramlog] ramlog_init init success

INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BIN1_32bit mode Jul 18 2024 00:32:18
INFO:    R1 0
INFO:    R2 0
INFO:    R3 0
ree_entry
         U[AT][MB][start ub][590]

U-Boot 2011.06-00095-gaf108c73-dirty (Jun 19 2025 - 17:52:52)

[Mboot] ===== sw IR Config Register =====
[Mboot] ===== Attach IR Interrupt  ======
Uboot Relocation:  152 MiB

eMMC HS400 5.1 200MHz
eMMC 14.48 GB
eMMC used life: 0~10%
 CID
  0x00AA352A
  0x362A0031
  0x30473631
  0x30000111
DRAM : 1536MB
SAR5=ON

 UART BUS OFF!!

もしUSBケーブルからのアクセスがどうしても上手くいかない場合、残された手段は「テレビの裏蓋を外し、メイン基板に直接シリアル通信ケーブル（UART）を接続する」という、完全にハードウェアハッキングの領域に入ります。

基板上の特定のピンにUSBシリアル変換モジュールを繋ぎ、PCの「TeraTerm」などのターミナルソフトを使ってアクセスします。

通信設定を「COMポート、通信速度115200bps、8N1」などに合わせ、テレビにコンセントを挿した瞬間に画面に流れる起動ログを監視するのです。

そして、起動プロセスが始まる一瞬の隙にキーボード入力を送り、「autoboot interrupt（自動起動の中断）」を発生させてコマンド待ち状態に持ち込むという手法です。

しかし、ここでも「TeraTermでキーボード入力が効かないように見える」といったトラブルがよく発生します。

実は入力が効いていないのではなく、TeraTermの設定で「ローカルエコー（自分が打った文字を画面に表示する設定）」が無効になっているため、画面に何も映っていないだけで実際にはテレビに信号が送られている、というトラップがあるのです。

また、背後で別のプログラム（スクリプトなど）がそのCOMポート（COM8など）を占有してしまっており、TeraTermからの入力がテレビに届かないといった通信の競合トラブルも起こり得ます。

ファームウェアの入手性の悪さ＋暗号化

ブートループという無限の再起動地獄に陥り、PCからのBROM接続もタイミングの壁に阻まれたTCL 32S5400。

最終的にメーカー（株式会社 TCL Japan Electronics）のカスタマーサポートへ連絡し、不具合対応として「アップデート用のソフトウェアが格納されたUSBメモリ」を郵送してもらうという、デジタル時代において極めて物理的かつアナログな救済措置に頼ることになります。

数日後、手元に届いた封筒には、TCLのロゴが入った案内状とともに復旧用のUSBメモリと手順書が同封されていました。

ハッカー気質のエンジニアであれば、このUSBメモリをテレビに挿す前に、まずPCに接続して中身を解析しようと試みるはずです。

「このUSBの中にファームウェアのイメージファイル（.imgや.bin）があるなら、それを展開して『boot.img』と『vbmeta』を取り出せば、安全にMagiskでパッチを当ててroot化を再開できるのではないか？」と。

しかし、ここで現代のスマートテレビが持つ第2の強固なセキュリティの壁、「ファームウェアのAES暗号化（Firmware Encryption）」が立ち塞がります。

USBメモリ内に格納されているファームウェアファイルは、単なるZIPアーカイブや生のディスクイメージではありません。

MediaTekや旧MStar系のSoCを採用したテレビのファームウェアは、メーカー固有の暗号鍵（AES等の共通鍵暗号やRSA署名）によって強固に暗号化されています。

PC上のバイナリエディタや、標準的なLinuxコマンド（binwalkなど）、あるいは汎用的なファームウェア展開ツールを用いたとしても、出力されるのは無意味な文字列の羅列（エントロピーの高い暗号データ）だけです。

SoCのハードウェア内に焼き付けられたマスターキー、あるいはTrustZone内に秘匿された復号ロジックを持たない一般のPC環境では、このファームウェアから生のパーティションを抽出することは実質的に不可能です。

root化は「自己責任」という重い言葉の意味

ここまでお読みいただければ、TCL 32S5400をはじめとするモダンなスマートテレビのroot化が、いかに難しく、そして危険な行為であるかがお分かりいただけたかと思います。

軽い気持ちでMagiskを導入し、たった一つの手順（vbmetaの検証無効化）を忘れただけで、数万円するテレビが一瞬にして鉄の塊と化します。

そして、そこからの復旧は、一瞬しか現れないUSBの通信ポートを神業的なタイミングで掴むか、あるいはターミナルソフトの通信設定と格闘するという、エンジニアレベルの知識と忍耐力が要求される戦いになります。

スマートテレビは、スマートフォンよりも遥かに復旧用の物理ボタンやインターフェースが乏しいため、一度システムが破損した際のリカバリー難易度が格段に高いのが特徴です。

メーカーの保証も当然一切効かなくなります。

もし「root化」という禁断の果実に手を伸ばすのであれば、最悪の場合はテレビを買い直す覚悟と、PCのコマンドプロンプトやデバイスマネージャーと何時間も格闘する強い意志が必要です。

テクノロジーの探求は素晴らしいことですが、安全にリビングで映像作品を楽しむか、それともリスクを冒してシステムの限界に挑むか。実行ボタンを押す前に、今一度その代償の大きさを考えてみてください。