phhusson / superuser

Keeping koush's Superuser fresh

Why another Superuser?

• Superuser should be open source. It's the gateway to root on your device. It must be open for independent security analysis. Obscurity (closed source) is not security.
• Superuser should be NDK buildable. No internal Android references.
• Superuser should also be AOSP buildable for those that want to embed it in their ROM.
• Superuser should also be AOSP embeddable, meaning a ROM can easily embed it into their Settings app.
• Maintenance and updates on both the market and source repositories should be timely.
• I want to be able to point users of my app to a Superuser solution that I wrote, that I know works, and that I can fix if something is wrong.
• Handle multiuser (4.2+) properly
• Handle concurrent su requests properly

Why NOT use this Superuser?

• If you have any doubt about how to go recover from a critical failure, DON'T TRY THIS
• Don't use it if you're afraid of a brick

Checking out the source

You'll need the "Widgets" dependency.

• $ mkdir /path/to/src
• $ cd /path/to/src
• $ git clone git://github.com/phhusson/Superuser
• $ cd Superuser
• $ git clone git://github.com/phhusson/Widgets

These repositories do not keep the actual projects in the top level directory. This is because they contain tests, libs, and samples.

Make sure the SDK Platform for API 19 is installed, through the Android SDK Manager. Install NDK Revision 9b from developer.android.com or use the latest and set NDK_TOOLCHAIN_VERSION=4.9.

Building the su and placeholder binaries

Make sure you have the android-ndk downloaded with the tool "ndk-build" in your path.

• $ cd /path/to/src/
• $ cd Superuser/Superuser
• $ ndk-build

The su binary will built into Superuser/Superuser/libs/armeabi/su, and the placeholder will be built into Superuser/Superuser/libs/armeabi/placeholder

Building the application

• $ ./gradlew assembleDebug

(Yes I use debug builds for the moment.)

Configuring the Package Name

//The Superuser distributed on Google Play is in the package name com.koushikdutta.superuser. (To be changed) To prevent conflicts with the Play store version, the build process changes the package name to com.thirdparty.superuser. You can configure this value by setting the following in your build.gradle

applicationId "com.thirdparty.superuser"

How to install?

You can install su in various different ways. All are not listed here.

Editing /system partition, and using placeholder binary

One way is through placeholder binary. It doesn't require to modify boot.img, only system partition. This doesn't work on Android M, and is considered obsolete. (SELinux policies aren't keeping up)

To install it this way, here are the needed steps:

• Rename /system/bin/app_process32 to /system/bin/app_process32.old
• Copy placeholder to system/bin/app_process32
• Ensure permissions of app_process32 are the same as of app_process32.old, including SELinux attributes (should be 0755 u:object_r:zygote_exec:s0)
• Put su file in system/xbin/
• Add /system/xbin/su --daemon in install-recovery.sh

From sources

Please refer to https://github.com/seSuperuser/AOSP-SU-PATCH/

Editing boot partition

Please refer to https://github.com/phhusson/super-bootimg/

TODO List

Here is a list of what's left to do, to be compatible with Chainfire's SuperSU (as documented at su.chainfire.eu):

• --mount-master

Here is an additional TODO list:

• Create restricted domains, which should match of basic needs. So that we can tell users "this app is not as bad as it might"
• Safer su --bind/su --init (should be package-name based, not uid-based)

Contact me

• IRC: #superuser-phh @ Freenode
• mail: [email protected]

Communication

This project is in REALLY early state, though some points have to be mentioned:

• For development purposes, please use the project's IRC: #superuser-phh @ Freenode
• Any issue discussed MUST have an entry in GitHub's bugtracker
• There will be security flaws. If you find one, please first discuss it with me privately ([email protected], phh on IRC).
• If you feel you need to be aware of security flaws before disclosure, please contact me. I might create a dedicated security mailing list.

Organisation

https://trello.com/b/adDbOmV0/superuser

Prebuilt images

I setup a robot to build rooted boot.img. The result is available at superuser.phh.me. Each boot.img is signed with the keystore at superuser.phh.me/keystore.img. Every boot.img contains the latest su and SELinux policy.

• orig-boot.img is extracted from the ROM and is provided for reference only.
• boot-su-eng.img is generated by calling su with the eng option.
• boot-su-user.img is generated by calling su without any arguments.

The matching APK is available at play.google.com/store/apps/details?id=me.phh.superuser.

If you want to add some ROMs or boot.img configurations into the auto-builder, open a pull-request or create an issue at github.com/phhusson/super-bootimg/tree/master/known-imgs.

superuser's Issues

su_sensitive domain addition

This would be a domain that can only be accessed through inputting of a strong password every time it is requested.

The key difference between su and su_sensive would be that su_sensitive will have permission to modify kernel security -- set permissive, reload selinux policy, etc.

It is important to keep this permission very highly protected, since it can be used to wreak all kinds of havoc, like modifying the boot image to disable dm-verity, replace the verity metadata and key, and modify the system partition without being immediately obvious.

I will discuss use case in another issue shortly.

Android 4.2 compatibility

I'm using AOSP 4.2.2, (and sadly can't upgrade for some reasons). While koush's Superuser seems to work on Android >= 2.2 properly, I wondered, why I just got the message: "Sorry, but your Android is too old for me..." on trying to flash your compiled version on my device.
What could I do, to get your great fork on my Android version to work, please?

