Native Root Detector Still Finds Modifications? Check Hide Unmount and SUSFS

TL;DR: If Native Root Detector still finds modifications, first check KernelSU’s “Umount modules” setting for that app. Then check “Umount modules by default”. If mount traces remain, susfs can hide supported paths, mounts and metadata at kernel level. Neither option guarantees that banking apps will work.

Native detectors inspect more than installed apps or Play Integrity results. They may find systemless mounts, root binaries, Zygisk traces, altered boot state and other signs of modification. KernelSU’s unmount controls can remove module mounts from an app’s view. A compatible susfs kernel adds deeper, feature-specific handling. Results still depend on the device, kernel, root manager and target app.

By the PrivacyPortal team

Last updated 15 August 2026. This guide covers devices you own and control. Back up all important data before changing a kernel or boot image. Unlocking the bootloader wipes user data on most Android devices.

What Native Root Detector is actually finding

Android Native Root Detector runs checks through native code. Native code is compiled for the device processor. It can inspect parts of Android that simple Java-based checks may miss.

The detector may report suspicious paths, mounted module files, Zygisk, Tricky Store or an unlocked bootloader. It may also notice inconsistent boot information. Hiding a root manager’s icon does not remove these technical signals.

Android Native Root Detector v7.3.1 is the verified release used for this guide. Test results from older versions may differ.

Android Native Root Detector v7.3.1 checks for modifications through native code, including signals that app-list hiding cannot conceal.

Caption: A Native Root Detector results screen separates mount, boot-state and root-framework findings.

An “Abnormal” result is useful evidence, not a final verdict. A working app may coexist with a detector warning. Another app may refuse to run despite apparently clean test results. Each app can use its own checks and server-side risk rules.

What “Hide Unmount” means in KernelSU

“Hide Unmount” is community shorthand. Current KernelSU interfaces use the labels Umount modules and Umount modules by default.

Systemless root modules expose changed files through mounts. “Systemless” means Android’s original system partition is not directly rewritten. The replacement files still need to appear somewhere in the live filesystem. A detector can inspect that mount layout.

KernelSU’s per-app “Umount modules” control removes eligible module mounts from the selected app’s view. The default control applies that policy more broadly. This can fix a mount-based finding when the modules support unmounting correctly.

KernelSU calls these controls “Umount modules” and “Umount modules by default” as of 15 August 2026.

Unmounting is not full root concealment. It does not relock the bootloader, restore the stock boot image or remove every kernel change. It may also stop a target app from seeing files that a module provides. That can break features which the app needs.

Where susfs fits into the hiding stack

susfs is a set of kernel changes for handling specific filesystem and system signals linked to root. It can cover supported suspicious paths, mounts and metadata before an app receives them. That is deeper than merely hiding a manager app.

The kernel must be built with compatible support. Installing a userspace module on an unsupported kernel does not add the missing kernel code. At best it will do nothing. At worst it may cause boot trouble or an unstable setup.

KernelSU users normally need both a compatible patched kernel and the matching SUSFS userspace module. SukiSU Ultra provides closer integration on kernels built for it. Follow the kernel maintainer’s exact compatibility notes rather than mixing releases.

The official SUSFS4KSU project repository is the best starting point for its source, supported features and release information.

SUSFS requires kernel-side support; a manager module alone cannot turn an ordinary kernel into a compatible one.

Caption: The hiding stack places app-list controls above module unmounting and kernel-level filesystem handling.

Unmount controls, susfs and other tools compared

Tool or control	Main purpose	Can address	Cannot guarantee
KernelSU “Umount modules”	Hide eligible module mounts from selected apps	Some suspicious mount and overlaid-file findings	A clean boot state or app acceptance
susfs	Handle supported filesystem signals in the kernel	Configured paths, mounts and related metadata	Removal of every detection vector
Hide My Applist	Restrict installed-app list queries	Discovery of root managers and related apps	Native mount, kernel or boot-state checks
Play Integrity tooling	Test or influence attestation outcomes	Some integrity-related compatibility issues	Passing a bank’s private checks
Renaming or hiding a manager app	Reduce obvious package-name detection	Simple package-list checks	Native root or filesystem detection

