KSuRoot

⚠️ ご注意：Blueファクトリーモデルのスケジューリングポリシーは比較的厳格で、権限昇格時に子プロセスがシステムに回収されやすいです。まず「開発者オプション」で「子プロセスの制限を停止」を有効にしてから権限昇格を実行してください。成功率が高くなります。

CVE-2026-43499（GhostLock） カーネル脆弱性に基づくワンクリック KernelSU 権限昇格ツール。

本ブランチは KSuRoot をベースに、Root-My-Galaxy v0.2.6 メインラインの更新を完全に同期し、その上にペイロードビルド、ベンダーペイロード内蔵、そして一連のリキッドグラス UI を追加しています。

Mod by hmascs · バージョン 4.1.2 · Apache-2.0 リポジトリ：https://github.com/hmascs/KSuRoot

---

4.1.2 の変更点

今回（4.1.2）の新機能：イメージから vr.ko のマークオフセットを読み出す

vr.ko は app からの task にマークを付けますが、そのオフセットには 0x04 / 0x06 の 2 種類があり、しかもコンパイル時にペイロードへ焼き込まれるため、patch できません。さらに厄介なことに、同一デバイスの 2 つの vr.ko がそれぞれ別の種類を持ちます （Y300 Pro+ の vendor_boot には 2 つ入っており、srcversion は完全に同一）—— 間違って選ぶと「バイトを消し間違え、マークが消えず、子プロセスは相変わらず殺される」という症状が出るのに、ログ上はすべて正常に見えます。

現在、Blueファクトリー方式では vendor_boot.img の提供を要求します：アプリはその中の実際にロードされる lib/modules/vr.ko から本機の真のオフセットを読み出し、ペイロードを書き換えます。4 つの同梱/自作ライブラリ （libbaseline_6_1 / libbaseline_6_12 / libbs / libionstack）はすべて自身の設定を強制し、 間違って選ぶとゼロヒットゲートでその場でブロックされ、そのままコピーしただけの産物が渡されることはありません。

さらに**「完全フラッシュパッケージのインポート」**を追加：ダウンロードした OTA zip や fastboot tgz を直接選ぶと、 それ自体が boot と vendor_boot を取り出します。事前に解凍する必要も、手動で抽出する必要もありません。

⚠️ 完全パッケージは丸ごとアプリキャッシュにコピーしないとランダム読み出しできません（ZIP 中央ディレクトリはパッケージ末尾にあり、SAF の uri は File に変換できないため）。容量が足りない場合はその場で拒否され、抽出後すぐにキャッシュは削除されます。

4.1.2 = 4.1.0 + 19 コミット。 これらのコミットは元々 fix/baseline-routing ブランチに留まっていましたが、 現在は main にマージ済みです。リリース済みの 4.1.0 インストールパッケージには含まれていません —— 以下の各項目はすべてその後に修正されたものです。

修正されたサイレント障害

#	欠陥	結果
1	6.1 の VR_TAG_A_OFF が 0x06 に設定（実測では 0x04 であるべき）	Blueファクトリー 6.1 機種でマークが1 バイトも消えず、しかも自検は成功と報告。症状は「権限昇格成功直後に子プロセスが即殺される」で、これが原因とは分からない
2	kallsyms オフセットテーブル定位に負の剰余を使用（Python セマンティクスの直訳）	6.4+ カーネルで全体が失敗し、ベースアドレスが ASCII テキストの一部を指す
3	オフセットテーブルの判定基準が「先頭 3 項目が単調」のみ	ほぼ識別不能（テーブル内の任意の位置が単調）；テーブルの形状を調べる方式に変更済み
4	BASELINE_6_12.imageBase がターゲットベースアドレスに設定	絶対アドレス形式の構築点がすべて未修正（39 箇所 → 9 箇所）
5	シンボルが揃わない場合に産物を空にするだけで、gate は Proceed のまま	blocked=false かつ産物 0 B で、UI がブロックダイアログを出さない
6	FopsSlot の fallback が一度も使われない	テーブルが見つからないと即諦め、予備シンボルに退避できない

機能補完

• 6.12 が本当に動作：ashmem は 6.12 で Rust 実装になり、シンボル名がすべて mangled に → 実行時に miscdevice の fops スロットから読み出す方式に変更（TARGET_ASHMEM_FOPS_UNSYMBOLED）
• 6.1 / 6.12 が汎用 / Blueファクトリー両方式で使用可能（4 つの組み合わせが各 16 / 16 / 13 / 13 段階）、 一覧はアーカイブ 07-文档/6.1-6.12-双方案清单.md を参照
• vr.ko マークオフセットを個体ごとに実測：6.1 = 0x04、6.6 / 6.12 = 0x06（3 台の実機ベンダーファームウェア内の vr.ko）
• ペイロードビルドレシピをリポジトリに同梱（载荷构建/）：これまでリポジトリ内に存在しないディレクトリを指す参照が 15 箇所あった

