Root done right

[nicholseric]

Not worried about my data, I did a flash-all.sh with mra58k then before it rebooted, I flashed my boot.img. Still get the corrupt device spash screen but the log was now happy with my userdata partition. Putting the hosts bind in su -c '' did not work, hosts was just the two liner, but it left no error in dmesg either. Getting nowhere fast with this. I think I'll leave it to the experts and check back in later. Ping me if you need a tester.

I ended up getting the corrupt device error even after flashing boot.img back to factory. So I went into recovery and did a Wipe data/factory reset. Now the corrupt device error is gone. I would expect flash-all.sh to accomplish the same thing but I guess not.

Now I am running the boot.img with verity on. There is no corrupt device warning. Android Pay still throws an error when trying to add a card. The mount bind does not work with or without su -c in init.rc but I can run it from terminal emulator. Things can move forward as fast as the dont.

---------- Post added at 11:03 PM ---------- Previous post was at 11:02 PM ----------

Ok, I'll definitely keep you in mind. I do appreciate your help.

My pleasure!

 

[doitright]

I ended up getting the corrupt device error even after flashing boot.img back to factory. So I went into recovery and did a Wipe data/factory reset. Now the corrupt device error is gone. I would expect flash-all.sh to accomplish the same thing but I guess not.

Now I am running the boot.img with verity on. There is no corrupt device warning. Android Pay still throws an error when trying to add a card. The mount bind does not work with or without su -c in init.rc but I can run it from terminal emulator. Things can move forward as fast as the dont.

Waitaminute! That is precisely what I said to try

Glad to hear that you have verity working now! I thought it would.

Now about android pay, I know that on other devices, like the Nexus 5, it does check for su specifically. There is no verity on Nexus 5, even on Android 6... which means that the key is in figuring out what mechanism(s) it is actually using to detect su, and alter the implementation so that it no longer trips them.

Things such as renaming the su binary to "geoff", or changing the package name throughout.


Since you're obviously advanced enough to handle a bit of implementation, you can take a look at this project I set up here to kill off the monthly security annoyance, and change it instead to run your bind mounts:
https://github.com/lbdroid/StopOTA
What it is, is an on boot receiver. That means that the code runs approximately 5 seconds after the lockscreen shows when the phone boots up. The nice thing about doing it like this, is that you know that by the time the boot is completed, everything is already properly mounted and available. You won't need the second round that sets an alarm or the alarm receiver.

More: You don't need to screw around with the context with this su, that was a hack to deal with the poorly implemented binary su.

 

[ECrispy]

This is an excellent idea. Some of the technical details are a bit over my head and I need to learn more.
Will this become part of some kernel eventually? Or can it be used with current kernels/roms?

 

[doitright]

ECrispy: this is independent of the kernel, rather impacting the ramdisk. For a beginner, there may not be much of a distinction between the two, however, since the kernel and ramdisk are packed sequentially into the boot partition. I.e., the "boot.img" contains both.

 

[nicholseric]

Waitaminute! That is precisely what I said to try

Glad to hear that you have verity working now! I thought it would.

Now about android pay, I know that on other devices, like the Nexus 5, it does check for su specifically. There is no verity on Nexus 5, even on Android 6... which means that the key is in figuring out what mechanism(s) it is actually using to detect su, and alter the implementation so that it no longer trips them.

Things such as renaming the su binary to "geoff", or changing the package name throughout.


Since you're obviously advanced enough to handle a bit of implementation, you can take a look at this project I set up here to kill off the monthly security annoyance, and change it instead to run your bind mounts:
https://github.com/lbdroid/StopOTA
What it is, is an on boot receiver. That means that the code runs approximately 5 seconds after the lockscreen shows when the phone boots up. The nice thing about doing it like this, is that you know that by the time the boot is completed, everything is already properly mounted and available. You won't need the second round that sets an alarm or the alarm receiver.

More: You don't need to screw around with the context with this su, that was a hack to deal with the poorly implemented binary su.

About the waitaminute, I figured that a flash-all.sh would be better and more complete than a factory reset from recovery. Apparently not.

So I thought geoff and I would nail this but no. I went through your patches and changed all /sbin/su to /sbin/geoff plus another occurrence of su or two and I renamed the su binary to geoff. I made the boot image and was able to use terminal emulator to start geoff and superuser asks permission. That part works fine but starting superuser says "The Superuser binary (su) must be updated etc.." That is understandable because I did not recompile the superuser.apk to reference geoff, heck I cant even compile a usable su with ndk-build, mine comes out much small than your binary. So at least geoff starts, asks superuser for permission and gives me root, great. But, android pay still gives the error on trying to add a card.

