NkBe

你好，這裡是 NkBe 的新站

Tue, 06 Oct 2026 00:00:00 GMT

這個站原本只是一頁導航，現在換成 Astro + Firefly 主題，之後會把專案紀錄和技術筆記寫在這裡。

目前還在整理中，專案請先看專案頁。

一加 Ace 6T 免深度測試秒解 Bootloader、偽回鎖與永久 Root 實錄

Sun, 08 Nov 2026 00:00:00 GMT

近期一加收緊了新機型的官方 Bootloader 解鎖申請。這篇記錄在一加 Ace 6T（代號 macan，型號 PLR110，搭載高通 SM8845 / 驍龍 8 Gen 5，系統版本 PLR110_16.0.10.500(CN01)）上，利用內核漏洞臨時提權、替換引導分區注入 superfastboot 秒解 BL、達成綠標「偽回鎖」並部署 SukiSU 永久 Root 的完整實測流程。

文末同時附上我們二次魔改的 Android 16 專用 TWRP Recovery，以及針對「非官方深度測試真解鎖」環境下的使用規範與踩坑記錄。

💡 方案特性總結#

免深度測試秒解 BL：不走官方排隊審核，利用漏洞臨時提權寫入紫標 ABL 與 GBL efisp，透過 superfastboot 直接達成 unlocked: yes。
偽回鎖綠標狀態：系統底層回報 ro.boot.vbmeta.device_state=locked 與 ro.boot.verifiedbootstate=green，開機無 Orange State 解鎖黃字警告，能無痛通過依賴 BL 狀態的各類環境檢測。
一氣呵成永久 Root：在解鎖清數據的同一趟引導流程中刷入修補好的 init_boot，開機即完成 SukiSU 永久 Root。

🧩 整體原理：四個關鍵環節#

整個方案由四個環節組成：

環節	目標	核心操作
1. 臨時提權（越獄）	在未解鎖系統上取得 `root` 權限	利用 `CVE-2026-43499-S26` 漏洞載入臨時 KernelSU，授權給 `adb shell`
2. 預提取與修補	準備永久 Root 與原機防磚備份	提取原廠 `abl_a/b`、`efisp`、`recovery_a` 備份，並預先將 `init_boot` 交由 SukiSU 修補
3. 注入 `superfastboot`	替換引導程序與偽回鎖模組	寫入具備高通硬體簽名的工程 `abl.img` 與基於 EDK2/GBL 的 `efisp.img`
4. 攔截秒解與固化	秒解 BL、雙清與進系統	狂點「音量下」進 `superfastboot` 秒解 BL，刷入修補好的 `init_boot` 並進官方 Recovery 格式化資料

🔓 第一步：利用內核漏洞臨時提權（越獄）#

未解鎖狀態下無法從 Fastboot 刷入未簽名分區，因此第一步需在系統內臨時取得 Root：

ColorOS 16（16.0.10.500）：安裝 GhostLock_1.2.apk 與 KernelSU_v3.3.1.apk，匯入 offsets-6.12.38-... 符號偏移配置，利用 CVE-2026-43499-S26 內核漏洞取得臨時 Root 權限。
ColorOS 17（待測）：提權工具可改用 Shark-v2.0.apk。

提權後開啟 KernelSU，在超級用戶中將 Shell 勾選授權，確保 adb shell 具備 su 執行能力。

📦 第二步：提取備份與預先修補 `init_boot`#

解鎖 BL 會強制清空 userdata，因此必須先將永久 Root 鏡像修補好並拉回電腦：

1. 備份原機關鍵分區#

Terminal window

1
adb shell "su -c '
2
  dd if=/dev/block/by-name/abl_a of=/data/local/tmp/orig_abl_a.img &&
3
  dd if=/dev/block/by-name/abl_b of=/data/local/tmp/orig_abl_b.img &&
4
  dd if=/dev/block/by-name/efisp of=/data/local/tmp/orig_efisp.img &&
5
  dd if=/dev/block/by-name/recovery_a of=/data/local/tmp/stock_recovery_a.img &&
6
  dd if=/dev/block/by-name/init_boot_a of=/sdcard/Download/init_boot.img &&