★ 実機で捕捉：6.1 上の 26 項目のオフセットが1 箇所も修正されず、それでもパッケージが出荷された

X100 Pro（6.1.145）でビルドを実行した結果は：

偏移解析: 28 / 28 项
需要改写: 26 项 · 校验通过: 0 项
该动态库未引用 26 项偏移

これは「変えるものが何もない」ではなく、「この二つは同じセットではない」ということだ。 根本原因は二つの独立した選択が食い違ったことにある：

何を選ぶか	何に基づいて選ぶか	6.1.145 で選ばれたもの
基礎ライブラリ	構造体ファミリー（F6_1）	libbaseline_6_1.so（旧値は baseline-6.1-tokay/target.h 由来）
プロファイル	三段ルーティング（カーネル文字列）	up-6-1-145-…（旧値は GhostLock の offsets.h 由来）

パッチの当て方は「プロファイル内の旧値を .so 内でリテラル検索する」というもの。二組の旧値は全く交差しないため、26 項目のどこにも一致せず、生成物は基礎ライブラリをそのままコピーしただけに等しい。

なぜ元のハードゲートが止められなかったか：hasFailures の判定条件は changed && !ok && !absent —— absent は明示的に除外されている。その理由（「古いバージョンの .so には対応するコードパスが存在しないかもしれない」）は個別のキーには成り立つが、「全てのキーが absent」には成り立たない。

修正は二本立て：

1. ライブラリとプロファイルを強制的に同源にする：自前ビルドファミリーのベースライン（libbaseline_6_1.so / libbaseline_6_12.so）は、それ自身のプロファイル（baseline-6-1-tokay / baseline-6-12-honor）と必ず組み合わせる。上流の up-* プロファイルは上流の .so にのみ適用される。BaselineLibraries.profileIdForLibrary() を新設。
2. ゼロヒットのハードゲート：オフセット仕様が一つもサイトに落ちなければパッケージングを停止する（ベースアドレスの項目はカウントしない —— それは全く一致しなくてもしばしば変化し、「オフセットが一つも変わっていない」ことを覆い隠してしまう）。このため SpecOutcome に kind フィールドを追加した。

回帰テストは BaselineLibraryPairingTest（4 件）にあり、そのうち一つは二組の旧値に交差がないことを直接アサートする —— 「なぜペアリングが必須なのか」を実行可能な事実に変えている。

動的ライブラリ：インポート後に「押しても何も起きない」類の問題

#	欠陥	結果
1	「ペイロード構築 → ペイロードとして使用」がメモリ内の生成物を使い、プロセス回収後に outputLibrary が null になるが、旧コードは ?: return	押しても何も起きない：Toast もエラーもなく、ボタンも変わらない —— ユーザーから見れば「押しても無反応」
2	PayloadStaging のキャッシュキーが「同名 + 同長」	カスタムペイロードはプライベートディレクトリ内で常に payload.so という名前になるため、バイト数がたまたま同じペイロードに差し替えると前のものを黙って再利用する
3	shizukuStage のキャッシュキーが長さのみ	同じ穴を Shizuku 経路でも踏む
4	カスタムペイロードを一つしか保存できない	二つ目をインポートすると一つ目を上書きし、通知もない
5	ファイルが全てアプリのプライベートディレクトリ内	ユーザーはファイルマネージャで見えず、自分でバックアップ・整理もできない

動的ライブラリ倉庫：Download/动态库/<機種>/<ファイル名>.so

• 倉庫（ユーザーが閲覧・整理可能）：Download/动态库/<機種>/<ファイル名>.so
• アクティブコピー（実際にロードされるもの）：files/active_payload/payload.so —— 下記の「なぜ二つ必要か」を参照
• UI に機種別グループの倉庫リストを新設、各項目を直接「使用」して現在のものに設定可能
• 同名だが内容が異なる二つは互いを上書きしない（自動でハッシュサフィックスを付与）

なぜ倉庫のものを直接 dlopen できないか：スコープドストレージ下ではアプリは自身が MediaStore 経由で作成したファイル群しか読めない。さらに /storage は FUSE（u:object_r:fuse:s0）であり、untrusted_app 以外のドメインからは全く読めない —— これは pm install 時に SELinux にその場でブロックされて判明した（avc: denied { read } ... tclass=file）。したがって倉庫は「ユーザーに見せ、管理させる」役割を、プライベートコピーは「確実にロードできる」役割を担う。

