"Inconsistent mount" on Native Test with KSU

[Unb0rn]

I'm trying to run add several systemless modules to the system - for now it's systemless hosts and wireguard cli tools (will probably test aa4mg later too)

Standalone systemless hosts module is detected by Momo, but not detected by Native Test.
After adding Zygisk Assistant, Momo does not detect anything, but Native Test adds "Found Injection" and "Futile Hide (10)" while the mount itself is not detected

But for WireGuard CLI Tools (installed from the app) the situation is different:
Standalone module is not detected by Momo but gets detected by Native Test ("Inconsistent Mount").
Adding Zygisk Assistant changes nothing - Momo still doesn't detect anything and Native Test still detects this "Inconsistent Mount" and adds "Found Injection" with "Futile Hide (10)" as before.

Steps To Reproduce

1. Install WireGuard Command Line Tools module from the official WireGuard app
2. Install ZygiskNext + Zygisk-Assistant
3. Check in Native Detector v24

Context

• Device: OnePlus 9 Pro (lemonadep)

• OS: iode OS 5.0 (Basically LineageOS 21 with MicroG and some privacy features)

• Version of Magisk, KSU or APatch: KernelSU v0.9.3(11804) , path_umount ported and auto unmount seems to be working

• Other Root Module(s): symbuzzer/systemless-hosts-KernelSU-module, WireGuard Commant Line Tools

• LSPosed Module(s): None

Logcat

log.txt

One more thing - maybe it's a good idea to enable GitHub discussions for questions like this - I'm not sure if this is a bug, or WireGuard CLI module has to be changed in some way or maybe even it's my fault?

[snake-4]

Inconsistent Mount is the only issue here, other two are expected since ZygiskNext leaves some traces of the Zygote injection and I haven't really looked into it yet.

Your log doesn't include ZygiskAssistant. Could you try sending another log while using the latest debug version from here?

I feel like I already fixed this in 7cbb41b so the problem might not even happen with the CI build.

[Unb0rn]

That's pretty strange - I think ZygiskAssistant was enabled. The new log is definitely taken after it's been enabled.
log.txt
It is even visible with different results:


(I think it has successfully hidden some properties (part of the ROM I think)

[snake-4]

I still don't see the module in the logs. Can you make sure that you are on a7dd49f-debug? Also ensure that enforce denylist, auto unmount or similar options are disabled in ZygiskNext.

[Unb0rn]

I still use the "old" - FOSS version of ZygiskNext, so no DenyList for me)
But autounmount is enabled for KernelSU modules (should I disable it?)

I can upgrade Zygisk if it's necessary, tho

[snake-4]

You can keep everything as-is except for the module. You're on the release build and not the debug build. The release build doesn't log.

Also, along with the logs, the output of this command will also be helpful: adb shell 'cat /proc/$(pidof icu.nullptr.nativetest)/mountinfo' > mountinfo.txt (app has to be running)

[Unb0rn]

Sorry, my bad - that was pretty obvious)
log.txt
mountinfo.txt
Hope that helps!

[snake-4]

Could you also try without the path_umount port? Also because there's an overlay on /system, #22 also applies here.

[Unb0rn]

Do you want me to rebuild the kernel or I can just disable "unmount by default" in KernelSU?
I think, I can rebuild the kernel without path_umount but in that case we'll need our own blacklist (if it helps, ofc) at some point, as KernelSU docs suggest porting this function and if we don't like it - well, we'll just contradict the docs of the main project.

On this /system and #22 thing - I wonder if merging tiann/KernelSU#1034 would help as it offers bind-mount alongside overlayfs; they also have a corresponding issue open tiann/KernelSU#929 but it's been quiet for quite some time.

Just one more thing - regarding the issue itself - is it correct that everything on /system will have this problem (so https://github.com/sn-00-x/aa4mg will have the same issue)? I feel like it's quite a silly question, but I thought that lemonadep is system-as-root, so both /etc/hosts and /system are on the same partition, and if it's correct - why does the hosts module work fine, while WireGuard doesn't?

Thanks!)

[snake-4]

I can rebuild the kernel without path_umount but in that case we'll need our own blacklist (if it helps, ofc) at some point

That's the idea. KSU unmounts the overlay on /system and causes the same issue that I've referenced. I wrote the denylist check with Magisk Manager in mind, where you can have a denylist that doesn't do anything by itself (i.e. Enforce DenyList option).

I can try making a WebUI for KSU with a separate denylist and ask the users to disable unmount by default but that's for another time. For the time being, the module just uses the denylist of the KSU Manager.

On this /system and #22 thing - I wonder if merging tiann/KernelSU#1034 would help as it offers bind-mount alongside overlayfs

Bind mounts would indeed solve this issue but this is a problem with this module (and KSU because it does the same thing). Also, a lot of modules for KSU just use overlays manually so no, that PR won't completely solve this issue.

so both /etc/hosts and /system are on the same partition

Not just the same partition, /etc on Android is actually a symlink to /system/etc.

why does the hosts module work fine, while WireGuard doesn't?

Systemless Hosts module would mount the overlayfs at /system/etc and Zygote usually doesn't open files from there. So unmounting that overlay doesn't cause any issues.

[HuskyDG]

Inconsistent Mount cannot be fixed

[Unb0rn]

I'm afraid the kernel without path_umount didn't change anything. The log is attached.
log.txt

[privacyguy123]

Inconsistent Mount cannot be fixed

Do elaborate

[Unb0rn]

This may be a bit of offtopic (@snake-4 please consider turning on discussions - I feel a bit wrong about offtoping in an issue)
If I understand it right - KSU just replaces bind mount with overlayfs but the "old" Magisk modules are still compatible so, for example, the WireGuard CLI binaries module is not a separate module, its actually the same package that's being handled differently on KSU and Magisk installations.

So, if we can't do anything on KSU side (or on Zygisk Assistant) - maybe, there's a way to modify the module itself? If so, I'm willing to try. Any help is appreciated.

For me, the problem is pretty simple - I want wg and wg-quick mounted inside /system/bin and several more files (stubs for Google Maps, Google TTS and an XML file with permissions alongside AndroidAuto Stub mounted on /system/product (so AA would work on MicroG installation) without anything detecting those changes - if it's achievable on KSU, I'm willing to try and educate myself, if not - well, that's sad)

[Microwwbin]

When mounting, the first number in each line of mountinfo is increasing one by one, the detector wouldn't show the tip in this time. However, after umount, it would be discontinuous and the detector found exception. So i guess, maybe, is this a check point?

[aviraxp]

Unshare twice cannot guarantee that mnt id is increasing one by one, as there may be some "released" mnt id from system itself's unmount, and other exited apps. Also, it is common that as system itself will do umount as well (especially on some VIVO/OPPO phones) so it is hard to use for detection. Btw, this is not what "inconsistent mount" detects.

[UjuiUjuMandan]

Why would you guys even care about a mysterious proprietary blackbox detector app, and even guess how it works?

The detector app with GNU icon has nothing of documentation, get some Quipucamayocs to decode it please.

[CyanChanges]

When mounting, the first number in each line of mountinfo is increasing one by one, the detector wouldn't show the tip in this time. However, after umount, it would be discontinuous and the detector found exception. So i guess, maybe, is this a check point?

Can we just overwrite the file and make it continuous?

[CyanChanges]

Why would you guys even care about a mysterious proprietary blackbox detector app, and even guess how it works?

The detector app with GNU icon has nothing of documentation, get some Quipucamayocs to decode it please.

According to the update logs in telegram. I guess it is heavily obfuscated and have many anti-debug protection. I guess it's hard to find how they actually detect something.