7
  chmod 644 /data/local/tmp/*.img
8
'"
9

10
adb pull /data/local/tmp/orig_abl_a.img ./
11
adb pull /data/local/tmp/orig_efisp.img ./
12
adb pull /data/local/tmp/stock_recovery_a.img ./
13
adb pull /sdcard/Download/init_boot.img ./init_boot_stock.img

2. 修補 SukiSU 鏡像#

在手機上安裝 SukiSU_v4.3.0-r2.apk，修補 /sdcard/Download/init_boot.img，完成後拉回電腦：

Terminal window

1
adb pull /sdcard/Download/kernelsu_patched_*.img ./init_boot_sukisu_patched.img

🛠️ 第三步：刷入工程 `abl.img` 與 GBL `efisp.img`#

工程紫標 abl.img：帶有高通 OPLUS SM8845 Attestation 合法硬體簽名，可安全通過 Secure Boot，並支援引導 efisp 中的 GBL 模組。
GBL 引導模組 efisp.img：基於 EDK2 / GBL 編譯，開機攔截按鍵提供 superfastboot（序號 0000000000000000），並在引導系統時注入偽回鎖參數（device_state=locked / verifiedbootstate=green）。

Terminal window

1
adb push abl.img /data/local/tmp/abl.img
2
adb push efisp.img /data/local/tmp/efisp.img
3

4
adb shell "su -c '
5
  dd if=/data/local/tmp/abl.img of=/dev/block/by-name/abl_a &&
6
  dd if=/data/local/tmp/abl.img of=/dev/block/by-name/abl_b &&
7
  dd if=/data/local/tmp/efisp.img of=/dev/block/by-name/efisp &&
8
  sync
9
'"

⚠️ 第四步：關鍵避坑——按「音量下」秒解 BL#

其實開機時螢幕上就清清楚楚寫著這幾行字（根本不用刻意去逆向字串表）：

1
Press Volume Down key to enter Fastboot mode
2
Press Volume Up key to enter Normal mode
3
boot confirmation is blocked before unlocking

換句話說，引導模組的邏輯非常直白：

音量下（Volume Down）：進入 superfastboot。
音量上（Volume Up）：跳過並嘗試一般開機。但在未完成解鎖前按音量上會觸發防護直接掉入 900E！很多人習慣性按音量上進 Fastboot，結果一按就黑屏掉進 900E。

Tip

若誤入 900E，長按「電源 + 音量下」約 10～15 秒強制斷電重啟，重啟瞬間改為連續狂點「音量下」即可脫離 900E 進入 superfastboot。

操作步驟：#

電腦端先執行指令守候：
Terminal window
```
1
fastboot flashing unlock
```
手機執行重啟，黑屏瞬間連續狂點「音量下鍵」。
進入 superfastboot 後指令瞬間返回 OKAY，確認 unlocked: yes。

直接刷入預先修補好的 SukiSU 鏡像並進入官方 Recovery：

Terminal window

1
fastboot flash init_boot_a init_boot_sukisu_patched.img
2
fastboot flash init_boot_b init_boot_sukisu_patched.img
3
fastboot reboot recovery

官方 Recovery 內點選「格式化數據分區（Format Data）」，輸入驗證碼清除數據並重啟。
進系統後安裝 SukiSU_v4.3.0-r2.apk，即享永久 Root 與偽回鎖狀態！

📦 附加內容：一加 Ace 6T 專用魔改版 TWRP Recovery#

為方便維護與刷入模組，我們基於社群底包（鳴謝 @colorospro/1724 / color597）對閉源 TWRP 進行了二次客製化：

版本自訂：界面與屬性更新為 3.7.1_16-Macan_NkBe918-V1.3。
標識重構：將設備顯示名重定義為標準 ro.product.model.display=OnePlus Ace 6T。
管理器注入：保留 Magisk-v30.7.zip，剔除舊版 Kitsune，全新注入 SukiSU-v4.3.0-r2.zip（內建自動適配插槽與自動執行 ksud boot-patch 修補 init_boot 的專用 update-binary）。

⚠️ 特別注意：未真正深度測試解鎖時的使用規範#

實測證實，本機在當前的「偽回鎖」機制下，使用 TWRP 需遵循以下規則：

Snapdragon 8 Gen 5 不支援 fastboot boot 臨時引導： Qualcomm SM8845 的工程 ABL 屬於純 64 位元 UEFI 架構，其 fastboot 記憶體引導僅接受具備 EFI Stub 標頭的映像。執行 fastboot boot twrp.img 會直接報錯 No EFI image found in boot.img，必須透過 fastboot flash recovery_a 寫入分區。
非深度測試真解鎖的設備，開機前必須刷回原廠 Recovery：透過該方案秒解 BL 的設備，其引導鏈本質上處於「偽回鎖」狀態，正常進入系統時仍受官方原廠 vbmeta 的嚴格驗證。
- 可以正常使用 TWRP：需要救磚、進 TWRP 操作或刷入模組時，隨時可以 fastboot flash recovery_a TWRP-16-OPAce6T-NkBe918-V1.3.img 刷入並進入 TWRP，觸控與各功能均完全正常；
- 但在重啟進入 ColorOS 系統前：必須將 recovery 刷回原廠 Recovery 鏡像（stock_recovery_16.0.10.500.img），否則系統在開機驗證階段發現 recovery 與 vbmeta 雜湊不匹配將無法正常引導開機。
- （註：若是日後通過官方深度測試審核、真正走官方通道完全解開 BL 的設備，則可常駐保留第三方 Recovery）。

💾 資源整合包與網盤下載#

已將解鎖所需的全套工程引導、GBL 模組、臨時提權工具、SukiSU、專用魔改版 TWRP、原廠 16.0.10.500 恢復鏡像及內建推薦工具（含最新正式版 Shizuku）打包整合。提供以下載點供按需取用：

雲端平台	下載方式 / 說明	連結與提取碼
Google Drive	ZIP 整合包，海外高速	Google 雲端硬碟
123 雲盤	資料夾形式，免登錄不限速	123 雲盤提取碼：`nkbe`
百度網盤	資料夾與 ZIP 完整收錄	百度網盤提取碼：`nkbe`

整合包目錄結構清單：#

1
OnePlus_Ace6T_BL_Unlock_Root_Pack/
2
├── 1_Privilege_Escalation/       # 臨時提權 (GhostLock 1.2, KernelSU, 6.12.38 內核偏移)
3
├── 2_Fastboot_Unlock_Files/       # 解鎖關鍵 (高通簽名 abl.img, superfastboot efisp.img)
4
├── 3_Root_Managers/               # Root 管理器 (SukiSU v4.3.0-r2)
5
├── 4_TWRP_Recovery/               # TWRP-16-OPAce6T-NkBe918-V1.3.img & stock_recovery_16.0.10.500.img
6
├── 5_Flash_Scripts/               # 刷入與還原輔助腳本
7
└── 7_Recommended_Tools/           # 內建推薦工具 (含 Shizuku v13.6.2 正式版)

NyaZygisk WebUI 使用說明：每個功能是做什麼的、怎麼用

Wed, 21 Oct 2026 00:00:00 GMT

NyaZygisk 裝好之後，不用開終端機也能確認它有沒有正常運作，還能針對單一 App 關掉 Zygisk 模組。這些都在模組自帶的 WebUI 裡完成。這篇把 WebUI 的每個區塊說明一遍：它顯示什麼、資料從哪來、每個開關改了什麼。

先說結論：WebUI 只有兩個分頁，概覽（看狀態、看模組、三個設定）和應用排除（挑 App 不載入模組）。日常只會用到後者。

Note

本文依據 NyaZygisk 倉庫的 module/src/webroot/（前端）與 zygiskd、loader（讀取設定的一端）原始碼整理，截稿時我沒有逐項在實機上重新操作一遍，介面文字以原始碼內的字串為準。如果你的版本和描述不一致，以實際畫面為準。

🚪 怎麼打開#

在 Root 管理器（KernelSU / APatch）的模組頁找到 NyaZygisk，點模組卡片上的 WebUI 入口（通常是個「開啟」或網頁圖示的按鈕）。
Magisk 本身沒有 WebUI 入口，要用支援 WebUI 的第三方管理器開。前端內建的橋接介面有 window.kernelsu、KernelSU、WebUIX、apatch、mmrl 這幾種，偵測不到任何一種時，頁面會跳出「找不到支援的 WebUI bridge」。

WebUI 所有資料都是透過管理器提供的 exec 介面，以 root 身分執行 shell 命令取得的，不是靠網路，離線也能用。

📊 分頁一：概覽#

頂部：版本與重新整理#

標題下方的小字是 NyaZygisk 版本 · Root 方案與版本，例如 v2.5 · KernelSU …。右上角的圓形箭頭是重新整理，會重新讀取所有狀態並重新載入應用清單，成功後底部會彈出「已重新整理」。

狀態卡片：Zygisk 現在到底有沒有在運作#

最上面的大卡片用顏色和圖示直接告訴你結論，下面列出三個組件的狀態：

組件	含義
Zygote 監控（Zygote Monitor）	盯著 Zygote 進程、負責注入的監控組件，它停了就不會有注入
Zygote（會標示 64-bit / 32-bit）	Zygote 進程有沒有被注入
守護進程（Daemon）	`zygiskd`，負責給模組提供檔案、companion 等服務

每個組件的狀態字樣分兩類：

正常（綠）：運行中、已注入、追蹤中
異常（紅）：已停止、已退出、已崩潰、未注入
其他（灰）：未知

大卡片的總結按下面的規則決定，這是前端 overallTone 的邏輯：

卡片	條件	怎麼辦
✅ 運行正常	三個組件全部正常	不用管
⚠️ 部分異常	監控與 Zygote 都沒問題，但別的組件異常（通常是守護進程）	模組可能載入不了，先重新整理，再重開機
❌ 未運行	監控或 Zygote 有一個異常	Zygisk 沒生效，重開機；仍然不行就收集 debug 日誌回報
❔ 狀態未知	讀不到狀態，或剛裝好還沒重開機	重開機後再看；若同時出現橋接錯誤，換一個支援 WebUI 的管理器

Tip

裝完模組、重開機之後，第一件事就是開 WebUI 看這張卡片。README 的安裝步驟最後一步也是這個。

裝置與環境#

這張卡片列出：

Root 方案：偵測 APatch / FolkPatch / KernelSU / Magisk，能取得版本時一併顯示。做法是檢查 apd、fpd、magiskd 進程與 /data/adb/ksu 目錄，SukiSU 這類會顯示為 KernelSU 或 SukiSU。
系統：只有偵測到廠商 ROM 才會出現。目前認得 ColorOS / OxygenOS、HyperOS、MIUI、One UI，版本取自各家的系統屬性。AOSP 類系統這格會隱藏。
內核、Android SDK、ABI：直接讀自守護進程回報的資料。

回報問題時，把這張卡片截圖附上最省事，維護者不用再追問你的環境。

已啟用模組#

列出目前啟用中、並且是 Zygisk 或 ZN 模組的項目，右上角的數字是總數。每個模組顯示名稱、版本、說明、作者，以及標籤：

Zygisk：走 Magisk Zygisk API 的模組（例如 LSPosed 這一類）
ZN：走 Zygisk Next API 的模組。若它的注入目標不是 zygote，會多顯示一行「目標：xxx」
Companion：這個模組有使用 companion 進程

清單的來源是兩份資料合併：

掃描 /data/adb/modules/*，跳過有 disable 或 remove 標記的目錄，只保留含有 zygisk/<abi>.so 或 zn_modules.txt 的模組，並讀它的 module.prop。
守護進程回報的模組清單，補上類型（Zygisk / ZN）、目標和 companion 資訊。

所以如果某個模組沒出現在這裡，先檢查它是不是被停用了，或者它根本不是 Zygisk 模組（沒有 zygisk/ 目錄也沒有 zn_modules.txt）。反過來，剛啟用還沒重開機的模組，可能已經在清單裡但還沒真正載入，要以重開機後的狀態為準。

設定#

匿名記憶體（Anonymous memory）——「特化後隱藏模組的記憶體映射」，預設關閉。

打開後，App 進程完成特化（specialize）之後，NyaZygisk 會把 /proc/self/maps 裡由模組產生的映射（路徑名含 jit-cache-zygisk、zygisk-module、zn-module 的私有映射）改成匿名映射，同時把 rwx 的映射去掉寫入權限。目的是讓偵測 App 掃描 maps 時，看不到這些帶有模組特徵的名字。

適合：你的 App 會掃 maps 找 Zygisk 痕跡，且你已經確認需要這個功能。
不適合：沒有這種需求的情況不用開。它會改動進程的記憶體屬性，有用戶反饋開啟後出現過系統介面進不去、狀態顯示 Monitor: NO 等問題。遇到類似狀況，先把它關掉確認是不是原因。
開關改動後即寫入設定，對之後啟動的 App 進程生效，已經在跑的 App 要重新啟動。

自訂鏈接器（Custom linker）——「不經過系統鏈接器載入模組（實驗性）」，預設關閉。

一般情況下，模組是交給系統的動態鏈接器（android_dlopen_ext）載入的，載入後會登記在鏈接器的 solist 裡。打開這個開關後，NyaZygisk 改用自己內建的 ELF 載入器把模組映射進記憶體並完成重定位，模組不會進入系統鏈接器的紀錄；搭配匿名記憶體時，還能直接映射成匿名頁面，不留下 memfd 的名字。

適合：想進一步減少模組在系統鏈接器裡留下的痕跡，並且願意承擔實驗性功能風險的人。
不適合：一般使用。它是實驗功能，所以預設不啟用。載入失敗或遇到不支援的模組時，會自動退回系統鏈接器；但如果開啟後出現閃退或模組異常，請先關掉它再回報。
同樣對之後啟動的 App 進程生效。想確認模組是由哪個載入器載入的，可以用 debug 版看日誌裡的 modloader: 紀錄。
從 v2.5-r2 起，沒有設定這個鍵時視為關閉；先前版本在沒設定時是開啟的，更新後如果還要用，需要在 WebUI 重新打開。

語言（Language）——EN / 繁中 / 简中，切換後立刻生效，選擇記在 WebUI 自己的本機儲存裡，不影響模組本身。

🛡️ 分頁二：應用排除#

這是 WebUI 裡最實用的功能：勾選的 App 完全不載入任何 Zygisk 模組。

典型場景：

某個 App 偵測到 Zygisk 或 Hook 就拒絕運行或封號，又不需要任何模組的功能。
某個模組對特定 App 造成閃退，你想先把那個 App 排除掉而不是停用整個模組。

怎麼用#

切到底部的應用排除分頁（分頁標籤上的數字是目前已排除的 App 數量）。
在列表裡找到目標 App：
- 搜尋框支援依名稱或套件名搜尋；
- 上方有「全部 N / 已排除 N」兩個篩選，可以只看已排除的。
打開該 App 右側的開關。每次切換都會立刻儲存，並彈出「已儲存」。
重新啟動那個 App（建議從最近任務裡徹底滑掉再開）。排除只在 App 下次啟動時生效，已經在跑的進程不受影響。尚未生效的項目旁邊會顯示「待重啟」標籤。

列表中已排除的項目會排在最前面，其餘依名稱排序。切換時列的位置不會跳走，所以連續勾選多個不會點錯。

「同時卸載模組掛載」#

分頁上方的這個開關（Unmount for excluded apps），預設開啟。

開：被排除的 App 除了不載入模組之外，還會像 DenyList 一樣，把 Root 與模組的掛載從它的 mount namespace 裡卸掉。
關：只是不載入模組，掛載痕跡不處理。

也就是說，開著這個開關時，勾選一個 App 的效果等於「既不讓模組進去，又讓它看不到掛載」。如果你本來就用 Root 管理器的「卸載模組」功能（APatch / KernelSU）或 Magisk 的 DenyList 處理過這個 App，這個開關和它們是並行的，不衝突。

Important

應用排除和 DenyList 不是同一個東西：DenyList 管的是掛載（Zygisk 模組還是會被載入），應用排除管的是模組載入（再加上可選的卸載掛載）。要徹底把 App 隔離在模組之外，用應用排除並保持「同時卸載模組掛載」開啟。

它的限制#

介面頂部的提示已經寫了，這裡再展開：

只列出使用者安裝的 App（pm list packages -3）。系統 App 不會出現，也不能排除，這是刻意的：system_server 和系統 UID 永遠不受影響，避免把系統搞壞。
共用 UID 的 App 會一起切換。 如果多個套件共用同一個 UID，排除其中一個等於排除全部，列表裡會標出「與另外 N 個套件共用 UID，會一起切換」。
與系統套件共用 UID 的 App 無法排除。 這類項目開關是灰的，並註明「與系統套件共用 UID，無法排除」。原因是守護進程只有在同一 UID 下所有套件都在排除清單裡才會排除，而系統套件不允許被列進去。
已解除安裝的套件會被自動清掉，不會留下看不見的殘留項目。
顯示 App 名稱需要管理器提供套件資訊介面（KernelSU 系的 WebUI 有）；沒有時只顯示套件名，功能不受影響。

🧰 常見狀況#

現象	可能原因與處理
打開後全是 `-` 和「狀態未知」，彈出「找不到支援的 WebUI bridge」	用的管理器沒有提供 `exec` 介面，換成 KernelSU / APatch 自帶的入口，或支援 WebUI 的第三方管理器
狀態是「部分異常」	守護進程沒起來，先重新整理，再重開機；仍異常就用 debug 版收集日誌
「未運行」	Zygisk 沒生效。確認沒有同時安裝別的 Zygisk 實作（NeoZygisk、ReZygisk、Zygisk Next），Magisk 用戶要關閉內建 Zygisk
模組清單是空的	模組沒啟用，或不是 Zygisk / ZN 模組
勾選排除後 App 還是載入了模組	沒有重啟該 App，或該 App 與系統套件共用 UID（開關是灰的）
彈出「儲存設定失敗」	寫入 `config.prop` 失敗，開關會自動彈回原狀態，檢查管理器是否給了 WebUI root 權限

🔧 給進階使用者：設定存在哪#

WebUI 的所有設定都是寫進同一個檔案：

1
/data/adb/nyazygisk/config.prop

鍵	值	含義
`anonymous_memory`	`1` / `0`	匿名記憶體，沒有這個鍵視為關閉
`custom_linker`	`1` / `0`	自訂鏈接器，沒有這個鍵視為關閉（只有 `1` 才啟用）
`exclude_unmount`	`1` / `0`	同時卸載模組掛載，沒有這個鍵視為開啟
`exclude_apps`	`pkg1,pkg2,...`	排除的套件名，逗號分隔

WebUI 寫入時只改自己的那一個鍵、其餘保留，並且先寫暫存檔再改名，避免寫到一半被讀到。守護進程會監看這個檔案的修改時間，變動後自動清掉快取，所以不用重啟守護進程，在 WebUI 之外手動編輯也一樣生效（同樣是對之後啟動的進程生效）。

小結#

裝完先看概覽的狀態卡片：綠色就是 Zygisk 正常。
模組清單用來確認「我的模組有沒有真的被識別、被當成哪一類」。
應用排除是主要的日常功能：勾選 → 重啟該 App；想連掛載也藏掉就保持「同時卸載模組掛載」開著。
匿名記憶體只有在 App 會掃 maps 的時候才需要開。
自訂鏈接器是實驗功能，預設關閉；開啟後若出問題，先關掉再回報。

如果你發現說明和實際行為不符，或有想要的功能，歡迎到 GitHub 開 issue，或到 Telegram 頻道 @NyaZygisk 反映。

Zygisk 實作怎麼選：多個 Zygisk 實作的詳細對比

Sun, 18 Oct 2026 00:00:00 GMT

在 KernelSU、APatch 上用 Zygisk 模組，或者想替換 Magisk 內建的 Zygisk，現在有好幾個選擇。它們名字相近，能力卻差很多，有的甚至不是同一類東西。

先說結論：如果你想要一個開源、裝一個就能同時跑 Zygisk 模組與 Zygisk Next 模組、並且把「精簡」和「隱藏」當成首要目標的方案，推薦 NyaZygisk。下文逐項對照每個專案實際做了什麼、沒做什麼，NyaZygisk 不適合的情況也會寫出來，你可以對照自己的需求確認。

Note

利益揭露：我是 NyaZygisk 的維護者，所以這篇會推薦它。但比較的部分只寫能在原始碼或官方文件裡找到依據的事實，NyaZygisk 的限制也一併寫出。

資料來源：各倉庫 2026-10-20 取得的預設分支原始碼、README 與 GitHub 資料。Zygisk Next 已閉源，它的資訊只來自官方 README、API 文件與發佈頁，無法核實內部實作，下文凡是這種情況都會標明。「原始碼中沒有找到」只代表我讀過相關程式碼沒看到實作，不等於一定不支援。

🧭 先釐清：這五個不是同一類東西#

講「Zygisk」時，其實混了兩套不同的模組 API：

Magisk Zygisk API：Magisk 定義的模組介面（入口 zygisk_module_entry），LSPosed 等大多數 Zygisk 模組都用這套。目前最新版本是 v5。
Zygisk Next API（ZN API）：Zygisk Next 閉源之後自己新增的介面（入口 zn_module，用 zn_modules.txt 登記）。它可以注入由 init 啟動的進程，提供 inline / PLT hook 與符號解析介面，還有 HyperOS Rust Runtime 的回呼。

各專案對兩套 API 的支援不同：

Zygisk Next 兩套都支援，是 ZN API 的原始定義者，但已閉源。
NyaZygisk 兩套都支援，是目前唯一同時支援兩套 API 的開源實作。
NeoZygisk、ReZygisk 只實作 Magisk Zygisk API。
ZNNext（原名 ZygiskNextNext）只載入 ZN 模組，本身不是 Zygisk 實作，要用 Zygisk 模組得另外裝一個。

📋 總覽#

	Zygisk Next	NyaZygisk	NeoZygisk	ReZygisk	ZNNext
維護者	Dr-TSNG（LSPosed）	HSSkyBoy / NkBe	JingMatrix	PerformanC	VeryBaaad
與其他專案的關係	原始專案	fork 自 NeoZygisk	延續 Zygisk Next 開源時期的程式碼（2024-12 改名）	fork 自 Zygisk Next 開源時期，以 C 重寫	從零實作的 ZN 模組載入器
授權	閉源（v4-0.9.2 起）	GPL-3.0	GPL-3.0	AGPL-3.0	GPL-3.0
能否審計原始碼	❌	✅	✅	✅	✅
Magisk Zygisk API	✅	✅ v5	✅ v5	✅ v5	❌
ZN API	✅	✅ v4	❌	❌	✅ v4
HyperOS Runtime API	✅	✅ v1	❌	❌	✅ v1
單一模組即可跑兩類模組	✅	✅	❌	❌	❌
主要語言	未公開	C++ + Rust	C++ + Rust	C	C++ + Rust（injector）
最低 Android	8.0	7.1	8.0	7.1	5.0
架構	arm64、armv7、x86、x86_64、riscv64	arm64、armv7、x86_64、riscv64	arm64、armv7、x86、x86_64	arm64、armv7、x86、x86_64	arm64、armv7、x86、x86_64、riscv64
WebUI	有（README 提到翻譯）	有	無	有	有
最新釋出版本	v1.5.2（2026-10-15）	v2.5-r1（2026-10-23）	v2.4（2026-08-08）	v1.0.0（2026-05-10）	v2.2.0（2026-10-24）
近三個月提交數¹	5	36	9	29	216
GitHub Stars¹	10.7k	286	2.5k	4.1k	65

¹ 取自 GitHub，統計區間為 2026-07-20 至 2026-10-20。「最新釋出版本」一列於 2026-10-25 更新。Zygisk Next 的提交數只計公開倉庫，它的原始碼不公開，所以這個數字不代表實際開發量。

Note

「最低 Android」「架構」取自各專案安裝腳本、建置設定或公開說明。架構欄是依專案釋出與社群實測彙整。

Stars 與提交數只是側面參考：Stars 反映知名度與使用者基數，提交數反映開發活躍度，兩者都不等於穩定或好用。NyaZygisk 的使用者基數相對小，這是客觀事實，意味著問題回饋與社群經驗都比 NeoZygisk、ReZygisk 少。

🔒 開源這件事為什麼重要#

Zygisk 實作以 root 權限執行，能注入每一個應用進程。它做什麼、收集什麼，原則上只有看得到原始碼才能確認。

Zygisk Next 的開發者在社群裡有很好的信譽，這篇不是在質疑他們。但如果你的原則是「root 權限的元件必須可審計」，那 Zygisk Next 就不在選項內。

這也是 NyaZygisk 存在的主要理由：在開源方案裡，想同時用 Zygisk 模組與 ZN 模組，過去只能是「NeoZygisk / ReZygisk + ZNNext」兩個模組疊在一起；NyaZygisk 把兩套 API 放進同一個 GPL-3.0 的實作裡，裝一個就夠。

🔬 逐項對照#

1. 注入方式與模組載入#

	NyaZygisk	NeoZygisk	ReZygisk	ZNNext
注入目標進程的方式	`ptrace` 遠端呼叫 `dlopen` 載入 `libzygisk.so`	同左	`ptrace` + 自製遠端 linker（CSOLoader），不經過系統 linker	獨立的 injector 常駐進程，用 `ptrace`
發現目標進程的方式	監控 `execve`，辨識 Zygote 與 `hyos_spawner`	監控 `execve`，辨識 Zygote	監控 Zygote	tracefs `sched_process_exec`、proc connector、eBPF、fanotify、KPM，都不可用時退回 `/proc` 輪詢
載入 Zygisk 模組	daemon 為每個模組建立密封的唯讀 memfd，進程用 `android_dlopen_ext` 從 fd 載入	同左	自製 linker 載入	不適用
載入 ZN 模組	依 `zn_modules.txt`，同樣經 memfd 載入	不支援	不支援	依 `zn_modules.txt` 載入
ZN 模組可注入的目標	Zygote、`hyos_spawner`	—	—	`name=` / `path=` 指定的任意 init 啟動進程
進程旗標查詢	daemon 以共享記憶體（memfd + mmap）快取，其餘走 IPC	每次 IPC 查詢	IPC	不適用
Hook 後端	Dobby（riscv64 上改用 rv64hook）、LSPlt	LSPlt	PLTI	Dobby、ShadowHook、rv64hook、And64InlineHook；LSPlt、PLTI、ByteHook、xHook，可選擇

幾點說明：

NyaZygisk 與 NeoZygisk 的注入流程基本一致（這是 fork 關係），差別主要在 Nya 多了 hyos_spawner 目標與 ZN 載入器。
ReZygisk 的取向不同：它不使用系統 linker，目的是對抗基於 linker 的檢測（例如檢查 solist）。這和 Neo / Nya「用系統 linker 載入、事後清理痕跡」是兩種思路，沒有絕對優劣。
ZNNext 的目標發現方式最多元，對核心要求最低，這是它支援 Android 5.0 與 riscv64 的原因之一。
NyaZygisk 的 ZN 注入範圍是真實的功能缺口：daemon 雖然會解析 path=，但進程監控只攔截 Zygote 與 hyos_spawner，所以指定注入其他系統守護進程的 ZN 模組不會生效。

2. 隱藏與痕跡處理#

下表只比較原始碼中能確認存在的實作。「—」代表我在原始碼裡沒有找到對應實作。

項目	NyaZygisk	NeoZygisk	ReZygisk
DenyList 應用的 mount namespace	Zygote 內直接卸載，失敗或被中止則 `setns` 切換到快取的乾淨 namespace	同左	`setns` 切換到 daemon 準備的 Clean / Mounted namespace
偵測到關鍵 overlay 時放棄直接卸載	✅（如 `/product`）	✅	—
為所有 isolated 進程提供一致的 mount 視圖	✅	✅	—
卸載模組後清除 linker 內的痕跡（`solist`）	✅	✅	不適用（不經系統 linker）
清除 libc / linker 載入痕跡、`fossil` 偽裝	✅	✅	—
卸載動作自身留下的痕跡	✅	✅（v2.4 之後的提交 #161）	—
清除 `ptrace_message`	✅（seccomp / `PTRACE_SYSCALL` 混合）	✅	✅（seccomp）
DenyList 應用移除 release 日誌	✅	✅	—
模組記憶體映射匿名化（maps）	✅ 可選，需在 WebUI 開啟「匿名記憶體」	—	—
CFI shadow 同步處理	✅	—	—
`TracerPid` 清理	✅（FD 追蹤，hook `open` / `openat` / `close` / `read`）	—	—
系統屬性欺騙（`spoof.prop`）	✅	—	—
逐應用的模組排除清單	✅	—	—
接管 KernelSU 的 `kernel_umount`	✅	✅	—

幾點說明：

Nya 的隱藏處理是疊加在 Neo 之上的。表中標 ✅ 且 NeoZygisk 也有的項目，是 Nya 從上游繼承的；Nya 自己新增的是匿名記憶體、CFI shadow、TracerPid、屬性欺騙和逐應用排除。
TracerPid 清理有範圍限制：它只 hook libandroid_runtime、libart、libjavacore、libopenjdk、libbase 這幾個庫的 PLT，攔截的是經由它們讀取 /proc/*/status 的路徑，不涵蓋應用自己的 native 程式碼直接發出的系統呼叫。
匿名記憶體預設不啟用，因為它會改動映射，需要使用者自己在 WebUI 裡開啟。
屬性欺騙會改變系統屬性的回傳值，預設的 spoof.prop 涵蓋 Bootloader 狀態、build type、debuggable 旗標，以及 MIUI、Realme、OPlus 的專屬屬性；ro.boot.vbmeta.digest 每次載入時隨機產生。不需要的人可以刪掉相應行。
ReZygisk 在隱藏上選擇了「根本不碰系統 linker」的路線，所以沒有 solist 清理；它在 TracerPid、屬性欺騙、maps 偽裝這幾項我沒有找到對應實作。
Zygisk Next 和 ZNNext 是否有同類處理，Zygisk Next 無法核實；ZNNext 的隱藏重點在注入器本身的行為，與上表的 Zygisk 實作面向不同，這裡不做逐項比較。
沒有任何一個專案能保證通過所有檢測，我也沒有逐機型、逐應用實測。

