I'm pretty sure this is the latest version of SuperSU, but every time I reboot my phone I get a message that reads: "The SU binary needs to be updated!", and when I click on the prompt to update it, it always fails and asks me to reboot.
Has anyone else run into this issue, or know how to resolve it? Thanks.
SuperSU APK and the SU binary are two different things :
SU is a binary executable, it's used by Android and other *nix based systems to allow a process to change the user it is run by and therefore what the process has the rights to do (as it inherit the user permissions). In the rooting case, processes invoke SU to switch to the root user therefore acquiring root permissions.
SuperSU is an Android application (.apk is an Android application package), it works as a sort of "gatekeeper" to the SU binary. Applications which attempt to invoke SU will be forced to route through SuperSU, which will then prompt the user with the options of approving or denying the access to SU (and optionally having SuperSU remember their decision and automatically apply it for subsequent calls by that app).
So what happens to you is, every time you boot, SuperSU v2.78 (which is the latest version of the SuperSU APK) checks the SU binary version and tells you that there is a newer version of it and that you should update it.
Then for SuperSU failing to update the SU binary I can't help as for me it always worked till now. But maybe there is a way to manually do it (by finding the binary in a flashable zip that you can flash in recovery)?
bafforosso said:
SuperSU APK and the SU binary are two different things :
SU is a binary executable, it's used by Android and other *nix based systems to allow a process to change the user it is run by and therefore what the process has the rights to do (as it inherit the user permissions). In the rooting case, processes invoke SU to switch to the root user therefore acquiring root permissions.
SuperSU is an Android application (.apk is an Android application package), it works as a sort of "gatekeeper" to the SU binary. Applications which attempt to invoke SU will be forced to route through SuperSU, which will then prompt the user with the options of approving or denying the access to SU (and optionally having SuperSU remember their decision and automatically apply it for subsequent calls by that app).
So what happens to you is, every time you boot, SuperSU v2.78 (which is the latest version of the SuperSU APK) checks the SU binary version and tells you that there is a newer version of it and that you should update it.
Then for SuperSU failing to update the SU binary I can't help as for me it always worked till now. But maybe there is a way to manually do it (by finding the binary in a flashable zip that you can flash in recovery)?
Click to expand...
Click to collapse
Thank you for explaining the difference for me. I went ahead and downloaded the .zip from here: http://forum.xda-developers.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703/page8
And then used the installation instruction found here: http://androiding.how/how-to-flash-supersu-using-twrp-recovery-and-root-any-android-device/
And I don't seem to be getting the prompt that SuperSU needs to be updated anymore.
Huh. Never mind. Seemed to work for about 12 hours, but now it's asking me to update again, and I can't. Looks like I need step-by-step instructions on how to clear this message, cause whatever I'm doing isn't doing the trick.
Did you disable Sony RIC and dm-verity when you modified the kernel? I'm not sure if it has anything to do with or whether it will solve your problem, but one time I patched my kernel leaving one of the options enabled and ran into all sorts of problems with apps that required root, so after that horrible experience I decided to just disable everything. During that horrid experience, I think I also had SuperSU (or was it busybox?) complain about not being able to update binaries.
Related
I've had an automatic reboot enabled on my phone for well over a year now that has worked perfectly using the process described here:
http://tasker.wikidot.com/devicereboot
This morning I had a notification that my SU binary was outdated asking if I wanted to update to. I updated, and now I can't get a prompt for the Tasker/Locale Execute Plug In action to give it root privleages. I get a SuperUser prompt for other apps, Titanium, Voltage Control, Root Explorer, etc, but for some reason the Locale Execute Plug In get's automatically denied without any prompt whenever it requests root privileages. This is confirmed by viewing the log.
Any ideas?
Ok, more info..
Manually rebooting the phone seems to partially downgrade the SU binary.
I get the notice that a new version of su binary is found.
Code:
Downloading manifest... okay!
Parsing manifest... okay!
Latest version = 3.0
Checking installed version = 2.3.1-ef
Fixing database... okay!
Downloading custom busybox... okay!
Checking md5sum... okay!
Checking current install path... /system/bin/su
Downloading new binary... okay!
Checking md5sum... okay!
Gaining root access... okay!
Remounting /system as rw... okay!
Copying su to /system... okay!
Checking md5sum... okay!
Moving su to it's final location... okay!
Checking md5sum... okay!
Changing su file mode to 06755... okay!
Remounting /system as ro... okay!
Checking installed version = 3.0
Cleaning up... okay!
It seems to be stuck in this endless loop now.
Every time I reboot the phone it reverts back to the older (working) SU binary and tells me a newer version is available. If I upgrade the SU binary, then my Tasker reboot is broken AND any reboot reverts the SU binary version back to the old one.
I'd be fine leaving the older SU binary on there and just ignoring the notification to update, but when it notifies of an update/newer SU binary it disables the ability to remember your SuperUser choices (Allow/Deny) for apps so either I have to manually allow any root apps every time they need access or change my Super User settings to always allow instead of prompt which isn't exactly ideal or safe.
Any thoughts or ideas?
Cross-posting for visibility...
Looks like others (Epic users) are having the problem as well with the SU binary update.
http://forum.xda-developers.com/showthread.php?t=1279238
In that other thread, the person get a message, that his su binary is installed in /sbin. That means it is in the ramdisk of his boot image.
su should be in /system/xbin, then it can be replaced. if placed in the ramdisk, you need to replace/modify the boot image, to change it.
Per
I don't have the problem with updating the binary, but I do have the same problem with the updated binary.
I've emailed the developer to ask him if there is a fix. I think what he's done is limit it to run only with the exact command you first grant.
So if you're using the Locale execute plugin to try running more than one command only the original command you allow is allowed and all others are denied.
Even setting the default to Allow doesn't help.
Hopefully he'll have a fix.
I'm noticing the same behavior with new Superuser. It no longer prompts to allow Locale Execute Plugin, just waits until the request times out and flashes that the permissions were denied.
I can't figure out how to execute Locale Execute Plugin in a manner that the new Superuser will prompt the request, nor haw to manually add it as allowed.
And this is a single line Tasker Execute, so it's not related to hastarin's comment.
Yes, it does seem to be a bug caused with the new su.
For anyone still stuggling, I managed to get my commands to run with this instead of the Locale Execute Plugin:
http://forum.xda-developers.com/showthread.php?t=1217767
Not sure if this is still relevant however I registered to post anyway.
Ran into this problem and couldn't find any answers so I fiddled around on my own.
By checking the "Advanced Prompt" option in Superuser's preferences I managed to get a prompt to appear and allow the locale execute plugin su permissions.
[FIXED]
Thank you all for the support! I was facing the same issue which Tasker had no root access.
The solution for me was checking the "Enable Permission Warning" option in SuperSU as in the attachment...
Conflicts? LG P769 rooted V18. Binary update fails, su reports "The ap su (processom.noshufou.android.su has stopped unexpectedly)" then crashes. Until resolved and certain that su will preserve root would like to prevent ph from forcing update. Have read several methods one is to freeze a couple of scripts w/Titanium, another to delete 24MB ip folder 10e>10g in cache and alter Google Framework. Not sure which is the safest or easiest with apps I already have. That's two requests which will be greatly appreciated: One to resolve su binary fail w/possible app conflicts the other to simply stop OTA until I understand Andoid and the apps better.
Installed: SuperSU (non-pro- no survival mode) , Superuser Elite(over vs from Bin4ry), Smanager Elite, OTA Root Keeper, Titanium BU Pro
btw- No response from ph running Bin4ry? Go to redmondpie com "how-to-set-up-android-adb-and-fastboot-on-windows-tutorial" Only way it worked for me. Followed the directions and was able to view my device in command box prior to executing v18.
note: When editing the string as described, redmondpie, +be sure not to wipe out any part of existing script+ (hit end , blue box turns white). Copied and pasted extracted bin4ry "stuf' in a folder labled Andoid-adb set up in adb environment. Root executed from there first try after dozens of failures w/other methods.
>>not sure if I have valid root restore tools should OTA (already in cache) executes<< >>Meanwhile, which method to prevent OTA execution<<
notes from apps
root checker basic verifies root; voodoo all boxes checked, protected su copy available but note "using both su and SupersSU take care keeping app and su bu consistent" (should not be issue since not the pro vs of SuperSU - no ota survival). edit just started to rept "sys running very slow-pls wait for r-ckr to cmplete.
Superuser elite v3.1.3(46) (downloaded over Bin4ry incl vs) shows no apps, no log, o entries Binary updater fails, "The ap su (processom.noshufou.android.su has stopped unexpectedly" then crashes. "bu written to sd card"black box flashes to say su has been granted superuser permission interactive shell access; access timeout aps not remembered set to 0; auto response set to prompt; ghost mode off; ...
SU updater reports "sigs ok"
SuperSU v0.96: all green # today (but not yesterday); superuser enabled; surv mode not avail (not pro);
Titanium BU Pro root ccess ok, busybox 1.19.4-titanium from ap ; sqlite- yes 3.7.6.-titan incl; All green checks on overview pg; has quite a few red line entries, probably hven't left ph on long enough for bu to complete
; active data pofile- sys rom 1.03gb ; internal 1.93/1.46 free note down from 1.7 when new.
Smanager reports root access Can this app delete cached ota update zip?
Did I err in downloading elite vs of Superuser over the copy already inserted by Binr4y? Thanks.
I just discovered a new permission request "Android System" UID System User 1000 in SuperSU .
I can't explain where this comes from.
So I did the following:
1.) Factory Wipe
2.) ODIN and simply flashed the Stock ROM with 1 file ROM in PDA slot
One thing I didn't do was Format the System Partition
But the next time I install SuperSU the permission request appears again.
So I want to know, does ODIN flash and Factory Wipe, truly wipe everything?
You didn't wipe everything. You didn't wipe the system partition where the su request came from.
Thanks, I thought the TAR.MD5 Odin ROMs clear out everything in the system partition before writing.
Weird, even after going into Touch CWM and doing the following:
1.) Factory Wipe
2.) Clear Cache
3.) Clear Davlik Cache
4.) Mounts and Storage > Format /System
5.) Reboot to Bootloader
6.) Loaded ROM via ODIN N8010XXUCMK2 http://www.android-hilfe.de/origina...jellybean-4-1-2-20-11-2013-a.html#post6823310
7.) Loaded Touch CWM
8.) Installed SuperSU zip
Upon the second restart, it again requests for root from Android System UID User 1000
Huh.. strange. You wiped everything this time so that's weird. I've never seen a su request from Android System (the android system has root as default, as an OS should have). I'll dig a little and i'll be back soon.
UPDATE: I think i cracked the case. It's Xposed that does this on Samsung devices. If you do not use Xposed, it could be SuperSU. Be sure to have the latest version installed.
If you are referring to this:
Current Superuser/SuperSU releases have security holes that allow any application to execute commands as root without the user's permission (even apps with no permissions). Please upgrade immediately to SuperSU >= v1.69 or another patched release.
Click to expand...
Click to collapse
The device is on one of the latest SuperSUs 1.80 and then updated to 1.85, and never on SuperSU =< v1.69
Regarding the System User Request, Is below what you are referring to?
cernekee said:
On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. If any of these checks fail, the denial is recorded by broadcasting an intent to the Superuser app through the Android Activity Manager binary, /system/bin/am. /system/bin/am is invoked as root, and user-supplied arguments to the "su" command can be included on the "am" command line.
On a rooted Android >= 4.3 device, due to changes in Android's security model, /system/xbin/su functions as an unprivileged client which connects to a "su daemon" started early in the boot process. The client passes the request over a UNIX socket, and the daemon reads the caller's credentials using SO_PEERCRED. As described above, /system/bin/am is called (now from the daemon) to communicate with the app that implements the user interface
Click to expand...
Click to collapse
If I understand this properly, it's saying SuperSU accesses some functions as the System User 1000 on Android devices previous to OS version 4.3
On Android 4.3 and newer, SuperSU access those same functions without using System User 1000.
This would explain why this permission request does not appear on my Android 4.3 device, but it does on my Android 4.1.2 device.
Is this the correct understanding?
klau1 said:
If I understand this properly, it's saying SuperSU accesses some functions as the System User 1000 on Android devices previous to OS version 4.3
Click to expand...
Click to collapse
Internally, Superuser/SuperSU can switch UIDs to execute different subprocesses with different user credentials. But these do not generate requests that you would see on the screen.
To track down the source of the request, can you run these commands from a PC while the SuperSU dialog for "Android System" is on the screen, then paste the results?
Code:
adb shell busybox ps -Tl
adb shell ps
Here it is:
Attached
The command output of "adb shell ps" is also inside, just search for "adb shell ps" in an txt editor to jump to it.
Although, I'm a noob I will try to help. If I mind correctly , If you go supersu > setting is a checkbox that says something about "system processes" or similar, make sure that is unchecked. You could also try emailing to the developer of supersu, your rom and kernel
Sent from my Xperia Mini using XDA Premium 4 mobile app
I know that, but just indiscriminately "trusting" the user doesn't make it safer. Just like keeping your doors open so you won't hear anyone break in doesn't stop the actual breakin from happening.
And it's also a stock ROM from: http://www.android-hilfe.de/origina...jellybean-4-1-2-20-11-2013-a.html#post6823310
Is it possible these Stock ROM uploads are infected with malware?
I don't know whereto put this thread although ths seems like a right forum,anyway, I have a problem with this persistent king root, and I want to remove it but these chinese 'communist' devs won't let me. I tried the following things:
1 Manually delete kinguser app from /system/app part, and then install supersu from play store. The result it just says what su binary is occupied.
2. Install BusyBox. Download this popular replace_kinguser_with_supersu_2.4.zip and 2.0 files (this ones with mrw folder) and run it. Supersu installs, asks for update and su binary update. Yes, yes, looks great, but doesn't work. When running any root app, like terminal emulator, nothing happens, no auth prompt pops up.
3. Reroot with older kingroot version (4.5), do the same as 2. Same result
4. Set auth mode in Supersu settings to allow/deny, when oddly it works. Allows or denies immediately, and I can find this in Supersu's log.
So, everything seems working fine except what Supersu doesn't want to show me my root promts when I need them.
If any information about my device needed, I will be happy to provide it. For starters, my device is ITELL K3300, I am not sure what else coud be needed if you want to help?
Hi,
I need to root a Zebra TC56 to install some other apps that require rooted Android. There is very little information in the way of rooting the Zebra TC56. I 'm pretty set on using Chainfire's superSU, but I cannot find any information on whether it will work on this hardware. Does anyone know if the superSU works on this device with Android 6? If not, is there another Root Tool that will work.
Any advice appreciated.
THANK YOU!
VK
1. Install BusyBox applet-suite what contains the SU-binary
2. Install latest SuperSU APK
jwoegerbauer said:
1. Install BusyBox applet-suite what contains the SU-binary
2. Install latest SuperSU APK
Click to expand...
Click to collapse
BusyBox installed fine.
SuperSU will not install all the way. When I select to root, it says root not detected and then, "How to Root", which launches my browser to a site that no longer exists.
Now what?
Thank You!
edit: Still stuck at this point. I read about TWRP, KingoRoot and some other random apps. I cannot brick this touch computer; it is $1600; that would be a very expensive brick. :crying:
So, I have no idea if I am right, but maybe I need to open the terminal emulator and "su" install the SuperSU apk. But I have no idea and I don't want to experiment. Hopefully, someone can help me.
@vidarr_kerr
Don't confuse things:
SU is the super user who unrestrictedly can perform any operation on Android OS. As soon as SU got installed Android is rooted! Again: BusyBox you successfully installed contains the su applet.
SuperSU is merely a root-manager app: it maintains a database where is stored what app can act as super user. SuperSU app doesn't grant super user rights.
BTW:
TWRP has nothing to do with rooting device's Android, as this is also true with Magisk.
The device is still not rooted after the "BusyBox Installer (No Root)", from your link, was installed.
I installed BusyBox, I followed the directions to then copy a command, then open a terminal, paste the command in and hit enter, then nothing happened. SuperSU was not installed with it.
So, as you told me, I then installed the latest SuperSU APK from your link. It says it installed, but when I run it, it says root not detected and then has a link named, "How to Root", which launches my browser to a site that no longer exists.
I followed what you said. Where did I go wrong?
Thank You!
You didn't get it. Sorry to say this.
jwoegerbauer said:
You didn't get it. Sorry to say this.
Click to expand...
Click to collapse
Didn't get what?
I installed the BusyBox you gave me the link to.
I semi-installed the SuperSU you gave me the link to.
SuperSU did not fully install, because the Android is NOT rooted..
BusyBox had no SuperSU as part of it --the file you said to use even says "BusyBox Installer (No Root)".
(That should have tipped me off right away you had no clue, but I thought maybe you knew something.
So, you gave me the links for both of those files and it doesn't work.
I don't think you have any idea what you are doing; and shouldn't be explaining things you do not understand.
The "no root" BusyBox, does not include SuperSU.
If it did, why did you give me the link for the separate SuperSU file?
All the "no root" BB did was install a terminal emulator (with no su abilities).
The SuperSU didn't install, because the Android is NOT rooted.
If the Android WAS rooted, SuperSU would run and allow me to grant su privilges to the apps that require it to work.
You basically just wasted my time.
I would have just said "thank you" and moved on, but you are rude.
You don't know what you are talking about either.
Hopefully, this will help others, to not do what you say to do.
vidarr_kerr said:
Didn't get what?
I installed the BusyBox you gave me the link to.
I semi-installed the SuperSU you gave me the link to.
SuperSU did not fully install, because the Android is NOT rooted..
BusyBox had no SuperSU as part of it --the file you said to use even says "BusyBox Installer (No Root)".
Click to expand...
Click to collapse
You're right: BusyBox (No Root) doesn't come with SU-binary. Wasn't aware of this. I misinterpreted APK's title. Pitty.
ERRARE HUMANUM EST ( To err is human ).
Installing BusyBox containing SU-binary requires your device's bootloader got unlocked before, because Android's /system partition gets modified. Hence manage to unlock device's bootloader as 1st thing of all things. Good luck.
DL BusyBox latest: https://github.com/meefik/busybox/releases/download/1.31.1/busybox-1.31.1-46.apk
My last 2 cents here: SuperSU and SU binary are totally different things.