As some of you might have read on Twitter, I had the chance to remotely(!) play with a Qualcomm-based SGS4 yesterday, and attempted to root it.

So far, it doesn't work. Don't get me wrong, flashing the device and injecting the su binary and app was no problem, but as soon as you actually execute the su binary, the device reboots. Setting ro.secure to 0 and reflashing boot/recovery is also no problem, but there's some added protection that breaks adbd if boot/recovery is modified.

I've only had about an hour (and no time today) so I haven't done more then some really quick tests, but SELinux is certainly present. It appears to be in permissive mode though, so I'm not sure whether it is responsible for this behavior or if it's something else. The SELinux policies and such are inside the boot/recovery ramdisks, and trying to modify those partitions results in adbd not working.

It's probably going to be something simple to disable this behavior, but an hour of remote access is not enough (at least for me) to figure it out. Several ideas, just have to build/upload/flash/test/etc them. To me it did seem there was actually an explicit policy to allow /system/xbin/su, but I'm no SELinux guru, so I might have misinterpreted that.

To prevent any confusion: there does not seem to be any protection from flashing custom firmwares if you want to do so (on this test device at least). The stock firmware just doesn't like being rooted (so far). This is not Samsung locking down the hardware, as some will undoubtedly have assumed.
Shared publiclyView activity