• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Root done right

Search This thread

nicholseric

Senior Member
Mar 20, 2012
180
40
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!
 
  • Like
Reactions: frikakwa

doitright

Senior Member
Oct 31, 2014
1,512
861
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 :p

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.
 
Last edited:

ECrispy

Senior Member
Jun 25, 2010
1,634
334
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

Senior Member
Oct 31, 2014
1,512
861
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

Senior Member
Mar 20, 2012
180
40
Waitaminute! That is precisely what I said to try :p

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

Senior Member
Oct 31, 2014
1,512
861
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

Senior Member
Mar 20, 2012
180
40
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.
 
Last edited:

doitright

Senior Member
Oct 31, 2014
1,512
861
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?
 

nicholseric

Senior Member
Mar 20, 2012
180
40
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:
Code:
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:
Code:
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:
Code:
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:
Code:
    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 :
Code:
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:

Code:
[[email protected] 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]
[[email protected] Superuser]$ ls -l ./li
libs/     lint.xml  
[[email protected] Superuser]$ ls -l ./libs/armeabi/
total 312
-rwxr-xr-x 1 havealoha havealoha 315980 Oct 30 14:51 su
 
Last edited:

abuttino

Senior Member
Sep 12, 2006
2,222
411
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

Senior Member
Mar 20, 2012
180
40
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

Senior Member
Jun 25, 2010
1,634
334
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

Senior Member
Mar 20, 2012
180
40
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.
 

nicholseric

Senior Member
Mar 20, 2012
180
40
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.
 
Last edited:

phhusson

Recognized Developer
Jul 23, 2009
2,472
4,729
Paris
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:
Code:
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:
Code:
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 :
Code:
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:

Code:
[[email protected] 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]
[[email protected] Superuser]$ ls -l ./li
libs/     lint.xml  
[[email protected] 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://forum.xda-developers.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

Senior Member
Mar 20, 2012
180
40
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

Senior Member
Dec 23, 2007
453
48
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.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 133
    WARNING: This is not a place for you to come to say how great you think Chainfire is. I'm not calling his character into question, only his methodologies and the character of the outfit he sold out to (and I don't question the act of selling out, that's business, pays the bills, and puts kids through college). The debates about what people prefer and why are as old as the first software. And of course, I will not tell you what to do, no matter how much I disagree with you. If you UNDERSTAND what I have to say, then THIS software is for you. If you don't, you are probably better off with binaries.

    The root situation on Android 5.x left a lot to be desired. There was basically just one distributor of a functional substitute user command (su), and it was binary. Recently, ownership of that binary and all of its history has become the property of a previously unknown legal entity called "Coding Code Mobile Technology LLC". While it was presented as a positive thing that that entity has a great involvement with android root control, this is actually a VERY frightening development.

    The people at CCMT are no strangers to the root community. They have invested in, or own, a number of popular root apps (though I am not at liberty to disclose which ones) - chances are, you are running one of them right now. I believe SuperSU has found a good home there, and trust time will not prove me wrong.

    There are precisely two motives I can imagine for buying up all the root control software for Android;
    1) monetizing it, which is contrary to the user's best interests,
    2) something very frightening and dangerous involving the potential exploitation of everybody's devices.

    You don't know the owners, and they are distributing a binary, so who the heck knows WHAT is going on.

    Now a few important considerations with respect to your security and privacy;
    1) Obfuscated binary cannot be sanely audited.
    2) Function of this binary depends on the ability to manipulate selinux policies on the fly, including RELOADING the policy altogether and replacing it with something possibly completely different. Frankly, I've never heard a single reason why this should be necessary.
    3) While a root control application may give you nice audits over other software that is using its service, it can *EASILY* lie about what it is doing itself. It can delete logs, it can share root with other applications that they have made deals with, it can directly sell you out to spammers, etc.

    That is WAY too dangerous, and not worth the risk.
    Frankly, you are safer if you disable selinux AND nosuid, and just run the old style of root where you set a copy of sh as 6755. And that is FRIGHTENINGLY dangerous.

    So not satisfied with this state of root, and especially now with a new unknown entity trying to control the world, we bring you the rebirth of the ORIGINAL Superuser:

    https://github.com/phhusson/Superuser
    https://github.com/lbdroid/AOSP-SU-PATCH (this one is mine)


    From the history of THAT Superuser:
    http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html
    Yes, look at the Superuser repo above and see whose space it was forked from.

    Note: This is a work in progress, but working VERY well.
    Use my patch against AOSP to generate a new boot.img, which includes the su binary.

    Features:
    1) selinux ENFORCING,
    2) sepolicy can NOT be reloaded.
    3) It is NOT necessary (or recommended) to modify your system partition. You can run this with dm-verity!


    The source code is all open for you to audit. We have a lot of plans for this, and welcome suggestions, bug reports, and patches.

    UPDATE NOVEMBER 19: We have a new github organization to... "organize" contributions to all of the related projects. It is available at https://github.com/seSuperuser

    UPDATE2 NOVEMBER 19: We have relicensed the code. All future contributions will now be protected under GPLv3.
    *** Regarding the license change; according to both the FSF and the Apache Foundation, GPLv3 (but not GPLv2) is forward compatible with the Apache License 2.0, which is the license we are coming from. http://www.apache.org/licenses/GPL-compatibility.html . What this means, is that it is *ILLEGAL* for anyone to take any portion of the code that is contributed from this point onward, and use it in a closed source project. We do this in order to guarantee that this VITAL piece of software will remain available for EVERYONE in perpetuity.
    31
    Added binaries to my the repo at https://github.com/lbdroid/AOSP-SU-PATCH/tree/master/bin https://github.com/seSuperuser/AOSP-SU-PATCH/tree/master/bin

    These are *TEST* binaries ONLY. Its pretty solid. If you're going to root, this is definitely the best way to do so.
    The boot.img has dm-verity and forced crypto OFF.

    The idea is NOT to use as daily driver, while I can make no warranties at all regarding the integrity of the software, I use it myself, as do others, and its pretty good.
    What I would like, is to have a few lots of people try it out and report on whether things WORK, or NOT.

    IF NOT, as many details as possible about what happened, in particular, the kernel audit "adb shell dmesg | grep audit". On non-*nix host platforms that lack the grep command, you'll probably have to have to add quotes like this in order to use android's grep: "adb shell 'dmesg | grep audit'".

    How to try:
    0) Starting with a CLEAN system.img, get rid of supersu and all of its tentacles if you have it installed, if it was there, it will invalidate the tests.
    1) Install the Superuser.apk. Its just a regular untrusted android application. Yes, there is a security hole here, since we aren't (yet) authenticating the communications between the android application and the binaries, or validating the application by signature, or anything else that would prevent someone from writing a bad Superuser.apk. This is on the list of things to do.
    2) fastboot flash boot shamu-6.0-boot.img
    3) test everything you can think of to see if it works as expected.

    Note: there are some significant visual glitches in the android application, but nothing that makes it unusable.[/quote] @craigacgomez has been working on fixing up the UI. Its really paying off!!!


    How you can reproduce this YOURSELF, which we RECOMMEND if you feel like daily driving it (in addition, make sure that you UNDERSTAND everything it does before you decide to do that, you are responsible for yourself;

    You can build it any way you like, but I do my android userspace work in eclipse, so that is what I'm going to reference. Import the project from phhusson's git, including SUBMODULES. Right click the Superuser project --> Android Tools --> add native support. The library name you choose is irrelevant, since it won't actually build that library. Right click project again --> Build configurations --> Build all. This will produce two binaries under "libs", placeholder (which we won't be using), and su. You need the su binary. Then right click project again --> run as --> android application. This will build Superuser.apk, install it, and launch it.

    Next:
    repo init -u https://android.googlesource.com/platform/manifest -b android-6.0.0_r1
    repo sync
    Then apply su.patch from my git repo.
    UNFORTUNATELY, the repo command isn't smart enough to apply a patch that it created itself. That means that you are going to have to split up the patch into the individual projects and apply them separately to the different repositories. This isn't that hard of a step though, since there are only FOUR repositories I've modified... build/ (this just makes it possible to build with a recent linux distro that doesn't have an old enough version of openjdk by using oraclejdk1.7. The boot.img doesn't actually need the jdk to install anyway -- its just part of the checking stage, so its up to you.), device/moto/shamu/, external/sepolicy/, system/core/.

    After applying the patches, copy the su binary you generated with eclipse into device/moto/shamu/

    Then ". build/envsetup.sh; lunch aosp_shamu-userdebug; make bootimage". That should take a minute or two to complete and you will have a boot.img built from source in out/target/product/shamu/

    NEW UPDATE!!!!

    While I haven't yet gotten around to running a complete cleanup (very important family stuff takes priority), I *HAVE* managed to find a half hour to get on with the Android-N program. If anybody takes a peek at the AOSP-SU-PATCH repository on the AOSP-N branch, you should find some interesting things there.
    One warning first though... I updated the patches to apply against the N source code, and then updated some more to actually compile, and compiled it all. BUT HAVE NOT HAD THE OPPORTUNITY TO TEST IT YET.
    14
    I'll try to answer to the various questions I've seen about difference between "standard Linux" root, and an Android root.

    The basic idea is that if you think a desktop Linux is architecturally secure, then you're ****ing wrong. If Linux is not hit by virus is more because users are more educated, and softwares less used, thus less attacked. (Possibly they have less security holes as well).
    Android is a real fortress compared to a desktop Linux.

    Android uses different security features coming from Linux, but extended to a whole new domain.

    First historically, is multi-user. On desktop Linux you can have multiple users, but they most likely represent physical user.
    On Android, of course you have multi-user, but besides that, every single application is running as a different user!
    (And multi physical user is implemented by having + 10.000 as user id, which means you're limited to 10k apps installed, possibly it has increased)

    Next feature to be used in Android is SELinux.
    Multi-user is still not totally secure, because the security is not centralized in one file, some permissions can't be expressed as simply multi-users.
    For instance the permission "every user app can access their subfolder on the physical sdcard but not system apps" would be very annoying to express as multi-user, it would require ACL containing the whole user application range (ie 10k entries).
    Another example is "every program can read the properties, but only some can write them". This can't be done with filesystem side permissions.
    Obviously there are some other ways to handle it, and before SELinux was implemented, it was implemented in the property service itself.
    But that means yet another place to look at for security constraints.
    So here comes SELinux. Most security features are at the same place. Most important thing to know about SELinux is that it's a deny by-default policy.
    If you want anything to be done in a program, you MUST allow it explicitly.

    And then, next feature is dm-verity, or full-length verified boot.
    This is meant to ensure that all the programs running the security decisions aren't modified by a virus.
    Everything from display of bootlogo to SystemUI or Dialer are protected by a (manufacturer) public key.

    There are a lot of different security features I'm missing for the sake of simplicity.
    So, that's the Android security landscape, so let's discuss more precise topics:
    - The difference between desktop Linux's sudo and an Android su: truth is you could use the same mechanisms on a modern desktop Linux on Android. (I'd say Android's su are a bit further in time than desktop Linux's, getting rid of setuid is fairly new to desktop Linux with machinectl, while it has been in Android since 4.3). The difference lies in the libraries used. Developers on a desktop/server Linux are more confortable with all the tools available, and can more easily do tools. On Android, not so many people have proper knowledge of all the frameworks interferring. And Android has many security frameworks interfering.
    - As for manufacturer/Google-locking: Google doesn't want to reduce root usage. Or rather, it wants to reduce root usage, by implementing functions previously only usable by root! cf the Android Pay's guy comment about root. What they mostly care about, is not to have half of Android zombie devices. Every OS conceptor has Windows XP in mind and wants to avoid doing that again. Of course Google cares about its ads, but they definitely don't seem to be activist about it. You've got the whole adblock suite available on Play Store!

    Some informations about "Google-locking":
    - ALL chromebooks, without a single exceptions can be reflashed with whatever OS suits you.
    And when I say it can be reflashed, the documentation of how to do that is on Google's website!
    And this, while being (one of) the most secure consumer OS available.
    - Google documents (and implements on Nexus-es... I think/hope) what a verified boot should look like: http://source.android.com/devices/tech/security/verifiedboot/verified-boot.html
    what is very interesting here, is that it describes how a custom ROM can have its own keystore.
    This means Google documents and implements ways of having custom ROMs as secure as original manufacturer ROM.
    We are no longer speaking of just allowing users to flash anything. It is allowing users to flash anything... and to keep secure!
    If a user want to have pure AOSP build, without Google Apps, then he can, and it can still be secure!

    There is one big difference between Android and desktop Linux which makes things harder, I haven't mentioned yet (and which doesn't really belong in this precise thread)
    Manufacturers are allowed to do mostly what they want on the boot system, and an SU is tied to the boot system (even more since SELinux). Good news is that boot systems are mostly converging, and having a code working on many devices is getting easier.
    But having a 100% devices coverage will be impossible.
    14
    I've started working on a updating the Superuser app UI to Material Design (the current design looks horrible compared to MD apps). It's still in the early stages (but looks better already [emoji14]) and there's a lot more that can be done, but here's what my first stab looks like (first 1 hour of work). I will be pushing all my changes to my GitHub (https://github.com/craigacgomez/Widgets & https://github.com/craigacgomez/Superuser) and anyone is welcome to fork it, cherry-pick or send pull requests
    11
    Those logs don't really say much. I would need to see something from when it crashes out.
    How about adding a bug report to phhusson/Superuser ...

    I finally have a logical explanation for this... and it's not an issue with the su code.

    I did a bit of research about init.rc (Android Init Language) and how it works with Full Disk Encryption.

    Basically, when we have an encrypted volume (not using the default password/not the forceencrypt way), Android starts up with a minimal framework to load the pin/password entry screen, which call the class_start main, thereby starting all services in class main. At this point only services in class main and class core are started.
    Once the password has been verified, Android calls the class_reset main (thereby killing all services in class main) and then loads the full framework which involves calling class_start main & class_start late_start. At this point, services in class main are restarted and those in class late_start are started for the first time. Services in class core were never killed and continue running.

    So here's what happens when we have this (code from your patch):
    Code:
    service daemonsu /sbin/su --daemon
        class main
        user root
        seclabel u:r:su:s0
        oneshot
    1. When the minimal framework is loaded (to display the pin/password prompt), daemonsu starts up just fine when class_start main is called.
    2. After verifying the password, daemonsu is killed because class_reset main is called
    3. Since daemonsu is defined as oneshot (which means do not restart the service when it exits), when class_start main is called again, daemonsu is not restarted

    In short, because class main is started twice for devices with encrypted data and because daemonsu is oneshot, daemonsu doesn't start when class main is started to second time.

    What are our options?
    1. Move daemonsu to class late_start which gets called only after decrypting and gets called only once
    Code:
    service daemonsu /sbin/su --daemon
        class late_start
        user root
        seclabel u:r:su:s0
        oneshot
    2. Remove oneshot from the daemonsu service definition to allow daemonsu to respawn when class main is restarted
    Code:
    service daemonsu /sbin/su --daemon
        class main
        user root
        seclabel u:r:su:s0