TCL 32S5400 スマートTV(TCL/G06_2K_GB, chip: MT5867)Magisk root化 手順まとめ

なんとか、32S5400でrootを奪取することが出来ました。
その備忘録として残します。

2026年10月27日追記：いま一番簡単なroot化方法は、公開bootをFastbootで書き込む方法

長い調査記録の前に、現在の導入方法を先にまとめます。

確認機では、Stock USBで純正状態へ復元し、ADBを有効化 → ブートローダーをアンロック → vbmetaの検証を無効化 → 公開済みのMagisk適用済みbootを書き込み → userdataを消去 → 再起動という流れで、通常起動できることを確認しました。

下に残しているMBOOT経由の作業より手順を短くできるため、対応する環境ではこちらを最初に検討するroot化方法として紹介します。

「簡単」は従来のMBOOT経由と比べての意味です。

対象はTCL 32S5400（G06／MT5867）の確認機です。

他個体・別基板・別ファームウェアまで保証するものではありません。純正復元、アンロック、userdata消去ではデータが失われるため、必要なデータを退避し、対象TVに合った純正ファームウェアと復旧手段を確保してから進めてください。

Magisk適用済みbootの説明・対応条件
boot・vbmeta・SHA-256のダウンロード

1. Stock USBで純正状態に戻し、ADBを有効化する

今回の確認では、まず対象機に対応するStock USBで純正状態へ戻し、ADBを有効化しました。別機種のUSB更新イメージは使わないでください。ADBの接続とPC側の認証を確認してから、ブートローダーのFastbootモードへ移ります。

adb devices
adb reboot bootloader
fastboot devices

2. ブートローダーをアンロックする

fastboot flashing unlock

TV側に確認画面が出る場合は、表示内容を確認して操作します。アンロックに伴うデータ消去に注意してください。処理が終わり、再びFastbootで対象TVを認識していることを確認してから次へ進みます。

3. 必ずvbmetaの検証を無効化する

Magisk適用済みbootを書き込む前に、必ずvbmetaのAVB検証を無効化してください。ブートローダーのアンロックだけでも、bootの書き込みだけでも、別パーティションのvbmetaは無効化されません。同じReleaseのvbmeta類はFlags=0のバックアップで、無効化済みのファイルではありません。使用するvbmetaが対象TVと同じファームウェアに対応することを確認してください。

# 例：対応するvbmeta.imgをDownloadsへ保存した場合
fastboot --disable-verity --disable-verification flash vbmeta "C:\Users\Owner\Downloads\vbmeta.img"

上記は検証無効化のコマンド例です。今回報告された成功手順では「vbmetaを無効化した」ことを確認していますが、その際に入力したコマンド全文までは記録していません。転送・書き込みが両方OKAYであることを確認し、FAILEDなら先へ進まないでください。vbmeta_systemも機械的に書き換える手順にはしていません。

4. Magisk適用済みbootを書き込む

Releaseのboot-magisk-25.2-g06.imgをダウンロードし、SHA256SUMS.txtと照合します。確認機では、次のコマンドでbootへ書き込みました。パスは自分の保存先に合わせて変更してください。

Get-FileHash "C:\Users\Owner\Downloads\boot-magisk-25.2-g06.img" -Algorithm SHA256
# SHA-256: ce9acfddb98cc1e27e09bde687114df13559eb0adc7e419b35c77276f2ec4747

fastboot flash boot "C:\Users\Owner\Downloads\boot-magisk-25.2-g06.img"

5. userdataを消去して再起動する

次のコマンドはTVのuserdataを消去します。設定、追加したアプリ、アプリデータなどが失われ、初期設定のやり直しが必要です。今回はこの消去も含む手順で起動を確認しています。消去せずに成功するかは、この確認結果からは判断できません。

fastboot erase userdata
# 消去が成功したことを確認してから実行
fastboot reboot

確認機では、この流れで通常起動しました。起動できることと、アプリがroot権限を取得できることは分けて確認します。必要に応じて公式のMagiskアプリを導入し、初期設定とADBを有効化し直したうえで、次を実行してください。Magiskの許可画面が出たら確認して許可し、uid=0(root)が返ればroot権限の取得を確認できます。

adb shell "su -c id"

MBOOT経由の作業は、知識が必要な調査・復旧向けの方法

以下に残すMBOOTの作業は、UART接続、RAMアドレス、パーティション名、書き込みサイズ、読み戻し照合を理解して操作する必要があります。アドレスや書き込み先・サイズを誤ると、boot以外の領域を破損し、復旧が難しくなるおそれがあります。コマンドを意味が分からないままコピーする方法としては勧めません。