3. 平台與環境適配#

	NyaZygisk	NeoZygisk	ReZygisk	ZNNext
APatch / KernelSU / Magisk	✅	✅	✅	✅
KernelSU Next 等變體辨識	✅	✅	✅	未逐項核實
Magisk Alpha / Kitsune 辨識	✅	✅	未找到	未逐項核實
KernelSU LKM 後載入（late-load）	✅	—	—	—
KernelSU 模擬軟重啟（臨時 root）	✅	—	—	✅（含 `emulated-soft-reboot.sh`）
HyperOS `hyos_spawner`	✅	—	—	✅
Android 17 Zygote 簽名	✅（繼承上游）	✅	未逐項核實	未逐項核實
BTI 設備	✅（繼承上游）	✅	未逐項核實	未逐項核實
32 位元 PLT hook 修正	✅（繼承上游）	✅	不適用	不適用

4. 管理介面#

	NyaZygisk	NeoZygisk	ReZygisk	ZNNext
WebUI	✅ 分頁式：概覽、模組、設定	—	✅	✅ Vue 3，兩套外觀
多語言	繁中、簡中、英文	—	透過 Crowdin 翻譯	未逐項核實
區分模組類型（Zygisk / Next）	✅	不適用	不適用	不適用
顯示 ROM、核心、ABI、SDK	✅	—	未逐項核實	未逐項核實
`action.sh` 狀態輸出	—	✅	未逐項核實	未逐項核實