replacing supersu app with the superuser app

Hi, i bought already rooted device with the supersu app preinstalled. I want to replace it with the superuser app from f-droid.

In the description of the superuser it is written (if i got it right) that I can install superuser parallel and then remove old supersu:

You must already have root for this to work, because it leverages the existing su and Superuser app to install itself. However, if you know what you are doing you can use this apk as a su/Superuser substitute if you are gaining an initial root. Once the install is completed you can disable or remove the old app.

Here is similar question on github: #29

Superuser is installed now in parallel, I can start it, it displays empty while field. I can open settings and that is it.

If I start rootverifier, it shows that device is rooted and supersu application is in use. So, would just deleting supersu do the job? I am sort of afraid of doing this.

Unable to remount system partition as rw after October security update

Opening an issue here because XDA apparently doesn't allow new users to contribute to your development thread.

Running your su 266 in eng verity crypt hidesu mode. I've just updated to the October security patch (on angler) and can no longer modify the system partition. Attempts to remount while running through adb and a terminal throw an error saying the device is in use. If I boot into recovery (TWRP) and modify the system partition, for example, changing the hosts file, I can complete the modifications (both by flashing and manually) but they are not reflected once I boot. Quite a baffling problem as the contents of the partition are persistent among reboots between OS and recovery, but are only reflected in recovery mode.

Is this directly related to your implementation of su or is this a new restriction from the latest android update? Alternatively, am I just a moron who is doing something wrong?

Just found this link explaining the issue:
http://www.the247tech.com/android/fix-android-n-preview-root-surviving-your-trip-to-mount-doom/

Is this something you've already addressed that has been broken by the update or did it never work?

Updated superuser.zip for recovery?

So reading this issue on the original Superuser git repo, I got here, and also reading issue #3 on this repo, I got to install the proper GUI app from the F-Droid repo. Now, all that is needed is to obtain an updated flashing package, so I could install Superuser off from recovery, and so I could get rid of SuperSU. Can anyone point me where I could download an updated package? And if not, could anyone instruct me (or point to a guide) how to build it off this repo on Linux?
Thanks in advance!

Make "getting `su binary`" path shorter and more obvious

It's so great it reached the F-Droid repo. (#3)
It's so sad that it behaves so weirdly:

1. It claims that su binary should be updated. The only option is through the Recovery
2. Tapping Recovery produces the error.
   A user is confused. He has no idea where to get the new su binary.
   Actually although I'm tracing the whole discussion here, but neither I know where I can get the su binary.
   Please put the su binary somewhere and make the app open that link for downloading. Thanks!

--context parameter not working

From here;
cea0c57

Missing change required here also:
https://github.com/phhusson/Superuser/blob/master/Superuser/jni/su/su.c#L678

Should add "z:" to optstring.

Submit application to F-Droid

Would it be possible to submit the application to the F-Droid repository?

Installation in OmniROM 6.0.1 (hammerhead)

Hello

I managed always to install SuperSU on my systems. But now I figured out that it isn't FOSS and need to change.

So here a few questions regarding your Superuser.

1. Is it compatible with Android 6+?
2. Do I first need to install the ROM (after a clean wipe?) and then flash "superuser.zip" from here ->http://superuser.phh.me/? Do I need to reboot between the installation of the ROM and flashing your zip?
3. Which Superuser app do I need to install from f-droid? I guess that one: https://f-droid.org/repository/browse/?fdfilter=superuser&fdid=me.phh.superuser

I tried it yesterday but the installation of OmniROM took forever so I restored to 5.1.1.

Error status 255

When I try to update from cache I get the following error:

E: Error in /tmp/sideload/package.zip (Status 255)

The phone I tested is a Samsung Galaxy Core (SM-G355M).

Considerations for Android 6.0 support

From what I can tell, the difference between 5.x and 6.0 basically involve a tightened up sepolicy. Specifically (and most likely), things like https://android.googlesource.com/platform/external/sepolicy/+/356df32778732aa576e15071bf2736fbbd778b77%5E!/#F0

The evil closed source supersu has implemented a sepolicy patcher in their "supolicy" command. It takes the factory sepolicy file and generates a "patched" sepolicy that works with the rest of their code. HOWEVER, they refuse to even document the changes they are making to the sepolicy, which makes it impossible to trust them.

