5ec1cff
警告:请勿安装近期 ci 版本的 kernelsu 内核或 lkm ,因为存在严重问题(已经安装的请勿卸载管理器)
解释一下这条消息,这是因为有用户安装了 CI 11709 管理器,并且安装了管理器内置的 lkm ,卸载管理器后出现系统卡死的问题,我可以在我的手机(hyperos)上复现。
此前怀疑是新增加的内核主动扫描管理器的机制导致,但目前我无法在其他系统上用 11709 复现该问题,且最新[*]的 ci 11717 在我的手机上也不会出现上述问题。
[*] 最新:截止本消息发出(2024.03.27)为止
此前怀疑是新增加的内核主动扫描管理器的机制导致,但目前我无法在其他系统上用 11709 复现该问题,且最新[*]的 ci 11717 在我的手机上也不会出现上述问题。
[*] 最新:截止本消息发出(2024.03.27)为止
Zygisk-Next-1.1.4-514-1919810-release.zip
1.6 MB
ZygiskNext 1.1.4 正式版
- 内置 Shamiko (以后不需要安装了)
- 内置绕过 Key Attestation
- 支持内核模式
- 支持 Apatch
- 支持 SuperSU
- 支持 KingRoot
- 愚人节快乐!
ZygiskNext 1.1.4 Stable Release
- Built-in Shamiko (no need to install in the future)
- Built-in bypass Key Attestation
- Support running in kernel mode
- Support Apatch
- Support SuperSU
- Support KingRoot
- Happy April Fools' Day!
- 内置 Shamiko (以后不需要安装了)
- 内置绕过 Key Attestation
- 支持内核模式
- 支持 Apatch
- 支持 SuperSU
- 支持 KingRoot
ZygiskNext 1.1.4 Stable Release
- Built-in Shamiko (no need to install in the future)
- Built-in bypass Key Attestation
- Support running in kernel mode
- Support Apatch
- Support SuperSU
- Support KingRoot
Zygisk-Next-1.0.3-287-bd5b40a-release.zip
1.7 MB
ZygiskNext-1.0.3 正式版
- 正式支持 APatch (感谢 @admireng 的协作)
- 增加自动卸载模块模式
ZygiskNext-1.0.3 Stable Release
- Officially supports APatch (Thanks to @admireng for the collaboration)
- Add auto umount module mode
real5ec1cff
- 正式支持 APatch (感谢 @admireng 的协作)
- 增加自动卸载模块模式
ZygiskNext-1.0.3 Stable Release
- Officially supports APatch (Thanks to @admireng for the collaboration)
- Add auto umount module mode
real5ec1cff
新功能 Auto Umount mode 的说明:
Umount ,即卸载/解除挂载模块
None 表示不执行自动模块卸载,对于新安装的用户,这是默认选项
Whitelist 表示除了被授予 root 权限的 app ,其他的都执行卸载
Blacklist :
- 在 KernelSU 中表示对勾选了 umount 的 app 进行卸载(启用全局 umount 选项后,非 root 应用视作勾选了 umount);
- 在 Magisk 中表示对排除列表中的 app 执行卸载;
- 在 APatch 中【待 APatch 开发者提供详细说明】。
Umount ,即卸载/解除挂载模块
None 表示不执行自动模块卸载,对于新安装的用户,这是默认选项
Whitelist 表示除了被授予 root 权限的 app ,其他的都执行卸载
Blacklist :
- 在 KernelSU 中表示对勾选了 umount 的 app 进行卸载(启用全局 umount 选项后,非 root 应用视作勾选了 umount);
- 在 Magisk 中表示对排除列表中的 app 执行卸载;
- 在 APatch 中【待 APatch 开发者提供详细说明】。
Zygisk-Next-1.0.4-292-b36a0ad-release.zip
1.7 MB
ZygiskNext 1.0.4 正式版
- 移除了不稳定的自动卸载模式
- 增加强制排除列表模式
- 清理不需要的配置项
ZygiskNext 1.0.4 Stable Release
- Remove unstable auto umount mode
- Add enforce denylist mode
- Clean up unused configuration items
real5ec1cff
- 移除了不稳定的自动卸载模式
- 增加强制排除列表模式
- 清理不需要的配置项
ZygiskNext 1.0.4 Stable Release
- Remove unstable auto umount mode
- Add enforce denylist mode
- Clean up unused configuration items
real5ec1cff
5ec1cff
Zygisk-Next-1.0.4-292-b36a0ad-release.zip
由于卸载模块这一功能的复杂性,产生了很多问题,因此「自动卸载模块」功能已经在 1.0.4 被移除。为了规范用户的行为,同时也为了保持与原版 zygisk 的设计一致,1.0.4 版本增加了「强制排除列表」功能以取代「自动卸载模块」。
「强制排除列表」类似于 Magisk 的「遵守排除列表」功能,该功能将导致位于「排除列表」中的应用不会加载任何 Zygisk 模块,并卸载已经挂载的模块文件。
对于 Shamiko 用户,本功能不应该开启,如开启将会影响 Shamiko 的正常工作。
该功能默认关闭,KernelSU 用户可以在 WebUI 开启或关闭。Magisk 用户及其他框架用户都可在终端使用命令
排除列表定义:
在 Magisk 上,「排除列表」指 Magisk 内置的排除列表。原版 Magisk 用户可能需要临时打开内置 Zygisk 开关以在 app 中配置排除列表,配置完成后需要关闭 Zygisk 开关。请注意:Magisk App 中的「遵守排除列表」开关并非本功能的开关,请勿试图通过此开关打开本功能。
在 KernelSU 上,「排除列表」指 App Profile 中启用了 Umount 的非 root app 。特别提醒:不要将本功能与「默认卸载模块」同时启用,否则未显式指定不需要 umount 的 app 都将无法加载 Zygisk 模块。
其他细节:
1. 为了正确使用本功能,请在启用的同时仅选择你认为不需要加载模块的 app 添加到 Magisk 的排除列表或打开 KernelSU 的 Umount 开关。
2. 由于已知的问题,对于基于 Chromium 内核的浏览器或使用了 WebView 的应用,将其加入 Magisk 排除列表或对其启用 Umount 可能会导致其崩溃或运行不正常,因此不建议对这类应用开启本功能。如有需要,使用 Shamiko 可满足该需求。
3. 本功能对系统服务无效,Zygisk Next 总是在系统服务加载 Zygisk 模块。
English Translation
「强制排除列表」类似于 Magisk 的「遵守排除列表」功能,该功能将导致位于「排除列表」中的应用不会加载任何 Zygisk 模块,并卸载已经挂载的模块文件。
对于 Shamiko 用户,本功能不应该开启,如开启将会影响 Shamiko 的正常工作。
该功能默认关闭,KernelSU 用户可以在 WebUI 开启或关闭。Magisk 用户及其他框架用户都可在终端使用命令
/data/adb/modules/zygisksu/bin/zygisk-ctl enforce-denylist <enabled|disabled>
开启或关闭。排除列表定义:
在 Magisk 上,「排除列表」指 Magisk 内置的排除列表。原版 Magisk 用户可能需要临时打开内置 Zygisk 开关以在 app 中配置排除列表,配置完成后需要关闭 Zygisk 开关。请注意:Magisk App 中的「遵守排除列表」开关并非本功能的开关,请勿试图通过此开关打开本功能。
在 KernelSU 上,「排除列表」指 App Profile 中启用了 Umount 的非 root app 。特别提醒:不要将本功能与「默认卸载模块」同时启用,否则未显式指定不需要 umount 的 app 都将无法加载 Zygisk 模块。
其他细节:
1. 为了正确使用本功能,请在启用的同时仅选择你认为不需要加载模块的 app 添加到 Magisk 的排除列表或打开 KernelSU 的 Umount 开关。
2. 由于已知的问题,对于基于 Chromium 内核的浏览器或使用了 WebView 的应用,将其加入 Magisk 排除列表或对其启用 Umount 可能会导致其崩溃或运行不正常,因此不建议对这类应用开启本功能。如有需要,使用 Shamiko 可满足该需求。
3. 本功能对系统服务无效,Zygisk Next 总是在系统服务加载 Zygisk 模块。
English Translation
Forwarded from Real Nullptr
We are planning to add new APIs for Zygisk Next, including injecting into more init-started processes. If you have any idea, please comment.
Anonymous Poll
20%
Inject to non-ART process, e.g. drmserver, surfaceflinger, perfd, keystore
12%
Inject to non-zygote ART process
17%
Module hot unload / reload
8%
Companion extension: env info, keep alive flag across soft reboot
7%
Separate code entry with original Zygisk API
10%
Compatible with original Zygisk API as extension
7%
Original Zygisk API is enough
64%
我不是开发者 / I am not a developer
5ec1cff
由于卸载模块这一功能的复杂性,产生了很多问题,因此「自动卸载模块」功能已经在 1.0.4 被移除。为了规范用户的行为,同时也为了保持与原版 zygisk 的设计一致,1.0.4 版本增加了「强制排除列表」功能以取代「自动卸载模块」。 「强制排除列表」类似于 Magisk 的「遵守排除列表」功能,该功能将导致位于「排除列表」中的应用不会加载任何 Zygisk 模块,并卸载已经挂载的模块文件。 对于 Shamiko 用户,本功能不应该开启,如开启将会影响 Shamiko 的正常工作。 该功能默认关闭,KernelSU…
已经移除 apatch 相关说明,因为 apatch 方面目前并未完整实现排除列表功能。如有问题请咨询 apatch 开发者
发现很多人不知道自己用了什么 Xposed 或者 Zygisk 模块导致系统崩溃,触发 ZygiskNext 的防护机制停止工作,然后就来向 ZygiskNext 反馈,看到这种反馈实在烦不胜烦,还是简单普及一下这种错误类型以及应对方法。
触发防护的标志是模块信息显示「❌ Stop inject zygote due to crash.」,这是由于 Zygote 多次重启而停止注入并显示的。一般来说 Zygote 重启都是系统服务崩溃导致的重启,而系统服务崩溃往往发生在更新系统后某些作用于系统的 Xposed / Zygisk 模块未能适配新系统变化而崩溃,典型的例子本频道曾经提过,至今仍然有人反馈,且都是这同一个原因。
希望你们在反馈之前先自行排查是哪一个作用于系统的模块导致的问题。简单的方法是卸载或停用相关的 Xposed / Zygisk 模块,如果卸载或停用某个模块后问题不再发生,则说明是该模块的问题,无需向 ZygiskNext 反馈。
real5ec1cff
触发防护的标志是模块信息显示「❌ Stop inject zygote due to crash.」,这是由于 Zygote 多次重启而停止注入并显示的。一般来说 Zygote 重启都是系统服务崩溃导致的重启,而系统服务崩溃往往发生在更新系统后某些作用于系统的 Xposed / Zygisk 模块未能适配新系统变化而崩溃,典型的例子本频道曾经提过,至今仍然有人反馈,且都是这同一个原因。
希望你们在反馈之前先自行排查是哪一个作用于系统的模块导致的问题。简单的方法是卸载或停用相关的 Xposed / Zygisk 模块,如果卸载或停用某个模块后问题不再发生,则说明是该模块的问题,无需向 ZygiskNext 反馈。
real5ec1cff
顺带一提,Xposed 模块注入系统框架(系统服务)是危险的,不仅容易导致 bootloop ,也存在其他的安全隐患。有些人喜欢用魔改版 LSPosed 的全选作用域,把不该注入的代码注入到系统框架中,这也可能导致全局性的崩溃。
Telegram
小页页的胡言乱语
提醒:作用于“系统框架”的模块可以打破作用域的限制
所谓“系统框架”其实指的就是 system server 进程,其中运行着大量的关键系统服务。虽然应用的进程是由 zygote fork 出来的,但实际上每个应用进程都会先向 system server 注册自己,system server 发回应用的信息,如 apk 路径,然后应用进程继续执行。只要作用于 system server 的模块都有机会篡改这个 apk 路径,打破作用域的限制,向任意应用进程注入代码。
这就完了吗?没有。
如果被注入的应用被授予了…
所谓“系统框架”其实指的就是 system server 进程,其中运行着大量的关键系统服务。虽然应用的进程是由 zygote fork 出来的,但实际上每个应用进程都会先向 system server 注册自己,system server 发回应用的信息,如 apk 路径,然后应用进程继续执行。只要作用于 system server 的模块都有机会篡改这个 apk 路径,打破作用域的限制,向任意应用进程注入代码。
这就完了吗?没有。
如果被注入的应用被授予了…
5ec1cff
由于卸载模块这一功能的复杂性,产生了很多问题,因此「自动卸载模块」功能已经在 1.0.4 被移除。为了规范用户的行为,同时也为了保持与原版 zygisk 的设计一致,1.0.4 版本增加了「强制排除列表」功能以取代「自动卸载模块」。 「强制排除列表」类似于 Magisk 的「遵守排除列表」功能,该功能将导致位于「排除列表」中的应用不会加载任何 Zygisk 模块,并卸载已经挂载的模块文件。 对于 Shamiko 用户,本功能不应该开启,如开启将会影响 Shamiko 的正常工作。 该功能默认关闭,KernelSU…
Due to the complexity of the unmount module feature, many issues arose, so the "Auto Unmount Module" feature has been removed in version 1.0.4. In order to standardize user behavior and also to maintain consistency with the original zygisk design, version 1.0.4 adds the "Enforce Denylist" feature to replace the "Auto Unmount Module" feature.
The "Enforce Denylist" is similar to Magisk's "Enforce Denylist" feature, which causes applications in the "Denylist" to not load any Zygisk modules and unmount already mounted module files.
For Shamiko users, this feature should not be enabled, as enabling it will affect the normal operation of Shamiko.
This feature is off by default, KernelSU users can enable or disable it in the WebUI. Magisk users and other root framework users can use the command
Denylist Definition:
On Magisk, the "Denylist" refers to the built-in denylist in Magisk. Original Magisk users may need to temporarily enable the built-in Zygisk switch in the app to configure the denylist, and after configuration, they need to disable the Zygisk switch. Please note: The "Enforce Denylist" switch in the Magisk app is not the switch for this feature, so do not attempt to enable this feature through this switch.
On KernelSU, the "Denylist" refers to non-root apps with Umount enabled in App Profile. Special reminder: Do not enable this feature together with "Unmount module by default", otherwise apps that have not explicitly specified that they do not need umount will not be able to load Zygisk modules.
Other Details:
1. To use this feature correctly, please select only the apps you think do not need to load modules to add to Magisk's denylist or enable KernelSU's Umount switch.
2. Due to known issues, adding Chromium-based browsers or apps using WebView to the Magisk denylist or enabling Umount for them may cause them to crash or malfunction, so it is not recommended to enable this feature for these types of apps. If needed, use Shamiko to meet this requirement.
3. This feature is ineffective for system server; Zygisk Next always loads Zygisk modules in system server.
中文原文
The "Enforce Denylist" is similar to Magisk's "Enforce Denylist" feature, which causes applications in the "Denylist" to not load any Zygisk modules and unmount already mounted module files.
For Shamiko users, this feature should not be enabled, as enabling it will affect the normal operation of Shamiko.
This feature is off by default, KernelSU users can enable or disable it in the WebUI. Magisk users and other root framework users can use the command
/data/adb/modules/zygisksu/bin/zygisk-ctl enforce-denylist <enabled|disabled>
in the terminal to enable or disable it.Denylist Definition:
On Magisk, the "Denylist" refers to the built-in denylist in Magisk. Original Magisk users may need to temporarily enable the built-in Zygisk switch in the app to configure the denylist, and after configuration, they need to disable the Zygisk switch. Please note: The "Enforce Denylist" switch in the Magisk app is not the switch for this feature, so do not attempt to enable this feature through this switch.
On KernelSU, the "Denylist" refers to non-root apps with Umount enabled in App Profile. Special reminder: Do not enable this feature together with "Unmount module by default", otherwise apps that have not explicitly specified that they do not need umount will not be able to load Zygisk modules.
Other Details:
1. To use this feature correctly, please select only the apps you think do not need to load modules to add to Magisk's denylist or enable KernelSU's Umount switch.
2. Due to known issues, adding Chromium-based browsers or apps using WebView to the Magisk denylist or enabling Umount for them may cause them to crash or malfunction, so it is not recommended to enable this feature for these types of apps. If needed, use Shamiko to meet this requirement.
3. This feature is ineffective for system server; Zygisk Next always loads Zygisk modules in system server.
中文原文
Forwarded from 钱庄 (钱钱)
一直以来,使用了修改系统叠加层(overlay)模块的用户经常遇到这样的问题:浏览器等使用系统 WebView 的应用打不开或白屏。经过试验,发现关闭 MagiskHide / Zygisk 排除列表 / KSU 模块卸载,浏览器就可以正常打开。近期,我们在排查 ZygiskNext 相关问题时做了一番研究,终于梳理清楚了问题根源。
先来了解一下 Zygote 预加载机制。在 Android 世界中,Zygote 是最先启动的进程,正常情况下,所有系统服务进程和应用进程都是从 Zygote fork 而来,并通过 COW(写时复制)机制,复用 Zygote 的部分物理内存,从而提升应用启动速度,减少资源占用。
因此,Zygote 在启动时,会预先加载一些应用普遍需要用到的库和资源,以避免应用启动时重复加载。预加载的内容主要包括 Java 和 Android 常用类、OpenGL 图形驱动、系统共享库、常用字体、系统资源等。注意,这里的系统资源,既包括 framework-res.apk,也包括目标应用为 android 的 overlay apk。
自 Android N 开始,系统增加了 fd 白名单机制,包括 overlay apk 在内的预加载资源需要在 Zygote fork 为 app 时先关闭一次,再打开。如果在打开时,fd 对应的文件不存在,应用将会直接崩溃。
无论是 MagiskHide 还是 Zygisk 排除列表,主要工作都是将额外挂载的文件 unmount 掉,还给用户一个干净的环境。因此,模块挂载的 overlay apk 也会被卸载,但这并不会影响普通应用,因为 Zygote 只会经历一次 fork(Zygote -> app),在重新打开这个环节,fork 仍未完成,overlay apk 仍是存在于相应 namespace 的,因此,应用并不会崩溃。
但对 child zygote(包括app_zygote 和 webview_zygote),情况有所不同:它们是从 Zygote 孵化的,但也可以再次孵化成隔离进程(isolated process)。也就是说,从 Zygote 到隔离进程,需要经历两次 fork。第一次 fork 如前所述,一切正常;在第二次 fork 时,overlay apk 已经在第一次 fork 后被卸载,不存在于相应 child zygote 的 namespace,但 child zygote 仍持有这些进程的文件描述符。因此,在重新打开这一环节,由于 overlay apk 并不存在,应用将会直接崩溃。
怎么修?说到底,这是 Zygote 的默认行为,因此算不上一个 bug。开发者的选择有很多,在此不再赘述。对用户而言,在使用替换 target 为 android 的 overlay 或 framework jar 的模块前要特别注意,当然,使用 Shamiko 可以解决此问题。
此外,前几天发现,某些 KSU 用户在使用了更改 /vendor 的模块后,如果再进行模块卸载,浏览器也出现了打不开的情况。分析 stacktrace 后发现,似乎是预加载的 OpenGL 驱动出现了某些问题,具体原因还在调查。对于这些用户,可以尝试设置 ro.zygote.disable_gl_preload=1 来关闭 OpenGL 预加载,临时规避这个问题。
先来了解一下 Zygote 预加载机制。在 Android 世界中,Zygote 是最先启动的进程,正常情况下,所有系统服务进程和应用进程都是从 Zygote fork 而来,并通过 COW(写时复制)机制,复用 Zygote 的部分物理内存,从而提升应用启动速度,减少资源占用。
因此,Zygote 在启动时,会预先加载一些应用普遍需要用到的库和资源,以避免应用启动时重复加载。预加载的内容主要包括 Java 和 Android 常用类、OpenGL 图形驱动、系统共享库、常用字体、系统资源等。注意,这里的系统资源,既包括 framework-res.apk,也包括目标应用为 android 的 overlay apk。
自 Android N 开始,系统增加了 fd 白名单机制,包括 overlay apk 在内的预加载资源需要在 Zygote fork 为 app 时先关闭一次,再打开。如果在打开时,fd 对应的文件不存在,应用将会直接崩溃。
无论是 MagiskHide 还是 Zygisk 排除列表,主要工作都是将额外挂载的文件 unmount 掉,还给用户一个干净的环境。因此,模块挂载的 overlay apk 也会被卸载,但这并不会影响普通应用,因为 Zygote 只会经历一次 fork(Zygote -> app),在重新打开这个环节,fork 仍未完成,overlay apk 仍是存在于相应 namespace 的,因此,应用并不会崩溃。
但对 child zygote(包括app_zygote 和 webview_zygote),情况有所不同:它们是从 Zygote 孵化的,但也可以再次孵化成隔离进程(isolated process)。也就是说,从 Zygote 到隔离进程,需要经历两次 fork。第一次 fork 如前所述,一切正常;在第二次 fork 时,overlay apk 已经在第一次 fork 后被卸载,不存在于相应 child zygote 的 namespace,但 child zygote 仍持有这些进程的文件描述符。因此,在重新打开这一环节,由于 overlay apk 并不存在,应用将会直接崩溃。
怎么修?说到底,这是 Zygote 的默认行为,因此算不上一个 bug。开发者的选择有很多,在此不再赘述。对用户而言,在使用替换 target 为 android 的 overlay 或 framework jar 的模块前要特别注意,当然,使用 Shamiko 可以解决此问题。
此外,前几天发现,某些 KSU 用户在使用了更改 /vendor 的模块后,如果再进行模块卸载,浏览器也出现了打不开的情况。分析 stacktrace 后发现,似乎是预加载的 OpenGL 驱动出现了某些问题,具体原因还在调查。对于这些用户,可以尝试设置 ro.zygote.disable_gl_preload=1 来关闭 OpenGL 预加载,临时规避这个问题。
5ec1cff
一直以来,使用了修改系统叠加层(overlay)模块的用户经常遇到这样的问题:浏览器等使用系统 WebView 的应用打不开或白屏。经过试验,发现关闭 MagiskHide / Zygisk 排除列表 / KSU 模块卸载,浏览器就可以正常打开。近期,我们在排查 ZygiskNext 相关问题时做了一番研究,终于梳理清楚了问题根源。 先来了解一下 Zygote 预加载机制。在 Android 世界中,Zygote 是最先启动的进程,正常情况下,所有系统服务进程和应用进程都是从 Zygote fork 而来,并通过…
省流:打开 umount 的情况下
1. 有 overlay app 模块(主题模块等)可能会出问题,shamiko 能修
2. 有修改 vendor 模块(驱动等)可能导致 chromium 系浏览器 app 的 opengl 出问题,设置 prop
0. 如果有字体模块,由于字体不会预加载,所以被 umount 的进程找不到字体会崩溃,shamiko 能解决。
当然关闭 umount 也能解决,实际上非必要不建议 umount ,ksu 的全局开关是可以关掉的。
1. 有 overlay app 模块(主题模块等)可能会出问题,shamiko 能修
2. 有修改 vendor 模块(驱动等)可能导致 chromium 系浏览器 app 的 opengl 出问题,设置 prop
ro.zygote.disable_gl_preload=1
解决0. 如果有字体模块,由于字体不会预加载,所以被 umount 的进程找不到字体会崩溃,shamiko 能解决。
当然关闭 umount 也能解决,实际上非必要不建议 umount ,ksu 的全局开关是可以关掉的。
Forwarded from EINVAL
- ZLoader 的 LSPosed 专版,只加载 LSPosed,且只会注入作用域中的应用
建议使用 LSPosed 7058 或更高版本。
- 这是一个非常早期的实验性版本,未经充分测试,可能存在各种奇怪的问题,刷入前请做好处理 bootloop 的准备。
- 与 Zygisk 和 ZygiskNext 冲突
- 需要 Android 12+、GKI 或其它 ebpf 支持较为完整的内核
建议使用 LSPosed 7058 或更高版本。
- 这是一个非常早期的实验性版本,未经充分测试,可能存在各种奇怪的问题,刷入前请做好处理 bootloop 的准备。
- 与 Zygisk 和 ZygiskNext 冲突
- 需要 Android 12+、GKI 或其它 ebpf 支持较为完整的内核
GitHub
GitHub - Mufanc/z-loader: Inject into processes specialized from Zygote
Inject into processes specialized from Zygote. Contribute to Mufanc/z-loader development by creating an account on GitHub.
5ec1cff
- ZLoader 的 LSPosed 专版,只加载 LSPosed,且只会注入作用域中的应用 建议使用 LSPosed 7058 或更高版本。 - 这是一个非常早期的实验性版本,未经充分测试,可能存在各种奇怪的问题,刷入前请做好处理 bootloop 的准备。 - 与 Zygisk 和 ZygiskNext 冲突 - 需要 Android 12+、GKI 或其它 ebpf 支持较为完整的内核
Mufanc 博士最新力作,和 ZygiskNext 作用类似,想体验的可以试试
Why choose z-loader?
🩸 Bleeding edge technology
🕹 Paradigm-changing (no more unsafe code!)
🔥 Blazingly fast
💡 Easy to use
🏆 Featuring way 👋 too 2️⃣ many 🤯 emojis in the 📖 post 🔥 🦀 💨
🦀 Built in 100% memory-safe Rust
P.S. 本频道主不对因使用该模块造成的任何不良后果负责
Why choose z-loader?
🩸 Bleeding edge technology
🕹 Paradigm-changing (no more unsafe code!)
🔥 Blazingly fast
💡 Easy to use
🏆 Featuring way 👋 too 2️⃣ many 🤯 emojis in the 📖 post 🔥 🦀 💨
🦀 Built in 100% memory-safe Rust
P.S. 本频道主不对因使用该模块造成的任何不良后果负责