⚠️ 探索能力の限界：倉庫は Download/动态库/ にユーザーが自分で放り込んだファイルを自動スキャンできない —— スコープドストレージはアプリが他アプリ（ファイルマネージャを含む）の作成したダウンロードファイルを読むことを許可しない。 エントリの出所は二つだけ：本アプリが書き込んだもの、およびユーザーがシステムピッカーで明示的に許可したもの。

ゲート補強

• CI に :app:testDebugUnitTest を追加 —— 以前は「コンパイルが通る」ことしか証明せず、「テストが正しい」ことは証明していなかった
• BundledPayloadVrKoAuditTest：表示用注釈テーブルとディスク上の実バイトを一件ずつ突き合わせ、沈黙の欠落を許さない
• 単体テスト 38 クラス / 394 ケース（4.1.0 は 37 / 382）

実測済みの限界（隠さない）

オフセットは実測済みだが、「マーカー消去」の工程はどの実機でも走らせていない。 vr detag はコードが組み込まれたことしか証明せず、正しく消せたことも、消した結果殺されないことも証明しない —— そのため三ファミリーのベースラインは一律 beta のままとする。

---

4.1.0 の変更点

⚠️ 4.0.0 のインストールパッケージは以下の一連の変更より前のもの（4.0.0 は 03:55 にパッケージング、藍廠の一連の変更は 04:32 以降）。 つまり 4.1.0 が初めて vr.ko 反 root バイパスを実際に搭載した正式版である。

藍廠 vr.ko 反 root：二つの自前ビルドファミリーベースラインがついにバイパスを搭載

4.0.0 では libbaseline_6_1.so / libbaseline_6_12.so の vr detag カウントは 0 —— これらは vr.ko のマーカー消去を一切含まない。藍廠機種でこれら二つのベースラインを選ぶことは、vr.ko の反 root をそのまま放置するに等しい。

4.1.0 では二つのベースラインを再ビルドし、二つの独立した欠陥を修正した：

1. vr.ko マーカー消去を含まない（vr detag カウント 0 → 2）；
2. 旧生成物がそもそもロードできない —— 旧ビルドは root.c / io_daemon.c をコンパイルしておらず、wallpaper_blob.S が必要とする素材も提供していなかったため、install_android_root などが UND への動的リロケーションとなり、dlopen が直接失敗する。これは元のタスク指示書にはなく、再ビルド過程で実測して発見した。

再現可能なレシピは 载荷构建/README.md にある（出所の階層分けと既知の制限を含む）。

上記はソースツリーのサイズ。APK 内の二つはさらに小さい（154856 B / 154840 B）—— release ビルドは native シンボルをストリップするためで、vr detag とは無関係（完成パッケージから取り出して再確認済み、依然 2）。

能力とゲートは対で存在する：com.kernelpack.vivo 下に VrKoPayloadCheck（バイトのみを読む判定条件）と VrKoPayloadGate（藍廠方案にのみ有効、汎用方案はショートサーキットし一切チェックしない）を新設。判定条件は「ログ文字列 vr detag」+「機械語特徴（add #0x2c かつ AND ~0x400）」の二つの組み合わせ —— 全 126 ペイロードの実測で、36/36 の正例がヒット、89 の負例は偽陽性ゼロ。

新規：完全パッケージリンクの解析（自分でファームウェアパッケージ内の boot.img を探す必要なし）

ペイロード構築ページに第三の道が追加された：完全パッケージ（OTA ZIP）の直リンクを直接貼り付ける。

完整包直链  ──►  只取需要的几块  ──►  boot 镜像  ──►  已有的构建流程

それは「パッケージ全体をダウンロードしてから解凍する」ではない —— 完全パッケージは通常 4～8 GiB で、スマホでは数十 GB の通信量になる。 実際のネットワークコストは：

取得するもの	おおよそ
ファイル末尾（ZIP セントラルディレクトリを探す）	64 KiB
ZIP セントラルディレクトリ本体	数百 KiB
payload.bin ヘッダ + パーティション一覧	24 B + 数百 KiB
boot パーティションで実際に使う数ブロック	~64～96 MiB

2 種類の完全パッケージ形態をどちらも認識する：

• A/B 完全パッケージ（payload.bin）：update_engine マニフェストを読み、dst_extents に従ってブロックをイメージに復元する； REPLACE / REPLACE_XZ / ZERO / DISCARD をサポート；
• recovery スタイル完全パッケージ：パッケージ内に直接 boot.img / init_boot.img を格納（国内メーカーで一般的）、 Stored と Deflate をサポート。

能力の限界（正直に列挙、粉飾なし）：