Zygisk-on-KernelSU-v4-0.8.0-106-release.zip
819.2 KB
Changelog
New mechanism for loading Zygisk without property modifying, in order to provide stronger hiding effects
Drop support for 32 bit applications (zygote 32 will not be injected)
Require SELinux enforced because it is necessary to prevent
Fix compatibility for Magisk (minimal version 26300) and support reading Magisk denylist for
New mechanism for loading Zygisk without property modifying, in order to provide stronger hiding effects
Drop support for 32 bit applications (zygote 32 will not be injected)
Require SELinux enforced because it is necessary to prevent
vold
from aborting Zygisk fuse connectionFix compatibility for Magisk (minimal version 26300) and support reading Magisk denylist for
PROCESS_ON_DENYLIST
flag (currently isolated processes cannot be flagged properly)🥰31👍13👎3🤡1
Shamiko-v0.7.4-188-release.zip
251.6 KB
Changelog
Support new Zygisk loading mechanisms
Fix some issues on Android 11 and below
Fix compatibility for Zygisk on KernelSU on Magisk
Support new Zygisk loading mechanisms
Fix some issues on Android 11 and below
Fix compatibility for Zygisk on KernelSU on Magisk
🔥36👍19👀4👎3🥰1👏1🤡1
I have tested on official Magisk 26302, Alpha 26302 and KernelSU with LSPosed and PlayIntegrityFix working properly. If you have any problem, please make issues on GitHub or join the discussion group to provide detailed logs.
👍49❤2🤡1
Zygisk-Next-v4-0.8.1-111-release.zip
1.4 MB
Changelog
Rename module name to Zygisk Next
Fix crash on Android 10
Add 32 bit support back
Rename module name to Zygisk Next
Fix crash on Android 10
Add 32 bit support back
❤44👍17🤔17👎4🔥4🥰3👏2🤡1
Zygisk-Next-v4-0.9.0-178-release.zip
1002.9 KB
Changelog
No mount needed. Now Zygisk Next is more compatible with some modules. (e.g. systemless hosts)
Recognize Magisk app correctly. Now Zygisk status and modules are no longer displayed as unloaded in Magisk Manager, and modules will not be injected into the Manager.
Requires Magisk 26402+ / KernelSU 11412+.
Guards the peace of Machikado.
No mount needed. Now Zygisk Next is more compatible with some modules. (e.g. systemless hosts)
Recognize Magisk app correctly. Now Zygisk status and modules are no longer displayed as unloaded in Magisk Manager, and modules will not be injected into the Manager.
Requires Magisk 26402+ / KernelSU 11412+.
Guards the peace of Machikado.
🔥45🤡16👍12🥰4🗿3
There's a bug that the module cannot work properly on Android 10, will fix in the next version
👍34🤡14🤯11🕊3❤1
Shamiko-v1.0-290-release.zip
1.9 MB
Changelog
Hide more traces of Zygisk, passing more detection (e.g., ACE, GoTyme Bank, MyTransport.SG, ZainCash, DBS PayLah!, Singpass, Marriott, BPI, Apps using liapp, Apps using Arxan like CaixaBank Sign, etc.)
Better support KSU
Hide some traces introduced by other modules (e.g. PlayIntegrityFix)
Guards the peace of Machikado
Hide more traces of Zygisk, passing more detection (e.g., ACE, GoTyme Bank, MyTransport.SG, ZainCash, DBS PayLah!, Singpass, Marriott, BPI, Apps using liapp, Apps using Arxan like CaixaBank Sign, etc.)
Better support KSU
Hide some traces introduced by other modules (e.g. PlayIntegrityFix)
Guards the peace of Machikado
❤61👍23🤡5🔥3🥰3👏3😁1
总有人跟我扯 Shamiko 开源的事,这就是隐藏类模块不加密的后果,甚至人家都没有开源,只是没加完整性校验。
https://www.coolapk1s.com/feed/52452919
https://www.coolapk1s.com/feed/52452919
👍113🤡9❤3👎3
Zygisk-Next-v4-0.9.1.1-189-release.zip
1014.5 KB
Changelog
1. Fix compatibility on Android 10 and some Magisk variants.
2. Requires Magisk 26402+ / KernelSU (Manager) 11425+.
3. Technical details: Zygisk Next is incompatable with kitsune Magisk's "sulist" feature. This is because Zygisk Next rely on ptrace init to inject into zygote, but it has already been traced by magiskd.
1. Fix compatibility on Android 10 and some Magisk variants.
2. Requires Magisk 26402+ / KernelSU (Manager) 11425+.
3. Technical details: Zygisk Next is incompatable with kitsune Magisk's "sulist" feature. This is because Zygisk Next rely on ptrace init to inject into zygote, but it has already been traced by magiskd.
👍46🤡9❤7🔥3
Forwarded from ✨Reveny's Chat✨
Funny since lsposed is mainly based on edxposed and they didn't mentioned that anywhere
🤡72👍3❤2🍌2
First he copied our open source code and then accused us of being thieves in turn. Then he starts accusing us of not opening source Shamiko because we are not able to behave like Jesus did to forgive all those who modified our packages for commercial use. And finally, he couldn't help but attack and spread rumors directly.
I really don't want to start a war, but seems he enjoys it.
I really don't want to start a war, but seems he enjoys it.
👍72🤣26🔥6😢6🤡5
This is actually why I think open source really sucks sometimes
😢70👍11🤡11🤝6❤3🤔3
Forwarded from 小页页的胡言乱语 (canyie | 愿你开开心心)
公开两个检测 resetprop 的方法:
通过 setprop/getprop 等手段操作property 实际上是操作了位于
更多细节可以查看 https://blog.canyie.top/2022/04/09/property-implementation-and-isolation/
Magisk 的 resetprop 在删除 property 时,会将 prop_bt 中指向 prop_info 的引用置空,然后清空整个
什么时候会发生删除操作?通过 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,而其他隐藏方案的开发者并不知道这两个检测点,也就没有办法处理它,所以我公开了。
通过 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,而其他隐藏方案的开发者并不知道这两个检测点,也就没有办法处理它,所以我公开了。
❤119👍44🤡7