NkBe
Zygisk 實作怎麼選：多個 Zygisk 實作的詳細對比
在 KernelSU、APatch 上用 Zygisk 模組，或者想替換 Magisk 內建的 Zygisk，現在有好幾個選擇。它們名字相近，能力卻差很多，有的甚至不是同一類東西。
先說結論：如果你想要一個開源、裝一個就能同時跑 Zygisk 模組與 Zygisk Next 模組、並且把「精簡」和「隱藏」當成首要目標的方案，推薦 NyaZygisk。下文逐項對照每個專案實際做了什麼、沒做什麼，NyaZygisk 不適合的情況也會寫出來，你可以對照自己的需求確認。
利益揭露：我是 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。
- ZygiskNextNext 只載入 ZN 模組，本身不是 Zygisk 實作，要用 Zygisk 模組得另外裝一個。
📋 總覽
| Zygisk Next | NyaZygisk | NeoZygisk | ReZygisk | ZygiskNextNext | |
|---|---|---|---|---|---|
| 維護者 | Dr-TSNG（LSPosed） | HSSkyBoy / NkBe | JingMatrix | PerformanC | VeryBaaad |
| 與其他專案的關係 | 原始專案 | fork 自 NeoZygisk | 獨立發展 | fork 自 Zygisk Next 開源時期 | 從零實作的 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 | 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.4（2026-08-10） | v2.4（2026-08-08） | v1.0.0（2026-05-10） | v2.0.0（2026-10-19） |
| 近三個月提交數¹ | 5 | 36 | 9 | 29 | 216 |
| GitHub Stars¹ | 10.7k | 286 | 2.5k | 4.1k | 65 |
¹ 取自 GitHub，統計區間為 2026-07-20 至 2026-10-20。Zygisk Next 的提交數只計公開倉庫，它的原始碼不公開，所以這個數字不代表實際開發量。
「最低 Android」「架構」取自各專案安裝腳本、建置設定或公開說明。架構欄是依專案釋出與社群實測彙整。
Stars 與提交數只是側面參考：Stars 反映知名度與使用者基數，提交數反映開發活躍度，兩者都不等於穩定或好用。NyaZygisk 的使用者基數相對小，這是客觀事實，意味著問題回饋與社群經驗都比 NeoZygisk、ReZygisk 少。
🔒 開源這件事為什麼重要
Zygisk 實作以 root 權限執行，能注入每一個應用進程。它做什麼、收集什麼，原則上只有看得到原始碼才能確認。
Zygisk Next 從 v4-0.9.2 起改為保留所有權利，授權明確禁止修改、再散佈，以及拆出任何部分用在其他專案。ReZygisk 的 README 把這點講得很直接：閉源讓社群無法貢獻，也無法審計，對一個 root 級別的模組來說是重大的安全疑慮。
Zygisk Next 的開發者在社群裡有很好的信譽，這篇不是在質疑他們。但如果你的原則是「root 權限的元件必須可審計」，那 Zygisk Next 就不在選項內。
這也是 NyaZygisk 存在的主要理由：在開源方案裡，想同時用 Zygisk 模組與 ZN 模組，過去只能是「NeoZygisk / ReZygisk + ZygiskNextNext」兩個模組疊在一起；NyaZygisk 把兩套 API 放進同一個 GPL-3.0 的實作裡，裝一個就夠。
🔬 逐項對照
1. 注入方式與模組載入
| NyaZygisk | NeoZygisk | ReZygisk | ZygiskNextNext | |
|---|---|---|---|---|
| 注入目標進程的方式 | 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、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 載入、事後清理痕跡」是兩種思路，沒有絕對優劣。 - ZygiskNextNext 的目標發現方式最多元，對核心要求最低，這是它支援 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清理有範圍限制：它只 hooklibandroid_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 和 ZygiskNextNext 是否有同類處理，Zygisk Next 無法核實；ZygiskNextNext 的隱藏重點在注入器本身的行為，與上表的 Zygisk 實作面向不同，這裡不做逐項比較。
- 沒有任何一個專案能保證通過所有檢測，我也沒有逐機型、逐應用實測。
3. 平台與環境適配
| NyaZygisk | NeoZygisk | ReZygisk | ZygiskNextNext | |
|---|---|---|---|---|
| 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 | ZygiskNextNext | |
|---|---|---|---|---|
| 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 更低；
- 有 WebUI，可以區分
[Zygisk]/[Next]模組並設定逐應用排除。
- 限制：
- ZN 模組只會注入 Zygote 與
hyos_spawner； - 不支援 riscv64，最低 Android 版本也高於 ZygiskNextNext 的 5.0；
- 使用者基數與社群經驗少於 NeoZygisk、ReZygisk（Stars 286，對比 2.5k 與 4.1k）；
- 程式碼量與維護面比上游大（見下文）；
- 屬性欺騙這類行為改變了系統屬性的回傳值，若你不需要，就多了一份額外的行為。
- ZN 模組只會注入 Zygote 與
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）。
ZygiskNextNext
- 優勢：ZN API 實作完整，可注入任意由 init 啟動的進程；對核心要求最低，支援 Android 5.0 起與 riscv64；開發最活躍（近三個月 216 次提交，v2.0.0 在 2026-10-19 釋出）。
- 限制：它不是 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 + ZygiskNextNext |
| riscv64 設備，或 Android 5.0 ~ 7.0，需要 ZN 模組 | Zygisk Next |
幾點補充：
- 不要同時裝多個 Zygisk 實作。NyaZygisk、NeoZygisk、ReZygisk、Zygisk Next 彼此是替代關係，Magisk 使用者也要先關閉內建 Zygisk。ZygiskNextNext 是唯一設計成與 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 萬行，ZygiskNextNext 約 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
- ZygiskNextNext
- ZygiskNextModuleSample：ZN 模組範例
支持與分享
如果這篇文章對你有幫助，歡迎分享給更多人或打賞支持！