🔍 各專案小結#

Zygisk Next#

優勢：兩套 API 都支援，ZN 模組可以注入任意由 init 啟動的進程；HyperOS Runtime API 由它提出；新的 ZN 模組通常以它為首要測試對象；活躍維護，v1.5.2 剛在 2026-10-15 釋出。
限制：閉源，無法審計，也不能被修改或 fork。

NyaZygisk#

優勢：
- 開源，且單一模組同時載入 Magisk Zygisk 模組（v5）、ZN 模組（v4）與 HyperOS Runtime 模組（v1）；
- 在 NeoZygisk 的 DenyList 基礎上疊加了 TracerPid、屬性欺騙、匿名記憶體、CFI shadow 與逐應用排除；
- 支援 KernelSU LKM 後載入與模擬軟重啟；
- 最低支援 Android 7.1，比上游 NeoZygisk 的 8.0 更低；
- v2.5-r1 起支援 riscv64（需 Android 15 以上），ZN 的 inline hook 在 riscv64 上由 rv64hook 提供；
- 有 WebUI，可以區分 [Zygisk] / [Next] 模組並設定逐應用排除。
限制：
- ZN 模組只會注入 Zygote 與 hyos_spawner；
- 不支援 32 位元 x86，最低 Android 版本也高於 ZNNext 的 5.0；
- 使用者基數與社群經驗少於 NeoZygisk、ReZygisk（Stars 286，對比 2.5k 與 4.1k）；
- 程式碼量與維護面比上游大（見下文）；
- 屬性欺騙這類行為改變了系統屬性的回傳值，若你不需要，就多了一份額外的行為。

