# sidex15/susfs4ksu-module: a KernelSU addon that talks to a SUSFS-patched kernel

> The module ships the ksu_susfs and sus_su userspace helpers into /data/adb/ksu and drives SUSFS kernel-level hiding from a script. It only works if your kernel already carries the SUSFS patch.

**sidex15/susfs4ksu-module** — An addon root hiding service for KernelSU

- Repository: https://github.com/sidex15/susfs4ksu-module
- Stars: 2,595 · Forks: 315
- Language: HTML
- License: AGPL-3.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/sidex15-susfs4ksu-module

## What sidex15/susfs4ksu-module actually does

KernelSU grants root at the kernel level, which makes it harder to detect than a userspace su binary, but the kernel side still leaves traces: mount entries, suspicious paths, and process artifacts that a determined app can look for. SUSFS is a kernel patch that adds hooks for hiding those traces. The patch alone is not enough, because something in userspace has to tell the kernel what to hide.

That is the gap this module fills. The README describes it as "An addon root hiding service for KernelSU" that "installs a userspace helper tool called ksu_susfs and sus_su into /data/adb/ksu and provides a script to communicate with SUSFS kernel." So the audience is narrow and specific: people running KernelSU on a device whose custom kernel has already been built with the SUSFS patch. If your kernel does not have it, this module has nothing to talk to. The README states this plainly: "Make sure you have a custom kernel with SUSFS patched in it. Check the custom kernel source to see if it has SUSFS."

It is not a Magisk module in the usual sense, even though the repository shows up in searches for Magisk modules. The install paths are KernelSU paths.

## How the helper, the scripts and the kernel hooks fit together

The repository layout tells most of the story. The module ships shell entry points that KernelSU executes at fixed stages: post-fs-data.sh, post-mount.sh, boot-completed.sh and service.sh. Alongside them are configuration files that the helpers read: sus_path.txt, sus_maps.txt, sus_mount.txt, sus_open_redirect.txt and sus_path_loop.txt. There is also legit_mounts.txt and try_umount.txt, plus a static kstat descriptor in sus_kstat_statically.json.

The data flow is: a boot-stage script reads those text files, passes the entries to the ksu_susfs binary, and the binary issues the corresponding requests to the SUSFS kernel interface. The kernel then applies the hiding. Two more scripts, susfs-bin-check.sh and susfs-bin-update.sh, handle the helper binary itself, and susfs_reset.sh clears state. uninstall.sh and susfs_reset.sh matter more than they look, because a hiding module that leaves kernel state behind after removal produces exactly the anomalies it was meant to suppress.

Revision 28 of the module corresponds to SUSFS 1.5.2, and the README warns that "the kernel is using SUSFS 1.5.2 or later for effective hide." Kernel and module versions are coupled, so a kernel built against an older SUSFS is a real failure mode, not a theoretical one.

## Installing the module and running a first hide

There is no package manager step. The README points at a nightly CI build and at the releases, and installation is the standard KernelSU module flow: flash the zip, reboot. What follows is verification, which the README supports directly.

Confirm the kernel actually reports SUSFS before you configure anything. The README gives these two commands for checking the kernel identity:

```bash
#This is for the Kernel Version
uname -r
#This is for the Kernel Build
uname -v
```

On a SUSFS kernel the version string carries the patch revision, for example 6.1.75-android14-11-g16c5f6cd5e9b-ab12268515. If the string looks like a stock build, stop here.

The module also creates a directory for devices whose boot hash is not exposed. The README says it "will now have a directory called VerifiedBootHash in /data/adb containing VerifiedBootHash.txt for users with missing ro.boot.vbmeta.digest value to prevent partition modified and abnormal boot state detection." The instruction is to copy the VerifiedBootHash value from the Key Attestation demo into that file. Note the README's own caveat: this path "will be deprecated in the next release and Latest CI."

```bash
cat /data/adb/VerifiedBootHash/VerifiedBootHash.txt
```

A populated file means the value is in place. The README does not document a command-line way to list the active hide rules, so the practical check is behavioural: an app that previously detected root stops doing so after a reboot.

## The kernel dependency is the whole ballgame

The most important limitation is structural. This module cannot hide anything by itself. The README repeats the requirement twice, and the second time it sets a version floor: SUSFS 1.5.2 or later. A device with KernelSU but a stock kernel gets an installed module, helper binaries in /data/adb/ksu, and no hiding, because the kernel side of the interface is absent.

That makes the module the wrong tool for anyone who cannot build or obtain a custom kernel. It is also the wrong tool for Magisk and APatch users, despite the search traffic around those combinations: the install paths are KernelSU's. The README does list compatibility with Shamiko v1.2.1 or later and HideMyApplist, but calls Shamiko "highly optional," and it recommends bindhosts "if you want to use systemless hosts." Those are adjacent tools, not substitutes for the kernel patch.

