Driver status "Not Found" after installing custom kernel with SusFS (KernelSU + SusFS patch)

[MiyumiKun]

Prerequisites

• I have searched existing issues (both open and closed) and found no duplicate.

• I am using the latest release of the App and driver.

Description

I'm using the ViPER4Android-RE-AIDL fork (https://github.com/likelikeslike/ViPER4Android) on my Xiaomi 13 Ultra (2304FPN6DG) with HyperOS 3.0.302.0 (Android 16, API 36). The driver installation completes successfully (both arm32/arm64 libs are placed, audio configs are patched, audioserver restarts). However, the app always shows "Driver not found" regardless of which driver version I try.

After extensive debugging, I've identified the root cause: my custom kernel includes SusFS (SUSFS — a KernelSU extension that hides root/module traces from detection). SusFS appears to be masking or blocking the audio driver's shared memory (SHM) or the V4A AIDL service communication, preventing the app from detecting the active driver.

The kernel is built for SukiSU Ultra (40839) with KernelSU (40387), SusFS, BBR, Baseband-guard, and the SukiSU patch. SusFS is the only new component that changed before the issue started. Disabling SusFS fixes the problem, but that exposes root detection in banking apps, so it's not an acceptable workaround for me.

I'm reporting this because I believe the V4A driver detection mechanism might need an alternative fallback or a way to work around SusFS's process/fs hiding. I'm happy to provide any additional logs or test builds if needed.

Steps to reproduce

1. Flash a custom kernel with SusFS enabled (any version that hides root/module paths).
2. Install ViPER4Android-RE-AIDL via Magisk/KernelSU module.
3. Open the V4A app → it shows "Driver not found".
4. Reboot, reinstall driver, restart audioserver — no change.
5. Remove SusFS from the kernel or disable its hiding features → driver is detected immediately after a reboot.

App logs

Attached: viper_install.log

The log shows that installation succeeds, all mounts and patches apply correctly, and the audioserver is restarted. The SHM files are created in /data/local/tmp/v4a/ with correct permissions. However, the app still reports no driver.

Effect settings

No effect settings are applied because the driver isn't detected. The app remains in "Disabled" state.

Diagnostic steps

• Checked SELinux (Enforcing) – policy rules are applied via ksud (rc=0).
• Verified library presence: /vendor/lib(64)/soundfx/libv4a_aidl.so both exist and have correct context.
• Verified audio config patches: both /system/etc/audio_effects.xml and /vendor/etc/audio/sku_kalama/audio_effects.xml contain v4a_aidl entries (2 each).
• Confirmed audioserver restarts after mount.
• Manually checked SHM files: /data/local/tmp/v4a/shm_*.bin exist, permissions 666, context shell_data_file.
• Tested with SusFS disabled (by rebuilding kernel without SusFS) → driver works flawlessly.
• Tested with SusFS enabled but with all hiding features turned off → also works. The problem only occurs when SusFS actively hides paths or processes (likely /data/adb/modules or the V4A service itself).
• No errors in logcat related to V4A or audio effects.

Additional context

• Device: Xiaomi 2304FPN6DG (Xiaomi 13 Ultra, 16/512 GB)
• ROM: HyperOS 3.0.302.0 (BP2A.250605.031.A3)
• Android version: 16 (API 36)
• Kernel: 5.15.178 with SusFS patch (custom build)
• Root: KernelSU 4.1.3-43-gb7437fb8 (ksud)
• V4A version: latest AIDL build from the RE fork

I suspect SusFS might be intercepting access to /proc/self/maps, /sys/module, or the SHM file handles that V4A uses to verify the driver is loaded. If there's any debug build or a flag to bypass path checks, I'd be glad to test it.

Thank you for maintaining this great project!

[Vxhxnx]

I found a fix for this : extract all file to a folder, go to post dada fs, edit with text file and add "#" before those lines :

if [ -d "/odm/etc/" ]; then

echo "Binding audio_effects.xml to odm partition..."

mount -o bind /data/adb/modules/ViPER4Android-RE/odm/etc/audio_effects.xml /odm/etc/audio_effects.xml

fi

Then save, rezip, and flash modules. Hopefully it'll work

@MiyumiKun

[Vxhxnx]

[MiyumiKun]

Thank you for such a quick response. I unpacked the module, made the changes, repacked it, installed it, and rebooted the phone. Unfortunately, it didn't work. The app still says "driver not found."
I also tried running it with and without the AIDL module, and it made no difference. "Driver not found"

[Vxhxnx]

You have others modules installing? Which one? Sound related?

[Vxhxnx]

If you have Aml installed, that could be the culprit too

[likelikeslike]

Thanks for the information.

On the AIDL path, the app detects the driver via shared memory: the driver (inside the audio HAL) writes its version into /data/local/tmp/v4a/shm_status.bin, and the app reads that same file. It doesn't touch /proc/self/maps or /sys/module at all.

SusFS's path/mount hiding may make that file resolve to different location for the app vs. the audio HAL, so the driver writes to one view and the app reads another (nothing there).

A possible fix is: add /data/local/tmp/v4a/ to SusFS's un-hide / path allowlist so both processes see the same real file. That keeps SusFS active for banking apps while letting ViPER's SHM work. But I am not sure the feasibility as I don't need to hide root.

[MiyumiKun]

I have 14 modules installed, if you need it, here is the full list of what I have installed:

• bindhosts v2.1.4
• BusyBox for Android NDK v1.36.1
• YouTube Morphe
• HMA-OSS-ZYGISK voss-164
• SusFS Manager v4.0.0(ShirkNeko)
• AlwaysStrong v1.0.2
• Viper4Android RE v2.0.0
• Viper4Android RE (AIDL) v2.0.0
• VPN Tethering Ultra v1.9
• VPN Hide (kernel) v1.1.1
• VPN Hide (Ports) v1.1.1
• LSPosed v2.1.0(LSPosed Developers)
• Zygisk-Derach v1.23.2
• Zygisk Next v1.4.3

I currently have both driver modules installed, but I'm too lazy to uninstall them. If I understand correctly, I need the regular driver, not the AIDL one?
I'll try the method with path resolution that you mentioned and I'll report the result.

[likelikeslike]

You need the AIDL one as you said it works when you disable SusFS. What you need to do is to find a way let SusFS skip hiding /data/local/tmp/v4a/. I don't know the exactly mechanism behind it, you may need to build a custom kernel to exclude it, or there are some configuration files to control the whitelist.

[MiyumiKun]

Yes, I figured that out myself. I'm using a script that compiles the kernel locally on my computer. Apparently, it has some bugs that I'll have to fix. I haven't found a solution to this problem yet, I'm still in the process.
I use the SusFS module because I have applications, including banking ones, from which only this module allows me to hide root traces. If I manage to find a solution, I will write here right away.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. Please reply if it is still relevant.

[MiyumiKun]

I managed to find out the reason for this behavior. The problem was not with SusFS. For reasons unknown to me, my mounting of the OverlayFS meta module has completely broken. A complete reinstallation of all modules, after a clean reinstallation of the meta module, helped restore everything. At the moment everything is working properly, the driver is visible