phh's SuperUser/ OpenSource SELinux-capable SuperUser

Search This thread

phhusson

Recognized Developer
Jul 23, 2009
2,489
4,794
Paris
Hi,

IT MIGHT BRICK YOUR DEVICE.
Always ensure you have a way back.


Here is a thread about my fork of Koush's Superuser, to handle SELinux: https://github.com/seSuperuser/Superuser
So I would like your help to make this SuperUser a proud opensource SU app!

If you have an application that requires root, and which needs specific SELinux configuration please ask!


Build bot: https://superuser.phh.me/
Currently, four flavors of su are available on the build-bot:
- "eng" which puts "su" in permissive mode. This is the most compatible mode, but you should trust the apps you give root to. This does NOT put SELinux in permissive mode.
- "noverity" is eng and dm-verity disabled
- "nocrypt" is eng, dm-verity and dm-crypt disabled
- "user" is meant to give a safe su. su-apps won't be able to access to your Android Pay (for instance) informations, or keep persistent su access without your consent

Please note that user is in heavy development and isn't up to its promises at the moment.

I setup a build bot, which generates boot.img based on my solution, and pushes them to https://superuser.phh.me/

I did this build bot in a way so it is easy to add new ROMs, so don't hesitate asking for new ROM/devices support.
Supporting new devices might mean some additional work on http://github.com/seSuperuser/super-bootimg/ if they are using non-standard boot.img format, but the aim is to support as many devices as possible.
You need to install the APK from PlayStore afterwards: https://play.google.com/store/apps/details?id=me.phh.superuser

Bot-supported devices
Here are some devices, but there are many more !
- A *lot* of Archos devices
- All Nexus-es, including Pixel C (if some Nexus is missing, just ask!)
- nVidia Shield TV
- nVidia Shield Tablet
- Fairphone 2

update.zip format
The zip is available at https://superuser.phh.me/superuser.zip
It should be able to root any device supported by super-bootimg from TWRP (and possibly other custom recoverys)
You still need to install the APK afterwards. https://play.google.com/store/apps/details?id=me.phh.superuser https://f-droid.org/repository/brow...lob/master/known-imgs/nexus/hammerhead/MRA58N describes a firmware, nothing device-specific). This only requires to do some PRs to add a device, or on updated firmwares
- Testers
- UI designer: The current UI dates back from 4.1...? It is really ugly and not really usable.
- Testers
- Root-related devs: SELinux policies are still being written
- Testers
- Security reviewers
- Testers

Bug report
If some app doesn't work, please ask me, not the dev.
I consider I have to fix support for other apps, not the other way around.



ChangeLog
2016-01-31 r170: superuser.zip can be included in other update.zip
2016-01-27 r166: Add support for Viper4Android
2016-01-15 r162: Add su --bind and su --init commands
2016-01-10 r154: Files are no longer copied multiple times. Fixes MultiROM, and multiple install for update.
2016-01-06 r152: Fix support for ChromeOS-like format (Pixel C)
2016-01-01 r144: Detect chromeos-style signature, and don't try to resign it in that case
2015-12-30 r143: Improved compatibility with apps.
2015-12-28 r142: Changed naming convention to include device name and release
2015-12-28: Added "nocrypt" target
2015-12-13: Added "noverity" target to buildbot
2015-12-13: Add options for noencrypt, noverity
2015-12-03: Fix TitaniumBackup
2015-11-24: mount --bind to /system/xbin/su if it exists to override ROM's su
2015-11-23: Fix CF.Lumen
2015-11-14: Add super-bootimg's version in boot.img, several network/firewall-related permissions
2015-11-11: Access to Android's services
2015-11-10: Recursive su access
2015-11-09: Fix pm disable command
 
Last edited:

Benko111

Senior Member
May 22, 2013
76
38
Berlin
It seems like many people still haven't understood the purpose of apps like SuperSu and Superuser. They are no exploits and don't gain your root access. What they do is they manage the root access and enable you to select which apps to grant root access, otherwise every single application on your device would have it. They are root managers. So this project won't help you in getting root for your device as long as there's no method (exploit) to gain it.
 