It is likely that a similar policy patch will be required. It should be possible to build it into an update zip that can repack the boot.img similar to things like http://forum.xda-developers.com/nexus-6/development/fix-fed-patcher-forceencrypt-disable-t3203867

I also suggest that consideration should be made to having the entire su system (save for the android apk) made part of the boot.img rather than breaking dmverity on the system partition. Since the boot.img will require modification either way, it is trivial to add the rest in there. Possibly even simplifies the process, since there are other hijacks made available for obtaining the init context from the boot.img.

Binary VS Source testing

Doing a seinfo/sesearch diff between the policy built from source and from binary would be a need in short term.
Especially since applying binary rules makes things more explicit and heavy, and doesn't check neverallow.

Hopefully this even could be done in continuous integration.

Ability to regenerate verity data

From https://source.android.com/devices/tech/security/verifiedboot/dm-verity.html

Using su_sensitive domain as discussed in issue #10 ... we may calculate new metadata and key for dm-verity based on the current filesystem, and input them into metadata partition and boot image verity key. This will allow end user to make customizations to system partition (such as ad-blocking using /system/etc/hosts list) without being forced to disable dm-verity.

placeholder? What placeholder???

I've done the NDK portion of the build, but there is no "placeholder" to be found anywhere. Aside from the references in Superuser/README.md and Superuser/Superuser/assets/update-binary I don't see any placeholder binary anywhere.

While I'm at it, why specify attaching to /system/bin/app_process32? 64-bit builds aren't much more complicated and in the near future some devices might choose not to run /system/app/app_process32 (or run it as a restricted user), while /system/bin/app_process64 could remain in service longer. (noticing all userspace on this device is 64-bit binaries now)

REQUESTOR multiple define

In branch stableL, Superuser/Superuser/jni/Android.mk for LOCAL_MODULE:=su, there TWO definitions for REQUESTOR, "-DREQUESTOR="$(SUPERUSER_PACKAGE)"" and "-DREQUESTOR="$(shell cat packageName)"". The preprocessor doesn't really like this. I'd simply rip it out, but it looks like it evolved that way for some reason, so ripping it out without knowing the reason seems bad.

I would like some binaries, please, if possible

Dear @phhusson, @jeekajoo, @AndyLiu008, and others:

Hi!

I wonder if someone could please build binaries of phhusson/Superuser and upload them somewhere. Maybe to your website or Dropbox or Google Drive or somewhere.

You will need to use https://github.com/phhusson/Widgets/ in order to complete the build.

There's a Docker image in @jeekajoo's GitHub space here which might help you.

Thanks!

--live option to sepolicy-inject (already implemented)

I have seen in README that you have --live option to sepolicy-inject in your TODO. If you want you can use implementation from my sepolicy-inject fork here: https://github.com/xmikos/setools-android

My setools-android/sepolicy-inject is made buildable with NDK out of the box. I have also implemented support for allowing multiple permissions at once in sepolicy-inject.

Example of usage:

sepolicy-inject -s vdc -t devpts -c chr_file -p read,write -l

Build issues

I'm not sure if my build environment is not correctly set up or they are legitimately issues, but there is 2 related issues I encountered while trying to build Superuser.

README file lists API 19 and NDK 9b as requirements, but su binary doesn't compile correctly while using them.

$ ls $ANDROID_HOME/platforms/android-19
data/  skins/  templates/  android.jar  build.prop  framework.aidl  sdk.properties  source.properties  uiautomator.jar

$ ls `which ndk-build`
/opt/android/ndk-r9b/ndk-build

$ cat /opt/android/ndk-r9b/RELEASE.TXT
r9b

$ ndk-build 
[x86] Compile        : selinux <= fgetfilecon.c
jni/libselinux/src/fgetfilecon.c:6:23: fatal error: sys/xattr.h: No such file or directory
compilation terminated.
make: *** [obj/local/x86/objs/selinux/src/fgetfilecon.o] Error 1

It looks like sys/attr.h was added later in SDK 21.

$ find /opt/android/ndk -name xattr.h | grep 'sys/'
/opt/android/ndk/android-ndk-r10e/platforms/android-21/arch-x86/usr/include/sys/xattr.h
/opt/android/ndk/android-ndk-r10e/platforms/android-21/arch-x86_64/usr/include/sys/xattr.h
/opt/android/ndk/android-ndk-r10e/platforms/android-21/arch-mips64/usr/include/sys/xattr.h
/opt/android/ndk/android-ndk-r10e/platforms/android-21/arch-mips/usr/include/sys/xattr.h
/opt/android/ndk/android-ndk-r10e/platforms/android-21/arch-arm/usr/include/sys/xattr.h
/opt/android/ndk/android-ndk-r10e/platforms/android-21/arch-arm64/usr/include/sys/xattr.h

If I switch to NDK 10, it compiles correctly but the resulting binary won't work in Android 4.4

