CVE-2026-43499 · HONOR WIN RT (AAK-AN00) 一時的Root研究ノート

（全部deepseekが書いたもので、私は何もわかっていない）（さらに数日格闘したが、進展はゼロ、諦めた）（現在rootは取得できるが、非常に不安定で、root後にネットワークが切断され、ケーブルを抜くと再起動する）（このリポジトリのすべての結論はHONOR WIN RT、CVE-2026-43499脆弱性、6.6.118-android15-8-gf17133276a57-abogki518694926-4kカーネルのみに適用され、結論を一時的rootに拡散しないこと。一時的rootは持続的かつ比較的安定して動作可能）

デバイスのBootloaderは永久にロック（ro.oem_unlock.supportedが空）、fastbootもなく、永続suもなく、Magiskもない。唯一残された道はカーネル脆弱性。本リポジトリは「攻撃できるか」から「攻撃後にどれだけ安定するか」までの完全な過程を記録する。

性質：一時的root、再起動で無効。

免責事項

本リポジトリは、本人所有デバイス上で行ったセキュリティ研究の過程を記録するものであり、目的はカーネルPI競合の成因と安定性の境界を理解することである。

exploitバイナリや直接実行可能な攻撃ペイロードは一切含まない —— ペイロードとフレームワークは上流の公開プロジェクトに由来し、本リポジトリは引用のみで再配布しない。
特定ベンダーのバイパス手段に関するチュートリアルは提供せず、非認可デバイスでの使用を推奨しない。
リポジトリ内のオフセット、シンボルアドレスは本文に記載されたただ一つのカーネルbuildに対してのみ有効であり、カーネルが変わればすべて無効となる。
関連する欠陥はupstreamで修正済み（下記参照）。本文の長期的価値は「この記録そのもの」にある—— 現実の、非理想的な条件下での競合脆弱性の実戦振り返りであり、そのすべての不快な副作用を含む。

0. 一言結論

唯一通り抜けられた経路は：

CVE-2026-43499（futex PI競合 write-what-where） + rt_sigreturnキャリア
  → LD_PRELOADでshellドメインプロセスに注入
  → 二段階式：まずSELinux Permissiveを攻撃、次にtask->real_cred / credをinit_credに変更
  → uid=0(root) context=u:r:kernel:s0、そしてsuデーモンを植え込む

しかし本当に書き残す価値があるのは「どうやってrootを取るか」ではない——取った後に起きたことだ。

手に入れたのは安定したrootではなく、「いつでも起爆されうる状態」である。

exploitの書き込みプリミティブは偽造されたrt_mutex_waiterを本物のfutex PIチェーンに繋ぎ込み、このwaiterのキャリアは後続のシステムコールで再利用されるカーネルスタック / スプレーページである。ゆえにrootが着地した瞬間から、あらゆるシステムレベルのスケジューリングや優先度変更がそれを踏みつけ、直接カーネルpanic再起動を引き起こしうる。これはbugではなく、この利用手法の固有の代償である —— 詳細はdocs/03参照。

1. 適用境界（合致しなければ方案全体が無効）

項目	値	説明
機種	HONOR WIN RT、型番 AAK-AN00	販売名「HONOR WIN RT」
SoC	Snapdragon 8 Elite SM8750-AB	HONOR WIN（AAP-AN00、SM8850-AC）とはファームウェア互換なし
システム	Android 16 / MagicOS 10	—
カーネル	`6.6.118-android15-8-gf17133276a57-abogki518694926-4k`	★ ハード条件、文字単位で一致
カーネル設定	4K pages、`VA_BITS=39`、`CONFIG_FUTEX_PI=y`	キャリア幾何の前提
ファームウェアパッケージ	`.170`	`.160` / `.175`は未検証
Bootloader	永久ロック	fastbootなし / 永続suなし

なぜカーネルバージョンを厳密に固定する必要があるか：欠陥は6.6.140で修正され、本機は6.6.118 < 6.6.140なのでまだ残っている；同時にexploitのすべてのカーネルシンボルアドレスと「キャリア幾何」はこの一つのbuildに固定されており、カーネルが変わればオフセットテーブルは即座に無効となり、かつ一般的にロールバック不可である。

2. 権限昇格経路の全景

