Zygisk & ZygiskNext are detected by Appdome, SingPass

privacyguy123 commented 5 months ago

Describe the bug At this point I have tried many combinations of things to beat this Appdome detection and I cannot make sense of it as installing your module beats one of their apps (Bet365 Authenticator) but not others (Kotaki Bank, Astrapay)

Steps To Reproduce

Install said apps
See popup about Magisk found (on KSU?)
???

Context

Device: S20 FE
OS: Android 13
Version of Magisk, KSU or APatch: KSU 11823
Other Root Module(s): ZygiskNext 1.0.5, Lsposed Mod, personal post-fs-data/service.sh scripts
LSPosed Module(s): Core Patch, Galaxy Max Hz, Hide My Applist, KnoxPatch, MessengerEx, NoVPNDetect, Re: Telegram, Settings Firewall, Update Locker. Before you say it, all of these modules on or off yields same results.

I see that your module is also detected as "Futile Hide" inside Native Test v24

privacyguy123 commented 5 months ago

mountinfonew.txt

snake-4 commented 5 months ago

Both detections are caused by ZygiskNext. It's not a bug.

privacyguy123 commented 5 months ago

Both detections are caused by ZygiskNext. It's not a bug.

I was hoping for more information as to why, if we are exhaustively hiding everything possible?

privacyguy123 commented 4 months ago

Some conversations had relating to this, not taking any credit ... but perhaps you can use this to help hide this particular detection:

I don't know the secret yet but I bet it is related to zygote/system_server process, somehow the mountinfo data is cached for one of those process, and mayber user can compare the cached mountinfo data and the current mountinfo data. 

but the leaked mountinfo cached by zygote/system process is already a sign that app can check more in memory the same way

Experienced KSU dev confirms it here:

And i can tell you it is the cache simo find (referring to simonpunk author of messages above)

snake-4 commented 4 months ago

Thanks for the information. One thing I've noticed is that with both ZygiskNext and Zygisk, there's always an extra read-write jit-cache mapping even after all modules are dlclose. I think they might be checking for this.

aviraxp commented 4 months ago

Thanks for the information. One thing I've noticed is that with both ZygiskNext and Zygisk, there's always an extra read-write jit-cache mapping even after all modules are dlclose. I think they might be checking for this.

That item is libzygisk itself. It shouldn't be there if Zygisk itself is unloaded.

snake-4 commented 4 months ago

That item is libzygisk itself. It shouldn't be there if Zygisk itself is unloaded.

This time it's not libzygisk, it's Zygote. I can confirm that all segments of it are unmapped correctly. You can see for yourself on AVD A14 and if you want more information, you can compile ART with debug logs.

This has been on my to do list for quite a while but I'm just busy.

aviraxp commented 4 months ago

That item is libzygisk itself. It shouldn't be there if Zygisk itself is unloaded.

This time it's not libzygisk, it's Zygote. I can confirm that all segments of it are unmapped correctly. You can see for yourself on AVD A14 and if you want more information, you can compile ART with debug logs.

This has been on my to do list for quite a while but I'm just busy.

I cannot reproduce it on Android 14. Also jit-cache maps can vary a lot across devices and environments.

Mind posting maps with and without zygisk?

snake-4 commented 4 months ago

@aviraxp Existing Zygisk implementations do something to the memfd. Could it be because they alter the file size to the module's size when they write the module to it? Both Magisk and Zygisk Next do this.

The following environment will allow you to reproduce this behavior consistently:

Google Play Intel x86_64 Atom System Image API=34 rev=13
bzImage https://github.com/tiann/KernelSU/actions/runs/8856457010/ SHA1=C9065682536D3132459DCA3C356D15B30444E5D1
Zygisk Next (tested v4-0.9.1.1 through 1.0.5) or stock Zygisk on Magisk (tested 27.0)
Any Zygisk module

# Zygisk disabled
$ adb shell 'su -c grep jit-cache /proc/$(pidof com.android.chrome)/maps'
56e62000-58e62000 r--s 00000000 00:01 309                                /memfd:jit-cache (deleted)
58e62000-5ae62000 r-xs 02000000 00:01 309                                /memfd:jit-cache (deleted)
7fcea6c00000-7fceaac00000 rw-s 00000000 00:01 309                        /memfd:jit-cache (deleted)
# Zygisk enabled
$ adb shell 'su -c grep jit-cache /proc/$(pidof com.android.chrome)/maps'
56e71000-58e71000 r--s 00000000 00:01 1478                               /memfd:jit-cache (deleted)
58e71000-5ae71000 r-xs 02000000 00:01 1478                               /memfd:jit-cache (deleted)
7043e67db000-7043e87db000 rw-s 00000000 00:01 1478                       /memfd:jit-cache (deleted)
7044395e8000-70443b5e8000 rw-s 02000000 00:01 1478                       /memfd:jit-cache (deleted)