I would build superuser and su with geoff if I could but Im not getting anywhere with it. I am not using eclipse, my ndk is 10d and I have SDK Platform 23 installed. Do I really need SDK Platform 19 and NDK 9b as https://github.com/phhusson/Superuser suggests? I was just following his instructions on that page but with current sdk and ndk.

 

[doitright]

About the waitaminute, I figured that a flash-all.sh would be better and more complete than a factory reset from recovery. Apparently not.

So I thought geoff and I would nail this but no. I went through your patches and changed all /sbin/su to /sbin/geoff plus another occurrence of su or two and I renamed the su binary to geoff. I made the boot image and was able to use terminal emulator to start geoff and superuser asks permission. That part works fine but starting superuser says "The Superuser binary (su) must be updated etc.." That is understandable because I did not recompile the superuser.apk to reference geoff, heck I cant even compile a usable su with ndk-build, mine comes out much small than your binary. So at least geoff starts, asks superuser for permission and gives me root, great. But, android pay still gives the error on trying to add a card.

I would build superuser and su with geoff if I could but Im not getting anywhere with it. I am not using eclipse, my ndk is 10d and I have SDK Platform 23 installed. Do I really need SDK Platform 19 and NDK 9b as https://github.com/phhusson/Superuser suggests? I was just following his instructions on that page but with current sdk and ndk.

Try UNINSTALLING the android application, leave geoff where he is, and rebooting. If then android pay can work, we have an idea that it is detecting the application.

Note that it could be storing the "don't run" state in something. It could require a wipe as well as rebooting.

 

[nicholseric]

Try UNINSTALLING the android application, leave geoff where he is, and rebooting. If then android pay can work, we have an idea that it is detecting the application.

Note that it could be storing the "don't run" state in something. It could require a wipe as well as rebooting.

Removing superuser was not enough. I used factory recovery to do a wipe and now android pay works. So I imagine like you that its both the name of superuser package and if it was ever detected, a wipe. So, creating a superuser.apk named something else that references geoff.

I wont touch eclipse and it should not be a requirement to successfully build superuser. This will need some attention. How can I help? Next steps?

What version of ndk and sdk platform are you using? I finally found how to get the 9b ndk https://dl.google.com/android/ndk/android-ndk-r9b-linux-x86_64.tar.bz2

Once I get a working build env for superuser, I see line 49 in su.h is where I might start? Or is that the same as /packageName #define JAVA_PACKAGE_NAME "com.koushikdutta.superuser"

An idea, how about in addition to dynamically fixing up boot.img from custom recovery, su\superuser lays dormant in boot.img and during boot, if the user has a specific file with a private key in it in \sdcard\random or \sdcard\superuser.key, then su\superuser wakes up during init? You get issued the key during the custom recovery modification of boot.img.

 

[doitright]

Removing superuser was not enough. I used factory recovery to do a wipe and now android pay works. So I imagine like you that its both the name of superuser package and if it was ever detected, a wipe. So, creating a superuser.apk named something else that references geoff.

I wont touch eclipse and it should not be a requirement to successfully build superuser. This will need some attention. How can I help? Next steps?

What version of ndk and sdk platform are you using? I finally found how to get the 9b ndk https://dl.google.com/android/ndk/android-ndk-r9b-linux-x86_64.tar.bz2

Eclipse is *NOT* and *NEVER HAS* been a requirement. Its just what I happen to be using.
Try following the directions in phhusson's readme: https://github.com/phhusson/Superuser

So I presume then that you mean that you still have the geoff binary in place?
Tried rebooting a few times and pay still works?
Then try going back to su binary. pay still works?
Rebooted a few times, pay still works?
Then build the application with a different package name.

As far as the build environment, I can confirm that I am building using the latest api for 6.0. As far as ndk goes, I would have to check the machine I've been using for that, *probably* the latest, but may be older?

 

[superdragonpt]

Hi

Thanks for this, it's awesome to have a open source su "tool"

I guess most people, still don't understand, how awesome this is/ will be...

cheers

 

[nicholseric]