Hide My Applist also requires LSPosed. It only helps when an app queries installed packages. Its official project documentation explains the whitelist and template model.

How to configure KernelSU unmounting and susfs

Use this sequence to change one layer at a time and keep useful test evidence.

1. Back up photos, messages, authenticator recovery codes and your current boot image. Confirm that you can restore the device before proceeding.
2. Record the exact device codename, Android build, kernel version and root-manager version. Do not rely on the retail model name alone.
3. Run Android Native Root Detector v7.3.1 and save its results. Also record whether your required apps currently open.
4. Open KernelSU’s app profile for the detector. Enable Umount modules, then fully stop the detector and clear only its cache.
5. Reboot and test again. If the mount findings disappear, avoid adding more hiding tools without a clear need.
6. If several untrusted apps need the same policy, review Umount modules by default. Check each module because unmounting can remove features from app processes.
7. If supported filesystem findings remain, obtain a kernel built for your exact device and build with compatible SUSFS support. Use only the maintainer’s stated installation route.
8. Install the matching SUSFS userspace module when your KernelSU kernel requires it. SukiSU Ultra users should follow their kernel maintainer’s integrated setup notes.
9. Reboot once more. Confirm that Android starts, storage mounts correctly and core functions work before opening any sensitive app.
10. Retest with the same detector version. Compare individual findings instead of treating one green or red summary as proof.

Prerequisites and files to prepare

You need an unlocked bootloader, a compatible root manager and a recoverable copy of the original boot image. Unlocking the bootloader normally performs a factory reset. Back up first, even if the device was unlocked before.

Prepare Android platform tools, the correct USB driver where needed and a known-good cable. Keep the stock image for the exact installed build. An older image may fail to boot after an over-the-air update.

Look for Android Native Root Detector v7.3.1, KernelSU Manager, a device-specific SUSFS-patched kernel and the matching SUSFS4KSU userspace module in the appended Modules, apps & files to try section. SukiSU Ultra is an alternative only when your chosen kernel explicitly supports it.

Safe kernel installation rules

There is no universal flash command for this change. Devices differ in partition layout, boot header version and recovery support. Some use a boot partition. Others place key kernel data in vendor_boot or another image.

Follow the instructions from the maintainer of your exact kernel build. Verify the device codename and installed Android build before flashing. Do not copy a command from a different phone, even if both use the same processor.

A wrong kernel or boot image can cause a boot loop or a hard-to-recover brick. It can also disable touch, Wi-Fi, cameras or encryption. Warranty support and normal over-the-air updates may be affected.

For readers considering a supported privacy-first setup instead of a rooted one, our guide to what a de-Googled phone changes explains the less fragile route.

How to verify each change

Use the same detector build before and after each change. Keep screenshots and note which setting changed. This makes it possible to reverse a failed test.

• Check that the phone completes two normal reboots.
• Check calls, mobile data, Wi-Fi, Bluetooth, camera and encrypted storage.
• Compare each Native Root Detector category with the baseline.
• Check Play Integrity separately if it matters to your apps.
• Test required apps only after the device is stable.
• Keep a restore plan even when all tests appear clean.

Caption: A simple test log compares baseline findings with unmount-only and kernel-level configurations.

Do not clear an app’s data unless you understand the effect. Banking and authenticator apps may require re-enrolment. Repeated device registrations can also trigger the app’s own security controls.

Common reasons detection remains

The wrong app profile is configured

A per-app unmount rule applies only to the selected package and process scope. Check that the profile belongs to the actual detector package. Cloned apps and work-profile copies can have separate identities.

Force-stop the detector after changing its profile. A process that was already running may retain its previous mount view until it restarts. A full reboot gives a cleaner comparison.