NeoZygisk#

優勢：NyaZygisk 的上游，專注做好 Magisk Zygisk API，功能範圍克制，社群經驗多（Stars 2.5k）；DenyList 的 Zygote 直接卸載加 setns 後備就設計在這裡；跟進 Android 17 與 BTI 設備的支援。
限制：不支援 ZN API，ZN 模組無法使用；無 WebUI；最低 Android 8.0；沒有 TracerPid 清理與屬性欺騙。

ReZygisk#

優勢：
- 整個程式碼庫用 C 重寫，二進位更小；
- 自製 linker（CSOLoader），不經系統 linker，對抗基於 linker 的檢測，這個設計方向在五者中獨有；
- 使用者基數大（Stars 4.1k），WebUI 翻譯與社群管道完整；
- 最低支援 Android 7.1；
限制：不支援 ZN API；在 TracerPid、屬性欺騙、maps 偽裝這幾項我沒有找到對應實作；最近一個正式版是 v1.0.0（2026-05-10）。

ZNNext#

優勢：ZN API 實作完整，可注入任意由 init 啟動的進程；對核心要求最低，支援 Android 5.0 起與 riscv64；開發最活躍（近三個月 216 次提交，最新版 v2.2.0 在 2026-10-24 釋出）。
限制：它不是 Zygisk 實作，Magisk Zygisk 模組（例如 LSPosed）不會被它載入，必須搭配另一個 Zygisk 實作使用，也就是要裝兩個模組。

