Androidのroot化(KernelSU Next)と周辺知識のサーベイ(?)

こんにちは、yukky_maruです。

タイトルの通り、この記事はAndroidのroot化に関する記事です。
「え、今どきroot化？」なんて声が聞こえてきそうですが、端末を隅々までカスタマイズしたい、ゲームの内部データにアクセスしてみたい…(チートはダメだよ!)といった、ギークな界隈（？）の探求心は尽きませんよね。

かく言う私は、人生で一度しかroot化経験のない初心者です。普段はiPhoneユーザーで、PCはWindowsかUbuntu。AndroidにもLinuxにも全く精通しておりません。なんなら5年ほど前に、一番簡単なLPICの本を枕にした…もとい、流し読みした程度の知識しかありません。root化した端末が熱で旅立ったので、新しくAndroidを買ってroot化しました。

つまり、この記事は「素人が1日で付け焼き刃の知識を詰め込んで、なんとかroot化に成功した記録」です。

その分、初心者の方がつまずきやすいポイントは、手に取るように…いや、実際に手を取り合って泣きたいくらい分かっているつもりです。今回はその手順と、私なりに調べて咀嚼した内容をまとめていきます。

【超重要：お約束】
この記事には、7割の座学パートが含まれます(もはやそちらが本編では？)。ただし、私の理解不足による間違いが大量に含まれている可能性があります。もし間違いを見つけた際は、石を投げる代わりに、優しくコメントでご指摘いただけると泣いて喜びます。
ただし、手順そのものは実際に成功しているので、そこはご安心ください。

0. 前提

この記事では、PCでADBコマンドを実行できる環境とAndroidのブートローダーアンロックができていることを前提とします。
今回、実験台となった端末の情報は以下の通りです。

• 端末: CPH2449 (OnePlus 11)
• OS: OxygenOS 15
• カーネルバージョン: 5.15.149-android13-…

1. なぜ今、新たなroot化記事を書くのか？

さて、「Android root化」と検索すれば、Magisk を使った日本語記事は星の数ほど見つかります。正直、この記事の存在価値が危ういレベルです。

…ですが、少し待ってください。

私にはささやかな野望があります。それは 「アプリ側にroot化していることを、できるだけ検知されたくない」 というものです。

例えば、銀行系のアプリはroot化端末を検知して起動を拒否してきたりします。「root化端末は趣味用にして、普段使いは別の端末にすれば？」というのは、あまりにも正論でぐうの音も出ません。
でも、それってなんだか、ちょっと悔しくないですか？ せっかくならroot検知を完璧に回避して、一つの端末で全てを完結させたい。そう思うのが人情というものです（たぶん）。

もし「わかる！」と思っていただけたなら、ぜひこのまま読み進めてください。（そう思わなかった方は、きっと他の"つよつよ"なガジェオタの方々が書いた素晴らしい記事を参照するのが幸せへの近道です。）

というわけで、まずは技術を齧ることから。root化手法のサーベイから始めましょう。

root化手法について

現在、Androidのroot化手法は、大きく分けて以下の2つが主流のようです。

1. Magisk
2. KernelSU

この2つが、どのようにしてroot権限を実現しているのか、その仕組みを覗いてみましょう。

Magiskのroot化手法

公式ドキュメントをムズカシイ言葉と格闘しながら眺めてみると（眺めただけで読めたとは言っていない）、どうやら Magiskは「ユーザー空間」をベースにした手法のようです。

以下、そう判断した根拠です。

Pre-Init
magiskinit will replace init as the first program to run.
… execute the original init to continue the boot process

システムの起動プロセスの一番最初（init）に magiskinit が割り込んで、root化の準備をするようです。カーネルそのものではなく、initプロセスにフックを仕掛けているわけですね？

post-fs-data
The daemon magiskd will be launched…

そして、magiskd というデーモン（常駐プログラム）がユーザー空間で起動する、と。

なるほど。どうやらinitを乗っ取って、ユーザー空間であれこれやるのがMagiskのスタイルのようです。これが/systemパーティションを改変しない「systemless」がウケて、Magiskが広く普及した理由なのでしょうか。

ただ、ふと不安がよぎります。ユーザー空間で色々やっているということは、検知する側から見れば、比較的見つけやすいのでは…？

KernelSUのroot化手法

一方、KernelSUの公式ドキュメントを読んでみると、こちらは名前の通りカーネルそのものに手を入れる「カーネルベース」の手法とのこと。

ユーザー空間からカーネル空間の奥深くを覗き見るのは、一般的に難易度が高いはず。ということは、原理的にはこちらの方が検知されにくい、と言えそうです。

どちらの手法も、/system を直接改変しない systemless root に分類されます。
この章のまとめとして、両者の違いを簡単な表にしてみました。