Fastboot経由の導入が利用できる環境では、今回の方法が先に試す手順です。以降のMBOOTや手動パッチの説明は、当初の試行錯誤と復旧・解析のための記録として読んでください。改変状態のままブートローダーを再ロックしないでください。

TCLのシークレットメニュー

設定 → 画像 → 詳細設定 → 明るさ → コントラスト → 1950 を入力

設定

リモコンの「メニュー」を押す。

ディスプレイと音

「ディスプレイと音」を押す

映像設定

「映像設定」を押す。

詳細設定を押す

「詳細設定」を押す

光度設定

「光度設定」を押す

コントラストに移動して「1950」と入力する

ファクトリーメニューが出てくる

パーティションの吸い出し方法

UartStatus=1 にする方法

ファクトリーメニューのOtherを開く

UartEnableをONにする

UARTで接続した状態でEnter連打

機種情報

今回判明した根本原因

1. 当初の boot パーティションが暗号化された状態だった
   (今回の会話より前の、別の作業由来。本筋には無関係と判明)。
2. 本当の root 化失敗の原因は、Magisk が 64bit (ARM64) 版の magiskinit でパッチされていたこと。
   このTVのカーネルは 32bit (armv7) なので exec が ENOEXEC(-8)で失敗し、Kernel panic: Requested init /init failed になっていた。
3. 32bit版 magiskinit(Magisk v30.6)に差し替えても、今度は Kernel panic: Attempted to kill init! exitcode=0x00007f00(= exit(127)、magiskinit が本来の init への exec 引き渡しに失敗)で止まった。これは、このTV独自の ramdisk-root構成 + カスタムSELinuxポリシーに、新しい magiskinit の実装が対応できていなかったため。
4. Magisk v25.2 の magiskinit(32bit)に変更したところ、正常に起動し、root が有効になった。

当初成功したMBOOT経由の手順（専門知識が必要）

必要なファイル

• 正規のストック boot.img
  (このTV用、平文・未暗号化。USBアップグレード(電源ボタン長押し+USBのupdate.img)で復元したものが正しい)
• Magisk v25.2 の APK から取り出した 32bit (armeabi-v7a) バイナリ
  • libmagiskinit.so → magiskinit
  • libmagiskboot.so → magiskboot
  • libmagisk32.so → magisk32
  • libmagiskpolicy.so → magiskpolicy
  • APK内 assets/boot_patch.sh, assets/util_functions.sh

TV本体上でパッチを当てる(adb経由、root不要)

adb push magiskinit magiskboot magisk32 magiskpolicy boot_patch.sh util_functions.sh /data/local/tmp/mg25/
adb push stock_boot.img /data/local/tmp/mg25/boot.img
adb shell "cd /data/local/tmp/mg25 && chmod 755 magiskinit magiskboot magisk32 magiskpolicy boot_patch.sh util_functions.sh"
adb shell "cd /data/local/tmp/mg25 && BOOTMODE=true sh ./boot_patch.sh boot.img"
adb pull /data/local/tmp/mg25/new-boot.img ./MAGISK25.BIN

• BOOTMODE=true を付けること(付けないと ui_print 等のヘルパー関数が読み込まれず、PREINITDEVICE 検出なども動かない)。
• TVの実機(32bit ARM)上でバイナリを直接実行しているので、アーキテクチャやABIの不一致が起きない。QEMU等のエミュレータは不要。

MBOOTコンソールから boot パーティションに書き込む

電源投入直後、シリアルコンソールに割り込んで MT5867 ># プロンプトを出す。

usb start 0
fatload usb 0:1 0x25000000 MAGISK25.BIN
mmc write.p 0x25000000 boot 0x1F00000 0
mmc read.p 0x2A000000 boot 0x1F00000
cmp.b 0x25000000 0x2A000000 0x1F00000

• cmp.b が Total of 32505856 bytes were the same と出れば書き込み成功。
• そのまま電源を入れ直し、割り込まずに自動起動させる。

確認

adb shell "su -c id"
# uid=0(root) gid=0(root) ... context=u:r:magisk:s0  が出ればOK

追記：TWRPからMagisk.zipをインストールする方法（本機では未検証）

今のところ非推奨です。

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

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

当初は、Magisk v25.2で作成したbootイメージをMBOOTから書き込んで動作確認しました。その後、冒頭のFastboot経由の手順でも通常起動を確認しています。TWRPのZIPインストールとは別の確認です。

この機種向けの非公式TWRPは、起動・USB ADB接続・ADB経由のカーソル移動まで確認しています。導入手順と制限事項は、GitHubのREADME、イメージはReleasesを参照してください。

TWRPが起動することと、Magisk.zipのインストーラーが本機で正常に動くことは、別の確認です。

