Porting KernelSU to other Devices

[diabl0w]

This space is dedicated to discussing KernelSU (and derivative) based issues. How do you know if its KernelSU specific issue? In 99% of cases, if DFRoot says "SUCCESS" or "FAILED: ksud exited with error" and you get permissive Selinux but don't have root, then you should be here and not in the Issues section of DFRoot, as DFRoot did its job as intended at that point.
As of v3.0 DFRoot is intentionally independent of KernelSU. Different manufacturers have different kernel exploit mitigations that may require specific changes to official KernelSU for it to work on that device. Aside from starting up the su daemon, DFRoot has zero involvement in that process and zero capability to do anything about that. Those things can be discussed here

[PixelFuck]

this is samsung A14 phone show success but ksud not load kernelsu manager still show jailbreak and phone permessive

[diabl0w]

@snothin

[snothin]

@snothin

i just got the reported logs within the last 30 minutes and successfully handled this device. hold on a second, i'll share the report

[snothin]

Update for SM-A146U (Galaxy A14 5G, MT6833, 6.6.89-android15-8-abA146USQSJEZH3-4k, android15-6.6 KMI):

In addition to the ksu_samsung_kdp_init / ksu_samsung_defex_init handling, this device needs two build-time Kconfig overrides so that the module matches the stock kernel. If either one is left at the DDK default, the module loads and then panics within ~0.1 s — i.e. the "executes, then immediately reboots" symptom.