$ export PATH=/opt/android/ndk/android-ndk-r10e:$PATH
$ which ndk-build 
/opt/android/ndk/android-ndk-r10e/ndk-build
$ cat /opt/android/ndk/android-ndk-r10e/RELEASE.TXT 
r10e

$ ndk-build clean
...
$ ndk-build
... compiles ...

but no libs/*/placeholder exits as the README says?

$ ls libs/*/
libs/armeabi/:
su*

libs/mips/:
su*

libs/x86/:
su*

And the resulting binary doesn't work

$ adb push libs/x86/su /system/xbin/su
3255 KB/s (602704 bytes in 0.180s)
$ adb shell
# ls -lZ /system/xbin/su*                                   
-rwxrwxrwx root     root              u:object_r:system_file:s0 su
-rwsr-sr-x root     root              u:object_r:su_exec:s0 su.original

# su
CANNOT LINK EXECUTABLE: cannot locate symbol "signal" referenced by "su"...

I know selinux contexts don't match but linking problem is seperate and it is a known issue

I transcripted this on a x86 4.4 emulator but the error was same a 4.4 armv7 phone last night.
I also tried changing include lines to linux/attr.h as they were on older SDK versions, but they seem to be different headers than sys/attr.h so there were compile errors. I didn't dig it further.

Titanium Backup can't find su

Name says it all. We added your su and all the apps I've tried work except this one. Let me know if more info is needed. Android 7.0.0_r6 angler

"Accept" button not usable

Hello,

When I try to give root access to apps, the "accept" button is not usable 2 minutes after boot time.
When I unlock the SIM card, if I'm fast enough, I can allow root access to one app, but after that, the accept button is not "touchable" anymore.

In the logs, I have :
"Syserr : binary is old" => the error message shown on start of the superuser app
This is odd, since I flashed my boot image this morning, and reinstalled the SuperUser app from F-Droid.
PackageManager: Failure retrieving resources for me.phh.superuser: Resource ID #0x0
ResourceType : No package identifier when getting value for resource number 0x00000000

Do you know what it means ?

Superuser Grants Permission to ADB even when set to Root to Apps Only

Builds fine, installs fine, works fine, except for still granting root via ADB even when set to granting root to apps only.

How to repeat: go to superuser settings, set to root to apps only, then enable adb, connect to PC, type adb shell, type su and root is granted for /data/data/

Also, when root is disabled within superuser, you can't return to any other settings. The only way to change it is through development settings.

This is on LP 5.1.1, custom rom...

Security vuln on 4.3+4.4+5.x: overwrite any file/device with the string "Permission denied"