1. Magisk v25.2の公式リリースからAPKを入手し、ファイル名をMagisk.zipへ変更する。これはAPK内のZIP形式のインストーラーを利用する方法で、ファイルを別形式へ変換するわけではありません。
2. TWRPから参照できる場所へMagisk.zipを保存し、TWRPを起動する。
3. 「Install」→「Magisk.zip」を選択→スワイプしてインストール、という流れで実行する。「Install Image」ではなく、ZIPを選ぶ通常の「Install」を使います。
4. 完了後、再起動する前に下記の方法で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

ストックに戻す方法（対応する純正イメージと復旧環境が必要）

usb start 0
fatload usb 0:1 0x25000000 BOOT2.BIN
mmc write.p 0x25000000 boot 0x1F00000 0
mmc read.p 0x2A000000 boot 0x1F00000
cmp.b 0x25000000 0x2A000000 0x1F00000

BOOT2.BIN = USBアップグレードで復元した正規ストックboot(平文)。

それでも起動しない/もっと手堅く戻したい場合は、同じ電源ボタン長押し+USBの公式 update.img で、ストックROM全体を再書き込みする(今回も実際にこれで復旧できた)。

よく使ったMBOOTコマンド

注意: setenv, ac, dc などの環境変数変更コマンドは、このTVでは sitadebug(工場用証明書)によってロックされており、証明書なしでは使えない。

パーティションの吸い出し方(汎用手順)

基本の3コマンド(読み取りのみ、安全)

usb start 0
mmc read.p <RAMアドレス> <パーティション名> <バイト数>
fatwrite usb 0:1 <RAMアドレス> <ファイル名> <バイト数>

• RAMアドレス は 0x25000000 を使うのが定番(バッファとして十分空いている)。
• ファイル名 は 8.3形式(拡張子抜きで最大8文字、拡張子最大3文字)。LINUX_ROOTFS.BIN のような長い名前は fatwrite が filename is not supported!!! で拒否するので、ROOTFS.BIN のように短くする。
• バイト数 は 16進数(0x...)で指定。パーティション表の「length」はセクタ数(512バイト単位)なので、バイト数 = length × 512。

パーティションテーブルとサイズ換算(このTVの例)

mmc part で出てくる length(セクタ数)を 512 倍すると、mmc read.p に渡すバイト数になる。

実行例

mmc read.p 0x25000000 dtbo 0x800000
fatwrite usb 0:1 0x25000000 DTBO.BIN 0x800000

吸い出しが途中で止まる場合

linux_rootfs_a(約85MB)の mmc read.p 自体が無反応になった事例があった。これは 書き込みではなく読み取りの操作なので、eMMCが壊れる心配はない。

止まったら

• 1〜2分待っても変化がなければ、電源を切って良い。
• そのパーティションは後回しにして、他のパーティションの吸い出しを先に進める。
• 読み取りにくい領域がある場合、それ自体がeMMCの物理的な劣化を示している可能性があるので、覚えておく価値がある。

RAMより大きいパーティション(super など)

DRAMは1.5〜2GB程度なので、super(約3.37GB)は一度にRAMへ読み込めない。チャンク分割で読む必要がある。

mmc read.p.continue <addr> <partition_name> <offset> <size>

例えば 512MB (0x20000000) ずつ、オフセットをずらして読み、USBにはそれぞれ別名(SUPER01.BIN, SUPER02.BIN, …)で書き出し、あとでPC側で結合する。super全体が必要になる場面(system/vendor/productの吸い出しなど)がなければ、優先度は低い。

今回ハマった点・学び

• boot_select_fdt: dtb entry <0> is not a valid fdt blob というログは、boot.img内蔵のdtbが dt_table(複数dtbをまとめた形式、マジック d7b7ab1e)になっているのに、MBOOTの一部の経路が単体FDT(マジック d00dfeed)を期待しているための表示で、実害のない警告だった(実際のdtbは dtbo パーティション経由で正しくロードされている)。
• MBOOTの Kernel command line: 表示は boot.img ヘッダの cmdline フィールドをそのまま出しているだけで、実際にカーネルへ渡される bootargs は環境変数側で組み立てられる別物。ヘッダをいじってもログの詳細度(loglevel等)は変わらない。
• vbmeta に flags=3(検証無効化)+ G06 のfingerprintが入っていたのは、実はこのTV自身の正しいモデル(G06)の構成だった(C06用OTAパッケージを参照にしていたため誤って「別モデル」と判断していた)。実際の問題には無関係だった。
• 文字列の init 終了コード 0x00007f00 は exit(127) <<8 であり、「execが失敗した」ことを示す一般的な規約。