Eclipse is *NOT* and *NEVER HAS* been a requirement. Its just what I happen to be using.
Try following the directions in phhusson's readme: https://github.com/phhusson/Superuser

So I presume then that you mean that you still have the geoff binary in place?
Tried rebooting a few times and pay still works?
Then try going back to su binary. pay still works?
Rebooted a few times, pay still works?
Then build the application with a different package name.

As far as the build environment, I can confirm that I am building using the latest api for 6.0. As far as ndk goes, I would have to check the machine I've been using for that, *probably* the latest, but may be older?

Once I can build superuser.apk and su from source without eclipse, I will flash the boot.img with that su and test as you suggest with rebooting between boot.img's.

In the meantime, I am making progress on #./gradlew assembleDebug --info
At first I got nowhere with this error:

FAILURE: Build failed with an exception.

* Where:
Build file '/home/havealoha/android/Superuser/Superuser/build.gradle' line: 33

* What went wrong:
A problem occurred evaluating root project 'Superuser'.
> Neither path nor baseDir may be null or empty string. path='null' basedir='/home/havealoha/android/Superuser/Superuser'

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

To fix that, I edited Superuser/Superuser/build.gradle line 33 to read
storeFile file('keystore')


Then I got this far:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'Superuser'.
> SDK location not found. Define location with sdk.dir in the local.properties file or with an ANDROID_HOME environment variable.

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

To fix this, I created Superuser/Superuser/local.properites with
sdk.dir=/home/havealoha/adt/sdk

Then I got this far:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'Superuser'.
> failed to find target android-22 : /home/havealoha/adt/sdk

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

