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

TL;DR: If a native root detector still reports modifications, first check whether your root manager actually unmounts modules for that app. Use susfs only when mount or path traces remain and your device has a compatible SUSFS-patched kernel. The userspace module alone cannot add support, and no configuration guarantees banking-app or Play Integrity acceptance.

Native detectors can inspect Linux mounts, namespaces, files and kernel-exposed metadata without relying on Android’s ordinary Java APIs. In practice, a failed detection test does not automatically mean you need a different kernel: incomplete module unmounting, an incorrectly scoped app profile or a detectable custom ROM is often responsible. Start with the least invasive fix, verify each change, and consider susfs only after identifying evidence that it can address.

By the PrivacyPortal team

Last updated July 2026. This guide applies only to devices you own and control.

What susfs does

SUSFS is a kernel-level concealment system originally developed around KernelSU. Its name refers to a “su system filesystem”. A supported implementation can alter what selected applications see when they inspect paths, mount entries, symbolic links and certain filesystem metadata associated with root or systemless modifications.

This matters because native Android code can read information exposed by the Linux kernel. A root manager may deny an app permission to obtain root while still leaving observable mounts or modified paths. SUSFS can conceal selected evidence closer to its source, before it reaches the detecting process.

SUSFS has two essential parts:

• A kernel built or patched with compatible SUSFS support.
• A userspace companion module that configures the kernel feature and supplies hide rules.

Installing only the userspace module does not patch the kernel. If the kernel lacks support, the module may install without producing the intended concealment—or it may report an unsupported feature, depending on the build.

The SUSFS project separates kernel support from its userspace configuration layer; installing the userspace companion cannot add the missing kernel implementation.

Image caption: SUSFS sits between a selected application and the kernel information that would otherwise expose modified paths or mounts.

Check hide unmount before changing the kernel

“Hide unmount” means placing a selected application in a mount namespace where root modules and systemless overlays have been unmounted. A mount namespace is the process-specific view of attached filesystems. When unmounting works correctly, the app should see something closer to the stock filesystem layout.

A detector can still find modifications when:

• The detector was not selected in the root manager’s app profile.
• A companion service, isolated process or secondary package was omitted.
• A module remounted a path after the hiding mechanism ran.
• The app was already running when its profile changed.
• Zygisk or another injection framework remains visible to native code.
• The ROM, boot state or device properties expose modifications unrelated to root mounts.

Force-stop the detector and clear it from recent tasks after changing its profile. Rebooting is more reliable when testing mount behaviour because it removes stale processes and reconstructs namespaces in a known order.

KernelSU-family managers normally restrict root access by default, while Magisk relies more heavily on explicit DenyList configuration. Neither behaviour means every modification is automatically invisible. Root authorisation and root concealment are separate controls.

How the available approaches compare

Approach	What it addresses	Kernel change	Main limitation
Root-access denial	Stops an app obtaining superuser permission	No	Does not necessarily hide mounts, files or injection
Per-app module unmount	Removes systemless module mounts from an app’s view	No	Can miss related processes or later remounts
Zygisk deny or exclusion controls	Reduces framework injection into selected app processes	No	Does not conceal every kernel or filesystem signal
SUSFS	Conceals configured paths, mounts and supported metadata at kernel level	Yes	Device-specific, experimental and dependent on a compatible kernel
Return to stock	Removes the widest range of root-related modifications	Usually restores stock boot images	May require a wipe and careful bootloader-state handling

The practical decision rule is simple: fix app scoping first, remove unnecessary modules second, and investigate susfs only if repeatable tests still expose mount or path evidence. If a detector instead objects to an unlocked bootloader, custom signing keys or failed attestation, SUSFS is not a universal remedy.

Prerequisites and risks

Back up everything before proceeding. Copy photos, documents, authentication recovery codes and app data to storage that does not depend on the phone. Bootloader unlocking wipes user data on compliant Android devices. Kernel flashing can also leave a device unable to boot, so keep the correct stock boot or init_boot image and the manufacturer’s recovery procedure available on another computer.

The Android Open Source Project documents that changing a device into the unlocked bootloader state performs a factory data reset.

Review the official Android bootloader locking and unlocking documentation before modifying the boot chain.

You will need:

• An unlockable bootloader and a known recovery route for your exact model and firmware build.
• A supported root manager, commonly KernelSU Next or another compatible KernelSU fork.
• A kernel explicitly built with SUSFS support for your device and current Android firmware.
• The matching SUSFS userspace companion module.
• ADB and Fastboot from current Android SDK Platform Tools, where the device’s flashing procedure uses them.
• Sufficient charge and a reliable USB cable.

Do not flash a kernel merely because its filename mentions GKI, KernelSU or SUSFS. GKI, the Generic Kernel Image architecture, improves reuse across devices but does not make every image interchangeable. The wrong kernel, security-patch level, compression format or boot-image layout can cause a boot loop or loss of hardware functions.

KernelSU Next 1.0.9 also requires a sufficiently recent GKI kernel build, commonly identified as build 12785 or newer in community guidance. Devices on an older supported kernel may require manager 1.0.8 instead. Confirm the current upstream requirements rather than treating a manager downgrade as a universal fix.

Consult the official KernelSU installation documentation and your device maintainer’s instructions before flashing anything.

How to troubleshoot and use susfs safely

