search

tiann / KernelSU

A Kernel based root solution for Android
https://kernelsu.org
GNU General Public License v3.0
9.92k stars 1.61k forks source link

KSU report "not installed" on installed system, but "installed" on Live boot when using BlissOS #1783

Closed hmtheboy154 closed 3 weeks ago

hmtheboy154 commented 4 months ago

Please check before submitting an issue

Describe the bug

Recent KernelSU version report "not installed" on BlissOS when the OS is installed. On Live Boot, it works normally and report the version on the KernelSU Manager app.

To Reproduce

  1. Get a BlissOS build with recent KernelSU in the kernel & Manager https://sourceforge.net/projects/blissos-x86/files/Official/BlissOS16/FOSS/Go/Bliss-Go-v16.9.5-x86_64-OFFICIAL-foss-20240529.iso/download https://drive.google.com/file/d/1tQAVbIygV4DqEyDpmGxsssF2whASzgK0/view?usp=sharing https://drive.google.com/file/d/19m0UOp70ZiNp74MHNswfjGsyqPdexDWP/view?usp=sharing

  2. Install it on a VM or baremetal

  3. Check KernelSU Manager

Expected behavior

It should work & report the version

Screenshots

image report "not installed" on installed system

photo_2024-05-29_16-04-00 report "installed" on Live boot

image currently where it keep looping

Logs

none, logs on the Manager can not dump anything

Device info

Additional context

According to the screenshot, it's being looped here: https://github.com/tiann/KernelSU/blob/main/kernel/core_hook.c#L189

hmtheboy154 commented 4 months ago

@tiann latest versions are even worse when in Live Boot, even though it said working, granting Termux can't be able to use su command

hmtheboy154 commented 4 months ago

I've downgraded to 0.9.2 and it's actually recognized on installed system, starting to build on 0.9.3 is when the bug start happenening

CanerKaraca23 commented 3 months ago

I've downgraded to 0.9.2 and it's actually recognized on installed system, starting to build on 0.9.3 is when the bug start happenening

Did you tried 0.9.5?

hmtheboy154 commented 3 months ago

I've downgraded to 0.9.2 and it's actually recognized on installed system, starting to build on 0.9.3 is when the bug start happenening

Did you tried 0.9.5?

yes. Even 1.0

hamjin commented 3 months ago

Which dentry is NULL? old_dentry or new_dentry？

hmtheboy154 commented 3 months ago

Which dentry is NULL? old_dentry or new_dentry？

It's been a while so I forgot, I'll check back when I got time

hmtheboy154 commented 4 weeks ago

Update: I pulled KSU to latest commit currently (9bcdff1) and boot in debug mode, it still not recognize the manager. There's some output on the console though

