Doesn't work on Samsung S4 I9500 with Android 5.0.1 stock ROM (LRX22C.I9500XXUHOD4)

[Meteorite]

I'v build your su binary with placeholder, installed them accoring to your instruction (with the help of chainfire's binary). Then rebooted. After reboot su returns 255 and I can't see su daemon...

And another question. On what devices and ROMS do you test your root ?

[phhusson]

I tested it on Nexus 5, several CAF devices, MTK baseline devices as well. Thanks for your report!

Do you have access to kernel messages to look for audit messages? Can you provide the result of ls -lZ /system/bin/app_process* ? Are you sure the install-recovery.sh script you changed is the right one (some ROMs have multiple install-recovery's), and that you put /system/xbin/su --daemon at the second line of the file ? (before it has any chance to exit for other reasons)

The fact that the device is still booting is already a rather good news.

[Meteorite]

ls -lZ /system/bin/app_process* -rwxr-xr-x root shell u:object_r:zygote_exec:s0 app_process -rwxr-xr-x root shell u:object_r:zygote_exec:s0 app_process32 -rwxr-xr-x root shell u:object_r:zygote_exec:s0 app_process32.old -rwxr-xr-x root shell u:object_r:zygote_exec:s0 app_process32_original -rwxr-xr-x root shell u:object_r:system_file:s0 app_process_init

As for daemonization points, I additionaly to install-recovery used ddexe:

cat /system/etc/install-recovery.sh

!/system/bin/sh

/system/xbin/su --daemon & /system/etc/install-recovery-2.sh

cat /system/bin/ddexe

!/system/bin/sh

/system/xbin/su --daemon & /system/bin/ddexe_real

[Meteorite]

Unfortunetly, I don't really know, how to see kernel messages.

[phhusson]

dmesg |grep audit should do the trick

[Meteorite]

its output is empty (no audit)

[phhusson]

But dmesg alone does give output?

[Meteorite]

Yes

[Meteorite]

And what is default behaviour, when apk is not installed ? Is root access granted or denied ?

[phhusson]

Default is denied, but if you don't even have daemon... Le 15 oct. 2015 7:24 PM, "Meteorite" notifications@github.com a écrit :

And what is default behaviour, when apk is not installed ? Is root access granted or denied ?

— Reply to this email directly or view it on GitHub https://github.com/phhusson/Superuser/issues/6#issuecomment-148465078.

[lbdroid]

Uh, wait a minute there, definitely something funny going on with all those app_process* processes. Lemme guess... you installed chainfire supersu, and then this just right overtop of it, right? You should clean out all the chainfire mess properly before trying this.

[Meteorite]

lbdroid, you are absolutely right. I installed this root using previously installed chainfire's one. But as for app_process-es, I renamed original firm app_process32 (it was named app_process32_original after chainfire) to app_process32.old. Ок, I'll try to reflash original firmware and install this root using twrp.

[Meteorite]

I refleshed original firmware, wiped data, cache and dalvik-cache, then flashed twrp as recovery. Then using adb support by twrp I installed this su binary and placeholder again. After rebooting and turning USB debugging on I typed:

shell@ja3g:/ $ su su 255|shell@ja3g:/ $

shell@ja3g:/ $ ls -l /system/bin/app_process*
ls -l /system/bin/app_process*
lrwxr-xr-x root shell 2015-01-20 16:21 app_process -> app_process32 -rwxr-xr-x root shell 55604 2015-10-15 21:15 app_process32
-rwxr-xr-x root shell 13588 2015-01-20 16:08 app_process32.old

shell@ja3g:/ $ ls -Z /system/bin/app_process ls -Z /system/bin/app_process lrwxr-xr-x root shell u:object_r:zygote_exec:s0 app_process -> app_process32 -rwxr-xr-x root shell u:object_r:zygote_exec:s0 app_process32 -rwxr-xr-x root shell u:object_r:zygote_exec:s0 app_process32.old

shell@ja3g:/ $ ls -l /system/bin/ddexe ls -l /system/bin/ddexe -rwxr-xr-x root shell 67 2015-10-15 13:26 ddexe -rwxr-xr-x root shell 14108 2015-01-20 16:08 ddexe_real

shell@ja3g:/ $ ls -Z /system/bin/ddexe ls -Z /system/bin/ddexe -rwxr-xr-x root shell u:object_r:ddexe_exec:s0 ddexe -rwxr-xr-x root shell u:object_r:ddexe_exec:s0 ddexe_real

shell@ja3g:/ $ cat /system/bin/ddexe cat /system/bin/ddexe

!/system/bin/sh

/system/xbin/su --daemon & /system/bin/ddexe_real

shell@ja3g:/ $ ls -l /system/etc/install-recovery.sh ls -l /system/etc/install-recovery.sh -rwxr-xr-x root root 78 2015-10-16 09:32 install-recovery.sh

shell@ja3g:/ $ ls -Z /system/etc/install-recovery.sh ls -Z /system/etc/install-recovery.sh -rwxr-xr-x root root u:object_r:system_file:s0 install-recovery.sh

shell@ja3g:/ $ cat /system/etc/install-recovery.sh cat /system/etc/install-recovery.sh

!/system/bin/sh

/system/xbin/su --daemon & /system/etc/install-recovery-2.sh

shell@ja3g:/ $ ls -l /system/xbin ls -l /system/xbin -rwxr-xr-x root shell 59752 2015-01-20 16:08 dexdump -rwxr-xr-x root root 315940 2015-10-15 21:15 su

shell@ja3g:/ $ ls -Z /system/xbin ls -Z /system/xbin -rwxr-xr-x root shell u:object_r:system_file:s0 dexdump -rwxr-xr-x root root u:object_r:system_file:s0 su

shell@ja3g:/ $ ps | grep su ps | grep su root 452 2 0 0 ffffffff 00000000 S sync_supers system 2569 1 192988 20784 ffffffff 00000000 S /system/bin/surfaceflinger u0_a172 4001 2584 1860220 67748 ffffffff 00000000 S com.samsung.android.widgetapp.briefing4x2 u0_a178 4010 2584 1847904 61740 ffffffff 00000000 S com.samsung.android.tripwidget u0_a63 4057 2584 1850464 60192 ffffffff 00000000 S com.samsung.android.app.storyalbumwidget u0_a62 4134 2584 1852856 62324 ffffffff 00000000 S com.samsung.android.app.episodes system 4251 2584 1867240 73796 ffffffff 00000000 S com.samsung.SMT u0_a6 5194 2584 1833808 50980 ffffffff 00000000 S com.samsung.android.providers.context u0_a142 5898 2584 1845304 57392 ffffffff 00000000 S com.samsung.android.sconnect system 6492 2584 1834736 50340 ffffffff 00000000 S com.samsung.android.securitylogagent u0_a177 6612 2584 1833932 49636 ffffffff 00000000 S com.samsung.android.service.travel u0_a37 6899 2584 2106520 96924 ffffffff 00000000 S com.samsung.android.app.galaxyfinder:tagService u0_a137 7036 2584 1881464 90800 ffffffff 00000000 S tv.peel.samsung.app system 7516 2584 1849880 54688 ffffffff 00000000 S com.samsung.android.MtpApplication

shell@ja3g:/ $ dmesg | grep audit dmesg | grep audit 1|shell@ja3g:/ $

[phhusson]

Perfect, now I know what to ask users for when debugging :)