phhusson

Recognized Developer
Jul 23, 2009
2,489
4,794
Paris
Not much activity here, but a lot on my side.
Android 6.0 is now out, with its new SELinux policy, which makes it impossible to update the policy after the boot, and dm-verity becomes mandatory (so no /system change without boot.img)
I'm thus totally retargetting my work:
- I've created https://github.com/phhusson/super-bootimg which will edit boot.img (the complicated part, because it needs A LOT of testing across many devices)
- change sepolicy
- Add su in /sbin/su
- Enable su daemon

With various options to disable dm-verity, encryption, etc. (please note that this is NOT required, since only boot.img is changed)
 

banderos101

Senior Member
Dec 26, 2010
1,261
374
Cannot express enough how much i want this project to succeed

And, at least for myself

"I also wonder about displaying an user-understandable SELinux policy, so that root applications can be "more secure
Would anyone be interested in such a feature?"

......Hell yeah, that most certainly does interest me.........controllable levels of su right?

Obviously, if its possible to do........even if android denies this possibility, an open source su is most assuredly welcome from this neck of the woods

I wish this project major luck



Edit
"(I'm thinking that I'm trying to be even more secure than "standard" non-rooted ROMs, that's perhaps a bit optimistic.)"

I love that mentality, and im enjoying immensley your discussions on github with lbdroid........i love that your taking security more seriously then most...love where your coming from on this.....major props
 
Last edited:

kennylam

Member
Aug 5, 2007
16
18
To better test on shell of recovery without making an update.zip , I modified the sepolicy-inject.c so that the usage() no longer blocks the "booting.sh"

on sepolicy-inject.c:377, insert a line "if ( NULL == optarg ) break;", as in my shell there will be a parameter value with null on last entry of "char** arguv", which will trigger the default switching case and exit the sepolicy-inject unexpectedly.

