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
#6 (comment).

[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.