Can you get a root access in this configuration? (ie without Chainfire's SuperSU) You can replace the adbd in boot.img to be root

[Meteorite]

To get root access in this configuration I can boot to twrp recovery, perform root operations there and then boot to system again. I'v never replaced anything in boot.img... Could you give me a link to sort of instruction, how to do it ?

[lbdroid]

Meddling with boot.img is... not the easiest thing to do.

You're going to need a script called "split-bootimg.pl". Just search google and you should be able to find it. You will also need the binary program mkbootimg, which is built during the process of building AOSP. On top of that, you will need gzip/gunzip and cpio to extract and rebuild the ramdisk, which is a gzip'ed cpio file.

[jcmajor]

I have had similar issues installing on i9507 with about 4.1 or 4.2 optus stock rom. I was installing by pulling the system image out of the rom, mounting it under linux, adding su, etc and then repackaging the rom. It was a while ago and I forget where I found the process for that, but I was seeing your symptoms. The resolution was that the selinux markers on the binaries did not allow them to be executed, and selinux was preventing the deamon ( or su ) from creating sockets for communicating between the two. This was patched by someone to use unnamed unix sockets rather than named as they weren't regulated by se at the time. I've been following this discussion for a while and I think that may be enough clues for someone here to solve that one properly.

Regards John On 17/10/2015 2:20 AM, "Meteorite" notifications@github.com wrote:

To get root access in this configuration I can boot to twrp recovery, perform root operations there and then boot to system again. I'v never replaced anything in boot.img... Could you give me a link to sort of instruction, how to do it ?

— Reply to this email directly or view it on GitHub https://github.com/phhusson/Superuser/issues/6#issuecomment-148744846.

[lbdroid]

That comment brings this patch to mind; https://github.com/koush/Superuser/pull/234

[lbdroid]

That comment also brings to mind that this whole daemon hack really needs to be eliminated properly by fixing the selinux policies. This really should not be that complicated of a process.

[phhusson]

I'm not 100% sure it can be removed, some devices might have /system mounted as nosuid

[jcmajor]

This was true of the galaxy rom I was playing with. The samsung apps, however, were loaded from the system part and had rights to manage other apps as far as I could tell. Perhaps they have a less hacky equivalent to su --daemon that loaded from a Samsung-system partion somewhere I didn't notice. On 17/10/2015 5:21 PM, "Pierre-Hugues HUSSON" notifications@github.com wrote:

I'm not 100% sure it can be removed, some devices might have /system mounted as nosuid

— Reply to this email directly or view it on GitHub https://github.com/phhusson/Superuser/issues/6#issuecomment-148889085.

[Meteorite]

Ok, I can now repack boot.img. Thank you. After changing ro.debuggable to 1 and everything with secure to 0 adb root says "restarting adbd as root", but after restarting adbd doesn't work as root. If i repeat adb root, it again says "restarting adbd as root", and adb mount says that permission denied. I tried to change adbd in stock boot.img to adbd from twrp. Repeating adb root now says "adbd is already running as root" but adb shell still doesn't give me root and remount permission is still denied. Could you please tell me, where I can get good adbd ?

[mdirik]

koush/Superuser#253 and koush/Superuser#266 seems similar.

[mdirik]

dmesg |grep audit should do the trick

its output is empty (no audit)

I just checked the stock Samsung rom for S4 and I confirm audit logs don't go to dmesg.

logcat on the other hand, is full of them :) (This was also same for 4.4.2)