✅ 按需求選#

你的需求	推薦
想要開源，又要同時跑 Zygisk 模組和 ZN 模組	NyaZygisk
用 HyperOS，需要 HyperOS Runtime 模組	NyaZygisk
只用 Magisk Zygisk 模組（如 LSPosed），但在意屬性與注入痕跡的隱藏	NyaZygisk
用 KernelSU LKM 後載入或臨時 root	NyaZygisk
只用 Magisk Zygisk 模組，想要最精簡、不需要額外隱藏處理，且重視社群經驗	NeoZygisk
只用 Magisk Zygisk 模組，重視對 linker 檢測的對抗，或偏好 C 程式碼庫	ReZygisk
ZN 模組要注入 Zygote 以外的系統守護進程	Zygisk Next，或 NeoZygisk + ZNNext
riscv64 設備，想用開源方案同時跑兩類模組	NyaZygisk（v2.5-r1 起）
Android 5.0 ~ 7.0，需要 ZN 模組	ZNNext（Zygisk Next 最低要 8.0；本文比較的 Zygisk 實作最低都要 7.1，Zygisk 模組那一側需另找相容方案）

幾點補充：

不要同時裝多個 Zygisk 實作。NyaZygisk、NeoZygisk、ReZygisk、Zygisk Next 彼此是替代關係，Magisk 使用者也要先關閉內建 Zygisk。ZNNext 是唯一設計成與 Zygisk 實作並存的。
Magisk 使用者：在 NyaZygisk / NeoZygisk 上，請勿開啟 Magisk 的「強制執行排除列表（Enforce DenyList）」，它是 Magisk 自己的機制，可能與實作本身的隱藏機制衝突。
隱藏效果因機型與檢測方案而異。以上只描述各專案的機制，沒有任何一個能保證通過所有檢測。

🎯 NyaZygisk 的定位：精簡，與隱藏#

最後說明 NyaZygisk 想做什麼，也方便你判斷它是不是你要的。

精簡，指的是目標，不是行數。NyaZygisk 把力氣花在注入引擎與模組載入引擎本身，不往模組管理、線上更新、主題之類的方向堆功能；ZN API 這一層也只做模組真正需要的部分（hook、符號解析、companion），而不是複製整個 Zygisk Next。

需要說清楚的是：這不代表程式碼量最少。以注入器與 daemon 的原始碼行數粗估，NyaZygisk 約 1.4 萬行，NeoZygisk 約 1.1 萬行，ReZygisk 約 1.1 萬行，ZNNext 約 1.3 萬行（不含第三方庫與 WebUI 前端）。相比上游多出來的部分，主要是 ZN 相容層、隱藏處理和 WebUI。如果「精簡」對你來說就是「程式碼最少」，NeoZygisk 更符合。

隱藏，是 NyaZygisk 和上游拉開差距的主要方向：

在上游 DenyList（Zygote 直接卸載 + setns 後備）的基礎上，補上 TracerPid、屬性欺騙、匿名記憶體、CFI shadow 處理；
模組全部卸載後把痕跡清乾淨，包括卸載動作自己留下的；
這些額外的隱藏處理都盡量做成可選或可調整的，例如匿名記憶體需要手動開啟、spoof.prop 可以自己編輯，不強迫所有人接受。

所以，如果你的需求是「模組能載入、盡量少露痕跡、不想為了兩套 API 裝兩個模組」，NyaZygisk 就是為這個場景做的；如果你只需要最基本的 Zygisk，或需要 ZN 模組注入任意系統進程，上面的表格已經列出了更合適的選擇。

🔗 相關連結#

Zygisk Next（README 與 API 標頭檔）
NyaZygisk（介紹頁）
NeoZygisk
ReZygisk
ZNNext
ZygiskNextModuleSample：ZN 模組範例

一加內核開源，發現新增「和平精英」專項檢測

Sat, 03 Oct 2026 00:00:00 GMT

在一加開源的 Ace 6 Ultra（聯發科 MT6993）內核模組原始碼中，出現了一個新的檔案 oplus_kernel_security_check.c。

檔案頭部註釋說明，這是為了「和平精英」的需求進行的內核完整性檢測，作者署名為 cenjun，日期標註為 2025 年 12 月。

它的思路並不複雜：不攔截，只記錄。ko 檔案照常載入，程序不會被終止，也沒有任何封禁動作，異常只會記錄為事件，等待用戶空間讀取。

🔍 檢測了什麼#

1. 系統調用表（Syscall Table）#

開機時，為整個表記錄一份 SHA256 指紋，之後每小時重新計算一次。
如果與初始值不符，就會記錄一條帶有時間戳記的事件。
限制：只比較表中的函數指標，不檢查函數本體，因此 inline hook 是無法檢測到的。

2. ko 模組載入（Kernel Module Loading）#

掛載在內核的 load_module 上，每次載入一個 ko 檔案，就會對其映像計算雜湊值，然後與名單進行比較：

不在名單中：記錄為未知模組
雜湊值不匹配：記錄為被篡改
雜湊值一致：放行

名單由系統程序 oplus_kohashpro 寫入，並且必須等待系統報告開機完成後，檢測才會啟動。每類事件最多保留 10 條，超出部分會丟棄最舊的。

⬆️ 對 root 用戶意味著什麼#

判定方式只有一條：是否在名單上。即使是自己編譯、完全無害的 ko 檔案，在它看來也與被篡改的 ko 檔案沒有區別。

KSU 的模組：不經過 load_module，不在檢測範圍內。
KernelSU 本體：如果以 LKM 方式載入，它自己的 ko 檔案會被記錄為未知模組（此項依程式碼邏輯推斷，尚未經實際設備驗證）。這也代表從理論上使用 GKI 或 Magisk 就能規避該項檢測。

不少 root 玩家表示，他們同樣反感作弊行為，也理解遊戲方維護公平環境的需要，只希望這類訊號僅作為參考，不要直接等同於作弊證據。

Note

以上內容均基於對公開原始碼的解讀。

原始碼來源：OnePlusOSS / android_kernel_modules_and_devicetree_oneplus_mt6993

適配 Minecraft 26.1.x：技術遷移實錄

Sat, 25 Apr 2026 00:00:00 GMT

深度解析 Java 25、Unobfuscated Loom 與 Mojang 官方對映的適配細節
由 Gemini 3.1 Pro 自我的 md 原稿重寫為 html，換行好像都是問題///

序言#

隨著 Minecraft 26.1.x 的釋出，Fabric 模組開發生態迎來了一次真正意義上的分水嶺。

