Exploit for amazon-mustang-hack

## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-ARTUR9010-AMAZON-MUSTANG-HACK
> **AI支援プロジェクト。** この研究、エクスプロイト開発、およびドキュメントは、 モデル **GLM-5.3** と **DeepSeek V4.1 Flash** を使用したAI支援によって作成されました。

# amazon-mustang-hack

最終ファームウェア — **Fire OS 7.3.3.1、PS7331.4463N、カーネル 4.9.117（ビルド 2025-05-03、SPL 2024-08-01）** における **Amazon Fire 7 第9世代（mustang、MT8163、Mali-T720）** のルートエクスプロイト研究。

目標: LineageOS。このユニットではブートローダーパスは死んでいる（パッチ済みブートROM — CMDショートによるpreloaderのみ）ため、 残された唯一の経路はソフトウェアカーネルエクスプロイトである。

## クイックスタート```

# one-shot: build, run the exploit (retries across the probabilistic reclaim),

# install a setuid-root su and verify it as an unprivileged user

nix-shell -p android-tools --run './run.sh' # add -p zig too if no zig

root@kitploit:~
    
    
    成功時:```
    /data/metrics/su id     # run a command as root
    /data/metrics/su        # interactive root shell
    

reclaim はおよそ **3 回に 1 回の起動** で成功し、失敗するとタブレットはパニック/再起動します。 `run.sh` は再起動を待ってリトライするだけです。SELinux はエクスプロイトの一環として 強制的に Permissive にされるため、root は **実行時のみ** です — 再起動すると ストック状態に戻り、`run.sh` を再実行する必要があります。

ビルド済みの `st3` と `su` (armv7 静的) がコミットされているため、実行に ツールチェーンは不要です。zig があれば `./run.sh --build` で `poc/*.c` から 再ビルドできます。

# 以下はすべてモデルが行った作業のログであり、以下に人間の入力はありません。

## 主要ターゲット (セッション 5 以降): kbase CVE-2022-38181 — ステージ 2 実証済み

GhostLock (下記) は保留中です: MTK の BUG_ON rtmutex 変種 + シェルからの カーネルアドレス開示ゼロ = このビルドではアーキテクチャ上の行き止まり (セッション 2-4)。 kbase JIT UAF は再診断され (destroy-worker の「無条件パニック」は JIT_FREE の 逆参照であり、ログはパニック途中の adbd 死亡により失われた)、ステージ 2 は 現在オラクル実証済みです — SESSION 5 のセクションを参照。

### 保留中: GhostLock, CVE-2026-43499

rtmutex `remove_waiter()` futex-PI スタック UAF (NebuSec 開示 2026-07、修正 `3bfdc63936dd` は 2026-04 に着地)。脆弱な範囲 2.6.39–7.1 → **我々の 4.9.117 (2025 年 5 月) は影響を受ける** 。

我々の正確なビルドで検証済み:

  * `CONFIG_FUTEX=y`、rtmutex はコンパイル済み、バグはそのまま存在: `rtmutex.c:1108-1111` は `current->pi_lock`/`current->pi_blocked_on` を使用 (本来は `waiter->task` であるべき); バグのある呼び出し箇所 `rtmutex.c:1723` (`rt_mutex_start_proxy_lock` エラーパス)
  * トリガー面 = 純粋な futex システムコール (`WAIT_REQUEUE_PI`/`CMP_REQUEUE_PI`)、デバイスノード不要、 SELinux でゲートされるものは何もない — kbase パスの致命的な障害はここには存在しない
  * コンシューマ: `sched_setattr` → `__sched_setscheduler` → `rt_mutex_adjust_pi(p)` が `sched/core.c:4706` で — 古い `pi_blocked_on` を逆参照 ✓



### TODO (移植計画)

  1. トリガーを書く (3 スレッド requeue-PI デッドロック、コア 0-3) — `exp32/main.c` の移植
  2. スタンプ形状: `rt_waiter` フレームオフセット vs `do_sys_select` fd_set 領域 — 我々の vmlinux を 逆アセンブル (`do_sys_select` の stack_fds vs `futex_wait_requeue_pi` フレーム)、 STAMP_NFDS/STAMP_WAITER_OFF を調整可能パラメータとして公開
  3. arm32 48 バイト waiter 用の偽ライターエンコーディング → 「ADDR に V を書き込む」スロット
  4. 2 スロット → modprobe_path、発火、root スクリプト
  5. select-stamp が届かない場合のフォールバック: setsockopt(MCAST_JOIN_SOURCE_GROUP) スタンプ



## ステータス

  * Bootrom (amonet ハードウェア方式) — このユニットではパッチ済み、行き止まり
  * mtk-su (CVE-2020-0069) — パッチ済み、`Failed critical init step 3`
  * 攻撃面調査 — `/dev/mali0` ワールド RW + SELinux `gpu_device`、kbase r26p0-01rel0
  * CVE-2022-38181 を正確なビルドのソースで確認; ステージ 1 トリガーは動作
  * CVE-2026-43499 (GhostLock) は検証済みだがブロック: MTK BUG_ON rtmutex 変種 + シェルからのカーネルアドレス開示なし (セッション 2-4)
  * **CVE-2022-38181 ステージ 2 実証済み (セッション 5): destroy-worker パニックは 誤診断だった; スプレー領域への UAF リダイレクト、オラクル検証済み**
  * ステージ 1: トリガー + スタンプ + コンシューマ (クラッシュ = チェーン稼働)
  * ステージ 2 (kbase パス): スプレー領域への UAF リダイレクト — セッション 5 で実証済み
  * ステージ 2b: 生バイトスロット制御 (xattr スタンプチャーン) → unlink 書き込み
  * **ステージ 3: 任意カーネル関数呼び出し → ROOT (セッション 10)** — nf LOCAL_OUT フックハイジャック、`selroot` 2 パケットチェーン:  をゼロ化、 偽エントリを  に書き換え。、SELinux Permissive。



## 主要な発見

### デバイス / ファームウェア

  * モデル KFMUWI、デバイス `mustang`、Fire OS 7.3.3.1 `PS7331.4463N/0031575863040`
  * カーネル `4.9.117-g08fe75b-dirty`、ビルド日時 Sat May 3 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)
  * Amazon は 2025 年 5 月に 7.3.3.1 をサイレントに再発行 (新しいインクリメンタル、同じバージョン文字列)
  * 2020 年以降のリビジョンの Bootrom: eMMC CMD の GND 短絡で **preloader のみ** が得られる (パッチ済み)
  * `/dev/kb`、`/dev/dkb` (Amazon カーネルバックアップパーティション) root:drmrpc 0660 — ロック済み



### CVE-2022-38181 が適用される理由

  * ドライバ: `mali_kbase` **r26p0-01rel0** (Midgard, Mali-T720)、**NVD の影響範囲 r4p0–r31p0 内**
  * Amazon の 2025 年 5 月の再ビルドは 2018 年のバグをそのまま出荷 — バックポートなし
  * 正確な脆弱コード、ソース検証済み: 
    * `mali_kbase_mem.c:2721` `kbase_jit_destroy_worker` が領域を解放、**`kctx->jit_alloc[id]` を決してクリアしない**
    * `mali_kbase_softjobs.c:1270` `kbase_jit_free_finish` が古い `jit_alloc[ids[j]]` を逆参照
    * `mali_kbase_mem.c:3138` `kbase_jit_backing_lost` → destroy パス (reclaim 中に発火)



### エクスプロイト環境 (すべてライブ config ダンプ + OTA vmlinux から検証済み)

  * armv7 32 ビット、非 LPAE → **KASLR なし** (カーネルは固定 `0xc0008000` VA / `0x40080000` PA)
  * **`ARM_SW_DOMAIN_PAN` なし** → ret2usr が可能; `CONFIG_PANIC_ON_OOPS=y` (失敗した試行 = 再起動)
  * `SLAB_FREELIST_RANDOM`/`HARDENED` なし、`CONFIG_USER_NS`/`USERFAULTFD`/`NF_TABLES` なし
  * `CONFIG_MODULES=y`、`STATIC_USERMODEHELPER` なし → `modprobe_path` 上書き = root
  * 1 GB RAM → 直接 reclaim (eviction に必要) は簡単に到達可能; **~1 GB 超のプレッシャーは カーネル自体をパニックさせる** (無関係な lowmem/OOM バグ) — スプレーは ≤ 900 MB に保ち、~700 MB を使用



### PoC 開発中に遭遇した UAPI の癖 (r26p0, `_IOC_TYPE 0x80`)

  * `MEM_ALLOC` union は 32 バイト (`in` は `extent` を含む 4 × u64)
  * フラグには `BASE_MEM_PROT_GPU_RD|WR` (ビット 2|3) を含める必要があり、レガシーな R|W ではない
  * **任意の alloc の前に tracking-page mmap が必須** : `mmap(fd, offset=3<<12, PROT_NONE)`
  * `JOB_SUBMIT` のストライドは `sizeof(base_jd_atom_v2)` = **48** と等しくなければならない (`base_jd_prio`/`base_jd_dep_type` は u8 typedef)
  * JIT: `MEM_JIT_INIT` (nr 14, v2 構造体)、alloc/free は `JOB_SUBMIT` 経由の **ソフトジョブ** (`BASE_JD_REQ_SOFT_JIT_ALLOC`=0x209, `...FREE`=0x20a; =ユーザーポインタ, =カウント)



### ステージ 1 の差分 (バグが発火することの証明)

パニックは eviction 自体の間に発生する (`evictable_reclaim_scan_objects` → `backing_lost` → destroy worker) — ぶら下がり参照 (`jit_alloc[]`、evict リスト) は、我々が `JIT_FREE` を submit する前に走査される。ステージ 2 はレースに勝つ必要がある: プレッシャーがまだ 実行中の間に、解放された `kbase_va_region` を我々自身の `MEM_ALLOC` スプレーで再確保する。

## 成果物

  * `poc/stage2.c` — ステージ 2 エクスプロイト (モード: `step`/`uaf`/`spstep`/`spfree`/`spray`/`keys`) — `spray 700` = 完全オラクル実行; 生存して一時停止 (クリーンアップには kill)
  * `poc/mustang_jit_uaf.c` — ステージ 1 PoC (モード: `jit N` / `control N` / `pressure N`)
  * `poc/build.sh` — zig クロスビルド (静的 musl armv7)
  * `kernel/vmlinux` — 正確な OTA ビルドから復元したシンボル (vmlinux-to-elf)
  * `kernel/config-*` — 実行中デバイスからの  ダンプ



## ビルドと実行```

nix-shell -p zig --run 'zig cc -target arm-linux-musleabihf -static -O2 -o juaf poc/mustang_jit_uaf.c' adb push juaf /data/local/tmp/juaf && adb shell chmod 755 /data/local/tmp/juaf adb shell /data/local/tmp/juaf jit 700 # full trigger (~reboots device) adb shell /data/local/tmp/juaf control 700 # no-JIT control adb shell /data/local/tmp/juaf pressure 700 # raw memory-pressure control

root@kitploit:~
    
    
    ## 参考文献
    
    - GHSL-2022-054 アドバイザリ: https://securitylab.github.com/advisories/GHSL-2022-054_Arm_Mali/
    - Mo による Pixel 6 エクスプロイトの解説記事: https://github.blog/2023-01-23-pwning-the-all-google-phone-with-a-non-google-bug/
    - Fire HD 10 (trona) の前例、同一バグファミリー: ericpardee.github.io/fire-hd-ownership
    - Amazon OSS ポータル: amazon.com gp/help/customer/display.html nodeId=200203720
    - XDA アンロックスレッド (このハードウェアリビジョンでは無効): xdaforums.com/t/fire-7-2019-mustang-unbrick-downgrade-unlock-root.3944365/
    
    
    ## セッション3 補遺 (詳細なシステムコールスタンプ調査)
    
    コピー元の深さを測定 (絶対値 vs システムコールエントリ時の sp0、waiter の範囲は -0x1d8..-0x1a8):
    - sendto sockaddr @ -0xc4 | process_vm iov @ -0x104 | recvmsg iov @ -0x11c
    - sendmsg iov @ -0x12c | recvmmsg iov @ -0x154 | select fds @ -0x174
    - pselect6 fds @ -0x19c | **sendmmsg iov @ -0x1bc (最良 — waiter+0x00 まであと 0x1c)**
    - poll entries @ -0x3e0 (完全に下方、逆側)
    
    今セッションで除外:
    - io_submit チェーンは浅すぎる (~-0x130) | semtimedop: CONFIG_SYSVIPC=n (スタブ)
    - configfs はマウントされているがサブシステムがゼロ登録 (mkdir 対象なし)
    - /sys/kernel/debug, /config: shell に対して SELinux 拒否
    - /proc/sys/kernel: getdents は動作 (29 エントリを列挙)、pid_max のみ OPEN 可能;
      kptr_restrict/hotplug/hostname/domainname の読み取りはすべて拒否
    - 書き込み値は常に waiter+0 (カーネルスタックアドレス、実行可能、シェルコードは
      +0x1c): rb_link_node *link = node、insert_color は parent-color を書き込む —
      ツリーフィールドスタンプなしでは制御値のバリアントは不可能 (ギャップ -0x1d8..-0x1bc)
    - 二重デリファレンスのディスパッチフィールドは *(waiter+0)=1, *(waiter+4/+8)=0 を読む — BLX 1/0
      (nf_hooks, net_families, inet[6]_protos, seq_file->op はすべて無効)
    - timer_list.function@+0xc と work_struct.func@+0xc は *(waiter+0xc) =
      pi_tree 自己ポインタ = 実行可能な waiter+0xc を読むはず — しかし waiter+0 を
      timer/work としてキューするパスがない (リンク破壊 / 間接キューソースなし)
    - ツリールート非ゼロ (sysctl ハンドラスロット) = .text を rb-tree として
      決定論的にポインタチェイス; ゼロワードで終端 — オフラインシミュレーション可能だが、
      有用な書き込み可能スロットに着地するのは非現実的
    
    セッション4 に向けた残りの手がかり:
    1. ioctl の深いパス: dev_ioctl の ifreq コピー (40B のユーザーデータ) —
       SyS_ioctl→sock_ioctl→dev_ioctl チェーンの深さを -0x1d8 と比較測定
    2. sendmmsg より 0x1c 深いコピーが他にあるか (今のところ見つかっていない)
    3. スタンプ表面の探索が失敗した場合: ウォークチェーン構築を再検討するか、
       まだ列挙していない書き込み可能ゼロ呼び出しスロットクラスを探す
    
    
    ## セッション4 — 二つのブレークスルー
    
    ### 1. MTK の rtmutex_common.h が謎のすべてだった
    MTK は上流の NULL 安全な rt_mutex_top_waiter を以下に置き換えた:```c
    w = rb_entry(lock->waiters_leftmost, struct rt_mutex_waiter, tree_entry);
    BUG_ON(w->lock != lock);   // compiled to: ldr sb,[lock+8]; ldr r3,[sb+0x1c]; cmp; bne→udf#0x12
    

NULL チェックなし + BUG_ON。全ゼロのアンカーはすべて *(NULL+0x1c) で死ぬ。ガベージ アンカーは udf で死ぬ。ウォークの要件: lock->waiters_leftmost (lock+8) が偽のウェイター W (書き込み可能) を指し、W->lock (+0x1c) == lock でなければならない。

ウォークフローを完全にマッピング (rt_mutex_adjust_prio_chain @ 0xc0189a58):

  * 9b44-9b54: retry ヘッド; pi_blocked_on==NULL → クリーン終了 ret 0
  * 9abc-9adc: orig_waiter==NULL → pi_waiters チェックをスキップ (adjust_pi は常に NULL を渡す)
  * 9b10-9b28: prio チェック (prio==task->prio + MIN → 終了 9b58)
  * 9b2c-9b38: trylock(lock+0) — チケット; 失敗 → カウンタ bail 付き retry ループ (9a90-9aa8, limit @ *(0xc11189c8))
  * 9ba4-9bc0: デッドロックチェック
  * 9bcc-9bd8: THE BUG_ON (leftmost→W→W->lock==lock でなければ死)
  * 9bdc-9c04: dequeue (残ったツリーは RB_CLEAR_NODE 化 = EMPTY → 安全にスキップ), prio/deadline 書き込み
  * 9c04 bl: rt_mutex_enqueue → *link = waiter+0 at lock+4 ← これが書き込み
  * 9c3c+: owner==NULL → クリーン終了パス



### 2\. カーネルスタックアドレスのリーク (アドレスフリー要件を破壊する)

/proc/self/task//stat のフィールド 28 (kstkesp) は、SHELL コンテキストから syscall でブロックされたスレッドの実際のカーネル SP を返す (検証済み: 非ゼロ値が観測された)。

  * ウェイターが read(blocking_pipe) でブロック → stat → kstkesp
  * スタックベース = kstkesp & ~0x1fff (arm32 THREAD_SIZE=8192)
  * rt_waiter の絶対アドレス = base + 固定デルタ (計算可能: sp0 = base+0x2000-0x48 pt_regs; waiter = sp0-0x1d8)
  * すべての自己参照スタンプ値が計算可能になる!



### 完全な自己整合スタンプ (リーク後):

  * L = waiter+0x24 (ウィンドウ内の偽ロック — 4 ワードすべて制御可能)
  * iov[0].base (waiter+0x1c lock) = L
  * iov[0].len (waiter+0x20 prio) = 1 (≠139)
  * W = waiter+0x1c; stamp *(W+0x1c) = *(waiter+0x38) = L (BUG_ON 通過)
  * lock+0 (waiter+0x24) = 0; lock+4 (waiter+0x28) = 0 (書き込みはここに着地); lock+8 (waiter+0x2c) = W; lock+0xc (waiter+0x30) = 0 (owner NULL)



### オラクル状態

  * ウォーク中のクラッシュ = ウォークが実行された (デッドロックプローブ: 決定論的クラッシュ、クリーンコード)
  * クリーンウォーク + 書き込みなし = trylock 失敗 retry-bailout (kptr アンカー: ランタイムワード非ゼロ)
  * ポリューション修正後、すべてが決定論的に。



### 次セッション TODO

  1. リークを実装: ウェイターがパイプでブロック、メインが stat を読み、ベースを計算
  2. 自己整合ウィンドウをスタンプ、ウォークを発火 → クラッシュなし完了 = 書き込み証明
  3. 兵器化: 書き込みは常に lock+4 (rb_link_node) に着地 — lock はウィンドウ内 (完全に制御されたメモリのみ) に存在する必要があるため、ターゲット選択の研究: ウィンドウ内の呼び出しスロットトリックを見つけるか、二段階構築のいずれか。



## セッション 4 最終状態 — 壁 (正確に特徴付け)

### 全体像

ウォークは決定論的に発火する (デッドロックプローブ: 毎回クラッシュ、クリーンコード)。 書き込みが着地できないのは、3 方向のカーネルハードニングの偶然による:

  1. **MTK rtmutex BUG_ON 変種** : lock+8 (leftmost) は W を指し、 *(W+0x1c)==lock でなければならない。全ゼロ/ガベージアンカーは死ぬ。静的な自己参照 パターンは存在しない (6571 候補をスキャン、0 ヒット)。ランタイムポインタは不明。
  2. **シェルからのカーネルアドレス開示なし** : 
     * arm32 の kstkesp = USER SP (task_pt_regs->ARM_sp) — カーネルスタックではない。DEAD。
     * dmesg/pstore/pagetypeinfo/kallsyms/stack — すべて拒否。
     * ランタイムで kptr_restrict=1 (fops アンカーワードもランタイム非ゼロ — kptr アンカー実行は trylock 成功ではなく trylock 失敗 retry-bailout で終了)
  3. **rodata 内の fops テーブル** : trylock strex がアボート (セッション 3 スイープクラッシュ)。



スタンプウィンドウ (waiter+0x1c..0x5b) は唯一の制御+既知内容の メモリだが、そのアドレスが我々が必要とする未知数である。自己参照構築は すべてカーネルアドレスを定数としてスタンプする必要がある — リークなしでは循環。

### gitchw 比較 (なぜ彼らの ARM32 書き込みは成功し、我々はまだできないか)

彼らの 5.4 カーネルは UPSTREAM rtmutex_top_waiter (NULL 安全: `if (!leftmost) return NULL`) — 空ツリーアンカーが生き残り、彼らの書き込みは null_fops (彼らのカーネルでは書き込み可能) に着地した。彼らでさえディスパッチで 行き詰まっている ("ioctl reboot")。Mustang の 4.9.117 MTK ツリーは BUG_ON 変種 — Fire OS 8 タブレット (GhostLock-5.10) は成功した。彼らの 5.10 カーネルが upstream スタイルだから。

### セッション 4 で検証された事実

  * ウォーク retry ループにはカウンタ bailout がある (limit @ *(0xc11189c8)); ランタイム非ゼロ アンカーワードで trylock 失敗 → クリーン retry-bailout 終了 (kptr アンカー実行)
  * No-requeue パス (9ce4, FULL ウォーク) も 9d64 で leftmost を deref — 逃げ道なし
  * RB_CLEAR_NODE 自己ポインタはウィンドウ内の残り物として存在する (waiter+0 と +0xc は自身のアドレスを含む) が、既知アドレスのスタンプを回避する方法で それらを使用するチェック比較はない
  * 実ミューテックス候補 (chain mutex はライブウェイターを持つ = BUG_ON が通過する) — しかし &chain_mutex はヒープアドレスで、リークなしでは到達不能



### 次セッションのオプション (ランク付け)

  1. **logcat カーネルポインタハント** : Amazon HAL/デーモンはおしゃべり; ログに記録された カーネルポインタ (古くても) が構築をアンブロックする。テストは安価。
  2. **このビルドでの /proc/net %pK 挙動** : 一部の 4.9 ツリーは非特権リーダーに対して /proc/net/tcp,udp,unix でハッシュ化されていないポインタを出力する。ライブでテスト。
  3. **ダングリング pi_blocked_on でのスレッド終了パス** (ワンショット、異なる deref)。
  4. 蓄積された 4.9 知識で棚上げされた kbase JIT バグを再訪。



## セッション 4 補遺 — リークハント: 枯渇 (決定的)

シェルドメインからテスト済みで死んでいる:

  * /proc/net/{tcp,unix,packet,netlink,ptype}: %pK ハッシュ化で 00000000 (kptr_restrict=1)
  * /proc/timer_list: 読み取り可能だがポインタは %pK ゼロ化 (シンボルは見える、アドレスなし)
  * logcat: Amazon/wpa のおしゃべりにカーネルポインタなし
  * kstkesp (stat f28): arm32 では USER SP (task_pt_regs->ARM_sp)
  * MTK ノード (/proc/ged, mtk_cmdq_debug, mtktz, ptp, chip, aed, driver/*): すべて SELinux 拒否
  * /proc/{iomem,vmstat,kmsg,keys,crypto,slabs...}: 拒否
  * /sys/kernel/notes: 拒否
  * CONFIG_VECTORS_BASE=0xffff0000 (ハイベクタ — NULL+0x1c フォルト)
  * CONFIG_KUSER_HELPERS=y (kuser は 0xffff0000、ページ 0 ではない)



結論: mustang 上の GhostLock は、このカーネルがシェルドメインに公開しない カーネルアドレス開示を必要とする。自己参照の偽ロックはそれなしでは構築できない。

## 決定ポイント

(a) ブート決定論的グラインド: 再起動 → クラッシュオラクルでスタックアドレスを キャリブレーション (~20-30 回の再起動)、再現性を検証。ロングショット — レイトブートの スレッドスタック割り当ては安定しそうにない。 (b) 蓄積された資産で kbase CVE-2022-38181 にピボットバック: 正確なビルドの vmlinux + 完全なソース + ツールチェーン + O_SYNC トレース規律 + 深い 4.9 知識。元のブロッカー (JIT エビクション中の destroy-worker パニック) はスプレイタイミングの問題で、今はよりよく理解されている。 (c) 正直な ~45% で停止: トリガー証明済み、ウォークは命令までマッピング済み、 書き込みは MTK BUG_ON + リークなしでブロック。

推奨: (b) — kbase バグはこの正確なソースで存在が検証されており、 動作するトリガーがあり、そのブロッカーはアーキテクチャ的ではなく機械的。

## セッション 5 — ステージ 2 証明 (オプション b 実行)

### 再診断: 「無条件 destroy パニック」は存在しなかった

`step` モード (alloc id=1 → DONT_NEED → 700MB プレッシャー → MEM_QUERY、free なし) は**生き残る** : query=-1 (リージョンは destroy ワーカーによって解放、rbtree クリーン)。 ワーカーパスはプレッシャー下の合法的な JIT_FREE フローとバイト単位で同一。 セッション 1 のクラッシュは常に `JIT_FREE` ダングリング deref だった; そのログ行は パニックがフラッシュ中に adbd を殺すため失われた。`uaf` モード (ベア free → パニック、 同じログカットオフ) でさらに 2 回検証。**GHSL-2022-054 フローはこのビルドで完全に ライブ。**

### 完全なプリミティブインベントリ (正確な vmlinux 逆アセンブリ)

`kbase_jit_free(kctx, reg)` @ 0xc058495c、完全に制御された偽 reg で:

  * `reg->cpu_alloc` NULL → backed size 0 → trim ブロックをスキップ (0xc0584978)
  * bin デクリメント: `kctx+0x147dd` (バイト) + `kctx+0x147de+bin_id` (バイト)
  * `mark_reclaim(reg->gpu_alloc)` @ 0xc059b158: チェーン `K=*(gpu_alloc+0x38)` → `*(K+0x1429c)==0` が mm-atomics をスキップ → atomic_sub nents@K+0x141c8, `D=*(K+4)` → atomic_sub nents@D+0x538。 nents=0 ではすべての書き込みは no-op ストア (同じ値の strex)。
  * `reg->flags |= 0x100000` (偽への書き込み、無害)
  * shrink_cpu_mapping は new==old で早期終了 (nents=0 → return)
  * `list_add(gpu_alloc->evict_node, &kctx->evict_list)`: evict_list ヘッド @ kctx+0x1427c; gpu_alloc+0x18/0x1c への書き込み (書き込み可能でなければならない)
  * WARN パス (0xc0584bd4) は非致命的 (panic_on_warn なし) で継続
  * **UNLINK @ 0xc0584b08/b0c** : `r3=*(reg+0x3c) prev, r2=*(reg+0x38) next` → `*(next+4)=prev; *(prev+0)=next` — 2 つの任意 write-what-where、 その後 reg+0x38 を jit_pool_head @ kctx+0x148e8 に再リンク



### 静的偽 gpu_alloc チェーン (オフライン vmlinux スキャン, /tmp/opencode/scan_s.py)

9 候補; **S=0xc118b7ec** (xfrm データ、このデバイスでは休眠): `*(S+8)=0` (nents), `*(S+0x18)=S+0x18` (空の evict_node → WARN なし), `K=*(S+0x38)=0xc118b820` → `*(K+0x1429c)=0`, K/D+0x141c8/+0x538 すべて 書き込み可能データ内。オラクルターゲットをステージング: `init_uts_ns.name.nodename=0xc110d561` ("(none)"、uname で読み取り可能)、スクラッチ P=0xc118bd58 (xfrm ゼロ)。 S=0xc111cba4 (tracepoint 隣接) を回避。CONFIG_DEBUG_RODATA=y → すべての書き込み ターゲットは .data/.bss 内でなければならない (bss 0xc11d9000-0xc12d9000)。

### スプレイエンジニアリング (何が機能し、何が機能しなかったか)

  * `add_key` (CONFIG_KEYS=y): シェルで SELinux 拒否。Dead。
  * `setxattr` 値バッファ: kvmalloc(96)+copy_from_user は SELinux チェックの 前に発生 → 呼び出しが失敗しても alloc ダンスは SELinux プルーフ; 一時的 (syscall 終了時に解放)、バイトは +4..95 に持続 (freelist ptr が +0..3 = rblink を上書き、kbase_jit_free では未使用)
  * **kbase_va_region 自体: kzalloc(72) → kmalloc-96!** MEM_ALLOC(va=0x40, commit=0x10) はリージョンのみを kmalloc-96 に置く (phy alloc → 384) → 決定論的リクレームタイプ。実リージョンの被害者は kbase_jit_free を 完全に合法的な状態で完了させる (空の jit_node → 自己アンリンク)。
  * プレッシャー後の逐次スプレイ: 常にミス — ワーカーはプレッシャー中に スロットを部分スラブに解放する (SLUB: 非アクティブスラブへの free ≠ cpu freelist); プレッシャー下では我々の alloc は失敗 → 正味ボリュームゼロ → ローテーションなし
  * ピン留めスプレイヤー + キャップ: まだミス (512 キャップがエビクション前に枯渇; ワーカーは任意の cpu で実行される可能性)
  * **勝者: commit_pages=0 スプレイ** — phys ページなし → MEM_ALLOC が プレッシャーストーム全体を通して成功 → ~6000 正味割り当て → 部分リスト ローテーション保証。8 スレッド (2/cpu、cpus 0-3 ハードコード — /proc/cpuinfo はシェルに 1 コアにフィルタされる、Cpus_allowed_list を使用) + プレッシャー子を cpu0 にピン留め + join 後の 16-alloc 保持バッチ。
  * query(jit_va) トラップ: リクレーム後、スプレイリージョンはカスタムゾーンで 解放された VA を再利用 → query=0 は曖昧 (ライブオリジナル vs スプレイが VA をカバー)



### オラクルヒット — マシン検証済みリダイレクト

`spray 700` 実行 2026-09-11: プレッシャー中に 5895 リージョンをスプレイ、ダングリング id=1 の JIT_FREE がリクレームされたリージョンで完了、その後 `JIT_ALLOC(0x40, bin 0)` が jit_pool_head をウォークし、**スプレイされたリージョン #4251 の VA (0x142701000)** を返した — ダングリングポインタが消費した正確な リージョン。その後プロセス kill: kctx ティアダウンクリーン、クラッシュなし。 **ステージ 2 完了: 制御されたオブジェクトタイプ + 内容での決定論的 UAF リダイレクト。**

### ステージ 3 計画 (生バイトアンリンク)

リージョンタイプのリクレームは合法的ダンスの生存を与えるが、jit_node は INIT された 自己 → アンリンクプリミティブなし。+0x38/+0x3c に生バイトが必要:

  1. xattr スタンピング: リージョン alloc バースト (正味ボリューム → スラブ ローテーション) と xattr ストーム (すべてのヘッドスロットをスタンプ、バイトは free 後も持続) を交互に → 静かなウィンドウ → deref
  2. またはピン留め sendmsg cmsg (optmem_max=10240 → ~106 × 96B 保持)
  3. その後: W1 `*(N+4)=P` で P=ユーザーランドシェルコードページ (PAN なし!) — 候補: const fops は .rodata (DEBUG_RODATA) → .data 内の非 const fn ptr をターゲット、または binfmt `formats` リストヘッド、または sysctl proc_handler (テーブル書き込み可能性を検証)。フォールバック: バイトチェーン書き込みによる modprobe_path (値は書き込み可能アドレスでなければならない — ポインタ形状の ターゲットを使用)
  4. KASLR なし + 正確な vmlinux: prepare_kernel_cred 0xc0149e3c, commit_creds 0xc014993c



## セッション 5B — ステージ 3: 兵器構築済み、リクレームレースはまだ勝てず

### 完了

  * **ステージ 3 兵器完成 & ステージング済み** (`poc/stage3.c`): 
    * ターゲット: `kern_table[pid_max].proc_handler @ 0xc1113f40` (書き込み可能 .data、文字列ポインタスキャン + handler == proc_dointvec_minmax で検証済み)
    * N = シェルコードエントリ 0x11111112 (mmap 0x11111000; W1 は entry+4 を上書き、 `b +8` でスキップ; W2 は P = handler フィールドに N を書き込む)
    * arm32 ring0 シェルコード手動エンコード: prepare_kernel_cred(0) + commit_creds + ret 0; トリガー = `read /proc/sys/kernel/pid_max` (シェルから読み取り可能); 自身のタスクコンテキストで実行 → creds が我々に適用
    * 良性オラクルモードは uts nodename (0xc110d561、非アライン OK) を書き込む
  * **スプレイプリミティブ選択** : 
    * NETLINK_USERSOCK sendmsg ピン (msg_control kmalloc-96 コピー、ブロック中保持、 決してパースされない): **SELinux 拒否** (socket create EACCES)
    * unix/UDP sendmsg: cmsg パースがペイロードバイトを汚染 ✗
    * **inotify イベント** : `inotify_handle_event` が name_len+0x1d を kmalloc、 name バイト (完全に制御、NUL/スラッシュフリー制約) が event+0x1c に; name_len=60 → kmalloc-96; キュー済み → 保持; 4 インスタンス → rename ごとに 4 イベント; シェルから SELinux-OK。偽を NUL フリーに再設計: cpu_alloc は S を指す (nents@S+8 = 0 → NULL と同じセマンティクス)
  * **機械的チェーンをエンドツーエンドで検証** (drain4、エビクションなし実行): 20K ドレインイベント + 13.5K マルチ cpu トレーリング rename + JIT_FREE + オラクル + ポーズ、すべてクリーン。O_SYNC ログ (/data/local/tmp/s3.log) は パニックを生き残る — 正確なクラッシュポイントフォレンジック。



### 解放されたスロットでのリクレーム試行 (これまですべてミス)

変種| 結果  
---|---  
ストーム中の並行 rename スプレイヤー| rename がストール (journal/GFP_NOFS) → 合計 128 → ガベージ deref  
12K イベント事前ドレイン + プレッシャー + 小さなトレーリング  
  
作業仮説: **ストームジャンクレース** — destroy ワーカーがスロットを解放する (ストーム中) のと子 kill/静けさの間に、残留リクレーム活動が被害者スラブの 唯一の空きスロットを非ペイロードバイトで取る。リージョンスプレイ (ステージ 2) は ストーム中に継続的に割り当てるため勝つ; rename はできない。

### 遭遇した落とし穴

  * スプレイトグルバグ: rename ソースはペイロード名でなければならない (一時名だった → 2 ウェーブ後に ENOENT → 512 イベントのみ)
  * デバイスホスト名は "localhost"/変動 — オラクルは前後を比較
  * ポーズされた st3 + pkill → デバイス WEDGE (33K イベントでティアダウン?!) — ポーズ されたプロセスは再起動でのみ kill; セッションの 2 回目のハードウェッジ
  * /proc/cpuinfo はシェルに 1 cpu を表示; Cpus_allowed_list を使用



### 次の動き (ランク付け)

  1. drain4 @ 500MB (エビクション閾値がそこで確認済み)、1ms ポーリング、即時 kill、4-cpu トレーリング × 3200 — ストームウィンドウを縮小
  2. xattr スタンプチャーン (setxattr alloc-copy は SELinux チェックの前に発生 — SELinux プルーフ) をストーム + リージョンローテーションと並行、最後にスタンプ
  3. リージョンリクレーム (証明済み) を受け入れ + リージョン被害者状態での セカンドステージプリミティブを探す (double jit_free 分析はこれまで否定的)



## セッション 5C — ブロッカー、正確に特徴付け

### 今セッションの経験的結果

  * drain4@500 (1ms ポーリング、即時 kill、+4.5K rename): まだ deref でクラッシュ
  * トレーリングを kill とオーバーラップ (drain5): より早くクラッシュ (kill リカバリー ストーム中の rename がシステムレベルフォルトにヒット) — オーバーラップ放棄
  * **分離実験 (`iso` モード)**: 同一タイミング、commit-0 リージョンでのトレーリング 
    * ステージ 2 プール再利用オラクル → **オラクルヒット** → タイミング/到達可能性は問題ない; イベントが問題
  * マスクサイクルイベント (MOVED_TO/CREATE/DELETE ローテーションで inotify_merge を破る): まだ deref でクラッシュ
  * CONFIG_MEMCG=n → イベントとリージョンは 1 つの kmalloc-96 を共有 (memcg 理論 死亡); inotify_merge は名前も比較 (マージ理論死亡 — 我々のトグル名は決して マージされなかった; イベントはずっとキューされ保持されていた)
  * /proc/slabinfo 不在; /proc/self/pagemap は読み取り可能だが PFN ゼロ化 (post-4.0 マスキング、CAP_SYS_ADMIN なし)



### 実際のブロッカー (2 部分、両方証明済み)

  1. **ソフトジョブ終了は kbase ジョブスケジューラのワーカーコンテキストで実行される** (jd_run_atom ← js dispatch, mali_kbase_jd.c:81-112/677)、submit ioctl に インラインではない → `current->mm` はカーネルスレッドのもの → エレガントな 「偽のポインタを我々自身のユーザーランド mmap に向ける」設計 (PAN なし!) が 非決定論的に FAULT する。それ以外は完璧な偽で 5/5 クラッシュ。
  2. したがって gpu_alloc は生存可能なランタイムチェーンを持つカーネルメモリを 指さなければならない: `K=*(S+0x38)` 読み取り可能、`*(K+0x1429c)==0` ランタイムで (mm-atomics をスキップ)、`K+0x141c8` 書き込み可能、`D=*(K+4)` → `D+0x538` 書き込み可能、nents `*(S+8)` はできれば 0。9 つのオフライン S 候補は ファイルバイトに対して検証された — ランタイムドリフト (xfrm/tracepoint init) がそれらを未検証にする。間違ったチェーン = クラッシュ = 再起動 (~3 分サイクル)。



### セッション 6 計画 (両方完全に指定)

A. **Physmap スプレイ偽 (ret2dir、古典的 arm32 no-PAN)** : 各々が 1 つの推測 アドレス G 用に焼き込まれた偽パターンを含む ~450MB のユーザーページを スプレイ (G&0xfff = 0x141 で NUL フリー名バイト; S=G; K=G-0x141b4 で K+4 がページ内に着地; K+0x141c8/+0x1429c → G+0x10/+0xd4 ページ内; D=G+0x300; はぐれた sub-0 ストアはランダムなマップ済み RAM にヒット - nents=0 で無害)。 スプレイはエビクションプレッシャーを兼ねる (ダーティ anon = エビクト不可 → 追加で ~100-200MB のみ必要)。オッズ ≈ 45% (ページヒット) × ~50% (外部 K+0x1429c ワードがゼロ... 上のレイアウトで K+0x1429c がページ内に保たれれば、 オッズ = ページヒットのみ)。ミス = クラッシュ = 再起動、リトライ。 B. **9 つの静的 S 候補をブルートフォース** (xfrm 0xc118b7ec 最初、 tracepoint 隣接 0xc111cba4 2 番目...): 候補ごとに 1 再起動、 良性オラクルペイロード最初、ヒットで兵器。 C. pagemap ベースの正確な G (死亡: PFN マスク済み) — 再訪しない。

## セッション 5D — physmap 偽構築; G スイープ 0/3; 交絡因子排除

### 今セッションで確立 (すべてバイナリ/デバイス検証済み)

  * **キャッシュ同一性確認済み** : region = kmem_cache_alloc_trace( kmalloc_caches[7], GFP|0x8000, 0x48) [kbase_alloc_free_region disasm]; event = __kmalloc(89, GFP) → kmalloc-96。イベントとリージョンは被害者の キャッシュを共有できる。(MEMCG off; 単一キャッシュセット。)
  * inotify キュー: ≥5000 イベント保持、オーバーフローなし、マージ崩壊なし (qmeas 1000 & 5000 実行) — イベントスプレイは持続
  * **iso2 (physmap スプレイ + リージョントレーリング + オラクル): ヒット** — physmap スプレイはリージョンリクレームを壊さない; 機構は健全
  * イベント vs リージョンリクレーム: リージョン 3/3 (iso, iso2, stage-2)、イベント 0/10 ただし 3 つの pmap 実行は各 0.3-0.45 オッズでの G ミスで説明される (P(3 ミス|イベント機能) ≈ 0.2-0.3 — 決定的ではない)
  * mix モード交絡: 480MB スプレイが kill 後の rename を窒息させる (+0); 350MB OK (+4452); スピンする失敗 rename スレッドもリージョン リクレームを妨害 (mix クラッシュ、iso2 クリーン)
  * query_commit は EINVAL でも -1 を返す — 計装済み; 観測された EINVAL = rbtree ルックアップミス = 真に解放 ✓ (偽陽性ではない)



### 現在の pmap 設計 (stage3.c 内、モード pmap/mix/iso2)

  * G をすべてのスプレイページに焼き込み (オフセット 0x2a4): nents@+### カーネルソース全体を抽出完了 `/tmp/opencode/ksrc2/kernel/mediatek/mt8163/4.9/` (arch/arm を含む mustang.dtsi、mm/、fs/eventpoll.c、fs/notify) を ksrc/platform.tar から。 知見:
  * 0x8000 GFP ビット = ___GFP_ZERO (単なる kzalloc、キャッシュ分割なし)
  * kmalloc-96 は真の 96 バイトキャッシュ (kmalloc キャッシュに HWCACHE_ALIGN なし)
  * mustang.dtsi: メモリノード 0x40000000/512MB — preloader により拡張 (デバイスは MemTotal 977MB を表示); CONFIG_VMSPLIT_3G、HIGHMEM=y
  * **zram0 アクティブ (SwapCached > 0)** → 「ダーティ anon = unevictable」は 誤り: physmap スプレーはプレッシャー下でスワップアウトされる → G エイリアスが 陳腐化 → kill 後に `physmap_retouch()` を追加 (trailing/deref の前に すべてのスプレーページをフォールトインし直す)



### 今回のセッションの実行 (すべて O_SYNC ログ、~6 回再起動)

### イベントに関する判定 (ベイズ的、正直に)

リージョン reclaim: 3/3。イベント: 0/~12 試行、28K の排他的 アロケーションをヘッドスタートと構成的に正しいフェイク付きで含む。もしイベントが p_hit(G)≈0.35 で reclaim するなら、5 回の pmap ミス ≈ 11.6% — 可能だが今や ありそうにない (~10-15%)。イベントが構造的にこのスロットを取れないのか (理由不明 — 同じキャッシュ、同じコンテキスト、同じタイミング)、それとも我々の G 推測が 系統的に外しているのか (highmem 境界の偏り、アロケータ配置)。

### セッション 7 の決定木

  1. **まず G を確定させる** (安価、エクスプロイトなし): ISO2 フローを一時的に 計装 — リージョン trailing + オラクル — ただし PAYLOAD イベントを physmap フェイクにし、リージョンが競合しない状態で掃引範囲内の任意の G が nodename 変更を生むか確認 (純粋な pmap、~0xc1500000-0xc2a00000 lowmem 中心の G 掃引、再起動あたり 1 G、4-5 回再起動)
  2. G 掃引が尽きたら → イベントは死亡宣告 → シェルから到達可能な代替の 生バイト kmalloc-96 アロケータを探す (監査: seq_file、tty ldisc、fdtable、 sk_filter (ブロック: +0x38 の code-field)、netlink nlmsg (skb ✗)、 keys (拒否)) — または二段階リージョンプリミティブを再検討 (これまでの分析は否定的)
  3. 後で root 経由の UART/ramoops アンロックを検討; 追わない



## セッション 7 — cmdline の衝撃的事実; イベントの謎が精密に境界づけられる

### mustang_defconfig CONFIG_CMDLINE (配置の ground truth):

`vmalloc=496M slub_max_order=0 slub_debug=O loglevel=8 initcall_debug`

  1. **vmalloc=496M → physmap = 0xc0008000..~0xc2080000 のみ (RAM の低い 520MB)** — 以前の G 推測 (0xc2a4xxxx+) はすべて VMALLOC 空間内だった。 セッション 5D/6 のすべての「G ミス」結論は無効化される; クラッシュ解釈は 成り立つが、掃引は間違ったマップを狙っていた。
  2. slub_max_order=0: すべての slab ページが order-0
  3. KMALLOC_MIN_SIZE = ARCH_KMALLOC_MINALIGN = 64 (L1_CACHE_SHIFT 6) → 96/192 の kmalloc_index() 特殊ケースは無効化 → リージョン kzalloc(0x48=72) → caches[7]; イベント __kmalloc(89) → caches[7] (disasm + include/linux/slab.h:287 で検証済み) — 両方とも統合された 128 バイト「kmalloc-128/96」キャッシュ内。キャッシュ同一性: 再確認済みで等しい。
  4. zram アクティブ → anon physmap スプレーを **kbm_spray** に置換: 160 × 2MB kbase MEM_ALLOC リージョン (GFP_KERNEL → ZONE_NORMAL → lowmem のみ、 ピン留め → zram 免疫)、パターンは CPU mmap 経由で書き込み — 正しい範囲、 ~65% lowmem カバレッジ



### 実行 (O_SYNC ログ)

  * kbm + G=0xc16412a4: deref でクラッシュ (+4831 リネーム)
  * kbm + G=0xc1c4b2a4 @200MB: エビクションなし (query=16 — プレッシャー キャリブレーションはピン留めスプレーで変動; 合法的に空き、生存)
  * kbm + G=0xc1c4b2a4 @400MB: エビクション ✓、+4053 リネーム、deref でクラッシュ
  * 有効範囲 G 記録: 0/2。もしイベントが ~65% カバレッジで機能するなら: P(2 ミス) ≈ 12%。問いは依然未解決だがかつてなく狭まった。



### 問い、最終形

リージョンは被害者スロットを 3/3 で取る; イベントは 0/13。同じキャッシュ (ソース + disasm レベルで証明済み)、同じプロセスコンテキスト、同じピン留め CPU、同じ kill 後タイミング、排他的ヘッドスタート付きの数千のアロケーション。 メカニズム不明。残る容疑者: アロケーションレート/頻度と部分リストローテーションの 相関 (リージョン ioctl は ~1ms 間隔 vs イベントリネームは ~100µs 間隔 — 逆方向?)、または slub_max_order=0 下の SLUB フリーリスト順序の詳細が 有利に働く…不明瞭。

### セッション 8 の TODO

  1. 計装グレードの実験: 異なる N/P 値を持つ TWO イベントペイロード変種を 交互に (2 つの名前セット) — nodename が変化すれば、最後の勝者が特定される; kbm スプレーで [0xc1200000..0xc2000000] の G を掃引、3-4 回再起動の予算
  2. それでも 0/N なら: イベントを放棄。代替案のランク: a. **F_SETPIPE_SZ 経由の pipe_buf 配列 (4096 → 1 buf? いや — 16 bufs = kcalloc(16, 28)=448→512 ✗)** — 死亡 b. 他の名前/データを運ぶ kmalloc-128 オブジェクトについて fs/notify + fs を 監査 (fanotify イベント? mq オフ; fanotify はグループが必要…) c. **seq_file バッファ** (kmalloc(PAGE_SIZE) ✗) d. sock フィルタ (+0x38 での code-field 衝突 ✗) e. リージョン型 reclaim を受け入れ + 第二のバグ/テクニックを連鎖
  3. なぜリージョンが勝つのかを再検討 — 複数の jit id で計装するかも: N 個のダングリングスロット、スロットごとのリージョン vs イベント競合、 オラクルがどのスプレーがどのスロットを取ったか検出 → メカニズムの 統計的フィンガープリント



## セッション 8 — デバイス上で任意書き込みを達成; dispatch の謎は残る

### マイルストーン```

[+] uname.nodename="X?lhost" (was "localhost") <<< ORACLE HIT

root@kitploit:~
    
    
    **完全な生バイトチェーンは実機で動作する**: イベントが解放済み
    リージョンスロットを回収 → kbase_jit_free が我々の偽物を逆参照 (S=kbm スプレーからの physmap ページ、G=0xc154b2a4) → unlink が我々の 2 つの書き込みを実行する。
    良性ペイロード (nodename 書き込み) で繰り返し検証済み。
    
    ### 発見のセッションチェーン
    1. kbm ページは GFP_HIGHUSER → HIGHMEM であり、physmap からは不可視
       (mali_kbase_mem_pool.c:164!) — zonelist スピルで修正: 260 × 2MB
       スプレー > highmem-free → 余剰が ZONE_NORMAL (physmap) に着地
    2. 最初の武器の試行はクラッシュ: W1 のターゲット N+4 は USER ページ —
       unlink は kworker コンテキスト (mm なし) で実行 → フォールト。修正は
       ring-0 シェルコードを physmap パターンの page+0x600 に焼き込むこと
       (arm32 非 LPAE でのダイレクトマップ RWX) — カーネル常駐コード、
       ret2usr 不要
    3. ctl_table オフセットバグ: proc_handler は entry+0x14 にあり、+0x18
       ではない (元のスキャンは正しかった; 私の define が間違っていた) —
       extra1 を書き込んでいた
    4. 過圧回帰を発見し巻き戻し: kid バジェット 20×100MB +
       末尾 10s が reclaim を壊した; 動作する設定は 2 kids/200MB +
       5s/+3200 末尾 (巻き戻し後、良性ヒット 1/1)
    5. **diag2: W2 → &pid_max グローバル (0xc1114d7c) → 読み取りが我々の値
       を返す (-1055861411 = 0xc110d55d as int32) — 書き込み + 読み戻し
       証明済み**
    
    ### 残る謎 (クローズまであと 1 実験)
    正しいハンドラアドレス (0xc1113f3c) での diag1: W1 が発火 (nodename
    が変化)、W2 は実行されたはず (次の命令) — それでも pid_max の読み取り
    はクリーンな値を返す → 我々が書き込むハンドラフィールドは、inode が
    ディスパッチするものではない。diag3 (キュー済み; ヒットブートが必要):
    W2 → entry->data フィールド (0xc1113f2c) を nodename に向ける — もし
    読み取りが nodename バイトを int として示せば、我々の entry は生きて
    おり、ハンドラオフセットだけがどういうわけか間違っている; 影響が
    なければ、inode はシャドウテーブルコピーを使っており、我々は生きた
    ものを探し求める。
    
    ### ヒット率の現実
    ブートごとのコイントス (~25-40%)、クラスタ化; 安全ミス/クラッシュ
    ブートが数回連続するのは普通。およそ 3-4 ブートに 1 回がヒット。
    動作する設定を正確に保つこと (2 kids、5s 末尾、260 リージョン kbm、
    G=0xc154b2a4)。
    
    ### セッション 9 TODO
    1. ヒットブートで diag3 を完了する ("W1 FIRED" までロールする)
    2. entry が生きている場合: ハンドラオフセットを経験的に再確認する
       (proc_dostring のアドレスをハンドラとして書き込む... N は有用な
       値と等しくなければならない — unlink を使って代わりに entry->data
       を書き込み、ピボットする: 例えば、data=selinux_enforcing 隣接...)
    3. シャドウテーブルの場合: 生きたものを特定する — kallsyms には
       データシンボルがない; 候補: /proc/sys の挙動をスキャンする、または
       .data 内のヘッダーリストパターン経由で 2 番目の ctl_table リージョン
       を見つける (handler=proc_dointvec_minmax と maxlen=4 を持つ
       0x20 ストライドのエントリ — すべてを列挙し、それぞれを diag 書き込み
       する)
    4. ディスパッチを完全に回避する代替ターゲットクラス: シェルから到達
       可能なパスから呼ばれる .data 関数ポインタ (監査が必要)
    5. 書き込みプリミティブ自体は完了 — 信頼できるカーネルアドレス
       ターゲットが今や root に十分
    
    ## セッション 9 — nf-WEAPON: reclaim+unlink+G-hit が武器内で証明済み; 残るはフックウォークのみ
    
    ### 新しいトリガー設計 (sysctl ハンドラパスを完全に置き換える)
    ユーザーのアイデアをカーネルメモリに翻訳: SUID ファイルなし (システム
    は dm-verity RO; プリミティブはカーネル RAM に書き込む)。代わりに:
    **偽の netfilter フック**。このカーネルは新しい nf_hook_entries API の
    Android-common バックポートを持つが、リンクリストとして実装されている
    (nf_hook_slow + ヘルパー 0xc09897d4 の逆アセンブルで検証済み):
    - `__ip_local_out(net, sk, skb)` は entries CELL を
      **[net+0x58c]** からロードし、state+0x1c に格納し、nf_hook_slow を
      呼び出す
    - ウォーク: `entry = *cell`; while(entry){ if (state->[4] <= entry->[0x20])
      call entry->[0xc](entry->[0x14], skb, state); entry = entry->[0]; }
      — つまり **fn@entry+0x0c, priv@entry+0x14, priority@entry+0x20,
      next@entry+0x00**; state+4 = INT_MIN 閾値 (常に通過)
    - init_net = **0xc1104548** (CONFIG_NET_NS=n → sock_net() が定数を
      インライン化; 6678 の movw/movt 参照、ヒストグラムチャンピオン;
      nf_hook_slow 自身のリテラルでクロス確認済み)。ターゲット:
      **[init_net+0x58c] = 0xc1104ad4**
    - LOCAL_OUT フックは送信者のプロセスコンテキストで実行される →
      我々の hookfn の commit_creds(prepare_kernel_cred(0)) がパケットを
      送信したプロセスを root 化する。トリガー = sendto(127.0.0.1:9) UDP。
    
    ### nf モードレイアウト (poc/stage3.c, モード `nf 200`)
    - kbm パターンページ (ページ相対、単一の真実の源 — 古い武器には
      今修正された 3 つのバグがあった: proc_handler@+0x14 であり +0x18
      ではない; W1 ターゲットはカーネルメモリでなければならない (kworker
      コンテキスト、mm なし); 焼き込まれたコードは page+0x600 にあり
      entry G+0x600=page+0x8a4 と不一致):
      - +0x2ac/+0x2bc/+0x2c0/+0x2dc/+0x3a8: 偽の phy-alloc チェーン (変更なし)
      - +0x600: nf_code hookfn (マーカーストア + prepare_kernel_cred +
        commit_creds + return NF_ACCEPT(1))
      - +0x700: 偽の entry {next=0, fn=PM_PAGE+0x600, priv=0, prio=0x100}
      - +0x740: cell → PM_PAGE+0x700
    - ペイロード: N = PM_PAGE+0x740 (0xc154b740), P = 0xc1104ad4
      → W1: *(cell+4)=P (我々のページに着地), W2: *(init_net+0x58c)=cell
    
    ### 自己診断インストルメンテーション (kbm_scan_for)
    kbm の CPU マッピングは保持される; free の後、スプレーしたすべての
    ページを既知のワードでスキャンする:
    - page+0x744 で scan(HOOKS_PTR_ADDR) → reclaim + unlink を証明し、
      G の推測を裏付ける物理ページを明らかにする
    - page+0x7f0 で scan(0x600d600d) → hookfn が実行されたことを証明する
      (nf_code はこのマーカーを 2 番目のアクションとして書き込む)
    
    ### 重要な実行 (2026-09-11, セッション 9 後半)```
    [+] W1 CONFIRMED: region 135 page+0x185000 <- 0xc1104ad4 (reclaim + G hit!)
    [+] nf trigger done, uid=2000 euid=2000
    

**ライブブートで完全な武器チェーンが発火** : イベントがスロットを回収し、偽物が実行され、unlink が実行され、G-guess ページ (0xc154b000) は本当に我々のものだった (リージョン 135 ページ 389)。W2 = *(0xc1104ad4)=cell は隣接する命令である — それは実行されたはずだ。しかし UDP sendto は我々を root 化しなかった → 失敗はフックパス内部にある: walk セマンティクス、[state+0x1c] の配管、優先度比較、またはエントリフィールドのいずれか。 (hookfn が実行されたか否かを判別するマーカー実験が追加された; セッション終了前のクラッシュブートのみ — クリーンなデータはまだない。)

### ヒット率 / ブート状態の知見 (苦労して得たもの)

  * 動作する設定 (触らないこと): 2 kids × 100MB 段階的プレッシャー、 末尾 100×50ms/+3200 renames、260×2MB kbm スプレー、G=0xc154b2a4、 事前ドレイン ~5000 renames
  * 過剰プレッシャー (20 kids / 10s 末尾) は回収を壊す — 元に戻した
  * ブートの安定が重要: boot_completed 直後に起動したランは システムの起動時アロケーションと競合する → コールドストリーク; 実行前にブート後 60-90 秒待って安定させる
  * 「W1 が発火しなかった」(nodename チェック) は nf ペイロードにとって 無意味 — W1 は我々のページに書き込む; 代わりに kbm_scan_for を使え
  * free 時クラッシュのブート ≈ ガベージスロットまたは G-miss 変換; 良性コントロール (`pmap 200`) が環境の健全性チェック (ウォーム時は 4/4 ヒット; コールド時はクラッシュミス)
  * /data/local/tmp/.w* ディレクトリはラン開始時にクリーンアップされる (蓄積されたディレクトリは回収を劣化させる)



### セッション10 TODO (決定木、順番通り)

  1. 安定遅延させたブートで `nf 200` を実行し、W1-CONFIRMED 行が 現れるまで待ち、次に MARKER 行を読む: a. マーカーが存在、uid!=0 → シェルコードの creds が失敗 (prepare_kernel_cred/commit_creds のアドレス; blx エンコーディングを確認) b. マーカーが不在 → walk が我々を呼んでいない: マーカーだけを書き込んで 1 を返す hookfn (creds なし) で検証する — それでも不在なら: 
     * トリガーの直前に CPU マッピング経由で実際のエントリバイトをダンプする (それらは我々が読むものだ!)
     * [init_net+0x58c] がそもそも参照されているかを確認する: 代わりに書き込みを使って観測可能な何かを破壊する (例: *cell = fn が kfree のようなカーネル関数であるエントリを持つセルを指す → トリガーで即クラッシュ = フィールドは参照されている)
     * 0x58c オフセットを再検証する: おそらく hooks_ipv4[NF_INET_LOCAL_OUT] は別のインデックスにある (NF_INET_POST_ROUTING=4?)
  2. walk が我々を呼ぶなら: creds を修正 → root → そしてユーザーの計画: setenforce 0; cp /system/bin/sh /data/local/tmp/su; chown root; chmod 6755; `ls -la` で確認; マーカーファイルを残す
  3. 永続化 (root 後): /dev/block/by-name/boot 経由のブートイメージパッチ 
     * dm-verity 無効化、または Magisk スタイル; /data 単体の su は再起動後に shell ドメイン内の uid0 になる (SELinux が再び enforcing) — setenforce 0 はランタイムのみ
  4. クリーンアップの注意: 一時停止した st3 プロセスは kctx 状態が破損している — 再起動でのみ kill 可能; nf ハイジャックは全トラフィックの LOCAL_OUT フックを壊す — root 後に再起動して復元する



### 今夜のアセット追加

  * `poc/stage3.c` モード: pin/root/drain{,2,3,4,5}/iso — 完全な武器 + オラクル + 分離ハーネス、O_SYNC クラッシュポイントフォレンジック
  * ユーザーランド偽装インフラ (ufake_prep) — 保持するが、コンテキストインライン デリファレンスパスが見つかった場合にのみ使用可能
  * tools/: kdis/scan_s/resolve/dumpb/findsysctl オフライン vmlinux 解析



## セッション10 — ROOT 達成 (2026-09-11)

### nf-weapon をブロックしていた3つのバグ、すべて修正済み

  1. **間違った`init_net`**: `0xc1104548` は `__stack_chk_guard` である (movw/movt ヒストグラムはスタックカナリアのロードで汚染されていた — 2025 は nf 計画全体を これの上に構築した)。本当の `init_net = 0xc1185040` (確認済み: `ip_send_skb(net,...)` が このリテラルで呼ばれる; ~994 の参照はすべて net スタック内)。IPv4 LOCAL_OUT セル = `init_net+0x58c = 0xc11855cc`。
  2. **二重デリファレンスバグ** : `nf_iterate` は `[init_net+0x58c]` を **`nf_hook_ops` ポインタそのものとして**扱う — その値から `fn@+0xc, priv@+0x14, prio@+0x20` を直接読む。セッション9の偽エントリは `PM_PAGE+0x700` にあり、セルが それを _指して_ いた (セルの未使用の `next`/`fn` フィールド →  → クラッシュ)。 偽エントリは (0xc154b740) に 存在しなければならない。これを修正すると、フック呼び出しが証明された ( モード = SAFE_FN が 200 の sendto すべてをクリーンに処理)。



### SELinux の壁と2パケットバイパス

`commit_creds(prepare_kernel_cred(0))` / `override_creds(&init_cred)` は uid 0 を与えるが、`kernel` SELinux SID に着地し、この Fire OS ポリシーは `/data` や `/sys/fs/selinux/enforce` への書き込みを**許可しない** (確認済み: EACCES)。 本物の `init` SID (7) も拒否される (偽の `struct cred` テスト)。`enforcing_setup` は `__init` (解放済み → クラッシュ)。`mark_reclaim` の `atomic_sub` は nents=1 を必要とし、 それが `shrink_cpu_mapping` の早期終了を壊す。

**勝利:** エクスプロイトプロセスは kbm CPU マッピングを保持するので、偽の nf エントリはパケット間でその場で書き換えられる:

  * `selroot` モード: entry = `{fn=0xc01d503c (mov r3,#0;str r3,[r0];bx lr), priv=0xc1213ea8 (selinux_state.enforcing)}`。
  * パケット1: `*(enforcing)=0` → **SELinux Permissive** 。
  * `kbm_cpu[reg]+off` 経由でエントリを `{fn=commit_creds, priv=&init_cred}` に書き換える。
  * パケット2: 送信者のタスクで `commit_creds(&init_cred)` → **uid 0** で permissive SELinux → 使用可能な root、すべて1回の回収で、チェーン不要。



### デバイスで検証済み (2026-09-11)```

[+] W1 CONFIRMED: region 67 page+0xad000 <\- 0xc11855cc (reclaim + G hit!) [*] sendto 0 -> -1 errno=1 uid=0 euid=0 [+] nf trigger done, uid=0 euid=0 <<< HOOK RAN - commit_creds OK [+] ROOT: uid=0 euid=0 [+] setenforce write=1 [+] su copied bytes=236220

root@kitploit:~
    
    
    - `getenforce` → **Permissive**、一時停止した st3 は `Uid: 0 0 0 0`、
      `CapEff: 3fffffffff`。
    - `/data` は **nosuid** でマウントされているため、setuid `su` は機能しない。小さな
      `rootshell`（UDP 送信 → 自身に `commit_creds` → `execl sh`）で
      対話型 root シェルが得られる: `uid=0(root) context=u:r:kernel:s0`。
    - root は `/dev/block/by-name/*` を読み書きできる（`dd if=boot ...` OK）。
    
    ### Stage-3 コードの状態 (`poc/stage3.c`)
    - モード: `nf <mb> [probe|uprobe|oc|chain|fc <sid>|notrig|selroot]`
    - `selroot` が動作する武器。主要な静的値: `init_net=0xc1185040`、
      `HOOKS_PTR_ADDR=0xc11855cc`、`ENFORCING_ADDR=0xc1213ea8`、
      `ZERO_GADGET=0xc01d503c`、`commit_creds=0xc014993c`、
      `init_cred=0xc1114f54`。
    - エクスプロイト後は直接 syscall を使用（`system()` は使わない）。kctx を生かしたままにする
      （`pause()`）ことで、teardown クラッシュを回避する。
    
    ### 残り (Stage 4/5)
    - 再起動をまたぐ永続化（verity / boot image / recovery）。セルハイジャック + permissive SELinux は
      実行時のみ有効であり、エクスプロイトの再実行には約 1/3 の reclaim コインフリップが必要なため。
    - `su` には非 nosuid のホーム（`/system`）か、再トリガーするランチャーが必要になる。
    
    ## SESSION 11 — 永続化の偵察 (Track B + Track A) と RE の引き継ぎ
    
    目標は永続的な root だった。2 つのトラックが検討された:
    - **Track B**: verified boot（dm-verity / SELinux）を無効化し、`/system` にパッチを当てられるようにする。
    - **Track A**: 起動時にエクスプロイトを再実行する。
    
    どちらも同じブロッカーに帰着する: **LK にデバイスを `eng`/`unlocked` として扱わせること。**
    
    ### Verified-boot の事実（正確なビルド）
    - ブートローダーはロック、AVB `green`、`ro.boot.unlocked_kernel=false`、`ro.boot.secure_cpu=1`、
      `rpmb_state=1`。Bootrom はパッチ済み（BROM なし）。preloader は CMD ショート経由のみ。
    - `/system` は **lk が構築した kernel cmdline から Android dm-verity によって**マウントされる:
      `root=/dev/dm-0 dm="system none ro,0 1 android-verity PARTUUID=b6404ef3-… "`、
      `veritykeyid=id:f3530e18f64d11fc25eb2dd762979f078de990bf`、`androidboot.veritymode=eio`、
      `skip_initramfs`（system-as-root）。`dm-0` = `system` という名前の verity デバイス、`dm-1` = `/vendor`。
    - LK: Amazon **UFBL**、`ro.boot.lk_version=0x0006`、ビルド `0db73c9-20231025_030009`、
      preloader `pl_version=0x000a`、ビルド `80c6fcb-20230523_065640`。`/dev/block/by-name/lk` = mmcblk0p5 (1 MB)。
    - 完全な GPT（16 パーティション、`persist`/`seccfg`/`nvram`/`protect`/`para` なし）:
      `proinfo` p0、`PMT` p1、`kb` p2、`dkb` p3、`lk` p4、`tee1` p5、`tee2` p6、`metadata` p7、
      `MISC` p8、`reserved` p9、`boot` p10、`recovery` p11、`system` p12、`vendor` p13、
      `cache` p14、`userdata` p15。eMMC boot0 (1 MB) = preloader（`EMMC_BOOT` マジック）、
      boot1 (4 MB) = IDME ストア。
    
    ### LK (UFBL) の静的解析結果
    `lk.img` ヘッダ: `88 16 88 58 | 00052974 | "LK"`、0x200 に ARM ベクタテーブル、残りは Thumb-2、
    位置非依存/再配置（リテラルプールは `ldr+add pc` を使うため、素朴なベース相対逆アセンブルは失敗する）。
    関連する文字列（ファイルオフセット）: `amzn_image_verify`、`amzn_verify_unlock`、`amzn_verify_code_internal`、
    `unlock_code`、`unlock code error`、`unlock failed`、`$Common Kernel Signing Engineering CA0`、
    `seccfg`、`para`、`ENV_v1`、`LK_ENV`、`Kfos_flags`/`Kdev_flags`/`Kusr_flags`/`Kunlock_code`/`Kunlock_version`、
    `FOS_FLAGS_{NONE,ADB_ON,ADB_ROOT,CONSOLE_ON,RAMDUMP_ON,VERBOSITY_ON,ADB_AUTH_DISABLE,FORCE_DM_VERITY,DM_VERITY_OFF,BOOT_DEXOPT}`、
    `[DM-VERITY] verify for system(root) is enabled`、`[DM-VERITY] verify off by fos_flags`、
    `[DM-VERITY] disabled by fos_flags on eng devices or unlocked device`、
    `[SELINUX] set to permissive mode by dev_flags`、`androidboot.prod=1|0`、`androidboot.unlocked_kernel=%s`。
    **結論: LK は `fos_flags`/`dev_flags` のセキュリティ効果を eng/unlocked でゲートしている。**
    
    ### IDME ストア (eMMC **boot1**) — 書き込み可能、永続的、LK と Android が読み取る
    - 0x0 にマジック `beefdeed` + `"2.1\0"` + count(0x19=25)、アイテムは 0x10 から。
    - アイテム形式: `char name[16]; u32 size; u32 type(=1); u32 magic(=0x124); u8 data[size] (pad4)`。
    - アイテムオフセット（初期状態）: `board_id@0x10 serial@0x3c mac_addr@0x68 mac_sec@0x94 bt_mac_addr@0xd0
      bt_mfg@0xfc product_name@0x198 productid@0x1d4 productid2@0x210 region@0x24c bootmode@0x26c
      postmode@0x28c bootcount@0x2ac manufacturing@0x2d0 unlock_code@0x4ec sensorcal@0x908 alscal@0x9c4
      KB@0xa00 DKB@0x1e1c device_type_id@0x2238 dev_flags@0x2274 fos_flags@0x2298 usr_flags@0x22bc
      wifi_mfg@0x22e0 unlock_version@0x26fc`。値は ASCII（フラグは**16 進文字列**）。
    - 実行時の読み取り: `/proc/idme/<name>`（読み取り専用）。前回起動時の値がキャッシュされ、boot1 への書き込みは
      次回起動時に有効になる。書き込みパスには `/sys/block/mmcblk0boot1/force_ro` のクリアが必要（root）。
    - **LK が boot1 を読み取ることを確認済み**: `serial` を変更すると次回起動時に `ro.boot.serialno` が変化した。
      しかし LK は **serial を 16 バイトに切り詰め**、`fos_flags=0x80`、`dev_flags=0xff`、
      オール 1 などを無視した — verity/selinux/`prod` は変化なし。よって serial 経由の cmdline インジェクションは失敗する。
    
    ### IDME フラグの Android 側コンシューマ
    - `/init.fosflags.sh`（サービス `fosflags`、`u:r:fosflags:s0`）: `FOS_FLAGS_ADB_ON=0x1`、
      `CONSOLE_ON=0x4`、`RAMDUMP_ON=0x8`、`VERBOSITY_ON=0x10`、`ADB_AUTH_DISABLE=0x20`、
      `BOOT_DEXOPT=0x100`。確認済み: フラグを設定すると有効になる（`sys.usb=adb`、`noadbauth=1`）。
    - **adbd**（ストリップされていない ARM ET_EXEC、`.text` VA 0x8160 / ファイル 0x160、fileoff = VA-0x8000）:
      - `amzn_is_root_allowed` @0x2d5b8 = `amzn_is_dev_unlocked() && (fos_flags & 0x2)`
      - `amzn_is_adb_auth_disable_allowed` @0x2d5e8 = `fos_flags & 0x20`（ゲートなし）
      - `amzn_is_dev_unlocked` @0x2d5fc = `/proc/cmdline` に `androidboot.prod=0` **または**
        `androidboot.unlocked_kernel=true` が含まれる
      - `fos_read_debug_flags` @0x2d724 は `/proc/idme/<name>` を読み取り、**16 進**をパースする
      - `restart_root_service` @0xcb74 / `restart_unroot_service` @0xcc64
      - 文字列: `amzn_fos: ADB: Auto-root succeeded`、`… eng_device=%d`、`… unlocked_kernel=%d`、
        `adbd cannot run as root in production builds`、`ro.debuggable`
      - `adb root` → "cannot run as root in production builds"（`ro.debuggable=0`）— つまり auto-root ゲートが
        満たされていても、AOSP の prod チェックがコマンドパスをゲートする。
    
    ### Session-10 の root が永続化しない理由
    - SELinux permissive + セルハイジャック + root は実行時のみ。
    - `/data/metrics` は **vpartition**: `/system/bin/vpartition.sh` が毎回の起動時に `/data/vp/metrics.img`
      （ext4、non-nosuid/noexec）を `/data/metrics` にマウントする。そこに書かれた `su` は**再起動を
      生き残らない**。（setuid `su` が uid 0 を与えたが**ケイパビリティがゼロ**だった理由でもある。）
    
    ### Track A（起動時の再エクスプロイト）— ブロック
    - 制御可能なコードを実行する init `.rc` トリガーは存在しない（インポートはすべて検証済み、`persist.*` トリガーは
      固定サービスの `start` のみ、スクリプトは `/system`/`/vendor` 内）。
    - root サービスは `/data` の設定を読むが、そこから exec することは決してない（`perfmonitord`、`amazonfiled`、
      `vpartition.sh`、`kisd`、…）。
    - 唯一の起動実行者 = **アプリ**だが、エクスプロイトの一時停止フットプリントは **VmRSS 534 MB**
      （`kbm` スプレー）→ lmkd が kill する。さらに reclaim を逃すとパニック（`PANIC_ON_OOPS`）→ bootloop。
    - **adbd auto-root** は存在するが、LK が構築した cmdline（`prod=0`/`unlocked_kernel=true`）でゲートされている。
    
    ### 結論 / 次のターゲット（選択: Track B RE）
    すべては LK に `eng`/`unlocked` を報告させることにかかっている。到達可能な範囲:
    `androidboot.prod=1|0` と `androidboot.unlocked_kernel=false` は LK によって設定される。LK をリバースして以下を特定する:
    1. `fos_flags`/`dev_flags`/`usr_flags`（`K*` アイテム）を読み取る場所と正確なゲート;
    2. `prod`/`unlocked` の判定（IDME アイテム? buildvariant? `amzn_verify_unlock` の結果?）;
    3. `amzn_verify_unlock`（libtomcrypt RSA 検証）のバイパスまたは弱い unlock_code/version パス;
    4. `seccfg`/`para`/`ENV_v1`(LK_ENV) ストレージ（ダンプされたどのパーティションにもない — tee 保護の可能性）;
    5. preloader（`boot0`、`EMMC_BOOT`）のバグ。
    これらのいずれかで eng/unlocked を（boot1 または生パーティション書き込み経由で永続的に）設定できれば、
    `FOS_FLAGS_DM_VERITY_OFF` が system(root) の verity を無効化し、`/system` に永続的にパッチを当てられる。
    
    ### 成果物（このセッションから）
    `/tmp/opencode/mustang-dumps/`（ホスト再起動で消去される可能性あり）: `lk.img`、`boot1.img`（初期状態）、
    `boot.img`、`MISC.img`、`metadata*.img`、`pmt.img`、`mbr.img`、`kb.img`、`dkb.img`、`reserved.img`、
    `cache.img`、`boot0.img`、`boot1.img`、`adbd.bin`、`perfmonitord.bin`、`amazonfiled.bin`。
    ヘルパー: `tools/findinitnet.py`、`findgadget*.py`、`findstores.py`、`adbd_sym.py`（/tmp 内）;
    リポジトリには `run.sh`、`poc/stage3.c`（`selroot`）、`poc/su.c`、`rootcmd.sh` がある。
    
    ### 便利なコマンド```
    # IDME read
    /data/metrics/su sh -p -c 'for f in fos_flags dev_flags usr_flags serial region device_type_id unlock_version; do echo -n "$f="; cat /proc/idme/$f; echo; done'
    # write boot1 (root; su lives only until reboot -> re-run run.sh first)
    /data/metrics/su sh -p -c 'echo 0 > /sys/block/mmcblk0boot1/force_ro; dd if=/data/local/tmp/boot1.img of=/dev/block/mmcblk0boot1 bs=4096 count=4; sync; echo 1 > /sys/block/mmcblk0boot1/force_ro'
    # dump a partition to host
    adb exec-out '/data/metrics/su dd if=/dev/block/by-name/lk bs=4096 2>/dev/null' > lk.img
    

## セッション12 — LK RE: eng/unlockedゲートは実在し、未署名フラグストアは存在しない

目的: LKにデバイスを`eng`/`unlocked`として扱わせる、またはpreloader/LKのバグを見つけることで、verity/SELinuxを永続的に無効化できるようにする。結果: **関連するLKコードパスをエンドツーエンドでリバースしたが、このフリップは利用可能なストアからは到達できない。** デバイスは文鎮化せず、唯一のboot1実験は元の状態に戻された。

### LKはThumb-2 PICであり、ベース0xFF400000に再配置される

`lk.img`は小さなARMスタブ(ファイル0x200)で始まる。0x224の再配置コードは`0x200`からリテラルで指定された宛先へコピーし、リテラルで指定されたエントリへ分岐する:

したがって、オフセット0x200以降では**実行時アドレス = 0xFF400000 + ファイルオフセット** となる。スタブ以降はすべてThumb-2であり、位置独立である。文字列は`ldr rT,[pc,#imm]`(T1オフセット = imm8*4、`ldr.w`オフセット = imm12)の後に`add rT, pc`を続けて構築され、ターゲットは`(add+4) + *pool`となる。ARMスタブとリテラルプールを乗り越える堅牢なスキャナを`tools/lk_xref.py`として追加した(16ビット形式と32ビット形式を処理し、2バイトごとにスキャンする)。以下のオフセットはすべて**ファイルオフセット** であり、実行時アドレスには0xFF400000を加算する。

### デコードされた制御フロー(オフセット -> 意味)

### アンロックコードはAmazon-RSA署名済みであり、偽造不可能

`0x20b4`は`unlock_code` IDME項目(0x400バイト、このユニットでは**すべてゼロ**)を読み取り、`amzn_verify_unlock` (0x222c -> 0x20f0)を実行する。この関数はlibtomcrypt(数十の`/features/libtomcrypt/src/pk/asn1/der/...`パスとRSA検証)を駆動し、イメージには証明書素材が埋め込まれている: 0x317d9+に`Sunnyvale` / `Amazon Lab126` / `"$Common Kernel Signing Engineering CA0"`、さらに診断メッセージ `Image FAILED AUTHENTICATION on PRODUCTION device` (0x3166e)、 `Authentication failed on engineering device with production certificate` (0x316a0)、 `Image FAILED AUTHENTICATION on ENGINEERING device` (0x31703)、 `Image AUTHENTICATED with PRODUCTION certificate` (0x31736)。 空コード/長さ/バージョンのショートカットは存在しない: `verify(zeros) != 0`、したがってとなる(で確認済み)。またはをフリップするには、有効なAmazon署名済み(秘密鍵は入手不可)か、検証器におけるコード実行バグのいずれかが必要である。0x20b4/0x222c/0x20f0には静的に悪用可能なもの(境界/サイズ)は見つからなかった。=>

### verity/SELinuxフラグは存在しないストアからは来ない

セキュリティフラグは`0x57c`のゲッターを通じて読み取られる。実証テスト:```

# boot1 IDME item fos_flags data (offset 0x22B4, 8 bytes) set to "00000080"

dd if=/dev/block/mmcblk0boot1 ... ; reboot /proc/idme/fos_flags -> 00000080 (persisted, Android sees it) ro.boot.veritymode -> eio (unchanged!) root=/dev/dm-0 dm="system none ro,0 1 android-verity PARTUUID=..." (unchanged) androidboot.prod=1 / secure_cpu=1 / buildvariant=user (unchanged)

root@kitploit:~
    
    
    `fos_flags=0x80` は `FOS_FLAGS_DM_VERITY_OFF` です。デコードされたゲートは、**もし** getter がそれを返していたなら verity をオフにしていたでしょう。しかし、返しませんでした。このゲートはデッドコードではなくライブです。そのワンタイムキャッシュセンチネルはイメージ内で `-1` (`*(u32*)0x50c74 == 0xffffffff`) であるため、関数は実際に `check_flag("fos_flags",0x80)` パスを実行し、0 を得ました。したがって、getter は（少なくとも verity 保護時点では）boot1 IDME アイテムを**読み取っていません**。
    
    もう一つの候補ストアは **LK env** で、文字通り `"para"` という名前のパーティション（loader 0x12fd4、マジック `ENV_v1`、チェックサム @0x3ffc）からロードされます。LK 自身のパーティションテーブル (0x4fcc0..0x50340) には preloader/proinfo/nvram/protect1/protect2/persist/seccfg/secro/**para**/logo/custom/expdb/tee1/tee2/metadata/system/cache/userdata がリストされていますが、タブレットの実際の GPT には**わずか 16 エントリ**しかなく、すべてタイプ `af3dc60f838472478e793d69d8477de4` です：```
    #0 proinfo 0x400   #1 PMT 0x1c00    #2 kb 0x4000     #3 dkb 0x4800
    #4 lk 0x5000       #5 tee1 0x5800   #6 tee2 0x8000   #7 metadata 0xa800
    #8 MISC 0x1e400   #9 reserved 0x1e800  #10 boot 0x22800  #11 recovery 0x2a800
    #12 system 0x34800 #13 vendor 0x644000 #14 cache 0x6b4800 #15 userdata 0x7ae800
    

この製品には **`para`、`seccfg`、`nvram`、`protect`、`persist` パーティションは存在しない**（また `PMT`/`pmt.img` のダンプはすべてゼロである）。したがって LK 環境変数は空であり、`Kfos_flags`/`Kdev_flags` キーは決して存在せず、すべての `fos_flags`/`dev_flags` チェックは 0 に解決される — IDME 項目の内容とは無関係に。boot1 の IDME 項目は Android（`/init.fosflags.sh`、`adbd`、`/proc/idme/*`）によって消費されるが、LK のセキュリティゲートによっては消費されない。

### 結論 — なぜ永続的な eng/unlock がブロックされるのか

  1. `unlocked_kernel` には Amazon 署名された `unlock_code`（RSA/libtomcrypt、組み込み CA）が必要である。オフラインで偽造することは不可能であり、検証器のバグも見つかっていない。**ハードブロック。**
  2. `DM_VERITY_OFF` / `selinux=permissive` フラグは LK 環境変数（`para`/`ENV_v1`）から消費されるが、この GPT にはそれが存在しない。IDME の `fos_flags` は経験的に LK に無視される（0x80 を永続化しても、verity は `eio` のままだった）。パーティションテーブルを変更しない限り **ハードブロック** 。
  3. 仮に `fos_flags=0x80` が成功したとしても、`androidboot.veritymode=disabled` と非 `dm-0` の `root=` が設定されるだけで、unlock はされず、SELinux が permissive になるには同じく存在しない環境変数からの `dev_flags` が依然として必要である。
  4. したがってトラック A（起動時の再エクスプロイト）は SESSION 11 とまったく同じようにブロックされたままである。その唯一の unlock 経路は同じ LK ゲートである。



### 残された道（将来的、より高リスク、未試行）

  * **`para`/`ENV_v1` ストアの合成**: `userdata` の後の空き領域（userdata は LBA 0x3a3dfde で終了、ディスク = 30535680 セクター）に `para` という名前の GPT エントリを追加し（プライマリ + バックアップ GPT の両方を更新する必要がある）、次に `fos_flags=0x80` と `dev_flags=0x40` を持つ env を作成する（チェックサムは +0x3ffc = 0x3ffc にわたるバイト和）。これが verity-off への唯一残された経路である。リスク: プライマリ/バックアップ GPT を破損すると文鎮化する可能性がある。また、verity ゲートが実際に `para` を読むことは**証明されていない** （boot1 IDME ではないことだけが確認されている）。
  * **Preloader（`boot0`/`EMMC_BOOT`）のバグ**: 今セッションではリバースエンジニアリングされていない。クリーンなコピーとリカバリ経路が存在するまで boot0 への書き込みは禁止である。
  * **検証器の研究** : エンジニアリング証明書の経路（0x316a0/0x31703）は、「エンジニアリング」として受け入れられるデバイス ID とエンジニアリングキーで署名されたコードがあって初めて到達可能であり、秘密鍵は入手できない。



### 成果物 / 再現性

  * 追加されたツール: `tools/lk_xref.py` — ベース非依存の LK 文字列クロスリファレンスリゾルバ。
  * 使用したダンプ: `/tmp/opencode/mustang-dumps/lk.img`、`boot1.img`（クリーン）、`boot0.img`、`mbr.img`（GPT）、`pmt.img`（すべてゼロ）。
  * boot1 実験イメージ（fos_flags=0x80）は `/tmp/opencode/s12/boot1_f80.img` に保存。**デバイスはクリーンな boot1 に復元済み** （`/proc/idme/fos_flags` -> `0` を検証済み）。



### 便利なコマンド（root 必須、`./run.sh` で再アーム）```

# re-arm runtime root (~1/3 per boot)

./run.sh --no-build

# confirm LK's decisions without a UART

/data/metrics/su /system/bin/sh -p -c 'cat /proc/cmdline'

# watch: root=/dev/dm-0 dm="system ... android-verity ..." (verity on)

# androidboot.veritymode=eio ; androidboot.selinux=enforce ; prod=1

# IDME read (Android copy; NOT what LK's gates use)

for f in fos_flags dev_flags usr_flags unlock_version serial; do cat /proc/idme/$f; echo; done

root@kitploit:~
    
    
    ## セッション 13 — プリローダーは結局到達可能（`1949:20ff` = MTK プリローダー、HID トランスポート）
    
    電源オフの状態で USB に接続すると、タブレットは **`1949:20ff`**（`Lab126`）として列挙される — Android でも `0e8d:0003` ブートROM でも*ない*。ディスクリプタ:```
    bInterfaceClass 3 (HID), iConfiguration "HID", iInterface "HID Interface"
    HID report descriptor = 05 01 09 00 a1 01 c0   (empty collection!)
    EP 0x81 IN  interrupt  4 bytes, bInterval 4
    EP 0x01 OUT interrupt  4 bytes, bInterval 4
    iSerial = GCC0X90805310009 (the IDME serial)
    

**識別。** `0x20FF` は mtkclient の `config/usb_ids.py` において **「MTK Preloader」** として記載されています（MediaTek VID `0x0e8d` の下: `0xe8d:{0x0003 Brom, 0x2000/0x2001/0x20ff/0x3000 Preloader}`）。Amazon は preloader PID を維持したまま VID を `0x1949` に変更し、ダミーのレポートディスクリプタを伴う HID エンドポイントペアとして提示しています。したがって、これは **MediaTek preloader / USBDL モード** であり、LK の _下位_ のステージです — ここでは CMD ショートではなく、電源オフ＋接続によって到達します。

ディスクリプタ文字列「HID」/「HID Interface」は `lk.img`、`boot0.img`、`boot.img`、その他のダンプには存在しません。つまり、このモードはまだダンプしていないコンポーネント（bootrom/TEE）によって生成されるか、実行時に組み立てられるかのいずれかです。

**これが重要な理由。** `aftv2-tools` が使用する Amazon preloader は、この正確なバイトストリーム上で、組み込みの **Download-Agent 不要** コマンドを公開しています:``` handshake : host A0 0A 50 05 -> dev 5F F5 AF FA 0xD1 read32 (addr, n_words) : echo cmd/addr/n, 00 00, n _u32, 00 00 0xD4 write32(addr, words[]) : echo cmd/addr/n, 00 00, n_ u32, 00 00

root@kitploit:~
    
    
    `aftv2-tools/read_mmc.py` は `read32`/`write32` を使用して MSDC コントローラ（MT8173 ではベース `0x11230000`、MT8163 では要確認）を操作し、DA を介さずに **raw eMMC ブロック**を読み書きするため、AVB/verity が介在しません。mustang の preloader が 0xD1/0xD4 を受け入れる場合、それは RSA アンロックコードや存在しない LK 環境変数に依存しない、永続的なアンロック（`boot` / `lk` のパッチ）への直接的な経路となります。
    
    ### 追加されたツール（root 権限が必要。まず USB ノードを chmod すること）```
    lsusb -d 1949:20ff                 # note Bus/Dev, e.g. Bus 001 Device 003
    sudo chmod 666 /dev/bus/usb/001/003
    # 1) does it answer the MTK handshake? (no DA, no flash access)
    nix-shell -p python3Packages.pyusb --run \
        'python3 tools/mtk_preloader_hid.py handshake'
    # 2) read-only arbitrary memory read
    nix-shell -p python3Packages.pyusb --run \
        'python3 tools/mtk_preloader_hid.py read32 0x00100000 4'
    

`tools/probe_preloader.py` は最小限のハンドシェイク専用プローブです； `tools/mtk_preloader_hid.py` は完全なトランスポートです（`handshake`/`read32`/ `write32`；`write32` はガードされており、eMMC レジスタマップが確認されるまで 使用すべきではありません）。

### ステータス / 次のステップ

  * **未確認** : mustang の preloader が実際に 0xD1/0xD4 を実装しているかどうか （ハンドシェイクプローブがこれを判定します）。実装していれば、aftv2 の eMMC 読み書き パスはおそらくそのまま移植できます。
  * 次に: MT8163 の MSDC ベース（カーネル DT または preloader）を見つけ、パーティションをダンプし （`read_mmc`）、preloader から `boot.img`/`lk` にパッチを当てて再起動します。
  * これは SESSION 12 のすべてよりも _低い_ ブートステージであるため、 `amzn_verify_unlock` や LK 環境ゲートには依存しません。
  * プロトコルと eMMC レイアウトが確認される前に、SP Flash Tool / mtkclient の書き込みを これに対して実行しないでください。