To fix that, I edited all the build.gradle's to match the versions of the SDK Platform tools I have:

    compileSdkVersion 23
    buildToolsVersion '23.0.1'

    defaultConfig {
        File f = new File("packageName")
        minSdkVersion 14
        targetSdkVersion 23

Then I was able to get this far and am currently stuck, even with adding --continue to :

Successfully started process 'command '/home/havealoha/adt/sdk/build-tools/23.0.1/aapt''
 Position 2 : Tag <manifest> attribute package has invalid character ' '.

:processDebugResources FAILED
:processDebugResources (Thread[main,5,main]) completed. Took 0.13 secs.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':processDebugResources'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/home/havealoha/adt/sdk/build-tools/23.0.1/aapt'' finished with non-zero exit value 1

I have tried adding lint options to

android {
lintOptions {
abortOnError false
}

and to

defaultConfig {
lintOptions {
abortOnError false
}
http://stackoverflow.com/questions/19389982/how-to-ignore-invalid-characters-in-androids-manifest

Finally I did a ./gradlew clean and that finished building but I dont find an apk anywhere.

As far as su goes, I build it and it is tiny compared to your binary and it does not work:

[havealoha@CentOS7-DELL9020 Superuser]$ ndk-build clean
[x86] Clean          : selinux [x86]
[x86] Clean          : sepol [x86]
[x86] Clean          : stdc++ [x86]
[x86] Clean          : su [x86]
[armeabi] Clean          : selinux [armeabi]
[armeabi] Clean          : sepol [armeabi]
[armeabi] Clean          : stdc++ [armeabi]
[armeabi] Clean          : su [armeabi]
[mips] Clean          : selinux [mips]
[mips] Clean          : sepol [mips]
[mips] Clean          : stdc++ [mips]
[mips] Clean          : su [mips]
[havealoha@CentOS7-DELL9020 Superuser]$ ls -l ./li
libs/     lint.xml  
[havealoha@CentOS7-DELL9020 Superuser]$ ls -l ./libs/armeabi/
total 312
-rwxr-xr-x 1 havealoha havealoha 315980 Oct 30 14:51 su

 

[Shawn5162]

This seams cool http://xdaforums.com/showpost.php?p=63197935&postcount=2. Looks like the same thing but at a bigger scale (because it's Chainfire).

 

[abuttino]

Hmm. I could have sworn his name wasn't to be mentioned in this thread.

Anyway... To fully implement this, it is best if used in a stock ROM, is this statement correct?

Sent from my XT1060 using Tapatalk

 

[nicholseric]

Eclipse is *NOT* and *NEVER HAS* been a requirement. Its just what I happen to be using.
Try following the directions in phhusson's readme: https://github.com/phhusson/Superuser

So I presume then that you mean that you still have the geoff binary in place?
Tried rebooting a few times and pay still works?
Then try going back to su binary. pay still works?
Rebooted a few times, pay still works?
Then build the application with a different package name.

As far as the build environment, I can confirm that I am building using the latest api for 6.0. As far as ndk goes, I would have to check the machine I've been using for that, *probably* the latest, but may be older?

I have gone back to boot.img with verity on and your binary named su. superuser is downloaded but not installed yet. I was able to add a card successfully! I added superuser.apk, used su in terminal emulator and then added another card to android pay.

I wonder if the addition of local.prop or /data/hosts and the bind mount is what is tripping safety net?

---------- Post added at 02:03 AM ---------- Previous post was at 01:35 AM ----------

Sure enough, adding local.prop to /data triggers safety net. Not su or superuser.apk.

 

[ECrispy]

ECrispy: this is independent of the kernel, rather impacting the ramdisk. For a beginner, there may not be much of a distinction between the two, however, since the kernel and ramdisk are packed sequentially into the boot partition. I.e., the "boot.img" contains both.

Thanks. What I meant is I see some kernels which list 'selinux permissive' as one of their features which means they'd undo this work.

 

[nicholseric]

Removing local.prop enabled me to add a card to Android pay. It even works after adding /data/hosts and mount -o bind /data/hosts /system/etc/hosts. So it looks like I can add setprop ro.sf .lcd_density 160 to init.rc

Another idea is to add a recovery private keyed\hashed key\pair file in /sdcard/ for reading properties.

 

[damodarreddy]

thanks for this doitright ,,, it is high time for change,,,, that too for good:highfive:

 

[nicholseric]

Removing local.prop enabled me to add a card to Android pay. It even works after adding /data/hosts and mount -o bind /data/hosts /system/etc/hosts. So it looks like I can add setprop ro.sf .lcd_density 160 to init.rc

Another idea is to add a recovery private keyed\hashed key\pair file in /sdcard/ for reading properties.

That idea probably does not sound clear. Here it is better explained. To keep verity and the functionality of local.prop, create a /sdcard/randomname. To secure it, write a custom recovery script that allows you to generate a hash of the /sdcard/randomname . The hash is stored into the boot.img and an init checks the hash before using setprop to parse and set the properties from /sdcard/randomname

And a similar idea for enabling su and superuser.
In addition to dynamically fixing up boot.img from custom recovery, su\superuser lays dormant in boot.img and during boot, if the user has a /sdcard/anotherrandomname file with the value enable su and enable superuser in it, then they get enabled too.

Both these ideas might obfuscate some of the future checks by safety net.

 

[phhusson]

Once I can build superuser.apk and su from source without eclipse, I will flash the boot.img with that su and test as you suggest with rebooting between boot.img's.

In the meantime, I am making progress on #./gradlew assembleDebug --info
At first I got nowhere with this error:

FAILURE: Build failed with an exception.

* Where:
Build file '/home/havealoha/android/Superuser/Superuser/build.gradle' line: 33

* What went wrong:
A problem occurred evaluating root project 'Superuser'.
> Neither path nor baseDir may be null or empty string. path='null' basedir='/home/havealoha/android/Superuser/Superuser'

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

To fix that, I edited Superuser/Superuser/build.gradle line 33 to read
storeFile file('keystore')

Erm yes, sorry about that, I changed the build.gradle to be able to make release builds (BTW I'm publishing the APK on https://play.google.com/store/apps/details?id=me.phh.superuser)
I added it in the issue list.

Then I got this far:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'Superuser'.
> SDK location not found. Define location with sdk.dir in the local.properties file or with an ANDROID_HOME environment variable.

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

To fix this, I created Superuser/Superuser/local.properites with
sdk.dir=/home/havealoha/adt/sdk
Actually, proper usual android way, is to set ANDROID_HOME=/home/havealoha/adt/sdk/
And put it in your bashrc/zshrc

Then I was able to get this far and am currently stuck, even with adding --continue to :

Successfully started process 'command '/home/havealoha/adt/sdk/build-tools/23.0.1/aapt''
 Position 2 : Tag <manifest> attribute package has invalid character ' '.

:processDebugResources FAILED
:processDebugResources (Thread[main,5,main]) completed. Took 0.13 secs.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':processDebugResources'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/home/havealoha/adt/sdk/build-tools/23.0.1/aapt'' finished with non-zero exit value 1

Did you change packageName? Please note that it must NOT contain a trailing \n

Finally I did a ./gradlew clean and that finished building but I dont find an apk anywhere.

You did ./gradlew assembleDebug?
It should create it in build/outputs/apk/ (yes gradle is annoying with the output paths)

As far as su goes, I build it and it is tiny compared to your binary and it does not work:

[havealoha@CentOS7-DELL9020 Superuser]$ ndk-build clean
[x86] Clean          : selinux [x86]
[x86] Clean          : sepol [x86]
[x86] Clean          : stdc++ [x86]
[x86] Clean          : su [x86]
[armeabi] Clean          : selinux [armeabi]
[armeabi] Clean          : sepol [armeabi]
[armeabi] Clean          : stdc++ [armeabi]
[armeabi] Clean          : su [armeabi]
[mips] Clean          : selinux [mips]
[mips] Clean          : sepol [mips]
[mips] Clean          : stdc++ [mips]
[mips] Clean          : su [mips]
[havealoha@CentOS7-DELL9020 Superuser]$ ls -l ./li
libs/     lint.xml  
[havealoha@CentOS7-DELL9020 Superuser]$ ls -l ./libs/armeabi/
total 312
-rwxr-xr-x 1 havealoha havealoha 315980 Oct 30 14:51 su

I don't understand... You call ndk-build clean? Why? It won't make the thing build
If you want to build just call ndk-build

Also, do you have a bit more infos than "doesn't work" ?

This seams cool http://xdaforums.com/showpost.php?p=63197935&postcount=2. Looks like the same thing but at a bigger scale (because it's Chainfire).

Way ****ing bigger scale is ongoing on https://github.com/phhusson/super-bootimg
It is still work in progress, but it takes a boot.img as input, and outputs a rooted boot.img, and will be callable either from a recovery or from a desktop.
Obviously not all architectures are supported yet, but I tested it on CAF 6.0 roms, Nexus 5 6.0, 5.1, Nexus 9 6.0, MTK 5.1 devices.
Also compared to current doitright's AOSP patch, not all domains are restrained, I still have some permissive domains.


Also, as for UI, if anyone wants to help, he is welcome, I really don't plan to work on UI, and I don't think doitright is planning to either.

 

[nicholseric]

Did you change packageName? Please note that it must NOT contain a trailing \n

Yes, this was the problem.

I don't understand... You call ndk-build clean? Why? It won't make the thing build
If you want to build just call ndk-build

Also, do you have a bit more infos than "doesn't work" ?

ndk-build worked fine but after using that su in boot.img (forget what didn't work), I did a ndk-build clean to prepare to modify something. Clean was just left on the screen and I mistakenly copied that portion here. You can see my su binary and its size, is it close to what should be expected?
ls -l ./libs/armeabi/
total 312
-rwxr-xr-x 1 havealoha havealoha 315980 Oct 30 14:51 su

Now that I can build superuser, I'll elaborate on any trouble Monday. Thanks for the pointers!

 

[TjPhysicist]

Stupid question warning


<warning>
This is a dumb question and I know it. I AM NOT asking this to be a troll, or to incite a war (which i 95% guarantee will happen). I am genuinely asking a question that has bothered me for YEARS and have not been able to answer it myself with any amount of research. PLEASE PLEASE I BEG OF YOU answer in a civil manner, I am honestly asking this question to learn the truth. The last time I asked this question, I got banned from a forum without saying anything more than said question.
</warning>

a very stupid question, but something i've wanted answered for a VERY Long time. I've been using and compiling etc various versions of unix and linux for over a decade now, all of which have a 'root user' or variation thereof (latest versions of solaris' variation of 'root' is arguably different from a traditional user with uid=0). Here's my question, I've been reading up on root on android and all it requires as well as this thread...HOLY CRAP that first post is SO COMPLICATED. SElinux reloading? what? Why in gods name?

So my question is this: Why can root on android not be as simple or almost as simple as root on freebsd or ubuntu? there's a root user, and a su app with setuid. I don't know too much about 'selinux' but ubuntu runs selinux and has no issues with root user being so complex and obfuscated. I am NOT AT ALL pointing fingers here, chainfire is an awesome dev, who does work that i could never do....BUT something somewhere is screwed up if we need to jump through insane hoops of fire and play gymnastics with our code to get something as fundamental as 'root'.
Note: I get that without unlocked bootloader root becomes tough, so for the purpose of simplifying things, let's assume my question is restricted to fully unlocked nexus devices only.