For testing purposes, I've also attached the following module compiled:

#include <unistd.h>
#include "zygisk.hpp"
using namespace zygisk;
class Module : public ModuleBase {
    void onLoad(Api *api, JNIEnv *env) override { this->api = api; }
    void preAppSpecialize(AppSpecializeArgs *args) override { api->setOption(Option::DLCLOSE_MODULE_LIBRARY); }
    void preServerSpecialize(ServerSpecializeArgs *args) override { api->setOption(Option::DLCLOSE_MODULE_LIBRARY); }
    Api *api;
};
REGISTER_ZYGISK_MODULE(Module)

dummy-module.zip

aviraxp commented 4 months ago

JIT shares dual view mapping: https://android.googlesource.com/platform/art/+/master/runtime/jit/jit_memory_region.cc#111

In theory, there should be two rw jit-cache mapping, one for non-executable code cache, and one for writable data cache. Maybe when there is no zygisk, these two sections are somehow continuous, thus we can only see one in maps. This may be due to the implementation of mmap and linker.

I tested a few real devices, still cannot reliablely produce this behaviour.

@aviraxp Existing Zygisk implementations do something to the memfd. Could it be because they alter the file size to the module's size when they write the module to it? Both Magisk and Zygisk Next do this.

The following environment will allow you to reproduce this behavior consistently:

Google Play Intel x86_64 Atom System Image API=34 rev=13

bzImage https://github.com/tiann/KernelSU/actions/runs/8856457010/ SHA1=C9065682536D3132459DCA3C356D15B30444E5D1

Zygisk Next (tested v4-0.9.1.1 through 1.0.5) or stock Zygisk on Magisk (tested 27.0)

Any Zygisk module
# Zygisk disabled
$ adb shell 'su -c grep jit-cache /proc/$(pidof com.android.chrome)/maps'
56e62000-58e62000 r--s 00000000 00:01 309                                /memfd:jit-cache (deleted)
58e62000-5ae62000 r-xs 02000000 00:01 309                                /memfd:jit-cache (deleted)
7fcea6c00000-7fceaac00000 rw-s 00000000 00:01 309                        /memfd:jit-cache (deleted)
# Zygisk enabled
$ adb shell 'su -c grep jit-cache /proc/$(pidof com.android.chrome)/maps'
56e71000-58e71000 r--s 00000000 00:01 1478                               /memfd:jit-cache (deleted)
58e71000-5ae71000 r-xs 02000000 00:01 1478                               /memfd:jit-cache (deleted)
7043e67db000-7043e87db000 rw-s 00000000 00:01 1478                       /memfd:jit-cache (deleted)
7044395e8000-70443b5e8000 rw-s 02000000 00:01 1478                       /memfd:jit-cache (deleted)
For testing purposes, I've also attached the following module compiled:
#include <unistd.h>
#include "zygisk.hpp"
using namespace zygisk;
class Module : public ModuleBase {
    void onLoad(Api *api, JNIEnv *env) override { this->api = api; }
    void preAppSpecialize(AppSpecializeArgs *args) override { api->setOption(Option::DLCLOSE_MODULE_LIBRARY); }
    void preServerSpecialize(ServerSpecializeArgs *args) override { api->setOption(Option::DLCLOSE_MODULE_LIBRARY); }
    Api *api;
};
REGISTER_ZYGISK_MODULE(Module)
dummy-module.zip

privacyguy123 commented 4 months ago

I am far noobier when it comes to this stuff, but I am able to reproduce having this extra jit-cache entry with Zygisk installed on multiple phones. 🤔

nitanmarcel commented 4 months ago

Thanks for the information. One thing I've noticed is that with both ZygiskNext and Zygisk, there's always an extra read-write jit-cache mapping even after all modules are dlclose. I think they might be checking for this.

It's not jit-cache, you can try with my latest artifact

https://github.com/nitanmarcel/ZygiskNext/actions

Also the extra jit-cache seems to be gone with LSPosed disabled

snake-4 commented 4 months ago

Thanks for testing it out everyone. As @aviraxp also said, it's not consistent so I don't think it can be used for detecting Zygisk. I wasn't sure initially because I didn't have enough devices to test this behavior on.

nitanmarcel commented 4 months ago

Actually it's gone now

~ ❱ adb shell 'su -c grep jit-cache /proc/$(pidof com.android.chrome)/maps' 18:46:07 9b090000-9d090000 r--s 00000000 00:05 67301 /memfd:jit-cache (deleted) 9d090000-9f090000 r-xs 02000000 00:05 67301 /memfd:jit-cache (deleted) 76a1f96000-76a5f96000 rw-s 00000000 00:05 67301 /memfd:jit-cache (deleted)

