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" [email protected] 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.

[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" [email protected] 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
#6 (comment).

[lbdroid]

That comment brings this patch to mind;
koush#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" [email protected]
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
#6 (comment).

[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#253 and koush#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)