┌─ 材料 ────────────────────────────────────────────────┐
│ boot.img + xbl_config.elf（デバイスファームウェアから抽出）            │
│        ↓ シンボル解決                                       │
│ target.h（カーネルシンボルアドレス、kallsymsとバイト単位で照合済み）      │
│        ↓ ビルド                                           │
│ preload.so ──► デバイス側 /data/local/tmp/*.so             │
└────────────────────────────────────────────────────────┘
                 ↓  LD_PRELOAD注入
     ┌──────────── 二段階式（必ず二つの独立プロセス）────────────┐
     │ 段階A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ 段階B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred（"プリセットライター"プロセスが実行）│
     │         → setresuid(0,0,0) 正規化                           │
     │         → 内蔵su + daemonを植え込む                              │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

必ず正しく行わなければならない三つの点（間違えるとフリーズまたは直接panic）：

順序の鉄則：先にreal_cred、後にcred。 逆順だと瞬時に全権限となり、スレッドが制御不能になる。
二刀の間には必然的にcred ≠ real_credの過渡状態が存在する。 この時いかなるsched_setaffinityもEPERMとなる → 全体がフリーズ。正解は第一刀の前に「プリセットライター」プロセスをforkしておくこと（憑証がクリーン）。親プロセスが第一刀を書き、ライターが第二刀を書き、誰も過渡状態でsyscallを発行しない。
アドレスモデルはKASLRと無関係。 利用全体は線形マッピング別名のみを通る alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ)、再起動を跨いで安定；いわゆる「slide段階」の真の価値は書き込みプリミティブの自己検証であり、KASLR回避ではない。

上流フレームワーク：Linuxoid-cn/CVE-2026-43499-Poc-Analysis。 これはGhostLockではない —— GhostLockはpselectルートを通り、本buildのwaiter着地点幾何と一致しない。詳細はdocs/06参照。

3. 目次

ドキュメント	内容
01 · 実現可能性分析	なぜ`rt_sigreturn`一本のキャリアしか残らないか
02 · 権限昇格チェーンと成功要素	書き込みプリミティブ、六段階チェーン、プリセットライター、成功判定基準
03 · 安定性の真因：PIチェーン残留	★ 核心。ネットワーク切断は切断ではなくpanic；クラッシュポイントの逆アセンブリ含む
04 · PC不要チャネル：Shizuku	Shizukuのrishでadbの代わりにexploitを起動
05 · KernelSUのlate-load	LKMのアクティベーション方式と、それがなぜ最も危険な起爆装置か
06 · 死路リスト	試したが通らなかった道、他人の再試行を省くため
07 · 落とし穴と環境	rootなしでpanicスタックを取得、スクリプト環境の落とし穴
08 · よくある誤診の識別	最も広く流布する誤った説明を逐条照合（「KSUモジュールを書いて残留をクリーンアップ」がなぜ不可行か含む）
09 · 二つのチャネル操作実務	★ 手の動かし方 —— adb側 / Shizuku側の完全なフロー、環境変数、判読と後始末
10 · B類ネットワーク切断の定論	★ 再起動しないがネットワークが麻痺；`ping 127.0.0.1`全ロス；30秒で速判
tools/	再利用可能なスクリプト（脱敏汎用版）

4. タイムライン

日付	進展
09-08	BL永久ロック、OEMアンロックチャネル削除済みを確認 ⇒ 公式ルートを諦め、脆弱性ルートへ転換
09-09	ベンダーアフターサービスファームウェアライブラリを攻略、boot.imgを取得、カーネルとシンボルを抽出
09-10	キャリア探索が`rt_sigreturn`に収束；権限昇格成功（20:14）、`uid=0`
09-11	PC不要チャネル（Shizuku）を開通；KernelSUがアクティベート可能；「ネットワーク切断」の真因を定性 = PIチェーン残留
09-12	① 「late-loadが首要の起爆装置」という帰属バイアスを覆す ⇒ デフォルトでKSUを開くよう変更；② USB判定基準を「抜く＝起爆、挿す＝安全」に細分化；③ B類ネットワーク切断の定論 = カーネルIP出力経路の麻痺（`ping 127.0.0.1`全ロス、`OutDiscards 53%`）
09-13	ツール確定 v6（分割ウィンドウ待機 / メトロノーム / `.stop`中止 / 診断はfd3経由、両ポートの口径統一）；本文書に操作実務とB類定論を補完

5. 最も間違えやすい四つの点

#	よくある誤解	実際
1	「USBの抜き差しはどちらも危険」	抜くのは危険、挿すのは安全（09-12実測、docs/08 §2.2参照）
2	「late-load KernelSUが首要の起爆装置」	09-11の帰属バイアス；真因はPIチェーン残留、実測でlate-load後43分安定（docs/05）
3	「権限昇格後のネットワーク切断 = Wi-Fiが壊れた」	まず`ping 127.0.0.1`。loopbackすら通らない ⇒ カーネルIPスタック麻痺、オンラインでは修復不可（docs/10）
4	「`ps`でNAMEが`true`のプロセスはクリーンアップできる」	その`comm`は`GWROOT42`、スプレーページを握っている ⇒ killすると直接panicの可能性

6. 後進への一言

もしあなたもBLロックされた機種を攻撃しているなら、まずrootを取って何をするかよく考えてほしい。なぜならこの種の機種ではrootはおそらく十数分しか使えない窓だからだ。「rootが必要で再起動を跨いで保持できる」操作をリストアップし、一度に全部実行し、その後rebootでクリーンな状態に戻す。「副作用を消そう」としないこと—— それは手法そのものの代償である。

やる気があるなら、docs/09 · 二つのチャネル操作実務から始めてほしい。

cve-2026-43499-aak-an00

人気