Second-order risk is version skew. The module tracks SUSFS revisions, and R16 introduced a "Spoof Kernel Build" parameter that the README spends a paragraph explaining because, in its words, "this may confuse some users about what those are." Spoofing uname output changes what apps see, so a mismatch between what you spoof and what the kernel actually is can be worse than not spoofing at all. The README does not document rollback beyond the presence of susfs_reset.sh and uninstall.sh.

## Shamiko and HideMyApplist solve a different problem

Shamiko is the obvious comparison, and the difference is architectural. Shamiko is a userspace denylist enforcement layer: it works alongside Zygisk and manipulates what apps can observe about mounts and root state from userspace. SUSFS, and therefore this module, moves the hiding into the kernel, where the hooks sit below the level an app can inspect.

The README treats them as complementary rather than competing, listing Shamiko v1.2.1 or later as "acceptable (but it's highly optional to use it)." The practical consequence: Shamiko needs a working Zygisk setup and does not require a custom kernel, while this module requires a custom kernel and does not need Zygisk. If you cannot patch a kernel, Shamiko is the realistic option. If you can, kernel-level hiding is the stronger position, because there is no userspace process to detect.

## Licence, updates and what maintenance costs you

The project is licensed AGPL-3.0. If you redistribute the module or a modified version, the AGPL's source-availability terms travel with it; that is a consideration for anyone repackaging it into a ROM or a kernel bundle. This is a description of the licence, not legal advice.

Upgrade cost is tied to the kernel, not the module. Releases are numbered as revisions of a SUSFS version (v1.5.2+_R28, R27, R26), so a module update usually implies a kernel that speaks the matching SUSFS revision. The last push to the repository was on 2026-09-08, and the newest release listed is v1.5.2+_R28 from 2026-07-26. There is an update.json in the repository root, which is the mechanism KernelSU managers use to check for new versions, and a nightly CI badge in the README for builds that are newer than the tagged releases. Running nightly builds alongside a kernel pinned to a tagged SUSFS revision is the fastest way to create a mismatch.

Localisation is a separate maintenance surface. The README asks contributors to use Crowdin for updating existing languages and to submit pull requests only for new ones, adding an XML file named after the language code (en.xml, es.xml) to the webui branch and registering it in ./languages/languages.json. Language update PRs are rejected automatically.

## Conclusion

Adopt this module only if you already run a custom kernel with SUSFS 1.5.2 or later patched in and you are on KernelSU; the module is the userspace half and cannot hide anything on a stock kernel. Skip it if you cannot rebuild or source such a kernel, or if you are on Magisk or APatch, where the module's KernelSU paths do not apply. Before flashing, run uname -r and uname -v to confirm the SUSFS version your kernel reports, and check whether ro.boot.vbmeta.digest is present on your device, because the module expects /data/adb/VerifiedBootHash/VerifiedBootHash.txt when that value is missing.

## FAQ

### What is the purpose of the susfs4ksu-module?

It installs the ksu_susfs and sus_su userspace helpers into /data/adb/ksu and provides scripts that communicate with a SUSFS-patched kernel, giving KernelSU kernel-level root hiding. The kernel patch itself is not included.

### How do I install susfs4ksu-module?

The README points to the nightly CI build and to the tagged releases; installation is the standard KernelSU module flash followed by a reboot. There is no separate install command documented.

### How does susfs4ksu-module relate to hiding KernelSU?

The module is described as an addon root hiding service for KernelSU, operating at the kernel level rather than in userspace. It pairs with the SUSFS kernel patch, and the README also lists Shamiko v1.2.1 or later and HideMyApplist as acceptable companions.

### How do I patch a kernel with SUSFS to use susfs4ksu-module?

The README does not cover patching a kernel. It only says to make sure you have a custom kernel with SUSFS patched in, to check the custom kernel source, and to use SUSFS 1.5.2 or later, and it credits the susfs4ksu repository at gitlab.com/simonpunk/susfs4ksu as the upstream.

## Sources

- [Issues](https://github.com/sidex15/susfs4ksu-module/issues)
- [License: AGPL-3.0](https://github.com/sidex15/susfs4ksu-module/blob/v1.5.2+/LICENSE)
- [README](https://github.com/sidex15/susfs4ksu-module/blob/v1.5.2+/README.md)
- [Releases](https://github.com/sidex15/susfs4ksu-module/releases)
- [sidex15/susfs4ksu-module on GitHub](https://github.com/sidex15/susfs4ksu-module)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sidex15-susfs4ksu-module