Imp nohello.cpp

[tryigit]

feat: Advanced path/FD detection and hook-based obfuscation

!!!
I have not tested this and it can cause applications to crash. So test it thoroughly and if it causes errors, backup the code and develop it in a test environment.
It's a better method but it needs to be tested.
I don't test it because I'm interested in root solutions at kernel level
!!!

[MhmRdd]

static const std::set<std::string_view> sensitive_proc_files = { "/proc/mounts", "/proc/self/mounts", "/proc/self/mountinfo", "/proc/modules", "/proc/vmallocinfo", "/proc/kallsyms", "/proc/cpuinfo", "/proc/stat", "/proc/vmstat", "/proc/version", "/proc/cmdline", "/proc/self/cmdline", "/proc/self/status", "/proc/self/maps", "/proc/self/smaps", "/proc/1/maps", "/proc/1/smaps", "/proc/1/cmdline", "/proc/1/status", "/system/build.prop", "/vendor/build.prop", "/default.prop" }; static const std::vector<std::string_view> sensitive_path_keywords = { "magisk", "kernelsu", "apatch", "/data/adb", "riru", "zygisk", "lsposed", "edxposed", "xposed", "shamiko", "supersu", "kingroot", "substrate" };

Why should we block access through sensitive_proc_files or having un-necessary keywords such as kingroot riru supersu
Also why hooking through file operations in zygote?

[tryigit]

static const std::set<std::string_view> sensitive_proc_files = { "/proc/mounts", "/proc/self/mounts", "/proc/self/mountinfo", "/proc/modules", "/proc/vmallocinfo", "/proc/kallsyms", "/proc/cpuinfo", "/proc/stat", "/proc/vmstat", "/proc/version", "/proc/cmdline", "/proc/self/cmdline", "/proc/self/status", "/proc/self/maps", "/proc/self/smaps", "/proc/1/maps", "/proc/1/smaps", "/proc/1/cmdline", "/proc/1/status", "/system/build.prop", "/vendor/build.prop", "/default.prop" }; static const std::vector<std::string_view> sensitive_path_keywords = { "magisk", "kernelsu", "apatch", "/data/adb", "riru", "zygisk", "lsposed", "edxposed", "xposed", "shamiko", "supersu", "kingroot", "substrate" };

Why should we block access through sensitive_proc_files or having un-necessary keywords such as kingroot riru supersu Also why hooking through file operations in zygote?

You can remove them, just ready-made templates.
Many apps still typically look for these filenames, I can reverse engineer it and even if there is this word anywhere it can return a false positive and so it is on my list but it is unnecessary and can affect performance. So you might want to remove it for that reason.

A small correction may be needed here: We do the hooking not directly "inside the Zygote process", but inside the application process that has been forked from Zygote, but before the application code starts running (in the preAppSpecialize phase). This is how Zygisk modules work.

blocking access with sensitive_proc_files and keywords is meant to cut off the most common ways apps gather information and detect rooting. Hooking file operations in the preAppSpecialize phase allows us to manipulate the apps interaction with the file system before it can perform these checks, effectively hiding the presence of root or modifications.

[MhmRdd]

Well, but i haven't noticed any changes before/after patch, except the freezing bug due to close(cfd) in postAppSpecialize, all apps works perfectly with ZygiskNext on my side, except 3 apps.

• SBI Card/Yono: which detects ptrace at /system/bin/init (That's being done by ZN & ReZ)
• NativeTest & Built-in Magisk Alpha's Zygisk: Futile Hide(08) > Leak of mountinfo to process with magisk mounted, was done by getmntent() on /proc/self/mounts.
• Risk Detector: 异常挂载/Evil/隐藏挂载 * > Shamiko passes this, NoHello doesn't.

Other than that, there's no known detection method yet.

[tryigit]

Shamiko uses a more aggressive method for /proc. You could do something similar, but it would require a lot of testing.
Apps that try to detect mountnamespace itself are normal

NativeTest & Built-in Magisk Alpha's Zygisk: "Futile Hide(08) > Leak of mountinfo to process with magisk mounted, was done by getmntent() on /proc/self/mounts

The call to is_path_sensitive("/proc/self/mounts") should return true because /proc/self/mounts is in the sensitive_proc_files list and the hooked_fopen function should return nullptr and set errno to EACCES.
Why might there still be leaks?
getmntent() may not be using fopen: The getmntent() function usually uses fopen in the standard C library, but the version or implementation of the C library used by the application or test tool may differ. It may be that it directly hooks the open syscall (which NoHello does not hook in this patch) and then reads the file with read.
Hook Timing/Effectiveness: The PLT hook is not active for that library at the time NativeTest does this check, or mount hiding in nocb_instance (which is triggered by unshare or setresuid) is not fully completed before the getmntent call. If the application reads the mounts before these triggering syscalls, the original (unhidden) mount information will be visible.
Mount Namespace may not have been cleaned thoroughly: Unmount operations may not have been completely successful or may have left some traces, which getmntent() can still catch.

Anyway, what I'm sending you right now is a pull request, just more flexibility, I haven't tested it but basically you have to implement it. You can reject it and write separate code, just understand the logic

[MhmRdd]

I tried it, and no hope, there's something wrong with the detection of leaked mountinfo in Magisk's built-in zygisk.

And for finding anomalies I'm planning to make a sort of a rule system with default settings, so when the user uses magic mount to install whatever modification he submits to the system, he can add an entry to the configuration and it will take effect instantly, instead of modifying to add redundant paths.

[tryigit]

I tried it, and no hope, there's something wrong with the detection of leaked mountinfo in Magisk's built-in zygisk.

And for finding anomalies I'm planning to make a sort of a rule system with default settings, so when the user uses magic mount to install whatever modification he submits to the system, he can add an entry to the configuration and it will take effect instantly, instead of modifying to add redundant paths.

Good idea, but if you still want to over-develop this project, use Strace
However, it can be bypassed as long as it is not closed source.