這不只是一次例行的版本升級——而是 26.1 Fabric 所代表的工具鏈、對映體系與開發流程的整體轉向。

不僅 Java 版本躍升至 25，構建工具 Loom 的核心架構、對映機制與 GUI 系統都發生了根本性的重構。

本文將以 BoatFly 與 PetPhraseX 的完整適配過程為例，簡單說下有關本次遷移的技術細節與踩坑經驗。

第一部分：工具鏈與環境配置#

1.1 Java 版本升級至#

Minecraft 26.1.x 要求最低 Java 25 作為編譯與執行環境，這不只是版本號上的遞進，更涉及 JVM 的多項新特性與效能最佳化。

在 gradle.properties 中，我們需要明確指定目標版本，如：

1
org.gradle.jvmargs = -Xmx4096m -Dfile.encoding=UTF-8
2
target_java_version = 25
3
minecraft_version = 26.1.2

Warning

**注意：**若使用 Gradle Wrapper 需升級至 9.4.0+。

1.2 Fabric Loader 與 Loom 的版本對齊#

Loom 1.15-SNAPSHOT 是適配 26.1.x 的關鍵版本。它引入了全新的編譯流程，不再依賴 Yarn 對映的中間層轉換。

同時也建議將 Fabric Loader升級至 0.18.6+，以支援新的模組載入機制。

1
plugins {
2
    // 引入支援 Unobfuscated 流程的最新版 Loom 外掛
3
    id 'net.fabricmc.fabric-loom' version '1.16-SNAPSHOT'
4
}
5
dependencies {
6
    // 指定目標 Minecraft 版本為 26.1.2
7
    minecraft "com.mojang:minecraft:26.1.2"
8

9
    // 引入支援新模組載入機制的 Fabric Loader 0.18.6+
10
    compileOnly "net.fabricmc:fabric-loader:0.18.6"
11
    }

1.3 fabric.mod.json 後設資料規範更新#

伴隨 Fabric Loader 0.18.6+ 的升級，模組後設資料檔案的校驗規則迎來了強約束更新，過往寬鬆的欄位宣告將直接導致模組無法載入，甚至出現啟動器校驗不透過的問題。

核心變更集中在依賴宣告、環境限定與 Java 版本約束三個維度，尤其針對 Minecraft 26.1.x 與 Java 25 的強制要求，必須在後設資料中明確宣告。

Warning

必須在 depends 中明確宣告 "java": ">=25"，否則 Loader 可能會直接阻斷模組載入，無任何容錯空間。

1.4 IDE 開發環境適配最佳化#

針對 Java 25 與全新 Loom 工具鏈，主流 IDE 也需要完成對應的配置最佳化，才能避免同步失敗、原始碼對映錯亂、除錯斷點失效等問題。

以 IntelliJ IDEA 為例，核心適配步驟如下：

升級 IDEA 至 2025.3+ 版本，才能獲得 Java 25 語法的完整支援與 Gradle 9.4+ 的原生相容
在 專案結構 → SDK 中新增 Java 25 正式版 SDK，並將專案的 SDK、語言級別均設定為 Java 25
在 Gradle 設定中，將「使用 Gradle 來自」設定為 gradle-wrapper.properties，並指定 Gradle JVM 為 Java 25

第二部分：對映機制遷移#

2.1 從 Yarn 到 Mojang 的範式變革#

本次 26.1.x 適配最核心的變革，莫過於 Loom 1.15+ 帶來的 Unobfuscated 原生官方對映開發流程。

過往 Fabric 模組開發的標準流程，是基於社群維護的 Yarn 命名對映編寫程式碼，編譯時通過 Loom 轉換為 Intermediary 中間對映，最終在執行時匹配遊戲的混淆位元組碼。

而全新的 Unobfuscated 流程，直接基於 Mojang 官方釋出的 deobfuscation 對映進行開發，徹底移除了 Yarn 中間層的依賴：

編譯流程大幅簡化，無需執行對映轉換，構建速度將會有所提升
命名與官方原始碼完全對齊，避免了 Yarn 與官方對映的命名差異帶來的理解成本
與 Forge 生態的命名體系完全一致，跨載入器模組開發的適配成本大幅降低

在 build.gradle 中，無需再引入任何 Yarn 對映依賴，僅需保留 Minecraft 官方依賴即可完成對映配置，這也是本次工具鏈升級最具顛覆性的變化。

2.2 大規模包名與類名變更#

官方對映的引入，導致了數百個類的重新命名。以下是在我專案中常出現的變更對照：

1
// 文本
2
net.minecraft.text.Text → net.minecraft.network.chat.Component
3

4
// GUI
5
net.minecraft.client.gui.screen.Screen → net.minecraft.client.gui.screens.Screen
6
net.minecraft.client.gui.widget.ButtonWidget → net.minecraft.client.gui.components.Button
7

8
// 渲染
9
net.minecraft.client.gui.DrawContext → net.minecraft.client.gui.GuiGraphics

Warning

**注意：**除了命名變更，大量方法的引數順序、返回值型別也發生了調整，切勿僅做簡單的查詢替換，需逐行核對方法簽名的完整性，避免出現執行時崩潰。

第三部分：GUI 系統重構#

3.1 渲染生命週期的變更#

在我的專案中，最重大的 API 變更發生在 Screen 類。

舊版本使用 render()，新版本則改為 extractRenderState()——必須重新適應新的圖形提取模式。

Note

提示：GuiGraphicsExtractor 的 text() 預設為左對齊，不再內建居中功能，反正開發文件裡我沒看到。

1
@Override
2
public void extractRenderState(GuiGraphicsExtractor graphics, int mouseX, int mouseY, float delta) {
3
    super.extractRenderState(graphics, mouseX, mouseY, delta);
4

5
    // 手動計算居中位置
6
    int titleWidth = this.font.width(this.title);
7
    int centerX = (this.width - titleWidth) / 2;
8
    graphics.text(this.font, this.title, centerX, 10, 0xFFFFFF, true);
9
}

第四部分：Mixin 注入體系適配要點#

本次 26.1.x 版本升級中，Mixin 注入邏輯的調整，是多數模組啟動崩潰的核心誘因。

除了前文提到的類名、方法名全量變更，遊戲核心類的執行流程、位元組碼結構也有深層重構，過往的注入點會出現無效異常，甚至直接阻斷遊戲啟動。

以下為本次適配的核心規則，均來自 BoatFly 與 PetPhraseX 的實戰驗證。

4.1 注入目標的全量重定位#

官方對映體系下，Mixin 注入的核心目標，必須完全替換為 Mojang 官方的命名規範，而非簡單替換 Yarn 對映的名稱。

核心調整包含三個維度：

其一，@Mixin 註解的目標類，需替換為官方對映的全限定類名，不可繼續沿用 Yarn 體系的類路徑。

其二，@At 註解中的注入目標，無論是方法呼叫還是欄位訪問，都需同步更新為官方對映的命名與描述符。

其三，@Shadow 註解的欄位與方法，必須與官方對映的簽名完全一致，否則會同時出現編譯與執行期雙重異常。

4.2 注入規範的強約束更新#

伴隨 Loom 1.15+ 的升級，Mixin 新增了編譯期強校驗機制，過往寬鬆的注入寫法將直接導致構建失敗。

最核心的變更，是要求所有注入點必須顯式宣告 require 屬性，推薦強制每個注入點必須匹配到對應目標以防止靜默崩潰。

同時，介面注入、訪問器的目標類與方法，也需同步完成官方對映的替換，並嚴格按客戶端、服務端環境拆分配置，避免服務端載入客戶端專屬 Mixin 導致的崩潰。

4.3 配置檔案的規範調整#