nitanmarcel commented 4 months ago

Thanks for testing it out everyone. As @aviraxp also said, it's not consistent so I don't think it can be used for detecting Zygisk. I wasn't sure initially because I didn't have enough devices to test this behavior on.

yeah. i noticed something in liapp, more specifically in the PixelHunter game. It says that it detected /system/bin/su no idea how since it's umounted, and reseting the path from apatch to something like /debug_ramdisk still makes it detectable in /system/bin/su https://play.google.com/store/apps/details?id=com.zilliongames.hunteridle&hl=en&gl=US

aviraxp commented 4 months ago

Thanks for testing it out everyone. As @aviraxp also said, it's not consistent so I don't think it can be used for detecting Zygisk. I wasn't sure initially because I didn't have enough devices to test this behavior on.

yeah. i noticed something in liapp, more specifically in the PixelHunter game. It says that it detected /system/bin/su no idea how since it's umounted, and reseting the path from apatch to something like /debug_ramdisk still makes it detectable in /system/bin/su https://play.google.com/store/apps/details?id=com.zilliongames.hunteridle&hl=en&gl=US

Don't trust what liapp tells you. Its detection name is often wrong deliberately.

nitanmarcel commented 4 months ago

Thanks for testing it out everyone. As @aviraxp also said, it's not consistent so I don't think it can be used for detecting Zygisk. I wasn't sure initially because I didn't have enough devices to test this behavior on.

yeah. i noticed something in liapp, more specifically in the PixelHunter game. It says that it detected /system/bin/su no idea how since it's umounted, and reseting the path from apatch to something like /debug_ramdisk still makes it detectable in /system/bin/su https://play.google.com/store/apps/details?id=com.zilliongames.hunteridle&hl=en&gl=US

Don't trust what liapp tells you. Its detection name is often wrong deliberately.

Right, it was detecting /system/addon.d

privacyguy123 commented 4 months ago

"2800000 ==MagiskManagerDetected"

Credit goes to ApkUnpacker. Finding this proves useless though, because we don't have Magisk and I personally have all root/Sus apps hidden from this thing. Sharing incase it gets someone else thinking. Is there "heuristics" scanning yet that would detect and app that BEHAVES like Magisk Manager? 🤔

privacyguy123 commented 4 months ago

Thanks for the information. One thing I've noticed is that with both ZygiskNext and Zygisk, there's always an extra read-write jit-cache mapping even after all modules are dlclose. I think they might be checking for this.

It's not jit-cache, you can try with my latest artifact

https://github.com/nitanmarcel/ZygiskNext/actions

Also the extra jit-cache seems to be gone with LSPosed disabled

Maybe not jit-cache then as you've proven but remapping other Zygisk stuff I think could be the key to this detection.

nitanmarcel commented 4 months ago

Fixed in

https://github.com/nitanmarcel/ZygiskNext/commit/3130705e258ca0c9456fcfbb86f35ba27f1830ac

Either wait for the action to finish and download the artifact or install this

Zygisk-Next-v4-0.9.1.1-206-3130705-release.zip

or you can build it yourself, which one makes you feel safer :)

nitanmarcel commented 4 months ago

@privacyguy123 please test :)

nitanmarcel commented 4 months ago

wait something is wrong xD

privacyguy123 commented 4 months ago

I have this one working on stock Zygisk my guy - it's even injected by Lsposed to hide dev options lol. Can we test on the more difficult apps mentioned above? Astrapay and Kotak811 seem to have an "updated" version of Appdome protections.

nitanmarcel commented 4 months ago

I have this one working on stock Zygisk my guy - it's even injected by Lsposed to hide dev options lol. Can we test on the more difficult apps mentioned above? Astrapay and Kotak811 seem to have an "updated" version of Appdome protections.

We can't really fix the detection in the stock ZygiskNext since well, it's closed sourced xD so we start with little steps

privacyguy123 commented 4 months ago

We can't really fix the detection in the stock ZygiskNext since well, it's closed sourced xD so we start with little steps

What I was getting at is that I can get this app to open across old and new versions, so we should test with the problem apps

rddelacosta commented 4 months ago

Fixed in

nitanmarcel/ZygiskNext@3130705

Either wait for the action to finish and download the artifact or install this

Zygisk-Next-v4-0.9.1.1-206-3130705-release.zip

or you can build it yourself, which one makes you feel safer :)

Hi. Could you pls clarify what is being fixed here?

snake-4 / Zygisk-Assistant

Zygisk & ZygiskNext are detected by Appdome, SingPass #24