[x-post from https://github.com/koush/issues/284]

This applies to any apps that request root permission and the user subsequently hits Deny. This only applies to all versions 4.3+ which use client/server instead of the traditional setuid model. The attacker only needs the ability to run executable code (such as embedded in a "libs" directory).

[exploit details withheld: contact me to discuss]

After the exploit code is run by an untrusted user, the user is presented with a permission request screen. Obviously there is no problem if the user allows permission. However, if the user denies permission, the string "Permission denied" is written into the file of the attacker's choice. This could have any number of consequences. Clearly this can be used to brick the phone. For example I could pass /dev/block/mmcblk0p40 and stick "Permission denied" at the beginning of the user's baseband or fastboot partition. Or I could break any apps on the writable data partition by overwriting their classes.dex.

The permission request screen can be easily hidden with a bit of WindowManager, Toast or Intent magic to get out of there before it even loads.

I don't know yet if the Permission denied string can be changed, but even as is, it means rogue apps can damage the phone which is pretty scary.

(Aside: thank you for fixing CVE-2013-6770 properly by removing the setuid bit. I had no idea this fork existed until after I reported my other bug.)

Why I get IOException: Permission denied When My apk quest su?

My phone is HUAWEI HONOR 4A 5.1.1

0. push SuperUser apk(com.koushikdutta.superuser) to /system/app, and reboot phone(HUAWEI HONOR 4A 5.1.1)

1. run su --daemon under root (after this, adb shell, exe su I can get "#")

2. but when exe su in my test apk(com.example.suTest), SuperUser apk's question dialog did not show, my test apk code as this:

if (exec("su", "id").contains("uid=0")) {
//root
}

    public static String exec(String su, String cmd) {
        DataOutputStream dos = null;
        BufferedReader bf = null;
        try {
            java.lang.Process process = Runtime.getRuntime().exec(su);
            dos = new DataOutputStream(process.getOutputStream());
            bf = new BufferedReader(new InputStreamReader(process.getInputStream()));
            dos.writeBytes(cmd + "\n");
            dos.writeBytes("exit\n");
            StringBuilder builder = new StringBuilder();
            String tmp;
            while ((tmp = bf.readLine()) != null) {
                Log.i(TAG, "exec tmp: " + tmp);
                builder.append(tmp);
            }
            dos.flush();
            String ret =  builder.toString();
            return ret;
        } catch (IOException e) {
            Log.e(TAG, "", e);
        } finally {
            close(dos);
            close(bf);
        }
        return "";
    }

I tried several times, so the log time maybe not match

SuperUser apk log:

03-10 21:47:36.114 V/ActivityThread(28244): ActivityThread,callActivityOnCreate
03-10 21:47:36.124 D/CubicBezierInterpolator(28244): CubicBezierInterpolator  mControlPoint1x = 0.2, mControlPoint1y = 0.65, mControlPoint2x = 0.28, mControlPoint2y = 0.97
03-10 21:47:36.124 D/CubicBezierInterpolator(28244): CubicBezierInterpolator  mControlPoint1x = 0.2, mControlPoint1y = 0.65, mControlPoint2x = 0.28, mControlPoint2y = 0.97
03-10 21:47:36.134 D/CubicBezierInterpolator(28244): CubicBezierInterpolator  mControlPoint1x = 0.2, mControlPoint1y = 0.65, mControlPoint2x = 0.28, mControlPoint2y = 0.97
03-10 21:47:36.134 D/CubicBezierInterpolator(28244): CubicBezierInterpolator  mControlPoint1x = 0.2, mControlPoint1y = 0.65, mControlPoint2x = 0.28, mControlPoint2y = 0.97
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.134 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.144 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.144 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.144 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.144 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.174 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.174 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.174 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.184 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.184 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.184 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.184 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.184 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.184 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.184 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.194 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.194 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.194 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.194 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.194 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.194 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.194 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.194 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.204 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.204 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.204 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.204 E/ZipFileCache(28244): init failed when open zip file.
03-10 21:47:36.214 I/Superuser(28244): Permission denied
03-10 21:47:36.214 I/Superuser(28244): java.io.IOException: Permission denied
03-10 21:47:36.214 I/Superuser(28244):  at android.net.LocalSocketImpl.connectLocal(Native Method)
03-10 21:47:36.214 I/Superuser(28244):  at android.net.LocalSocketImpl.connect(LocalSocketImpl.java:293)
03-10 21:47:36.214 I/Superuser(28244):  at android.net.LocalSocket.connect(LocalSocket.java:130)
03-10 21:47:36.214 I/Superuser(28244):  at com.koushikdutta.superuser.MultitaskSuRequestActivity$7.run(MultitaskSuRequestActivity.java:278)
03-10 21:47:36.224 I/ViewRootImpl(28244): CPU Rendering VSync enable = false
03-10 21:47:36.224 I/View    (28244): ssignParent(ViewParent parent) parent is: android.view.ViewRootImpl@3255354a
03-10 21:47:36.254 E/HAL     (28244): hw_get_module_by_class: lib loaded: /system/lib/hw/gralloc.msm8909.so

test apk log:

03-10 22:09:28.514 I/tag( 6291): exec tmp: log: [d] su invoked.
03-10 22:09:28.524 I/tag( 6291): exec tmp: log: [w] hacks: Testing (com.keramidas.TitaniumBackup:0:10068)
03-10 22:09:28.544 I/tag( 6291): exec tmp: log: [d] mkdir /dev/com.koushikdutta.superuser 0777
03-10 22:09:28.554 I/tag( 6291): exec tmp: log: [d] chown (/dev/com.koushikdutta.superuser, 10067, 10067)
03-10 22:09:28.574 I/tag( 6291): exec tmp: log: [d] database_check ret: 0
03-10 22:09:28.584 I/tag( 6291): exec tmp: log: [d] /dev/com.koushikdutta.superuser/.socket23342
03-10 22:09:28.594 I/tag( 6291): exec tmp: log: [d] socket_create_temp socket_serv_fd: 4
03-10 22:09:28.614 I/tag( 6291): exec tmp: log: [d] send_request needs_owner_login_prompt: 0
03-10 22:09:28.624 I/tag( 6291): exec tmp: log: [d]  /system/bin/app_process
03-10 22:09:28.634 I/tag( 6291): exec tmp: log: [d]
03-10 22:09:28.634 I/tag( 6291): exec tmp:
03-10 22:09:48.674 I/tag( 6291): exec tmp: log: [e] select failed with 2: No such file or directory
03-10 22:09:48.674 I/tag( 6291): exec tmp: log: [d]  /system/bin/app_process
03-10 22:09:48.694 I/tag( 6291): exec tmp: log: [d]
03-10 22:09:48.694 I/tag( 6291): exec tmp:
03-10 22:09:48.714 I/tag( 6291): exec tmp: log: [w] request rejected (10186->0 /system/bin/sh)
03-10 22:09:48.754 I/tag( 6291): exec tmp: log: [d] starting daemon client 10186 10186
03-10 22:09:48.754 I/tag( 6291): exec tmp: log: [d] connecting client 23321
03-10 22:09:48.754 I/tag( 6291): exec tmp: log: [d] client exited 1

daemon log:

log: [d] remote pid: 30221
log: [d] remote pts_slave:
log: [d] remote uid: 10068
log: [d] remote req pid: 30176
log: [d] remote args: 1
log: [d] waiting for child exit
log: [d] sending code
log: [d] child exited

Your Superuser for f-droid

Is it possible to bring your version of superuser to fdroid? If so it would be nice, since fdroid version still does not support android 5.0 and higher.

Android TV support

Support for Android TV would be nice. This might include:

• Manifest definitions to say the app is compatible with ATV
• New logo for home screen
• Remote friendly menus (not sure how hard this might be)

Guide for AOSP developers

Is there a guide on how to add both the su executable and the SuperUser application to the AOSP build and compile it along with the rest of the AOSP code?
Do I just copy the su part to /system/extras/su/
and the application to /packages/apps/ ? While Android.mk should I use for the app?
A guide for that would be awesome.

Thanks!

ARM64 support

So far from what it seems, there is no ARM64 support for phones such as the Samsung Galaxy S6 and S6 edge. Would it be possible to add support for ARM64?

Can't get updated su binary to install under SlimKat on an SG3.

I'm trying to get this version of Superuser installed from FDroid, onto my Samsung Galaxy 3 running SlimKat 4.4.4 ROM. I already had the other SuperUser installed from FDroid.

This newer more open version keeps popping up a notification saying the su binary is out of date. Trying to install http://superuser.phh.me/superuser.zip from recovery shows an error. I've had to revert to the older Superuser.

There really should be better instructions to get this to work, I had to hunt through other peoples issues to figure this out. Still not working though.

Android M support plan ?

I used this on android M , device is xiaomi 5
dmesg as this:
avc: denied { execute_no_trans } comm="init" scontext=u:r:init:s0 tcontext=u:object_r:system_file:s0 tclass=file

Verified boot integration

Coming with Android M, verified boot will become mandatory on many devices. ( https://static.googleusercontent.com/media/source.android.com/fr//compatibility/android-cdd.pdf section 9.10)
It is unclear whether this refers to http://source.android.com/devices/tech/security/verifiedboot/verified-boot.html, but we might expect so.

This enables users to keep a trusted (from a user point-of-view) system, by having a verifiable (by viewing fingerprint of the keystore at boot).
We could integrate this verified boot in our SU.
Multiple possibilities:

• "Superuser's organisation" generation: The "Superuser" organisation has one keystore, and generates root for many ROMs/devices. This way, assuming all bootloaders uses the same algorithm, every devices rooted by our root will have the same fingerprint, easier to remember, and users can compare their fingerprints to ensure noone got MITMed
• auto-generation without destroying: We could generate a keystore on first boot, and ask the user to protect it with a password on first boot, and then all updates would resign boot.img/system partition with this key
• auto-generation with destroying: Generate a new keystore everytime we flash a new boot.img/system partition (makes it almost impossible for the user to ensure the fingerprint is the expected one)
• on-device user generation: As auto-generation without destroying, but only with a keystore provided by the user if he wants to put one
• off-device user generation: Mostly the same as Superuser's organisation generation, as script will be public anyway, but the user takes care of the generation itself.

I got undefined reference to 'atexit' when build arm?

hello, when i build Superuser as instraction, i got this error:

ndk-build
[x86] Install                :su => libs/x86/su
[armeabi] Executable  :su
jni/su/su.c:1001: error: undefined reference to 'atexit'
external/jemalloc/src/jemalloc.c:707: error: undefined reference to 'atexit'
collect2: error: ld returned 1 exit status
make: *** [obj/local/armeabi/su] Error 1

I look it on google,stack overflow,etc. but i got noting useful,please help me.

Doesn't work on Samsung S4 I9500 with Android 5.0.1 stock ROM (LRX22C.I9500XXUHOD4)

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 ?

ndk-build not building placeholder

I followed README.md to the letter, and I was able to make su build, as well as an APK with the GUI app side. However, placeholder did not build, so I cannot follow that step. Is this something new that the readme just needs updating for?

If it matters, this is a Nexus 6 I'm targeting, running Android 5.0.1, and installing the binary via TWRP with ADB.

Without placeholder, su inevitably exits with '1' whenever I try to run it. Not even sure if the daemon is starting.

cannot compile the su binary

Cannot build the su binary in ndkr13. It seems like the nested function causing the trouble? Do I need special configuration to compile it?

[x86] Compile        : su <= su.c
In file included from jni/su/su.c:45:
jni/su/binds.h:17:9: warning: 'BINDSH' is used as a header guard here, followed by #define of a
      different macro [-Wheader-guard]
#ifndef BINDSH
        ^~~~~~
jni/su/binds.h:18:9: note: 'BINDS_H' is defined here; did you mean 'BINDSH'?
#define BINDS_H
        ^~~~~~~
        BINDSH                                                                                   
1 warning generated.
[x86] Compile        : su <= daemon.c
In file included from jni/su/daemon.c:50:
jni/su/binds.h:17:9: warning: 'BINDSH' is used as a header guard here, followed by #define of a
      different macro [-Wheader-guard]
#ifndef BINDSH
        ^~~~~~
jni/su/binds.h:18:9: note: 'BINDS_H' is defined here; did you mean 'BINDSH'?
#define BINDS_H
        ^~~~~~~
        BINDSH
jni/su/daemon.c:464:6: warning: comparison of unsigned expression < 0 is always false
      [-Wtautological-compare]
        if(s<0)
           ~^~
jni/su/daemon.c:506:69: error: function definition is not allowed here
        auto void cb(void *arg, int uid, const char *src, const char *dst) {
                                                                           ^
jni/su/daemon.c:545:15: error: use of undeclared identifier 'cb'
        bind_foreach(cb, NULL);
                     ^
jni/su/daemon.c:549:53: error: function definition is not allowed here
        auto void cb(void *arg, int uid, const char *path) {
                                                           ^
jni/su/daemon.c:566:15: error: use of undeclared identifier 'cb'
        init_foreach(cb, NULL);
                     ^
2 warnings and 4 errors generated.
make: *** [obj/local/x86/objs/su/su/daemon.o] Error 1

No keystore-less build

Building without having KEYSTORE env set is not possible

No neverallow breakage policy

Something that could be great would be a specific policy which doesn't break any neverallow, and would actually be able to pass CTS (except for the explicit check of "su" binary)
This would obviously make this su not as useful or powerful, but I believe this could trigger interesting discussions either on Google's side or manufacturer's side.
Possibly it would make Google update neverallow to harder policies, but I doubt they would add neverallow rules "just to piss of SU guys"

Prevent su domain from remounting or modifying partitions, esp. system, boot, metadata.

Depends on issue #10 - since this operation is required.
Depended on by issue #11 since it requires blocking everything like that.

IDEA - SuperUser as permission

Seeing how CyanogenMod implemented SU as a permission into their own fork, would you not think that a better approach for SuperUser access in apps would be a system-wide controlled feature, via opt-in permissions?

Especially with the 6.0 permission system, I think it would be a lot more humane way of accessing superuser-reliant content (system providing access to files, filesystem, etc.) through system API calls (a la libsupersu), instead of starting own su processes. That way the system could still keep up granular access (allow-deny with remember option), while management would be in Settings-Applications-Permissions.

This would, of course, require a framework-level addition instead of a separate application, and my idea is more targeted towards the custom ROM sphere (and maybe even at manufacturers?).

BIZARRE warning in my logcats right after flashing superuser.zip !

Hello.

After flashing the superuser.zip for the first time, a strange warning started to show in my logcats. Something like:

W/su ( 3736): hacks: Testing (com.keramidas.TitaniumBackup:-1:0)
W/su ( 3737): hacks: Testing (com.keramidas.TitaniumBackup:10060), 0

This warnings were appearing continuously but without a pattern. I imidiately stop using the device for its original purpose and start to meticulously search for the origin of the warning. But the only thing I found out is that the messages appear only when wifi or data are on or in the boot process.

After several tests I was thinking that the problem could be with the superuser binary. I wiped my device and clean installed CM 12,1. After the installation I only installed the superuser app and changed the root configurations on developer options (always paying attention to the logs) and right after that I flashed the supersu.zip.

Right after booting my device, the same warnings start to appear again :( The most bizarre of all, is that I never installed the TitaniumBackup app or nothing similar...

Someone have a similar problem or could give me some light about the situation, please?

PS: Sorry for my poor english...

Does it support systemless root?

Several months ago Samsung note 5 needs custom kernel to root ,but then Chainfire's SuperSU provides a feature called "systemless root" (http://forum.xda-developers.com/showpost.php?p=64161125&postcount=3), which can root note 5 without custom kernel .Does this Superuser support it ?

Replace supersu with phhusson/superuser

Ther is an app called Supersu Me which can replace KingoRoot with SuperSu while runtime. Is something like this possible with supersu and superuser, to get rid of supersu? What would I need to do, and what is specific to which device?
I'm beginner with that, so I'm sorry if this sounds stupid 📦

mfg schabi

Compile inline with AOSP n preview

Can we extract those nested methods to allow compilation inline with AOSP?

external/Superuser/Superuser/jni/su/daemon.c:506:69: error: function definition is not allowed here
auto void cb(void *arg, int uid, const char *src, const char *dst) {

external/Superuser/Superuser/jni/su/daemon.c:545:15: error: use of undeclared identifier 'cb'
bind_foreach(cb, NULL);

external/Superuser/Superuser/jni/su/daemon.c:549:53: error: function definition is not allowed here
auto void cb(void *arg, int uid, const char *path) {

external/Superuser/Superuser/jni/su/daemon.c:566:15: error: use of undeclared identifier 'cb'
init_foreach(cb, NULL);

Question about progress; possible help; and donations.

Would you be interested in defining a list of all the todos necessary to have a complete viable alternative to supersu? I mean including the latest versions of android. I see that there is a flashable zip (http://superuser.phh.me/) here. But I'm not sure if that includes 6.0.1, etc.

Of course there is a lot of interest, and I'm not sure how you feel about this but there is also a lot of interest in donating to such a cause. That is why I ask if you could define these so they can be put on bountysource, according to this (https://www.reddit.com/r/linux/comments/3myp1r/why_the_hell_android_community_support_a/) there are many who are willing to help financially. Though, I guess, it isn't just helping you financially but also getting those with expertise to help you as there are some who don't wanna do it for free.

The overall goal to make it as easy as a universal flashable zip, and keeping the superuser apk updated from time to time, maybe a lot to ask, so maybe all the help and incentive that one could put on the table would be best? I apologize if this is seems uninformed or pushy, but I'm very interested in supporting open source projects, and for those for which I know little about, I guess the best I can do is to bring more awareness to it.

Thanks for reading.

APK detection

When su/su_sensitive are properly implemented
We might want to detect the calling APK to determine if it is supposed to be run in su or su_sensitive.
With a whitelist of apps needing su_sensitive, and a notice in the popup that the app didn't declare which sensitivity it has?

Update About tab from app & icon app from Google Play and F-Droid stores

For differentiate both apps (Superuser by koush & Superuser by pphusson)

Run application as root

Once I've been granted superuser capabilities, is it possible for SU app to relaunch the application as root:root? or to seteuid/setuid to root?

MRA58R boot.img on MRA58X?

I recently performed an OTA to 6.0.1 on my Nexus 6 and would like to root it. I'd really would like to avoid using a closed source Superuser like SuperSU so I was very excited to find this fork. I was just wondering if I could use the MRA58R boot.img on my phone?

Thanks!

Getting exe path failed with 13: Permission denied

01-11 18:11:13.997 14152-14152/? D/su: su invoked.
01-11 18:11:14.007 14153-14153/? W/su: hacks: Testing (com.keramidas.TitaniumBackup:-1:0)
01-11 18:11:14.017 14154-14154/? D/su: Allowing root/system/radio.
01-11 18:11:14.017 14155-14155/? W/su: hacks: Testing (com.keramidas.TitaniumBackup:0), 2075236441
01-11 18:11:14.017 14156-14156/? D/su: 0 /sbin/su executing 0 /system/bin/sh using binary /system/bin/sh : sh
01-11 18:11:34.047 14534-14534/? D/su: su invoked.
01-11 18:11:34.057 14535-14535/? W/su: hacks: Testing (com.keramidas.TitaniumBackup:-1:0)
01-11 18:11:34.057 14536-14536/? E/su: Getting exe path failed with 13: Permission denied
01-11 18:11:34.067 14538-14538/? W/su: request rejected (10104->0 /system/bin/sh)

using latest master code, In Android 4.3.
using su in adb shell is ok, but other app return Getting exe path failed with 13: Permission denied, why?

Writing to sysfs is broken (sometimes)

Use case: Nexus 6P's touchscreen sensor exposes a parameter that enables double tap to wake via sysfs (/sys/devices/soc.0/f9924000.i2c/i2c-2/2-0070/input/input0/wake_gesture). Kernel Adiutor as well as a number of apps, some of them open source (for example https://github.com/manuelsc/DoubleTap-for-6P) allow the user to enable dt2w either interactively from within the app or on boot.

What's broken: While all of those apps work when toggling the parameter from within the app, none of them are able to do it on boot. In a root adb shell, 'echo 1 > /sys/devices/soc.0/f9924000.i2c/i2c-2/2-0070/input/input0/wake_gesture' either fails silently (sh) or reports EINVAL (ash).

Why I think it's phh superuser: There are no reports of this not working either via the shell or with the apps and it is widely used. Presumably, this means it works on SuperSU. It certainly worked for me on a custom ROM with SuperSU baked in.

Why no patch/fix from me: I'm a bit mystified by a number of things. I suspect this is your locked-down SELinux policy at work, but I'm seeing nothing in either dmesg or logcat when attempting to write with an su shell. If it is SELinux, would the context be different for an activity that runs on BOOT_COMPLETED compared to when it is started normally?

Frankly, although I'm prepared to debug it further myself, it would be a big help if someone who knows what they're doing with this stuff chimed in first to at the very least point me in the right direction.

Version detection

There are several problems about version detection:

• First of all, su -V should return a version number (same for -v?)
• libsuperuser, which I assume most apps use, sets up the context only if su -V says SUPERUSER
  Luckily for us, it only do a contains() so we can tell we do SUPERUSER
• Some apps, like FlashFire do the check by themselves. Same trick can be applied as well.