1. Create and test your backup. Confirm that important files open from the backup location. Record the exact device model, Android build number, kernel version, active slot and root-manager version. Download the matching factory image before changing the kernel.
2. Establish a baseline. Disable unnecessary root modules, reboot, and run the native detector once. Record its exact findings rather than relying on a single pass/fail result. Screenshots or exported logs help distinguish mount traces from bootloader, ROM or attestation findings.
3. Configure the app profile. In KernelSU Next or the installed root manager, deny the detector root access and enable the available per-app module-unmount option. Include related packages or processes only when you can identify them safely. Do not place core Android services into experimental hide profiles without understanding the consequences.
4. Restart the target cleanly. Force-stop the detector, then reboot. Run it again before adding anything. If the relevant mount or path finding disappears, stop here: a kernel change adds risk without a demonstrated benefit.
5. Confirm genuine kernel compatibility. Obtain a kernel specifically maintained for your exact model, firmware and root-manager branch. Its release notes must explicitly state compatible SUSFS support. On non-GKI devices, support generally requires building the device kernel from source with the appropriate patches; a generic image is not a substitute.
6. Follow the maintainer’s flashing method exactly. Some devices patch or flash boot; others use init_boot, vendor_boot or a dedicated kernel installer. Do not translate instructions from another model. Keep the stock image ready and do not relock the bootloader while modified images remain installed.
7. Verify the new kernel before installing modules. Boot Android, check that cellular service, Wi-Fi, cameras and storage work, then open the root manager. Confirm that its kernel status reports the expected version and explicit SUSFS capability. If support is absent, restore the correct stock image rather than repeatedly installing the userspace module.
8. Install the matching userspace companion. Use the SUSFS module named in the “Modules, apps & files to try” section supplied with this guide. Confirm that its release branch matches the kernel integration and root-manager family. Reboot after installation.
9. Apply the smallest useful hide scope. Enable SUSFS handling only for the target app profile and the specific supported categories needed to address the recorded finding. Broad rules make troubleshooting harder and may conceal information from tools that legitimately need it.
10. Verify with controlled tests. Re-run the same detector under the same conditions. Confirm that the original mount or path finding has changed, then test ordinary functions such as calls, updates and app launches. A detector passing is evidence about that detector only; it is not proof that the device is stock or undetectable.

Image caption: Record detector findings before and after each isolated change so that a genuine improvement is distinguishable from a stale process or random result.

What actually goes wrong in practice

The most common failure is a version mismatch. A kernel may contain one SUSFS revision while the userspace module expects another. Symptoms include an unsupported-feature message, missing controls, ineffective rules or a boot-time module failure.

Other recurring pitfalls include:

• Installing a SUSFS module on a stock or unsupported kernel and expecting it to provide kernel functionality.
• Flashing a GKI image built for a different kernel generation or Android security-patch level.
• Testing without force-stopping the app, leaving an old process and namespace alive.
• Changing several modules simultaneously, making the responsible component impossible to identify.
• Assuming every detection result concerns root when it actually concerns a custom ROM, unlocked bootloader or device certification.
• Relocking the bootloader with non-stock or incorrectly signed images, which can make the device unbootable.
• Accepting opaque binaries from reposting channels instead of checking the maintainer and release provenance.

Use the official SUSFS project repository to examine current source, compatibility notes and supported features. Community packages can be convenient, but their kernel base, patches and update cadence still need independent verification.

As of 16 July 2026, SUSFS remains an experimental concealment layer, not a guarantee of acceptance by Play Integrity, Google Wallet, a banking app or any other specific service.

Image caption: A safe recovery kit includes the exact factory image, current Platform Tools, a charged computer and model-specific flashing instructions.

Security, banking apps and Android updates

SUSFS changes what selected processes can observe; it does not make a rooted device inherently secure. Root modules execute with extensive privilege, and an untrusted module can compromise credentials or alter the operating system. Install as few components as possible, prefer reproducible open-source projects, and review updates before applying them.

Banking and payment apps use different combinations of local detection, server-side risk signals, Play Integrity and account history. A setup that works for one app, device or week may fail after an app or backend update. No responsible guide can promise that susfs will defeat a particular institution’s checks.

Over-the-air updates may replace the patched boot or kernel image, fail because partitions differ from stock, or leave root unavailable after reboot. Restore the required stock images and follow the device maintainer’s documented update path. Never relock the bootloader until every required partition is genuinely stock and the device boots correctly.

If reliability matters more than modification, returning fully to stock is the lower-maintenance choice. Readers choosing their next device can also explore PrivacyPortal’s guide to de-Googled Android phones, where privacy is approached through a supported operating-system configuration rather than root concealment.

Frequently asked questions

Can I install susfs as an ordinary Magisk module?

Not by itself. A userspace module can configure SUSFS only when the running kernel already contains a compatible implementation. Magisk does not automatically provide that kernel support. Compatibility depends on the device kernel, patch set and integration used by its maintainer.

Why does a native detector still find modifications after root is denied?

Denying root prevents the app from receiving superuser permission, but it may still observe module mounts, injected libraries, modified properties, an unlocked bootloader or custom-ROM characteristics. Check the detector’s individual findings and verify per-app module unmounting before changing the kernel.

Does susfs make Play Integrity pass?

No guaranteed relationship exists. Play Integrity evaluates signals beyond visible filesystem paths, and Google can change its server-side decisions. SUSFS may conceal certain local traces, but it cannot promise any Integrity verdict or continued acceptance by an app.

Is KernelSU Next required?

No single root manager suits every device. SUSFS is commonly integrated with KernelSU-family kernels, including KernelSU Next and SukiSU Ultra, but support must be explicit. Choose the branch maintained for the device rather than switching solely because another user reported better hiding.

Can I use susfs without unlocking the bootloader?

Ordinary consumer devices generally require an unlocked bootloader to boot a modified kernel, unless the manufacturer provides another authorised development mechanism. Unlocking normally wipes data and can affect warranty support, device security, updates and app compatibility.

How do I remove susfs?

Disable or uninstall the userspace companion first and reboot. To remove kernel support and root completely, restore the exact stock images required by the device’s firmware. Verify a clean boot before considering bootloader relocking; relocking with incompatible modified images can brick the device.