公开两个检测 resetprop 的方法：

通过 setprop/getprop 等手段操作property 实际上是操作了位于 /dev/__property__ 下的文件。按 property 各自的 SELinux Context 存储，相同的 context 分为一组，存储在一个文件内。每个文件大小为固定的 128KB。需要使用的 prop_bt prop_info 等对象由一个线性内存分配器实现，每次分配内存时只是简单地 bump 地址，不支持释放内存。
更多细节可以查看 https://blog.canyie.top/2022/04/09/property-implementation-and-isolation/

Magisk 的 resetprop 在删除 property 时，会将 prop_bt 中指向 prop_info 的引用置空，然后清空整个 prop_info 的内存。问题就发生在这里，prop_info 的内存被清空但并没有被释放，这就导致对应内存位置出现一片很大的空区域。通过检测这里，应用可以检测到对应属性区域有属性被删除了，进而推断出设备已经 root（因为正常情况 property 是不支持删除的）。

什么时候会发生删除操作？通过 resetprop 重置 ro 也就是只读属性时。而保存着 bootloader 锁定状态的多个 property 和保存着 native bridge 的 ro.dalvik.vm.native.bridge 还有经常被修改的设备指纹都是只读属性。也就是说，除非避免修改这些属性，否则就会被检测到，而不修改 bootloader 状态的属性又会导致里面直接存着“已解锁”，应用一样可以读到。

在 https://github.com/topjohnwu/Magisk/commit/f41994cb52ca08856216a8da0a28ed148c833f4e 过后，作为副作用，上面的问题刚好被缓解，但还有另一个问题：

prop_info 上有一个字段叫 serial，当这个 prop_info 被更新时，serial 会自增 2。也就是说，prop 被更新的次数 = serial / 2。而对于 ro 属性，它们是只读的，正常情况根本无法被更新，因此 serial 应该始终保持为 0。也就是说，如果发现 serial 不为 0 的只读属性，就代表它被 resetprop 过。

我们调查发现已经有应用在使用这些方法检测 root，Shamiko 1.0+ 已经尽全力隐藏了相关痕迹。我知道有很多人并不愿意使用 Shamiko，而其他隐藏方案的开发者并不知道这两个检测点，也就没有办法处理它，所以我公开了。

笑点解析：已被删评拉黑

Seems that someone is spreading rumors that this event is related to kisune magisk. I have to clarify: NO.

增强检测
调整 Malicious Hook 判断标准，允许 Xposed

具体更新内容：检测未卸载的 Zygisk 模块（可用 lsp 勾选一个模块来测试），强度有点高，可能存在假阳性

修复部分假阳性和闪退

Android 用户态注入与隐藏总结
https://nullptr.icu/index.php/archives/182

添加了一些 trick

之前犯了个低级错误，导致某些检测结果不显示

Changelog
Copyright license change
Minor bug fixes
Experimental: Support Xiaomi tango translator. This function is enabled by default for supported devices (e.g. Xiaomi 14), however it will lead to some performance loss. To disable this function, write 0 to /data/adb/zygisksu/tango

Explanation of article 4 of copyright terms: We do not restrict on continuing development based on the previous fork, while only prohibiting claiming / implying to be the successor. This refers to the trademark, instead of the code.
To be more specific, you are allowed to use such module names: "Zygisk Next Mod", "Zygisk Next Next", etc. However, you are NOT allowed to use "Zygisk Next" without any change. This is similar to Topjohnwu forbidding Magisk forks to release with the name "Magisk".

Changelog
Correctly check whether tango is enabled
Fix a bug causing apps to crash

对 tango 支持的一些说明
- 该功能可在任何设备手动开启或禁用，如果设备无 tango 转译，开启后也可正常注入 32 位 app。
- 开启该功能可能会减慢开机速度。
- 除上一点外，对于无 tango 转译的设备，该功能开关与否应无差别。
- 对于使用 tango 转译的设备的用户，如果没有 32 位 app 注入需求，可以关闭该功能，这不会影响 32 位 app 的正常运行。

某些小丑在开喷之前建议先看看贡献列表有没有 LSPosed 开发组外的任何一个人捏。所有贡献者都同意更改协议，你不同意，你算老几？张口开源奶嘴，闭口隐私巨婴，你也不看看从这个项目开源以来我们收到过任何来自“社区”的帮助没？不会真的以为我们是做慈善的吧？不知道的还以为我们是欠了你几个亿要无偿给“社区”写代码还要反过来被“社区”骂。当然你说的很对，一开始选择开源就是最错误的决定，因而亡羊补牢为时不晚。

For jokers who have not even read the GPL license carefully, I suggest that the nozzle at least learn about what copyright is first.
https://www.gnu.org/licenses/gpl-faq.html#DeveloperViolate

Is the developer of a GPL-covered program bound by the GPL? Could the developer's actions ever be a violation of the GPL?
Strictly speaking, the GPL is a license from the developer for others to use, distribute and change the program. The developer itself is not bound by it, so no matter what the developer does, this is not a “violation” of the GPL.

And we also have no restrictions for the commits that was under GPL before the license change.

事情变得更离谱了，甚至有人做了个假的 tg 账号冒充我做出授权

新的 ksu webui 预告