我々が目指すべき道

調査の結果、我々の目的「検知を回避したい」には、KernelSUの方が筋が良さそうです。

さらに調査を進めると、XDA Forumsにこんな投稿を見つけました。

T0: Perfect concealment, T1: Some flaws

T0: KernelSU Next GKI mode
Modules: [ZygiskNext, susfs4ksu-module, [Lsposed IT or LSPosed_mod], Tricky Store]
Lsposed App: [Hide-My-Applist]

T0: Magisk alpha
...

T0: KernelSU GKI mode
...

「T0: 完璧な隠蔽」を達成するには、上記3つの手法があるようです。
というわけで、今回は一番上に書かれている KernelSU Next GKI mode の導入手順を解説していきます。（各種モジュールの導入は、それらを入れればいいだけなので、また機会があれば…）

2. 座学タイム：KernelSU周辺のあれこれ

いよいよインストール…の前に、少しだけ座学にお付き合いください。この知識があるのとないのとでは、文鎮化のリスクが天と地ほど変わります（7万で学んだ実体験）。

この章の内容は、基本的にKernelSUの公式ドキュメントに基づいています。

まず、KernelSUには2つのモードが存在します。

• GKIモード: 端末本来のカーネルを、KernelSUが提供する汎用カーネルイメージ (GKI) で丸ごと置き換えるモード。
• LKMモード: 端末本来のカーネルはそのままに、ローダブルカーネルモジュール (LKM) を後から読み込ませるモード。

我々が目指すのは「GKIモード」なので、こちらを少し深掘りします。

GKI と KMI について

公式ドキュメントによると、最近のAndroidは「カーネルを汎用的にして、メーカーごとのカスタマイズによる断片化を防ごう」という思想（Generic Kernel Image (GKI) プロジェクト）があります。

その「汎用性」を担保しているのが KMI (Kernel Module Interface) です。
KMIは、カーネル本体と、後から読み込むドライバモジュール（Wi-Fiやカメラなど）との間のプロトコルのようなものだと考えてください。

このKMIが一致していないと、カーネルはモジュールを正しく認識できず、悲劇が起こります。

ブートループ発生のメカニズム

なぜKMIが違うとマズいのか、ブートループが起きる流れを見てみましょう。

【正常な状態】

Androidデバイス
├─ カーネル (boot.img内)
│  └─ KMI: 5.10-android12-9
│
└─ ベンダーパーティション (/vendor内)
   ├─ カメラドライバ.ko (KMI 5.10-android12-9用)
   ├─ Wi-Fiドライバ.ko (KMI 5.10-android12-9用)
   └─ ...その他大勢のドライバたち

1. 元の状態（正常動作）

   • カーネル (KMI: 5.10-android12-9)
   • モジュール群 (KMI: 5.10-android12-9用)
   • 結果: 通信OK！ ✅

2. 違うKMIのカーネルを焼いてしまう

   • 新カーネル (KMI: 5.10-android12-10) ← KMIが違う！
   • モジュール群 (KMI: 5.10-android12-9用) ← 変更なし
   • 結果: 合い言葉(プロンプト)が通じない！通信失敗！ ❌

3. ブートループ

   • カメラドライバがロードできない！
   • Wi-Fiドライバがロードできない！
   • システム起動に必要なドライバが軒並み沈黙…
   • システム起動失敗 → 再起動 → 無限再起動（ブートループ） 💥

セキュリティパッチレベル

最近のデバイスは、さらに厄介なことに、同じKMIであってもセキュリティパッチレベルが古いと起動を拒否する仕組みがあります。自分の端末のセキュリティパッチレベルは、以下のコマンドで確認できます。

adb shell getprop ro.build.version.security_patch
2025-02-01

【最重要】カスタムカーネル選びで見るべきはKMIバージョン

よくある間違いとして、「自分のスマホはAndroid 13だから、"android13"って名前の改造カーネルを選べばいいや」と考えてしまうことがあります。しかし、OSはあくまでアプリケーションでカーネルではありません。改造カーネルのバージョンはカーネルに依存すべきです。そして厄介なことに、OSのバージョンとカーネルのKMIバージョンは必ずしも一致せず、さらにKMIバージョンにandroidという言葉が含まれるため余計ややこしいです。

• ❌ 間違った選び方: 「Android 15だから android15 って名前が入っている改造カーネルを選ぼう」
• ✅ 正しい選び方: 「自分のKMIバージョンが android13-5.15 だから、同じ android13-5.15 の改造カーネルを選ぼう」

もう一度言います。必ず、自分の端末のKMIバージョンと、導入するカーネルのKMIバージョンが一致しているものを選んでください。

3. KernelSU-Next GKI mode インストール手順

さて、長かった座学も終わりです。いよいよroot化本番と参りましょう。