console:/ # dmesg -w | grep KernelSU                                           
[    0.916158] KernelSU: *************************************************************
[    0.916160] KernelSU: **     NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE    **
[    0.917040] KernelSU: **                                                         **
[    0.917878] KernelSU: **         You are running KernelSU in DEBUG mode          **
[    0.918737] KernelSU: **                                                         **
[    0.919624] KernelSU: **     NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE    **
[    0.920658] KernelSU: *************************************************************
[    0.922675] KernelSU: sucompat: execve_kp: 0
[    0.924856] KernelSU: sucompat: newfstatat_kp: 0
[    0.925533] KernelSU: sucompat: faccessat_kp: 0
[    0.926440] KernelSU: sucompat: devpts_kp: 0
[    0.926519] KernelSU: ksud: execve_kp: 0
[    0.927568] KernelSU: ksud: vfs_read_kp: 0
[    0.928789] KernelSU: ksud: input_event_kp: 0
[    3.527695] KernelSU: /system/bin/init argc: 2
[    3.527698] KernelSU: /system/bin/init first arg: selinux_setup
[    4.690941] KernelSU: /system/bin/init argc: 2
[    4.690943] KernelSU: /system/bin/init first arg: second_stage
[    4.690943] KernelSU: /system/bin/init second_stage executed
[    4.690957] KernelSU: SELinux permissive or disabled, apply rules!
[    4.697879] KernelSU: android context saved disabled
[    4.885659] KernelSU: /system/bin/init argc: 4
[    4.891864] KernelSU: vfs_read: /system/etc/init/atrace.rc, comm: init, count: 1024, rc_count: 351
[    4.892422] KernelSU: read_iter_proxy append 673 + 351
[    4.892429] KernelSU: unregister vfs_read kprobe: 1!
[    4.892434] KernelSU: unregister vfs_read kprobe: 0!
[    4.892436] KernelSU: unregister vfs_read kprobe: 0!
[    4.892437] KernelSU: unregister vfs_read kprobe: 0!
[    4.892458] KernelSU: unregister vfs_read kprobe: 0!
[    4.892465] KernelSU: unregister vfs_read kprobe: 0!
[    4.892468] KernelSU: unregister vfs_read kprobe: 0!
[    4.892470] KernelSU: unregister vfs_read kprobe: 0!
[    4.892473] KernelSU: unregister vfs_read kprobe: 0!
[    4.892478] KernelSU: unregister vfs_read kprobe: 0!
[    4.892480] KernelSU: unregister vfs_read kprobe: 0!
[    4.892491] KernelSU: unregister vfs_read kprobe: 0!
[    4.892493] KernelSU: unregister vfs_read kprobe: 0!
[    4.892498] KernelSU: unregister vfs_read kprobe: 0!
[    4.892500] KernelSU: unregister vfs_read kprobe: 0!
[    4.892502] KernelSU: unregister vfs_read kprobe: 0!
[    4.892504] KernelSU: unregister vfs_read kprobe: 0!
[    4.892513] KernelSU: unregister vfs_read kprobe: 0!
[    4.892515] KernelSU: unregister vfs_read kprobe: 0!
[    4.892516] KernelSU: unregister vfs_read kprobe: 0!
[    4.892520] KernelSU: unregister vfs_read kprobe: 0!
[    4.892525] KernelSU: unregister vfs_read kprobe: 0!
[    4.892527] KernelSU: unregister vfs_read kprobe: 0!
[    4.892581] KernelSU: unregister vfs_read kprobe: 0!
[    4.892585] KernelSU: unregister vfs_read kprobe: 0!
[   11.512477] KernelSU: exec app_process, /data prepared, second_stage: 1
[   11.512488] KernelSU: on_post_fs_data!
[   11.512497] KernelSU: unregister input kprobe: 1!
[   11.512502] KernelSU: devpts sid: 638
[   11.512504] KernelSU: unregister execve kprobe: 1!
[   11.512513] KernelSU: Unsupported profile version: 0
[   11.512518] KernelSU: Failed to set app profile: invalid profile!
[   11.512553] KernelSU: load_allow_list open file failed: -2
hmtheboy154 commented 4 weeks ago

The same log does show up on Live boot, but it actually continue find the manager