Mixin 配置檔案需同步完成兩項核心調整，否則會直接導致 Mixin 無法載入。

第一，必須顯式宣告 compatibilityLevel 為 JAVA_25，確保 Mixin 適配 Java 25 的位元組碼版本。

第二，必須顯式宣告 required 為 true，明確告知 Loader 該配置為模組必需，避免載入時的警告與潛在異常。

第五部分：Fabric API 核心體系變更#

Fabric API 針對 26.1.x 同步完成了架構重構，大量常用事件、工具類被標記為棄用甚至移除，事件的觸發時機、引數列表也有破壞性變更。

5.1 客戶端生命週期事件重構#

伴隨 GUI 渲染系統的重寫，客戶端核心生命週期事件也同步完成了調整。

螢幕渲染相關事件，完全對應新的 extractRenderState 生命週期，替換了舊版本的 render 相關事件，觸發時機與傳入引數均有對應調整。

客戶端 Tick、螢幕開啟關閉等核心事件，也進行了名稱空間與分類的重構，需按新的事件路徑完成註冊，否則會出現事件不生效的問題。

5.2 聊天與文本系統適配#

除了前文提到的 Text 到 Component 的類名變更，聊天訊息的事件監聽、文本元件構建 API 也有全量調整。

文本元件的構建方法，需替換為官方對映對應的靜態方法，樣式設定的流式 API 也有對應調整。

聊天訊息相關事件進行了強約束重構，新增了訊息取消機制，攔截或修改聊天訊息需按新的規範返回對應結果，否則會出現訊息重複傳送、攔截失效的問題。

5.3 輸入與按鍵繫結系統調整#

客戶端輸入處理的重構，也帶來了按鍵繫結、滑鼠鍵盤事件的對應變更。

按鍵繫結需使用新的註冊 API，而非舊版本的直接例項化註冊。

按鍵按下/釋放、滑鼠點選滾動等輸入事件，也進行了名稱空間重構，引數列表新增了視窗上下文資訊，需同步完成適配。

第六部分：常見踩坑與解決方案#

在 BoatFly 與 PetPhraseX 的完整適配過程中，我們整理了多數開發者都會遇到的共性問題，對應的解決方案可大幅縮短適配週期。

6.1 編譯與環境類問題#

最常見的「無效的目標發行版: 25」報錯，核心原因無非三點：Gradle 版本過低、IDE 配置的 Java SDK 版本不正確、目標版本宣告錯誤。

對應解決方案也很明確：升級 Gradle Wrapper 至 9.4.0+ 版本，在 IDE 中配置 Java 25 正式版 SDK，並將專案與 Gradle 的 JVM 均設定為 Java 25，同時確認配置檔案中的目標版本號正確。

另一類常見的依賴同步失敗問題，多是 Loom 版本與 Minecraft 版本不匹配，需使用 1.15-SNAPSHOT 及以上的 Loom 版本，才能完整支援 26.1.x 的官方對映流程。

6.2 執行與載入類問題#

模組載入時提示「依賴約束不滿足」，核心是 fabric.mod.json 中的依賴宣告不符合新規範。

必須在依賴中顯式宣告 Java 25、對應的 Fabric Loader 與 Minecraft 版本範圍，否則 Loader 會直接阻斷模組載入，無任何容錯空間。

遊戲啟動時的「模組訪問許可權異常」，是 Java 25 強化了模組系統的訪問控制，需在執行引數中新增對應的模組開放配置，解決反射訪問的許可權問題。

6.3 功能與渲染類問題#

GUI 渲染時文本錯位、元件不顯示，多是未遷移至新的渲染生命週期，仍沿用舊的 render 方法，或是文本座標計算不符合新 API 的預設規則。

需將所有螢幕渲染邏輯遷移至 extractRenderState 方法，手動計算文本與元件的座標，不再依賴舊版本的內建居中功能。

Mixin 注入失效、功能不生效，需先開啟 Mixin 除錯模式，檢視詳細的注入日誌，核對注入目標的命名、描述符是否與官方對映完全一致，多數問題都來自命名的細微偏差。

總結#

Minecraft 26.1.x 的適配雖然涉及深度的技術重構，但也為模組開發生態帶來了長期的穩定性與可維護性。

透過採用官方對映、新的 GUI API 與改進的構建流程，我們現在能編寫更清晰、更易維護的程式碼。

NkBe

你好，這裡是 NkBe 的新站

一加 Ace 6T 免深度測試秒解 Bootloader、偽回鎖與永久 Root 實錄

💡 方案特性總結#

🧩 整體原理：四個關鍵環節#

🔓 第一步：利用內核漏洞臨時提權（越獄）#

📦 第二步：提取備份與預先修補 init_boot#

1. 備份原機關鍵分區#

2. 修補 SukiSU 鏡像#

🛠️ 第三步：刷入工程 abl.img 與 GBL efisp.img#

⚠️ 第四步：關鍵避坑——按「音量下」秒解 BL#

操作步驟：#

📦 附加內容：一加 Ace 6T 專用魔改版 TWRP Recovery#

⚠️ 特別注意：未真正深度測試解鎖時的使用規範#

💾 資源整合包與網盤下載#

整合包目錄結構清單：#

NyaZygisk WebUI 使用說明：每個功能是做什麼的、怎麼用

🚪 怎麼打開#

📊 分頁一：概覽#

頂部：版本與重新整理#

狀態卡片：Zygisk 現在到底有沒有在運作#

裝置與環境#

已啟用模組#

設定#

🛡️ 分頁二：應用排除#

怎麼用#

「同時卸載模組掛載」#

它的限制#

🧰 常見狀況#

🔧 給進階使用者：設定存在哪#

小結#

Zygisk 實作怎麼選：多個 Zygisk 實作的詳細對比

🧭 先釐清：這五個不是同一類東西#

📋 總覽#

🔒 開源這件事為什麼重要#

🔬 逐項對照#

1. 注入方式與模組載入#

2. 隱藏與痕跡處理#

3. 平台與環境適配#

4. 管理介面#

🔍 各專案小結#

Zygisk Next#

NyaZygisk#

NeoZygisk#

ReZygisk#

ZNNext#

✅ 按需求選#

🎯 NyaZygisk 的定位：精簡，與隱藏#

🔗 相關連結#

一加內核開源，發現新增「和平精英」專項檢測

🔍 檢測了什麼#

1. 系統調用表（Syscall Table）#

2. ko 模組載入（Kernel Module Loading）#

⬆️ 對 root 用戶意味著什麼#

適配 Minecraft 26.1.x：技術遷移實錄

序言#

第一部分：工具鏈與環境配置#

1.1 Java 版本升級至#

1.2 Fabric Loader 與 Loom 的版本對齊#

1.3 fabric.mod.json 後設資料規範更新#

1.4 IDE 開發環境適配最佳化#

第二部分：對映機制遷移#

2.1 從 Yarn 到 Mojang 的範式變革#

2.2 大規模包名與類名變更#

第三部分：GUI 系統重構#

3.1 渲染生命週期的變更#

第四部分：Mixin 注入體系適配要點#

4.1 注入目標的全量重定位#

4.2 注入規範的強約束更新#

4.3 配置檔案的規範調整#

第五部分：Fabric API 核心體系變更#

5.1 客戶端生命週期事件重構#

5.2 聊天與文本系統適配#

5.3 輸入與按鍵繫結系統調整#

第六部分：常見踩坑與解決方案#

6.1 編譯與環境類問題#

6.2 執行與載入類問題#

6.3 功能與渲染類問題#

總結#

📦 第二步：提取備份與預先修補 `init_boot`#

🛠️ 第三步：刷入工程 `abl.img` 與 GBL `efisp.img`#