ここまでの話を読むと、「改造カーネルをダウンロードしてきて、fastbootでbootパーティションに書き込むだけ？」と思うかもしれません。

# これは危険な例！
fastboot flash boot 改造boot.img

その考えは非常に危険です。
何を隠そう、私自身がこの安易な考えでOnePlus 13をハードブリックさせました。ソフトブリックではありません。修復不可能な、正真正銘の文鎮です。あるパーティションにサイズ超過のファイルを書き込んでしまい、根幹システムが破壊されました。
バックアップもして万全を期したはずでしたが、コマンド一つで私の7万円が電子の藻屑に…。起動すらしなくなった端末の前では、バックアップも無力です。

この苦い経験を糧に、今回はもっと安全な方法を採用します。大まかな流れは以下の通りです。

1. 安全な「一時root」状態で端末を起動する。
2. root権限で動作する専用アプリを使い、安全にカーネルを書き換える（フラッシュする）。

手順の多くは、XDA Forumsのこちらのスレッドを参考に（というか、ほぼパクって）います。最初からこの記事を見つけれてればよかったですが、失う前はなぜか見つけられないものですこーゆうのは。

Step 1: KernelSU Next アプリのインストール

KernelSU Nextのリリースページから、最新の .apk ファイルをダウンロードし、端末にインストールしてください。

⚠️ 注意
2025年9月現在、v1.0.9には一部環境で動作しないバグが報告されています。もし上手くいかない場合は、v1.0.8を試してみてください。（私はここで少しハマりました。）

Step 2: 一時rootでの起動

こちらのリンクから、OnePlus 11用の一時rootブートイメージ (susfs-temp-op11-boot.img) をダウンロードします。(突然謎のダウンロードリンクを貼られると怖いと思いますが、このリンクは先ほどのXDAスレッド内に記載されています。）

ダウンロードしたら、PCから以下のコマンドを実行します。

# まずはbootloaderモードで再起動
adb reboot bootloader

# ダウンロードしたイメージを使って「一時的に」起動
fastboot boot susfs-temp-op11-boot.img

flashではなくbootコマンドなので、書き換え自体は行われます。あくまで指定したイメージで起動を試みるだけなので、もし起動に失敗しても端末を再起動すれば元通りです。文鎮化の心配はないので、ここは気軽に試せます。

Step 3: KernelFlasher の準備とバックアップ

1. こちらから KernelFlasher の .apk をダウンロードし、インストールします。

2. 端末で KernelSU Next アプリを開き、スーパーユーザー タブから KernelFlasher にroot権限を与えます。

3.　バックアップを取る
KernelFlasher アプリを開き、現在のカーネルのバックアップを取ります。万が一の時のお守りです。
最近の端末はA/Bスロットという冗長化の仕組みを持っています（ありがたい！）。自動アップデートで片方のアップデートを試みて失敗したら別スロットで起動して元に戻す仕組みです。念のため、スロットAとスロットBの両方をバックアップしておきましょう。
バックアップファイルは /sdcard/KernelFlasher/backups に保存されるので、さらにPCにもコピーしておくと完璧です。

Step 4: AnyKernel3 ZIPの選択とフラッシュ

1. XDAのこちらのスレッドに戻り、自分の Androidバージョン と KMIバージョン に合った AnyKernel3 のZIPファイルを選びます。
   私の場合は Android 15, KMIは 13.5.15 だったので、その中で一番 Susfs バージョンが高い Anykernel3-OP11-A15-android13-5.15-KernelSU-Next-1.0.7-12681-SUSFS-1.5.7.zip を選びました。
   

2. ダウンロードしたZIPファイルを、KernelFlasher を使ってアクティブなスロットにフラッシュします。
   私の場合はスロットBがアクティブだったので、Bにフラッシュしました。あとは画面の指示に従い、ファイルを選択してフラッシュを実行するだけです。
   
   
   

Step 5: 最終確認

フラッシュが完了したら、端末を再起動します。

最後に KernelSU Next アプリを開き、**「GKIで動作中」**と表示されていれば、ミッションコンプリートです！
（私は前述のバグのせいで最初は表示されませんでしたが、アプリのバージョンをv1.0.8に下げたところ、無事に表示されました。）

4. おわりに

お疲れ様でした！
これで、我々の目標であった

T0: KernelSU Next GKI mode
Modules: [ZygiskNext, susfs4ksu-module, [Lsposed IT or LSPosed_mod], Tricky Store]
Lsposed App: [Hide-My-Applist]

このうちの土台となる KernelSU Next GKI mode の導入が完了しました。
あとは、必要なモジュールのZIPファイルをダウンロードし、KernelSU Nextアプリからインストールしていくだけです。この記事が、同じように探求心あふれる誰かの一助となれば幸いです。