A module does not unmount cleanly

Some modules create files, processes or properties outside the mounts that KernelSU removes. A detector may still find those traces. Disable suspect modules one at a time and reboot between tests.

A large stack is harder to debug. Start with the root manager and the minimum required modules. Add one component per test cycle.

The kernel and userspace module do not match

SUSFS features depend on matching kernel code, manager support and userspace configuration. Mixing a current module with an old kernel patch may leave features unavailable. It may also cause errors during boot.

Check the maintainer’s release notes for the exact kernel build. Do not assume that two packages with similar names are compatible.

The finding is outside filesystem hiding

An unlocked bootloader, altered verified-boot state or hardware-backed attestation result is not merely a hidden path. App-list tools and mount unmounting cannot make those facts genuinely stock.

Some native checks also produce false positives or ambiguous labels. Confirm findings with a second test and normal device behaviour. Passing several detector apps still does not predict every real app.

Security and compatibility trade-offs

Root expands what trusted tools can do. It also increases the impact of a malicious module or a poor configuration. Kernel patches deserve extra care because they operate below normal Android app controls.

Only install signed or reproducibly sourced files from a maintainer you trust. Check hashes where the project publishes them. Avoid repackaged downloads and unexplained bundles shared through chat groups.

Root concealment can make your own security checks less clear. It may also delay updates because a new stock boot image needs fresh kernel support. Restoring stock images incorrectly can cause a boot loop or data loss.

Play Integrity is a separate attestation system. A device can pass some integrity labels while a native detector reports changes. It can also show clean detector results while an app rejects the device. Never assume a setup will defeat a specific bank’s checks.

If stable updates and strong verified boot matter more than root access, a supported privacy-focused operating system may be the better choice. Our GrapheneOS and LineageOS comparison covers the main security and compatibility differences.

A practical decision framework

• Only app-list detection appears: review visible packages and use an app-list control only when justified.
• Only module mounts appear: test KernelSU’s per-app “Umount modules” control first.
• Supported path or mount findings persist: consider susfs only when a trusted kernel exists for the exact build.
• Boot-state or attestation checks fail: do not expect filesystem hiding to solve them.
• The device becomes unstable: restore the known-good kernel or stock boot image before further testing.
• A vital app still refuses to run: use an unmodified device or the provider’s supported access method.

The safest stopping point is often earlier than the cleanest detector screen. A stable phone with one understood warning is better than a fragile stack of overlapping concealment modules.

Frequently asked questions

What is susfs on Android?

susfs is a kernel-level approach for handling supported filesystem signs linked to root. It can alter how configured paths, mounts and metadata appear to selected processes. It needs compatible kernel support and does not make a modified device stock.

Does “Umount modules” hide root completely?

No. It can remove eligible systemless module mounts from an app’s view. It does not relock the bootloader, undo every kernel change or guarantee a clean result from native detection.

Can susfs make every banking app work?

No. Banking apps may combine Play Integrity, native checks, app history and server-side risk signals. Their rules can change without notice. No root-hiding method can promise compatibility with a named bank.

Why does Native Root Detector show abnormal when my apps work?

The detector reports technical signals, while each app applies its own policy. A finding may be irrelevant to one app or may be a false positive. Working today also does not guarantee future acceptance after an app update.

Do I need a patched kernel and a module?

KernelSU setups generally need a kernel built with compatible SUSFS support. They may also need the matching userspace module. SukiSU Ultra can integrate these controls when the device’s kernel build supports that design.

Will changing the kernel affect Android updates?

It can. An over-the-air update may replace the boot image or fail its pre-install checks. Restore the required stock images before updating when the device maintainer says so. Back up data and keep exact build files first.

How do I return to a safer stock setup?

Remove root modules, then restore the exact stock images for the installed build using the device maker’s supported method. Confirm normal boot before considering bootloader relocking. Relocking with incompatible images can brick the device and may wipe data again.