NPatch 對於 API 101 的相容基本穩定了,目前測試完畢與推薦的 API 101 模組有: 話說這不算廣告吧?
TCQT | @astcqt
FreeMoe | @freemoe520
NewHookVip | @HookVipCl
ForbidAd4TieBa | Github
來測試 NPatch v1.0.5 嗡嗡蜂群更新
t.me/ONPatch
今天還正好是520😈 那這就是我送給你們的禮物🦀
TCQT | @astcqt
FreeMoe | @freemoe520
NewHookVip | @HookVipCl
ForbidAd4TieBa | Github
來測試 NPatch v1.0.5 嗡嗡蜂群更新
t.me/ONPatch
今天還正好是520
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ONPatch
@NPatch 的测试发布频道
❤27🤪1
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🤪4👍1
Forwarded from ONPatch
NPatch-v1.0.5-639-release.apk
7.8 MB
https://github.com/7723mod/NPatch/issues/82
有類似情況的來測試一下
有類似情況的來測試一下
❤9🔥1
v1.0.6 將引入更強力的去除簽名校驗機制,並進一步提升對加固環境的處理能力;小部分免費版 360 加固已可被繞過。這項成果歸功於 @QToolCI 的 FunPatchApp,也就是由 Fun 團隊開發的 FPA。
v1.0.6 will introduce a more powerful signature verification removal mechanism and further improve handling for protected environments; some free 360 protection builds can now be bypassed. This achievement is credited to FPA, developed by the @QToolCI
新版本(v1.0.6)暫預計命名為 霜焰更新
The new version (v1.0.6) is tentatively named The Frostburn Update
v1.0.6 will introduce a more powerful signature verification removal mechanism and further improve handling for protected environments; some free 360 protection builds can now be bypassed. This achievement is credited to FPA, developed by the @QToolCI
新版本(v1.0.6)暫預計命名為 霜焰更新
The new version (v1.0.6) is tentatively named The Frostburn Update
MC 技術變革: 表面上像是一次普通的內容更新,但實際上 Minecraft 1.10 更偏向底層細節、穩定性與整體機制補強的技術型版本。對 NPatch 而言,The Frostburn Update 這個名字也象徵著本次更新並不只是表面功能增加,而是一次著重於去簽能力、加固繞過與底層處理強化的版本演進。
MC technical transformation: On the surface, Minecraft 1.10 looked like a regular content update, but in reality it was more of a technical version focused on low-level details, stability, and overall system refinement. For NPatch, the name The Frostburn Update also represents a version that is not merely about visible feature additions, but about stronger signature bypass, protection handling, and deeper low-level enhancements
👍30🔥5❤2🆒2
嗡嗡蜂群 (The Buzzy Bees) 是 NPatch 的一次底層技術革新與穩定性更新。v1.0.5 是嗡嗡蜂群的正式版本,發布於 2026 年 5 月 24 日。此次更新完整實作了 Modern Xposed API 101 基礎設施,新增 native-only 模組入口支援,並全面重構 SigBypass (LV3) 與多項底層邏輯以顯著提升整體的穩定性與相容性。
Modern Xposed API 101 Support
Major Stability & Core Architecture Improvements
Convenience & UX Enhancements
Github Releases
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
Release v1.0.5 The Buzzy Bees · 7723mod/NPatch
The Buzzy Bees (嗡嗡蜂群)
表面上是加入了蜜蜂,但真正重要的是底層技術革新。Minecraft 1.15 不只是內容更新,更是一次以 Blaze3D 重構渲染架構、專注修復與穩定性的技術版本。
On the surface, this was the “bees update,” but its real significance was a deep technical o...
表面上是加入了蜜蜂,但真正重要的是底層技術革新。Minecraft 1.15 不只是內容更新,更是一次以 Blaze3D 重構渲染架構、專注修復與穩定性的技術版本。
On the surface, this was the “bees update,” but its real significance was a deep technical o...
👍11🔥3❤1
shizuku-v13.6.1-RC1.r1148.37e50c83-release.apk
2.5 MB
The recommended Shizuku Fork version
https://github.com/HSSkyBoy/Shizuku
https://github.com/HSSkyBoy/Shizuku
🥰15❤2
After preparation, our first official website is online.
We have compiled detailed guides to help users get started easily.
Welcome to visit.
https://npatch.nkbe.top/
We have compiled detailed guides to help users get started easily.
Welcome to visit.
https://npatch.nkbe.top/
🔥17❤5
libxposed API 102 is currently in the RFC stage. Please provide suggestions on the API design.
https://github.com/libxposed/api/pull/62
https://github.com/libxposed/api/pull/62
GitHub
RFC for API 102 by Dr-TSNG · Pull Request #62 · libxposed/api
libxposed API 102
This PR introduces API 102 across the libxposed module API, service API, annotations, and lint checks.
Module API
Added hot reload lifecycle callbacks for modules with exactly on...
This PR introduces API 102 across the libxposed module API, service API, annotations, and lint checks.
Module API
Added hot reload lifecycle callbacks for modules with exactly on...
👍17❤5
Forwarded from ONPatch
NPatch-v1.0.6-668-release.apk
6.9 MB
665-668
更多說明:
這次更新主要針對的是目前 Android 生態圈中中高強度的加固方案(如 360 加固等)以及深度的環境檢測框架(如 Smallcheck)。這些檢測手段不再僅限於簡單的包名比對或 root 偵測,而是深入到 Linux 核心層與 ART 執行緒。
以下為具體「過掉」的檢測機制解析:
- 將衝突檢查延後到啟動初始化之後執行,確保啟動流程正確
- 修正 LSPlant 的 rwxp 記憶體權限洩漏所導致的環境異常問題
- 提升 seccomp 重導穩定性並更新 NPatch 的 LSPlant 相容性鉤子
- 加強 I/O 與路徑檢測繞過,補齊 APK 可見路徑與 fd 掛載資訊偽裝
更多說明:
這次更新主要針對的是目前 Android 生態圈中中高強度的加固方案(如 360 加固等)以及深度的環境檢測框架(如 Smallcheck)。這些檢測手段不再僅限於簡單的包名比對或 root 偵測,而是深入到 Linux 核心層與 ART 執行緒。
以下為具體「過掉」的檢測機制解析:
1. 提升 seccomp 重導穩定性並更新 LSPlant 相容性鉤子
這個部分的更新主要解決了主動探測防禦與 ART 執行緒逃逸的問題:
過掉「探測性崩潰(Crash-based Probing)檢測」:
- 檢測原理: 偵測會故意向openat等系統呼叫傳入「畸形的路徑」或「不可讀的記憶體指標」。如果你的 seccomp 攔截器(SIGSYS handler)直接去讀取(解引用)這些指標,就會觸發 Segmentation Fault,導致外掛進程崩潰,或者暴露出有工具在攔截 syscall 的事實。
- 繞過方式: 更新後,不再於 SIGSYS 中直接解引用指標,而是先讓核心去驗證該路徑是否合法並打開它,再透過/proc/self/fd解析回傳的 fd。這讓惡意探測無法引發攔截器崩潰,完美隱蔽了 seccomp 重導的存在。
過掉「ART 內聯優化逃逸(Inline / AOT Escape)檢測」:
- 檢測原理: 現代 Android (特別是 Android 8.0+) 的 ART 虛擬機會頻繁利用 ProfileSaver 進行 AOT (Ahead-of-Time) 編譯,並將部分頻繁呼叫的方法「內聯 (Inline)」。一旦目標方法被內聯,呼叫者會直接執行機器碼,不再經過方法的入口點,這會導致 LSPlant 等依賴入口點替換的 Java Hook 失效。防護系統會利用這一點,透過頻繁觸發特定邏輯並檢查執行時間或路徑,來判斷是否被 Hook。
- 繞過方式: 透過安裝 ProfileSaver 相容性鉤子並強制對dex2oat關閉 inline,確保目標方法永遠不會被編譯成無法攔截的內聯狀態。這保證了 Hook 的絕對覆蓋率,過掉了依賴內聯機制的完整性校驗。
2. 加強 I/O 與路徑檢測繞過,補齊 APK 可見路徑與 fd 掛載資訊偽裝
這部分是針對 VFS (虛擬檔案系統) 級別的深度稽查,特別是 Smallcheck 這類極度吹毛求疵的環境檢測工具:
過掉「Java 層 API 交叉比對檢測」:
- 檢測原理: 應用不僅會透過Context.getPackageCodePath()獲取 APK 路徑,還會深入反射讀取LoadedApk、BoundApplication內的ApplicationInfo.sourceDir等欄位,甚至透過java.io.FileAPI 進行交叉比對。如果重導邏輯只覆蓋了表層,底層欄位仍指向你 patch 過的私有目錄,就會被抓包。
- 繞過方式: 啟動後主動將這些深層框架變數恢復為原始 APK 的「可見路徑」,並偽裝 File API,讓所有 Java 層的路徑查詢都得到一致的假象。
過掉「底層 Metadata (中介資料) 檢測」:
- 檢測原理: 防護系統不呼叫 Java,直接透過 native 的stat,lstat,statfs或statx系統呼叫,去查驗 APK 檔案的「大小」、「Inode 節點」、「建立時間」或「磁區資訊」。如果讀取到的是補丁 APK 的資訊,大小和時間絕對與原始 APK 不符。
- 繞過方式: 將 native 檔案 hook 擴充到所有涉及 file stat 的 syscall,強制回傳原始 APK 的 Metadata,讓檔案屬性在檢測工具眼中完美無瑕。
過掉「掛載點特徵 (Mount ID / FD) 深度比對」:
- 檢測原理: 這是 Smallcheck 的拿手好戲。即使你完美偽裝了路徑與大小,檢測工具會去讀取/proc/self/fd/下打開的檔案描述符,並進一步讀取/proc/*/fdinfo/<fd>裡面的mnt_id(掛載點 ID)。如果你的補丁 APK 放在另一個分區(例如某個私有 data 目錄或 OverlayFS),它的mnt_id會與預期中/data/app/目錄所在的mnt_id不同,重導行為直接曝光。
- 繞過方式: 系統動態追蹤被重導的 fd,並在檢測讀取 fdinfo 時,直接將裡面的mnt_id覆寫篡改為「可見路徑(原始 APK)」應該要有的mnt_id。這直接在 VFS 層面阻斷了掛載點異常洩漏的問題。
過掉「虛擬檔案系統 (FUSE) 探測」:
- 檢測原理: 檢查/dev/fuse或相關掛載行為,來判斷系統是否運作在被魔改的模組環境(某些模組會利用 FUSE 來做檔案攔截)。
- 繞過方式: 直接對/dev/fuse的查詢回傳「不存在」,減少異常掛載點暴露的面積。
❤27👍9👾1