Kconfig	DDK default	Stock kernel (A14)	Symptom when mismatched
CONFIG_SHADOW_CALL_STACK	y	n	Struct layout is off by 0x10 (task->stack is read at 0x38, device has it at 0x28) → Oops in ksu_sys_enter_handler+0x40 (write to 0x1_0000_3EF0) on the first hooked syscall
CONFIG_CFI_CLANG (KCFI)	y	n	The module carries 47 indirect-call checks (brk #0x822x, across 41 functions) but the kernel has no __cfi type hashes → BRK handler die → panic on the first hit (ksu_samsung_defex_sync_current+0x98, defex creds sync at module init)

Two notes from debugging this:

• CFI can not be fixed with per-function __nocfi: the checks are spread across the whole module (ksu_supercall_handle_ioctl, ksu_wrapper_*, sucompat, …). Even if you dodge the defex call, the next supercall/ioctl/sucompat would trap — it must be disabled for the entire build.
• Both options change ABI/layout/instruction sequences, so the module must mirror the target kernel's settings. Don't disable blindly if your target kernel is built with SCS/CFI enabled.

How to build (DDK — override the two generated files via bind-mount, then build as usual):

sed -i 's@^#define CONFIG_SHADOW_CALL_STACK 1@/* disabled: a14xm SCS=n */@' $KDIR/include/generated/autoconf.h
sed -i 's@^CONFIG_SHADOW_CALL_STACK=y$@# disabled for a14xm@'               $KDIR/include/config/auto.conf
sed -i 's@^#define CONFIG_CFI_CLANG 1@/* disabled: a14xm CFI=n */@'          $KDIR/include/generated/autoconf.h
sed -i 's@^CONFIG_CFI_CLANG=y$@# disabled for a14xm@'                        $KDIR/include/config/auto.conf

(keep CONFIG_KSU_SAMSUNG_KDP=y / CONFIG_KSU_SAMSUNG_DEFEX=y / CONFIG_KSU_RKP_NO_PATCH_TEXT=y; inject the target UTS_RELEASE; empty __versions. If your flow embeds the ko in ksud, rebuild ksud too.)

Pre-flash sanity checks (all green on our build):

• llvm-objdump -d kernelsu.ko | grep -cE 'brk.*#0x822' → 0
• ksu_sys_enter_handler uses ldr x8,[x20,#0x28] + str x19,[x8,#0x3ef0] + str w9,[x8,#0x3fc8], and no [x20,#0x38]
• vermagic contains the device release; __versions size == 0

Status: rebuilt a new ksud (ksud-a14xm, sha256 d561573d0c048e558127d2cd1e6d17280501271514b9920041d7716d1c271d33).

TL;DR — on this device the module must be built with SCS=n + CFI=n, on top of the KDP/DEFEX switches.

Quick note on the ksud-a14xm file I attached, just so it's clear where it came from:

ksud-a14xm.zip

• It's a build I made myself — compiled from my fork.
• The fork is here: https://github.com/snothin/KernelSU
• I went with that branch just for convenience — it pins the version to 32601 and the UAPI version to 2.
• GhostSam can load a ksud of your choice from local storage, so you're free to use your own ksud.

[snothin]

Full write-up is above; TL;DR: this device needs SCS=n + CFI=n build overrides, and the rebuilt ksud is attached (ksud-a14xm.zip).

@PixelFuck — if you can give it a retry on your A14, that'd help a lot. @diabl0w — a look whenever you get a chance. Thanks!

[snothin]

Ghostsam uses the Dirtyfrag exploit to load the custom ksud?

no, it's that when using the Dirtyfrag exploit, you can choose a custom ksud to load

[zandatsu07]

@diabl0w regarding to this #65 (comment) I finally found out why it's not working it's kinda dumb and funny. It happens to be my ksud's hash and manager are not the same. It's a noob mistake I really forgot about these hashes and I created a huge fuss about this issue. Anyways it's working now, I just have to create a keystore in my github to prevent hash mismatches again.

[zandatsu07]

Skill issue 😅

[deathgamer29016]

07-10-2026_22-37-36.mp4

[deathgamer29016]

So what do i do? I mean dfroot, dirtyfrag and root my galaxy next all manage to set selinux to permissive infact with root my galaxy next now shizuku+ says a su binary is detected though kernelsu and termux dont pick it up

[PixelFuck]

=== setup ===
found ko_target: /vendor/lib64/libbinderdebug.so
encap port: 50067
spi: 0x4879c78a

=== exploit (patching files) ===
patch: crash_dump64 <- splicehelper (1408 bytes)
patched 1408 bytes to /apex/com.android.runtime/bin/crash_dump64+0x0
Using KMI: android15-6.6
patch: /vendor/lib64/libbinderdebug.so <- dfroot.ko (8224 bytes)
patched 8224 bytes to /vendor/lib64/libbinderdebug.so+0x0
Finding symbol offsets for /system/lib64/libc++.so:
PACIASP/BTI found at hook site, advancing +4
Found: hook=0xb30ac shellcode=0xfe628 len=468
patch: /system/lib64/libc++.so <- shellcode (480 bytes)
patched 480 bytes to /system/lib64/libc++.so+0xfe628
patch: /system/lib64/libc++.so <- trampoline (16 bytes)
patched 16 bytes to /system/lib64/libc++.so+0xb30a0

=== init ===
Triggering hook...
libc++: loading custom module
kernel module: launching bootstrap
bootstrap: loading app preferences file
bootstrap: cloning zygote env
bootstrap: setting partitions ro
bootstrap: starting SU daemon
ksud start: SUCCESS

=== cleanup ===
restoring trampoline in /system/lib64/libc++.so
log.zip

patched 16 bytes to /system/lib64/libc++.so+0xb30a0
restoring shellcode in /system/lib64/libc++.so
patched 480 bytes to /system/lib64/libc++.so+0xfe628

[PixelFuck]

i have created

[k10halifa]

If you were using the "Root My Galaxy" exploit before trying DFRoot, your issue is likely caused by conflicting leftover modules from the previous root method.

To fix this, you need to completely clean your system first by following these steps:

1. Delete and uninstall all root modules you previously installed.
2. Perform a soft reboot.
3. Perform a full (hard) reboot immediately after to completely clear the system environment.

Once the system is clean, you can try running DFRoot again.

[glitchphantom67696e-dot]

Samsung Galaxy A05 SM-A055F

Android 15
Build: A055FXXSHDZF1
Kernel: 6.6.89-android15-8-abA055FXXSHDZF1-4k
KMI: android15-6.6

DFRoot:
ksud start: SUCCESS
SELinux: Permissive

But KernelSU Manager still shows "Not installed".

What KernelSU changes/build are required for this device?

[glitchphantom67696e-dot]

Why isn't it working even though I've already disabled Auto Soft Reboot?

[deathgamer29016]

Its the same for me. I even tried uninstalling other root apps. Didnt work. Im on the a06 on android 16

[glitchphantom67696e-dot]

It's as if we have to give up—there's no hope left lol