......
while ((ch = getopt_long(argc, argv, "a:f:g:s:t:c:p:p:eek::Z:z:n", long_options, NULL)) != -1) {
if ( NULL == optarg ) break;
switch (ch) {
......
 
Last edited:

phhusson

Recognized Developer
Jul 23, 2009
2,489
4,794
Paris
To better test on shell of recovery without making an update.zip , I modified the sepolicy-inject.c so that the usage() no longer blocks the "booting.sh"

on sepolicy-inject.c:377, insert a line "if ( NULL == optarg ) break;", as in my shell there will be a parameter value with null on last entry of "char** arguv", which will trigger the default switching case and exit the sepolicy-inject unexpectedly.

......
while ((ch = getopt_long(argc, argv, "a:f:g:s:t:c:p:p:eek::Z:z:n", long_options, NULL)) != -1) {
if ( NULL == optarg ) break;
switch (ch) {
......

I'm not sure I understand...
When calling what command do you need this?
 

zameer_yus

Senior Member
Mar 14, 2013
60
4
Hi,

IT MIGHT BRICK YOUR DEVICE.
Always ensure you have a way back.



I'm the author of a fork of Koush's Superuser, to handle SELinux: https://github.com/phhusson/Superuser
It is in early-stage, but thanks to recent events related to SuperSU, it got some spotlight.

So I would like your help to make this SuperUser a proud opensource SU app!

I have mostly two sides of things left to do:
- Device compatiblity/update.zip
- Application compatbility

I've tested my Superuser on Qualcomm/CAF 5.1 devices, on MTK 5.1 devices, on CAF 6.0, on Nexus 5/9 6.0, and I believe it should work on most devices which are close enough to AOSP.

I have missing steps to be compatible with SuperSU (see https://github.com/phhusson/Superuser#todo-list ).
I'd like to have feedback from app developers about which features they need the most.

If you have an application that requires root, and which needs specific SELinux configuration please ask!

There are main two types of builds, and some sub-types in it:
- @doitright did an integration in an AOSP tree, to make it suitable for ROM integration, https://github.com/lbdroid/AOSP-SU-PATCH/
- I did http://github.com/phhusson/super-bootimg/ which integrates su in a binary boot.img, and outputs a root-ed boot.img

@doitright's source solution currently has one SELinux policy, which is fully enforcing, and currently works in most cases.
My solution currently has two different policies, one which has su permissive, meaning it can do anything, which is not as safe as source-based s solution, and one which is WIP (basically unusable, because almost nothing is allowed to root).

I setup a build bot, which generates boot.img based on my solution, and pushes them to https://superuser.phh.me/

I did this build bot in a way so it is easy to add new ROMs, so don't hesitate asking for new ROM/devices support.
Supporting new devices might mean some additional work on http://github.com/phhusson/super-bootimg/ if they are using non-standard boot.img format, but the aim is to support as many devices as possible.

The plan is to have a third method for rooting:
super-bootimg will work from a recovery, so that you can root any ROM from recovery.

Thanks !
my question is how to change a file label to u: object_r:system_file:s0
i modify system.img to add some additional apps into /system/app/ directory i did modification then build a new system.img after flashing phone with new system.img the app was appear in menu but once i am trying to open it gives me error (com.xxxxxx.andriod) stopped working then i execute ls -Z command in /system/app/ directory to see the different and i realize that the new app i copied in system/app/ directory it has a different label than others
so i tried to change .apk file label to (u: object_r:system_file:s0) using chcon command but failed
chcon: Could not label u: object_r:system_file:s0

can you please guide me how to do it ?
 
Last edited:

phhusson

Recognized Developer
Jul 23, 2009
2,489
4,794
Paris
my question is how to change a file label to u: object_r:system_file:s0
i modify system.img to add some additional apps into /system/app/ directory i did modification then build a new system.img after flashing phone with new system.img the app was appear in menu but once i am trying to open it gives me error (com.xxxxxx.andriod) stopped working then i execute ls -Z command in /system/app/ directory to see the different and i realize that the new app i copied in system/app/ directory it has a different label than others
so i tried to change .apk file label to (u: object_r:system_file:s0) using chcon command but failed
chcon: Could not label u: object_r:system_file:s0

can you please guide me how to do it ?
Can you check in audit log?
How did you put the file?
Don't you have any other message?
 

nicholseric

Senior Member
Mar 20, 2012
180
40
Maybe in your intro you can eloborate on the naming convention of your bot built .img’s?

one which has su permissive (power?), meaning it can do anything, which is not as safe as source-based s solution (user?), and one which is WIP (eng?)


Your HTTPS link to superuser.phh.me is refusing connections?:

This webpage is not available

ERR_CONNECTION_REFUSED
ReloadHide details
Google Chrome's connection attempt to superuser.phh.me was rejected. The website may be down, or your network may not be properly configured.
Check your Internet connection
Check any cables and reboot any routers, modems, or other network devices you may be using.
Allow Chrome to access the network in your firewall or antivirus settings.
If it is already listed as a program allowed to access the network, try removing it from the list and adding it again.
If you use a proxy server...
Check your proxy settings or contact your network administrator to make sure the proxy server is working.

If I do a flash-all.sh of mra58r, reboot to bootloader, fastboot flash boot your-boot.img, would you expect this to boot fine?

Can you detail which phones can take a custom keystore?
 
  • Like
Reactions: phhusson

phhusson

Recognized Developer
Jul 23, 2009
2,489
4,794
Paris
For https, I know it is a must, but i'm waiting for let's encrypt.
For naming convention, I have to rethink those, and i'll update first post.
Anyway it's user < power < eng.
User has only safe permissions, power has all known permissions, eng is permissive. There is nothing source based.
For custom keystore, at the moment I have only seen CAF 5.1/6.0 bootloader with verity enabled to work, and it doesn't display key ID, so it is useless everywhere.
I should get a hand on a Nexus 5X soon, to test properly and get screenshots if it works as advertised.
For your last question, yes. I always work with factory image's partitions, and only change boot.img


I welcome any suggestion about naming convention.
 
Last edited:

nicholseric

Senior Member
Mar 20, 2012
180
40
Some times I dont know where to post, here or the Nexus 6 doitright thread. Anyway, I found this interesting.
http://events.linuxfoundation.org/sites/events/files/slides/ABS Lollipop MR1 Verified Boot.pdf
"• We relax some security policies in eng/userdebug loaders to make life less annoying for development • Persistent Data Block ignored, device always unlockable"

If this is true of the boot.img's you build, the only one we could trust is user or are they talking bootloader? Maybe the factory bootloader (user) that google is distributing does not have the verification functionality? Is the bootloader AOSP? If so, what would prevent someone from creating a bootloader, boot.img and /system that circumvents all the verification?
 
Last edited:

nicholseric

Senior Member
Mar 20, 2012
180
40
I used your bot built mra58r.

Unfortunately, if forced encryption is on, local.prop does not get parsed and I dont get my custom LCD. This means unless you offer variants of the auto built boot.img with forced encryption off or the ability to pass a noencrypt parameter to the update.zip or build.sh for modifying fstab, I will be forced to modify source and build myself. As for mount -o bind /data/local/tmp/hosts /system/etc, as long as the custom hosts has chcon u:eek:bject_r:system_file:s0, things work great.

I still like idea of having the ability to establish a trust between boot.img and a config file in /data/ that do things like custom hosts file, lcd density, iptables (one of my favorites: iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 8.8.8.8:53; iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53)
 
Last edited:

phhusson

Recognized Developer
Jul 23, 2009
2,489
4,794
Paris
Some times I dont know where to post, here or the Nexus 6 doitright thread. Anyway, I found this interesting.
http://events.linuxfoundation.org/sites/events/files/slides/ABS Lollipop MR1 Verified Boot.pdf
"• We relax some security policies in eng/userdebug loaders to make life less annoying for development • Persistent Data Block ignored, device always unlockable"

If this is true of the boot.img's you build, the only one we could trust is user or are they talking bootloader? Maybe the factory bootloader (user) that google is distributing does not have the verification functionality? Is the bootloader AOSP? If so, what would prevent someone from creating a bootloader, boot.img and /system that circumvents all the verification?
They are talking about the bootloader, but as it is built in the Android build system, they are using Android build system flags.
I know the Nexus 6/9 doesn't have this functionnality. I'm waiting to get a Nexus 5X in my hands to say for 5X/6P.
Either way, we can't circumvent the verification, all we can do is have a YELLOW state instead of ORANGE, which displays the fingerprint of the keystore.
I forgot this presentation from Intel, so I thought I'd give it a try on Nexus Player. Intel has a proper implementation of the bootloader of Google's recommendation, it sounds logical the Nexus Player would implement it.
Oh wait. Google's logic striked again. No they didn't implement it on Nexus Player.

There is no AOSP bootloader... Or there are three (there are two LK and one u-boot), but neither of them are supported, and neither of them support the different verified boot states.
CAF bootloader handles the four states, but doesn't display them. Thanks to you I checked Intel reference bootloader, and it DOES implement the full spec \o/. Though I have no device to test. But basically, there is no opensource arm bootloader implementing it, and that makes me rant a lot against Google.

I used your bot built mra58r.

Unfortunately, if forced encryption is on, local.prop does not get parsed and I dont get my custom LCD. This means unless you offer variants of the auto built boot.img with forced encryption off or the ability to pass a noencrypt parameter to the update.zip or build.sh for modifying fstab, I will be forced to modify source and build myself. As for mount -o bind /data/local/tmp/hosts /system/etc, as long as the custom hosts has chcon u:eek:bject_r:system_file:s0, things work great.
Two sides:
1. For LCD density, have you tried just doing adb shell wm density? Possibly it doesn't even break SafeNet
2. My plan on the matter is to keep my current builds as is, but add a configuration file, and when I'll make an update.zip, the user will be able to change the config file directly in the update.zip

I still like idea of having the ability to establish a trust between boot.img and a config file in /data/ that do things like custom hosts file, lcd density, iptables (one of my favorites: iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 8.8.8.8:53; iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53)
Well for iptables, I put it in standard su permission. Well ATM because of some bugs it's only in "power", but I expect it to get into "user" when a bug concerning pts is fixed.
 

nicholseric

Senior Member
Mar 20, 2012
180
40
Two sides:
1. For LCD density, have you tried just doing adb shell wm density? Possibly it doesn't even break SafeNet

Yay! As su in Terminal Emulator, wm density 360 worked. The launcher didn't work until #am start -c android.intent.category.HOME -a android.intent.action.MAIN and other apps also needed to be killed before they would display at the new density like lock screen and existing notifications. There are a few issues with the status bar and nav buttons depending on what app you try to run. I assume that if you set this early enough with a hook from init.rc, (nudge nudge) say a trusted file from /data/ that there would be no problem.

LCD density set from setprop, local.prop and wm density all break SafeNet. Even worse, SafeNet now checks /sbin/ for su, requiring a mount bind to a copy of sbin without su. Next thing you know, it will check for bind mounts!

How about a build of SuperSU, su in a random directory with random names? I know, name it the hash of boot.img or the public key from the user generated keystore.


Dont read on, I fixed it , the /data/setlcd.sh 560 needed quotes around it.

I created a Terminal Emulator widget in an attempt to make it easy to switch between resolutions. Interestingly, when set with #wm density 360 and then #am restart, the density sticks across reboots, I was not expecting that!

Ive tried the widget with different combinations of explicit paths for su with options like --context and -c with wm density and am restart and even with a /data/setlcd.sh that is chmod 750 and chcon u:eek:bject_r:system_file:s0. Any tricks to accomplish this? I would expect the widget to prompt for root permission and then run my setlcd.sh taking the DPI as argument $1 I am envisioning one main .sh that has a function for each of my customizations, wm density, hosts, iptables and mount bind to a /sbin that has no su. I dont want to keep building boot.img's with special init.rc's.

The closest I have gotten is a widget with command /sbin/su with the arguments -c /data/setlcd.sh 560
This results in a terminal launching that asks for su permission and then:
$"/sbin/su" -c /data/setlcd.sh 560
sh: /data/setlcd.sh: can't execute: Permission denied
nothing in dmesg
 
Last edited:

nicholseric

Senior Member
Mar 20, 2012
180
40
I have finally gotten the functionality I need with the exception of iptables which I understand you are working on adding. I am testing with shamu mra58r and the boot-su-power.img.

Here is my setup that features:
  • custom hosts file for browsing without advertisements
  • set the LCD density to tablet mode
  • quickly disable su and revert density when I want to use Android Pay

As root, I created a script in /data/android.sh and set the context to system via chcon u:eek:bject_r:system_file:s0 and chmod 700 here are its contents:
Code:
#!/system/bin/sh
#bind mounts transcend am restarts
#wm density transcends reboots
function lcd
{
	/system/bin/wm density $density
	/system/bin/sleep 3
	/system/bin/am restart
}
function hosts
{
	mount -o bind /data/hosts /system/etc/hosts
}
function nosu
{
	/system/bin/wm density 560
	cp /sbin /data/sbin -r
	rm -f /data/sbin/su
	mount -o bind /data/sbin /sbin
	/system/bin/am restart
}
function dns
{
#not working yet in phh
	iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 8.8.8.8:53
	iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53
}
density=$2
case "$1" in
	lcd) lcd ;;
	hosts) hosts ;;
	nosu) nosu ;;
	dns) dns ;;
esac

The hosts file was copied from http://winhelp2002.mvps.org/hosts.txt and placed in /data, its context was also set chcon u:eek:bject_r:system_file:s0 and chmod 644. The local host entries were modified to match those found in /system/etc/hosts. It was important that the contents of this file were terminated on each line and with a blank line at the end.

The tricky part was creating launchers on a home screen using the Terminal Emulator Widget. It seemed that you could not just type in /sbin/su, instead you had to browse to it. Screenshot of widget config attached.

I learned a few interesting things during testing.
  • Using a /data/local.prop with an encrypted disk resulted in the local.prop not being read during init.
  • Once wm density is set, it is persistent.
  • Using mount -o bind gives persistent mounts if you reboot using am restart from the terminal
  • SafetyNet now checks for su in /sbin
  • SafetyNet for AndroidPay checks for LCD density regardless of setting it via local.prop (if unencrypted), setprop or wm density

This will be easy for me to reproduce across all my devices without granting persistent root to any app and without adding any app but superuser and terminal emulator.
 

Attachments

  • Screenshot_20151113-180156.png
    Screenshot_20151113-180156.png
    249 KB · Views: 1,054
Last edited:

phhusson

Recognized Developer
Jul 23, 2009
2,489
4,794
Paris
Thanks for your test! It's really interesting.
You must be the first user of something other than eng :p
iptables does work for me (in adb shell). Looking back, it should have been fixed by https://github.com/phhusson/super-bootimg/commit/31d3a635eea4fe66071346e05913acfb00d60144
That made me realize that if I don't do releases, I still need to know what users are using, so I added /super-bootimg which contains the git version of super-bootimg repo

For local.prop I'm happy to see you don't need it. I really feel like user shouldn't be allowed to change it (but I'm thinking only about some properties which are in /default.prop so it can't be overriden. perhaps local.prop is safe enough)

am restart is not a reboot, so it's normal mount bind stays
I think you could just mount bind an empty folder to /sbin. The only risks are if adbd/ueventd/watchdogd/healthd restarts, but they shouldn't
 

nicholseric

Senior Member
Mar 20, 2012
180
40
Any idea why busybox nslookup is not working?
root@shamu:/data # ls -Z nslookup busybox-android.bin
lrwxrwxrwx root root u:eek:bject_r:system_data_file:s0 nslookup -> busybox-android.bin
-rwxr-xr-x root shell u:eek:bject_r:system_file:s0 busybox-android.bin
root@shamu:/data # ./nslookup superuser.phh.me 8.8.8.8
Server: 8.8.8.8
Address 1: 8.8.8.8

nslookup: can't resolve 'superuser.phh.me'
1|root@shamu:/data # dmesg
[39764.686702] healthd: battery l=91 v=4144 t=28.1 h=2 st=3 c=-439 chg=
root@shamu:/data #
 

Top Liked Posts

  • There are no posts matching your filters.
  • 333
    Hi,

    IT MIGHT BRICK YOUR DEVICE.
    Always ensure you have a way back.


    Here is a thread about my fork of Koush's Superuser, to handle SELinux: https://github.com/seSuperuser/Superuser
    So I would like your help to make this SuperUser a proud opensource SU app!

    If you have an application that requires root, and which needs specific SELinux configuration please ask!


    Build bot: https://superuser.phh.me/
    Currently, four flavors of su are available on the build-bot:
    - "eng" which puts "su" in permissive mode. This is the most compatible mode, but you should trust the apps you give root to. This does NOT put SELinux in permissive mode.
    - "noverity" is eng and dm-verity disabled
    - "nocrypt" is eng, dm-verity and dm-crypt disabled
    - "user" is meant to give a safe su. su-apps won't be able to access to your Android Pay (for instance) informations, or keep persistent su access without your consent

    Please note that user is in heavy development and isn't up to its promises at the moment.

    I setup a build bot, which generates boot.img based on my solution, and pushes them to https://superuser.phh.me/

    I did this build bot in a way so it is easy to add new ROMs, so don't hesitate asking for new ROM/devices support.
    Supporting new devices might mean some additional work on http://github.com/seSuperuser/super-bootimg/ if they are using non-standard boot.img format, but the aim is to support as many devices as possible.
    You need to install the APK from PlayStore afterwards: https://play.google.com/store/apps/details?id=me.phh.superuser

    Bot-supported devices
    Here are some devices, but there are many more !
    - A *lot* of Archos devices
    - All Nexus-es, including Pixel C (if some Nexus is missing, just ask!)
    - nVidia Shield TV
    - nVidia Shield Tablet
    - Fairphone 2

    update.zip format
    The zip is available at https://superuser.phh.me/superuser.zip
    It should be able to root any device supported by super-bootimg from TWRP (and possibly other custom recoverys)
    You still need to install the APK afterwards. https://play.google.com/store/apps/details?id=me.phh.superuser https://f-droid.org/repository/brow...lob/master/known-imgs/nexus/hammerhead/MRA58N describes a firmware, nothing device-specific). This only requires to do some PRs to add a device, or on updated firmwares
    - Testers
    - UI designer: The current UI dates back from 4.1...? It is really ugly and not really usable.
    - Testers
    - Root-related devs: SELinux policies are still being written
    - Testers
    - Security reviewers
    - Testers

    Bug report
    If some app doesn't work, please ask me, not the dev.
    I consider I have to fix support for other apps, not the other way around.



    ChangeLog
    2016-01-31 r170: superuser.zip can be included in other update.zip
    2016-01-27 r166: Add support for Viper4Android
    2016-01-15 r162: Add su --bind and su --init commands
    2016-01-10 r154: Files are no longer copied multiple times. Fixes MultiROM, and multiple install for update.
    2016-01-06 r152: Fix support for ChromeOS-like format (Pixel C)
    2016-01-01 r144: Detect chromeos-style signature, and don't try to resign it in that case
    2015-12-30 r143: Improved compatibility with apps.
    2015-12-28 r142: Changed naming convention to include device name and release
    2015-12-28: Added "nocrypt" target
    2015-12-13: Added "noverity" target to buildbot
    2015-12-13: Add options for noencrypt, noverity
    2015-12-03: Fix TitaniumBackup
    2015-11-24: mount --bind to /system/xbin/su if it exists to override ROM's su
    2015-11-23: Fix CF.Lumen
    2015-11-14: Add super-bootimg's version in boot.img, several network/firewall-related permissions
    2015-11-11: Access to Android's services
    2015-11-10: Recursive su access
    2015-11-09: Fix pm disable command
    98
    So, I've made a quick and dirty version of hidesu which hides su enough for current version of Pokemon Go. (noone cares about anything else anyway right? Oh right it also circumvents SafetyNet...)
    I fully agree to what ChainFire says about circumventing SU detection (on http://xdaforums.com/showpost.php?p=68424605&postcount=2 )

    The demo superuser.zip is available at http://phhusson.free.fr/superuser-r266-hidesu.zip (you'll notice this is not hosted on https://superuser.phh.me, so don't consider it a real release).
    hidesu is enabled by default for the "com.google.android.gms.unstable" process (this is the one scanning for Pokemon Go and SafetyNet as far as I know)

    I think this actually could be easily used to circumvent SafetyNet with Xposed enabled (we can make the process think it has the original /system), but that's out of the scope of this PoC.

    (I have no clue how this compares to CF's suhide)
    61
    - Added a new "Smart mode" for notifications (shows a toast when screen is in use and notification when it's off)

    - Added a setting to notify only when access is denied

    - Removing an app from the list will require PIN (if it's set)

    (I haven't tested these new additions much. So, please let me know if something's wrong)

    - @Captain_Throwback some blank space will be removed now
    41
    @PunchUp One more request for the superuser app.

    An option to hide the app in the app drawer for those ROMs that integrate it in Settings. like Substratum does?

    I use Pure Nexus and it integrates phh superuser and Substation (as well as that "other" su). ;)

    Thanks
    Alright, now there's a setting available to hide the launcher icon
    Also, someone asked for the round icon. So, now there's one available for API 25+
    And some other minor bug fixes and improvements

    Plus, there's an "App shortcut" to quickly enable/disable Superuser. I'm currently not using Nougat. So if someone who is on 7.1.1 can test it, that'd be helpful :)
    29
    I don't think so, @PunchUp made an amazing work there :)
    Still waiting for your reply to the email so that I can finalise it :D

    It works great! Although I feel the full screen request activity is a little intrusive, I'll live with it to avoid the super long SuperSU dialog :p
    Full screen request? I think you're using an old build.


    Anyway, I did make some more changes a few weeks ago (after beta 9). Since the final release has gotten delayed a bit, here is a new build