[   18.616524] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   18.623490] KernelSU: Searching manager...
[   18.623507] KernelSU: Search manager finished
[   28.677255] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   28.686915] KernelSU: Searching manager...
[   28.686957] KernelSU: Search manager finished
[   32.491071] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   32.498248] KernelSU: Searching manager...
[   32.498274] KernelSU: Search manager finished
[   36.313269] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   36.318839] KernelSU: Searching manager...
[   36.318872] KernelSU: Unknown id: 0x42726577
[   36.318874] KernelSU: Unexpected v3 signature scheme found!
[   36.318875] KernelSU: Found new base.apk at path: /data/app/~~N-zSbZIhNrUyGH03qJy_Cw==/com.termux-c41V9Ag0oAST8BJLiVk3zw==/base.apk, is_manager: 0
[   36.318886] KernelSU: Unknown id: 0x504b4453
[   36.318887] KernelSU: Unknown id: 0x42726577
[   36.318888] KernelSU: Found new base.apk at path: /data/app/~~iz2FDWukoEBo5TfjpTJHkQ==/com.amaze.filemanager-rxf6UxLNEJwlv_5zgegrXQ==/base.apk, is_manager: 0
[   36.318890] KernelSU: Search manager finished
[   36.969531] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   36.976644] KernelSU: Searching manager...
[   36.976705] KernelSU: sha256: c371061b19d8c7d7d6133c6a9bafe198fa944e50c1b31c9d8daa8d7f1fc2d2d6, expected: c371061b19d8c7d7d6133c6a9bafe198fa944e50c1b31c9d8daa8d7f1fc2d2d6
[   36.976707] KernelSU: Unknown id: 0x504b4453
[   36.976708] KernelSU: Unknown id: 0x42726577
[   36.976732] KernelSU: Found new base.apk at path: /data/app/~~gbnxVANZr-B4M7dU3px2RA==/me.weishu.kernelsu-zw7nokylm5JUIKLNI7Ptfw==/base.apk, is_manager: 1
[   36.976734] KernelSU: manager pkg: me.weishu.kernelsu
[   36.976736] KernelSU: Crowning manager: me.weishu.kernelsu(uid=10251)
[   36.976737] KernelSU: Search manager finished
[   37.417133] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   38.070150] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
[   39.238175] KernelSU: renameat: packages.list.tmp -> packages.list, new path: /system/packages.list
hmtheboy154 commented 4 weeks ago

Which dentry is NULL? old_dentry or new_dentry？

So with the help of ChatGPT, I made a patch to print some more info to debug:

diff --git a/kernel/core_hook.c b/kernel/core_hook.c
index b63ea0b1..0fada79b 100644
--- a/kernel/core_hook.c
+++ b/kernel/core_hook.c
@@ -167,41 +167,55 @@ void escape_to_root(void)

 int ksu_handle_rename(struct dentry *old_dentry, struct dentry *new_dentry)
 {
-   if (!current->mm) {
-       // skip kernel threads
-       return 0;
-   }
-
-   if (current_uid().val != 1000) {
-       // skip non system uid
-       return 0;
-   }
-
-   if (!old_dentry || !new_dentry) {
-       return 0;
-   }
+    // Print the old and new dentry names at the beginning
+    pr_info("Handling rename: old_dentry = %s, new_dentry = %s\n",
+            old_dentry ? old_dentry->d_iname : "NULL",
+            new_dentry ? new_dentry->d_iname : "NULL");
+
+    if (!current->mm) {
+        // Skip kernel threads
+        pr_info("Skipping kernel thread\n");
+        return 0;
+    }
+
+    if (current_uid().val != 1000) {
+        // Skip non-system UID
+        pr_info("Skipping non-system UID: %d\n", current_uid().val);
+        return 0;
+    }
+
+    if (!old_dentry || !new_dentry) {
+        // One of the dentries is NULL
+        pr_info("One or both dentries are NULL\n");
+        return 0;
+    }

    // /data/system/packages.list.tmp -> /data/system/packages.list
-   if (strcmp(new_dentry->d_iname, "packages.list")) {
-       return 0;
-   }
-
-   char path[128];
-   char *buf = dentry_path_raw(new_dentry, path, sizeof(path));
-   if (IS_ERR(buf)) {
-       pr_err("dentry_path_raw failed.\n");
-       return 0;
-   }
-
-   if (strcmp(buf, "/system/packages.list")) {
-       return 0;
-   }
-   pr_info("renameat: %s -> %s, new path: %s\n", old_dentry->d_iname,
-       new_dentry->d_iname, buf);
-
-   track_throne();
-
-   return 0;
+    if (strcmp(new_dentry->d_iname, "packages.list")) {
+        pr_info("New dentry name is not 'packages.list': %s\n", new_dentry->d_iname);
+        return 0;
+    }
+
+    char path[128];
+    char *buf = dentry_path_raw(new_dentry, path, sizeof(path));
+    if (IS_ERR(buf)) {
+        pr_err("dentry_path_raw failed.\n");
+        return 0;
+    }
+
+    // Check if the path is "/system/packages.list"
+    if (strcmp(buf, "/system/packages.list")) {
+        pr_info("Path is not '/system/packages.list': %s\n", buf);
+        return 0;
+    }
+
+    // If all conditions are met, print the rename operation details
+    pr_info("renameat: %s -> %s, new path: %s\n",
+            old_dentry->d_iname, new_dentry->d_iname, buf);
+
+    track_throne();
+
+    return 0;
 }

 int ksu_handle_prctl(int option, unsigned long arg2, unsigned long arg3,

The result is that I saw this image

It seems like KSU can be able to look at the actual dir instead of just /data/system . On Android-x86 (or here is BlissOS), we prepare the system under /android and then switch_root or chroot to it.

Remon98 commented 1 week ago

The same thing happened with LKM in lineage-21.0-20240923-nightly-oriole pixel 6.

helamonster commented 1 week ago

Glad to see this is fixed. Can we get an updated release?

hmtheboy154 commented 1 week ago

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

helamonster commented 1 week ago

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

Hmm. I'm using what I thought was the latest build: BlissOS 16.9.7. Am I missing something?

Zetan9565 commented 1 week ago

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

Hmm. I'm using what I thought was the latest build: BlissOS 16.9.7. Am I missing something?

I had tried just now, it's still not working on B.OS 16.9.7

hmtheboy154 commented 6 days ago

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

Hmm. I'm using what I thought was the latest build: BlissOS 16.9.7. Am I missing something?

Give me the iso name & what show in KSU Manager

hmtheboy154 commented 6 days ago

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

Hmm. I'm using what I thought was the latest build: BlissOS 16.9.7. Am I missing something?

I had tried just now, it's still not working on B.OS 16.9.7

you too

hansalemaos commented 3 days ago

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

I tested them yesterday and today and only could get a shell root activating adb shell in kernelsu, and doing this hack in the adb shell

printf "%s\n" 'mount -o remount,rw /' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" 'rm -f /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'echo '\''#!/system/bin/sh'\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c  # or some less permissive chmod 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'printf "%s" '\''exec printf '\''\'\'''\''/data/adb/ksu/bin/busybox sh -c "/system/system_ext/bin/bash" < /dev/tty'\''\'\'''\'' | tr '\''\'\'''\''\n'\''\'\'''\'' '\''\'\'''\''\0'\''\'\'''\'' | toybox xargs -0 -n1 su --preserve-environment --mount-master -c '\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c   # or some less permissive chmod

This gives me a su shell using bashsudo

I hope you get it fixed! I love your project! Really awesome!

hmtheboy154 commented 2 days ago

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

I tested them yesterday and today and only could get a shell root activating adb shell in kernelsu, and doing this hack in the adb shell

printf "%s\n" 'mount -o remount,rw /' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" 'rm -f /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'echo '\''#!/system/bin/sh'\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c  # or some less permissive chmod 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'printf "%s" '\''exec printf '\''\'\'''\''/data/adb/ksu/bin/busybox sh -c "/system/system_ext/bin/bash" < /dev/tty'\''\'\'''\'' | tr '\''\'\'''\''\n'\''\'\'''\'' '\''\'\'''\''\0'\''\'\'''\'' | toybox xargs -0 -n1 su --preserve-environment --mount-master -c '\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c   # or some less permissive chmod

This gives me a su shell using bashsudo

I hope you get it fixed! I love your project! Really awesome!

Yea I will have to create a new Github Issue here, I do notice that on Termux I can only get /system/bin/su to working so far.

hansalemaos commented 2 days ago

Glad to see this is fixed. Can we get an updated release?

It's already available on all public BlissOS builds

I tested them yesterday and today and only could get a shell root activating adb shell in kernelsu, and doing this hack in the adb shell

printf "%s\n" 'mount -o remount,rw /' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" 'rm -f /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'echo '\''#!/system/bin/sh'\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c  # or some less permissive chmod 
printf "%s\n" " " | tr '\n' '\0'  | toybox xargs -0 -n1 su -c 'printf "%s" '\''exec printf '\''\'\'''\''/data/adb/ksu/bin/busybox sh -c "/system/system_ext/bin/bash" < /dev/tty'\''\'\'''\'' | tr '\''\'\'''\''\n'\''\'\'''\'' '\''\'\'''\''\0'\''\'\'''\'' | toybox xargs -0 -n1 su --preserve-environment --mount-master -c '\'' > /system/bin/bashsudo'
printf "%s\n" 'chmod 777 /system/bin/bashsudo' | tr '\n' '\0' | toybox xargs -0 -n1 su -c   # or some less permissive chmod

This gives me a su shell using bashsudo I hope you get it fixed! I love your project! Really awesome!

Yea I will have to create a new Github Issue here, I do notice that on Termux I can only get /system/bin/su to working so far.

If I try ksud, su, toybox su, /data/adb/ksu/bin/busybox sh, I don't get anywhere, but using ... toybox xargs -0 -n1 su after piping, piping and more piping it works all of a sudden.

VirtualBox:/ $ whoami
shell
VirtualBox:/ $ printf "%s\n" 'whoami' | tr '\n' '\0' | toybox xargs -0 -n1 su -c
root

VirtualBox:/ $ printf "%s\n" '/system/system_ext/bin/bash < /dev/tty' | tr '\n' '\0' | toybox xargs -0 -n1 su -c
localhost / #

2024-10-02 14_32_01-KSU report _not installed_ on installed system, but _installed_ on Live boot whe

hansalemaos commented 2 days ago

I have just found something else that might help you to solve the problem, but maybe you know it already:

https://github.com/termux-play-store/termux-tools/commit/9187cfa169cc64861a0fc7e98a01b9c78eb1634d#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R7

hansalemaos commented 2 days ago 
sudo(){
    printf "%s" "$*" | toybox xargs -0 -n1 su -c 
}

sushell(){
    echo | toybox xargs -0 -n1 su -c '/system/bin/sh < /dev/tty'
}

Here are 2 more user-friendly ways to invoke su, maybe it serves as a temporal workaround for blissOs

2024-10-02 15_20_23-Open

hmtheboy154 commented 2 days ago

I have just found something else that might help you to solve the problem, but maybe you know it already:

termux-play-store/termux-tools@9187cfa#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R7

I didn't know about this...... interesting though

hansalemaos commented 2 days ago

I have just found something else that might help you to solve the problem, but maybe you know it already: termux-play-store/termux-tools@9187cfa#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R7

I didn't know about this...... interesting though

It may help you. Maybe there is a way to trace how the toybox executable calls: xargs -0 -n1 su -c and then reproducing the syscall somehow.

It seems like through all this piping stuff and toybox, an environment is created where this: execve(2) call in kernel to redirect it to kernel is triggered calling su

hmtheboy154 commented 2 days ago

I have just found something else that might help you to solve the problem, but maybe you know it already: termux-play-store/termux-tools@9187cfa#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R7

I didn't know about this...... interesting though

It may help you. Maybe there is a way to trace how the toybox executable calls: xargs -0 -n1 su -c and then reproducing the syscall somehow.

It seems like through all this piping stuff and toybox, an environment is created where this: execve(2) call in kernel to redirect it to kernel is triggered calling su

Made new issue https://github.com/tiann/KernelSU/issues/2113 . If you have any new finding please go there