Database Info

Fake su's make phones cry!

The common method of enabling root by creating a suid root shell named 'su' opens the device to malicious programs; it is trivial to 'echo rm -rf|/system/bin/su'. Changing the name of 'su' only makes the exploit slightly more complicated at best. A standard /etc/shadow auth will not work, as this would require a shell program to set the password, and anything a user can do in Term.apk can be automated by a malicious program.
This method uses Dalvik's own security system, in which a GUI app cannot read the database of another app. 'SU Passwd' is a simple program to set a password value in it's database. 'su' is a modified version of the su from GNU Coreutils 5. When it's suid root, it can read the database, prompt for a password, and spawn a root shell if the typed password matches. By default it will reject if there's no database or no password entry, however it will not prompt for a password if the user sets it to 'NONE'.
* TO INSTALL:
put dist.newsu/su into /system/bin/su
chmod 4755 /system/bin/su
Install SUPasswd.apk
* SPECS:
The database structure is an approximation of /etc/passwd:
username|cleartextpass|homedir|shell
The GUI app currently doesn't support changing the home directory or the shell, however this can be done (as root) with:
sqlite /data/data/org.fnord.android.passwd/databases/passwd.db "update passwd set shell='/data/opt/bin/ash' where user='root'"
or:
sqlite /data/data/org.fnord.android.passwd/databases/passwd.db "update passwd set home='/data/opt/home' where user='root'"
* LICENSE:
'su' is covered under the terms of the license of GNU Coreutils-5.0
SUPasswd can be freely distributed, however any publicly modified version must also have publicly available source.
If you want to include this in your firmware distribution, please leave the database blank, as setting a default would defeat the purpose :>
* TODO:
Modify Term.apk to have a config option that throws 'su\nPASSWD' into the shell after launching it. This should make the security transparent while still
keeping a phone safe from naughty apps.
Make SUPasswd less cruddy and add home / shell options.
* Thanks to plusminus from anddev.org for the helpful example database app!
Alternate dl: http://g1.fnord.to/newsu-0.9.tgz

Gah! This is exactly the kind of sandboxing off of su i've been attempting to do for the past week. Good job Fnord!

Can somebody explain to me why we can't just create passwd file, change the root password by 'busybox passwd' and then use 'busybox su' to get root access?

Dimath said:
Can somebody explain to me why we can't just create passwd file, change the root password by 'busybox passwd' and then use 'busybox su' to get root access?
Click to expand...
Click to collapse
You can but either (a) you have an exploitable 'passwd' or (b) you're locked out if you forget.

A better way to do this is to leave a normal root su (sh) sitting in /system/bin and chown it to a custom group, of which the SUPasswd application userid is a member of.
Then the SuPasswd application can expose a <permission> that other applications can apply for (via <uses-permission>). Another application can fire off a intent to start a su confirmation Activity to request access to su.
SuPasswd handles that intent (the Java permission to even launch the activity is handled automatically by the Android system), and pops a dialog verifying that you want to give that application access to su. If accepted, SuPasswd then uses su (which it obviously has access to) to add the requesting application to the su group.
Don't need to mess around with databases then, and because su is using the standard Linux/Android security model. And any Java application can request access to su in a user friendly fashion, if allowed.
http://code.google.com/android/devel/security.html#manifest
Note: I had planned on implementing this myself, but there's so many other cooler things I wanted to work on first.

Koush said:
A better way to do this is to leave a normal root su (sh) sitting in /system/bin and chown it to a custom group, of which the SUPasswd application userid is a member of.
Then the SuPasswd application can expose a <permission> that other applications can apply for (via <uses-permission>). Another application can fire off a intent to start a su confirmation Activity to request access to su.
SuPasswd handles that intent (the Java permission to even launch the activity is handled automatically by the Android system), and pops a dialog verifying that you want to give that application access to su. If accepted, SuPasswd then uses su (which it obviously has access to) to add the requesting application to the su group.
Don't need to mess around with databases then, and because su is using the standard Linux/Android security model. And any Java application can request access to su in a user friendly fashion, if allowed.
http://code.google.com/android/devel/security.html#manifest
Note: I had planned on implementing this myself, but there's so many other cooler things I wanted to work on first.
Click to expand...
Click to collapse
Yeah, what he said. Sounds good.

How do you use the ?
put dist.newsu/su into /system/bin/su
Just got premission denied when using put command.

bunny0007 said:
How do you use the ?
put dist.newsu/su into /system/bin/su
Just got premission denied when using put command.
Click to expand...
Click to collapse
Assuming you have a modified RC30, run adb remount first.

bunny0007 said:
How do you use the ?
put dist.newsu/su into /system/bin/su
Just got premission denied when using put command.
Click to expand...
Click to collapse
If you have rc30_full_xda-dev_v1.2 installed, run these:
> adb remount -or- >adb shell mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
> adb shell rm /system/bin/su
> push su /system/bin
> adb shell chmod 4755 /system/bin/su
> adb install SUPasswd.apk
Koush, i'm looking forward to seeing that implementation ;-)
edit: Doh, forgot /system ro

Koush said:
Then the SuPasswd application can expose a <permission> that other applications can apply for (via <uses-permission>). Another application can fire off a intent to start a su confirmation Activity to request access to su.
Click to expand...
Click to collapse
It's posible to set custom permissions like that? I figure that would require modifying stuff in /system. I stuck with the KISS principle

Yup, custom permissions are pretty easy to use.
I was also wrong earlier about my previous hypothetical implementation: The Android version of Linux is considerably different when it comes to security: you can't use 'busybox addgroup' to add a user to a group: it works but it doesn't actually do anything (Android doesn't use/care/have a /etc/group).
But, what you CAN do is the following:
chown 0:10026 sh_26 (this gives the root user and app_26 group ownership of a copy of shell).
chmod 4750 sh_26 (this setuids the sh_26 to root, and gives app_26 execute permissions, but no one else)
-rwsr-x--- root app_26 86936 2008-11-21 17:25 sh_26
That should work, right?
The problem with this approach is that there are X copies of the shell laying around for however many applications need them.
You can, however, put give applications the same uid by signing the APK with the same private key, and using the <sharedUserId> attribyte. http://code.google.com/android/reference/android/R.attr.html#sharedUserId
This is equally bad though, because then the user confirmation is taken completely out of the equation, and then you introduce private key distribution or some sort of signing process.
So, it probably is just better to use a custom su, and include have applications make requests to get the password from the database using the <permissions> thing I mentioned.

Actually, you can probably just chown a single copy, and so long as execution is started by the given app before another one requests it, it should work fine-- even if the permissions change underneath it while it is running.

Koush said:
Actually, you can probably just chown a single copy, and so long as execution is started by the given app before another one requests it, it should work fine-- even if the permissions change underneath it while it is running.
Click to expand...
Click to collapse
Great app now i have no worries bout su !

Modified an icon from here to use for the SU Passwd applet. You can get the modified file here. Just open the Passwd.apk file and substitute it for the one in \res\drawable, then sign the apk with SignApk.jar. Here's what it looks like in the ui:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

usmc2k said:
Great app now i have no worries bout su !
Click to expand...
Click to collapse
I just started working on the application I described. I'll be done shortly.

Ok all, it's working. Will release it tonight. I wrote a custom terminal app called Shell to confirm it works. This Superuser application will provide a clean, standard (as in no custom version of su needed), way of exposing su to Java applications, and also close the security hole on your phone.
Shell tries to run su, but can't:
Shell requests access to su from the Superuser application I wrote:
User gets confirmation to grant Shell Superuser access.
Shell can now run su:
I'll be releasing the source to both Superuser and Shell so you guys can double check the security and also learn how to use the intents.

koush, nice job man. i was just avoiding the use of su until something could be done. for root access i limited myself to adb shell.. now i can safely use su, thanks to you.

Koush said:
Ok all, it's working. Will release it tonight. I wrote a custom terminal app called Shell to confirm it works. This Superuser application will provide a clean, standard (as in no custom version of su needed), way of exposing su to Java applications, and also close the security hole on your phone.
Click to expand...
Click to collapse
Hmm not sure if I prefer that method, but I may alter mine slightly; Writing a simple program (pwupdate) that updates /etc/passwd & /etc/shadow entries based on the SUPasswd database. This would be globally executable as well, but in theory as it takes no arguments it wouldn't matter (since the db is secure), and SUPasswd would call it after writing the db. There would be no need for a wrapper to getpwuid etc, though I'm not sure if bionic supports those functions. crypt() would need to be ported for pwupdate.
I'll implement this method next week - unless it's hectic.

jashsu said:
Modified an icon from here to use for the SU Passwd applet. You can get the modified file here. Just open the Passwd.apk file and substitute it for the one in \res\drawable, then sign the apk with SignApk.jar.
Click to expand...
Click to collapse
Thanks! I'll add this to the next version if that's ok?

Fnorder said:
Thanks! I'll add this to the next version if that's ok?
Click to expand...
Click to collapse
Knock yourself out.

Superuser App - fix the su security hole on modified RC30 - source/apks included

Summary:
There have been a few threads about the root setuid su being a potential security hole on modified RC30 phones. We all want to have root on our phones, but we don't want malicious programs/people to take advantage of it.
To that end, I came up with the following program that fixes the security hole, and also allows you or any application to get root when authorized.
This program works with any application that may use su: no special code or support needs to be written. Just use su like normal from within both Java applications or a terminal.
To install, simply install the Superuser application on top of modified RC30 V1.2.
If Superuser does not install properly automatically, do the following to install it manually:
Make sure you have the adb tool from the SDK.
Unzip the ZIP file (it will create a folder called Superuser).
Run install.bat (or install.sh if you are on Linux) from the Superuser directory.
Here's the script that the install runs:
Code:
adb push bin/su /system/bin
adb shell chmod 4755 /system/bin/su
adb uninstall koushikdutta.superuser
adb install bin/Superuser.apk
How it works:
The modified su command looks in a whitelist database for uids that is allowed root access. That database is only accessible by the Superuser application and root.
If a database entry is found, it decrements the white list counter by one (so, an application can access su 10 times, 1 time, etc, depending on the count).
If no database entry is found, it will show the Superuser confirmation activity and wait for 10 seconds for the user to respond. If the user presses yes or always, it adds the user id to the white list. (If yes is pressed, the white list counter is just 1).
If access was granted, su will setgid/setuid and call /system/bin/sh.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Implementation:
The Superuser Java application was written by me.
su was based on the su implementation built by Google for the Android platform. http://android.git.kernel.org/?p=pl...eb00e56211962786ff89d0e7940f73d7e914e;hb=HEAD
Source code and binaries are attached to this post.

[*]The standard RC30 install will have a setuid /system/bin/su. (if you deleted disabled it, reenable it for setup)
Click to expand...
Click to collapse
v1.2 and up only, correct? Not the setuid sh of v1.1.

jashsu said:
v1.2 and up only, correct? Not the setuid sh of v1.1.
Click to expand...
Click to collapse
Edit: Yeah, you need a setuid su in /system/bin. Having a setuid sh won't work.

?
Can't root just be blocked from the handset..? So the only root access would b from adb..doesn't that make the phone safe? Or is this the only real answer to the security issue?

cookzitall said:
Can't root just be blocked from the handset..? So the only root access would b from adb..doesn't that make the phone safe? Or is this the only real answer to the security issue?
Click to expand...
Click to collapse
Yup, of course you can delete the su command from the handset so you can only adb shell for root.
However, then legitimate uses of having root on your handset would not be possible:
For example, I am currently working integrating the G1 WiFi router instructions sticked in this forum into the Android WiFi settings application.

I did this and now everything is working fine, however I was wondering how another application can have root access other than the shell program you created.
Great work by the way!

persiansown said:
I did this and now everything is working fine, however I was wondering how another application can have root access other than the shell program you created.
Great work by the way!
Click to expand...
Click to collapse
They can use the Intent that is exposed by Superuser, that Shell uses to get root:
Code:
final int SUPERUSER_REQUEST = 2323; // arbitrary number of your choosing
Intent intent = new Intent("android.intent.action.superuser"); // superuser request
intent.putExtra("name", "Shell"); // tell Superuser the name of the requesting app
intent.putExtra("packagename", "koushikdutta.shell"); // tel Superuser the name of the requesting package
startActivityForResult(intent, SUPERUSER_REQUEST); // make the request!
Then, if the user presses Yes or Always, that Java application can call su just like normal:
Code:
Runtime.getRuntime().exec("su -c <your privileged command here>");
Otherwise, that command will fail.

Koush said:
They can use the Intent that is exposed by Superuser, that Shell uses to get root:
Code:
final int SUPERUSER_REQUEST = 2323; // arbitrary number of your choosing
Intent intent = new Intent("android.intent.action.superuser"); // superuser request
intent.putExtra("name", "Shell"); // tell Superuser the name of the requesting app
intent.putExtra("packagename", "koushikdutta.shell"); // tel Superuser the name of the requesting package
startActivityForResult(intent, SUPERUSER_REQUEST); // make the request!
Then, if the user presses Yes or Always, that Java application can call su just like normal:
Code:
Runtime.getRuntime().exec("su -c <your privileged command here>");
Otherwise, that command will fail.
Click to expand...
Click to collapse
Sounds good. Great job. Hopefully apps that require root in the future use this method rather than trying to force it.

Hi Koush,
I have Jf's modified RC30 but I am not that tech savy. Before I could access su in terminal emulator but now i am locked out. I downloaded both your apps off the mark but when I request superuser I get an error. Also terminal emulator now doesn't work when i enter in su. I think that was the point though.
However the error message on shell when i request superuser says;
error: permission denied: starting intent {action= android... and so on....
What should i do to get root back?
PLease advise.
Thank you,
hbguy

question
i change the "su" to a different word...thinking it wouold help with security a little while back..does that effect your program?

hey can anyone tell me what empty whitelist means?

I am having the same issue. I cannot execute su from terminal, permission denied. and when i try to get su access with the new shell program i get and error with "android.permission.ACCESS_SUPERUSER.
now my root job is all for nothing and im wondering how to get it back to normal.
Do i have to reflash from the backup image?

Check to make sure you have the latest version of the RC30 mod (1.2). If not. copy the update to your SD and install the new update. Then superuser and shell will work just fine and you will have root.

Leeah said:
Check to make sure you have the latest version of the RC30 mod (1.2). If not. copy the update to your SD and install the new update. Then superuser and shell will work just fine and you will have root.
Click to expand...
Click to collapse
Yes, don't worry: it is not possible to "lose" root with Superuser. You can always adb shell in for root; and if worst comes to worst (and it shouldn't), you can reflash.

I am updated to Jesusfreke's newest modified version 1.2 but I still get the same error when i request superuser off of shell ( i also remembered to run superuser before requesting access in shell too). I just re-flashed ( i think that's what its called) JF's modified and now I can run root on terminal emulator again if DONKEY still trying to figure out how to get it back.
I'd like to use superuser and shell but I think I'm missing something lol.
Sorry, clearly a noob here.

I think what we need is a combination of fnord's and koush's approach .
I'm thinking something along the lines of a sudo type program. Let's call it asudo (android sudo). Basically, there would be a sqlite database that contains a "white list" of user ids (java applications) that are allowed root access. This could potentially be time limited, or even "use" limited (i.e. a single use permission).
So when asudo is executed, it checks the database for the calling user id, and if it is allowed access to root, it would automatically run the specified command with root access. Otherwise, if the calling user id doesn't have explicit permission, it would prompt for a global password (which only the real person using the phone should know). The password would also be stored in the same sqlite database.
The same type of java based permissions scheme as Koush's could be implemented. When an application requests root access, it would pop up a notification screen similiar to what it shows now, with options something like - "allow access once", "allow access for 10 min", or "always allow access". And "don't allow access" of course. It would write a corresponding "allow" entry into the database based on what the user selected, and then the requesting application could execute asudo.
Thoughts?
Anyone wanna take this on? If not, I may have to do it myself

JesusFreke said:
I think what we need is a combination of fnord's and koush's approach .
I'm thinking something along the lines of a sudo type program. Let's call it asudo (android sudo). Basically, there would be a sqlite database that contains a "white list" of user ids (java applications) that are allowed root access. This could potentially be time limited, or even "use" limited (i.e. a single use permission).
So when asudo is executed, it checks the database for the calling user id, and if it is allowed access to root, it would automatically run the specified command with root access. Otherwise, if the calling user id doesn't have explicit permission, it would prompt for a global password (which only the real person using the phone should know). The password would also be stored in the same sqlite database.
The same type of java based permissions scheme as Koush's could be implemented. When an application requests root access, it would pop up a notification screen similiar to what it shows now, with options something like - "allow access once", "allow access for 10 min", or "always allow access". And "don't allow access" of course. It would write a corresponding "allow" entry into the database based on what the user selected, and then the requesting application could execute asudo.
Thoughts?
Anyone wanna take this on? If not, I may have to do it myself
Click to expand...
Click to collapse
IMO, su should act like normal su in every respect from a scripting perspective. IE, it never prompts for password on stdin. Piping in passwords from Runtime.exec is sort of kludgy. Also, if you start start prompting for passwords on su, you open a whole can of worms moving forward: some su's on people's phones will require passwords on stdin, while others won't.
That is my primary aversion to fnord's implementation; it makes development a pain, and future compatibility scary.
I think one way to do what you are suggesting is to implement a su.jar, and have a /system/bin/su script that launches that jar file. That su.jar can then redirect the stdin/stout to /system/bin/realsu (which is the vanilla RC30 v1.2 su). su.jar can interact with the Android application layer (which realsu can not do) and prompt for a password, ask for confirmation, or check the whitelist in the Android UI.
This way, su behaves exactly as it should from an implementation standpoint, inside a console. Thoughts?
Edit:
Or conversely, you can modify a normal su to block on a call to an Android Activity that asks for user confirmation. That's actually probably the better way to do it: avoid the Java code unless absolutely necessary.

I think one way to do what you are suggesting is to implement a su.jar, and have a /system/bin/su script that launches that jar file. That su.jar can then redirect the stdin/stout to /system/bin/realsu (which is the vanilla RC30 v1.2 su). su.jar can interact with the Android application layer (which realsu can not do) and prompt for a password, ask for confirmation, or check the whitelist in the Android UI.
This way, su behaves exactly as it should from an implementation standpoint, inside a console. Thoughts?
Click to expand...
Click to collapse
Having a su script launch the jar file is more or less just the same as the requesting application launch the jar directly, I think. In any case, the difference would only be relevant for Android apps that use su. Given the relatively small number of apps that will fall into that category, it begs the question whether it is really necessary to implement Android su so perfectly transparent. I also wonder if the fully open Android implementations (e.g. Android on Freerunner) will have a su command and if so what their security implementation will be like.
Also, if you start start prompting for passwords on su, you open a whole can of worms moving forward: some su's on people's phones will require passwords on stdin, while others won't.
Click to expand...
Click to collapse
Coming together and getting a de facto standard solution in place (and possibly pre-installed in JF's update packages) can't hurt.

jashsu said:
Having a su script launch the jar file is more or less just the same as the requesting application launch the jar directly, I think. So the only benefit would be for Android apps that specifically use su. Given the relatively small number of apps that will fall into that category, it begs the question whether it is really necessary to implement Android su so perfectly transparent. I also wonder if the fully open Android implementations (e.g. Android on Freerunner) will have a su command and if so what their security implementation will be like.
Coming together and getting a de facto standard solution in place (and possibly pre-installed in JF's update packages) can't hurt.
Click to expand...
Click to collapse
Yeah, I admit the su script isn't ideal. Which is why I edited my post and suggested that su block on an Android Activity (the other way around) when necessary.
Off the top of my head, there are several applications that I am working on or have planned that will require su:
Fully configurable WiFi Router UI (that basically automates the instructions found in the sticky in this forum)
Screenshot Application
Auto Screen Rotation
And there will be even more applications that will require su as we move forward: and they won't just be reduxes of a console/shell, where it is reasonable to prompt for a password on stdin. So for that reason, I want the su implementation to be as transparent as possible, so future usage from Java applications isn't a pain in the ass.

Jf, you are the man! and yes i am making sure that this message is over the required character and it is indeed a message with a profound meaning...
hbguy

Creating /system/xbin on Android 9

Hoo roo,
Am currently trying to install a custom version of BusyBox to get Linux Deploy working. The installation script is slightly buggy, but you can workaround it by changing the .sh script slightly and creating the folder /system/xbin.
However, having a bit of trouble. Using su in Termux and mounting / as rw, then attempting to mkdir /system/xbin softlocks my Boox Max 3. This appears to be as a result of android 9 doing system-as-root.
I'm following the instructions mentioned in this Github issue.
Am so close to getting working Arch Linux on my eink tablet, can anyone point me in the right direction? Thank you in advance

If you want to tamper Android's system partition then
Phone's bootloader must be unlocked
AVB must be disabled
before.
Also: Android's /system partition is of fixed size. Have you checked there is enough free space to hold the BusyBox suite, too?

Why not install your BusyBox suite in /system/bin, what will overwrite Android's default ToyBox suite thus you won't have 2 more or less equal suites present in Android?

jwoegerbauer said:
If you want to tamper Android's system partition then
Phone's bootloader must be unlocked
AVB must be disabled
before.
Also: Android's /system partition is of fixed size. Have you checked there is enough free space to hold the BusyBox suite, too?
Click to expand...
Click to collapse
Thank you so much for responding jwogerbauer, using TWRP so bootloader is unlocked, and dm-verity is disabled as well. There's also most definitely enough space on /system, can't even make the folder though.
Linux Deploy needs this specific version of BusyBox installed, which is strange. The developer is a bit slack and more of a shell scripting sort of guy, so there's a heap of small hack arounds.
Was thinking there might be something possible with symlinks or something, but no idea where to start

snug.gy said:
Hoo roo,
Am currently trying to install a custom version of BusyBox to get Linux Deploy working. The installation script is slightly buggy, but you can workaround it by changing the .sh script slightly and creating the folder /system/xbin.
However, having a bit of trouble. Using su in Termux and mounting / as rw, then attempting to mkdir /system/xbin softlocks my Boox Max 3. This appears to be as a result of android 9 doing system-as-root.
I'm following the instructions mentioned in this Github issue.
Am so close to getting working Arch Linux on my eink tablet, can anyone point me in the right direction? Thank you in advance
Click to expand...
Click to collapse
How can I create xbin on android 11 please? Its rooted and unlocked thank you

Why trying to install BusyBox? Android since version 6 already comes with ToyBox - Android's official BusyBox equivalent.

xXx yYy said:
Why trying to install BusyBox? Android since version 6 already comes with ToyBox - Android's official BusyBox equivalent.
Click to expand...
Click to collapse
I have instructions to install other things that I'm following and that requires for me to put things into that specific ×bin to then give commands on terminal emulator and working with linux I think it def is for busy box @xXx yYy thanks

Joy28 said:
I have instructions to install other things that I'm following and that requires for me to put things into that specific ×bin to then give commands on terminal emulator and working with linux I think it def is for busy box @xXx yYy thanks
Click to expand...
Click to collapse
So what should I do how do I get it on there? Thx

Joy28 said:
So what should I do how do I get it on there? Thx
Click to expand...
Click to collapse
@xXx yYy

Since now almost 2 years you ( and other member ) are struggling with this problem: looks you ( both ) never correctly read the related posts here.
Same question got asked here, too
Creating /system/xbin on Android 9
Hoo roo, Am currently trying to install a custom version of BusyBox to get Linux Deploy working. The installation script is slightly buggy, but you can workaround it by changing the .sh script slightly and creating the folder /system/xbin...
forum.xda-developers.com
Note:
BusyBox binary ( current version is 1.36_0 released 3 weeks ago ) is compiled to be run on Android 8 and lower. For Android 8 and higher you've to use BusyBox as Magisk module.
My recommdation: Install Brutal BusyBox as Magisk module. Watch this video:
BTW:
Folder /system/xbin holds “Extra” binaries generated by some of 3rd-party-packages that aren’t essential to the system’s operation. To get these binaries working Android's path variable must get adjusted, too.
Folder /system/ sbin typically hold binaries essential to the system administrator, it contains only ueventd and adbd.
FYI:
TWRP times ago has started replacing Busybox with Toybox

xXx yYy said:
Since now almost 2 years you ( and other member ) are struggling with this problem: looks you ( both ) never correctly read the related posts here.
Same question got asked here, too
Creating /system/xbin on Android 9
Hoo roo, Am currently trying to install a custom version of BusyBox to get Linux Deploy working. The installation script is slightly buggy, but you can workaround it by changing the .sh script slightly and creating the folder /system/xbin...
forum.xda-developers.com
Note:
BusyBox binary ( current version is 1.36_0 released 3 weeks ago ) is compiled to be run on Android 8 and lower. For Android 8 and higher you've to use BusyBox as Magisk module.
My recommdation: Install Brutal BusyBox as Magisk module. Watch this video:
BTW:
Folder /system/xbin holds “Extra” binaries generated by some of 3rd-party-packages that aren’t essential to the system’s operation. To get these binaries working Android's path variable must get adjusted, too.
Folder /system/ sbin typically hold binaries essential to the system administrator, it contains only ueventd and adbd.
FYI:
TWRP times ago has started replacing Busybox with Toybox
Click to expand...
Click to collapse
I dont have an sbin either please in really simple terms can you please tell me how to install xbin??? Please I'm going crazy over here

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

No i need this bad please can you point me in the right direction

just install busybox from Magisk
https://github.com/Magisk-Modules-Repo/busybox-ndk

aIecxs said:
just install busybox from Magisk
https://github.com/Magisk-Modules-Repo/busybox-ndk
Click to expand...
Click to collapse
Thanks but I don't think that is the extent of it... I need to put linux file into xbin

I am using Linux Deploy app on systemless-root without any hassle

Please see pm

I don't reply pm. keep it in the threads.
what's the point, if you're rooted with Magisk, just install UPDATE-Busybox.Installer.v1.34.1-ALL-signed.zip from Magisk modules, reboot, and find "compatible BusyBox in path /system/xbin" (or /system/bin if no mount point exist)
Linux Deploy doesn't care about install location of busybox as long as it is in path.

I need help rooting my zte quest 5

Ok so i got a zte quest 5 (z3351s) though qlink. Not the phone i wanted but it was one i could afford. And it works very well just can't run amazon music and other apps at the same time.
But the bloatware is unreal. Used to in my galaxy s3&s4 days i could root and delete all apps i didn't need. I know i can disable them but i want them gone completely.
Majisk didnt work
Kingoroot same even used pc.
I am hoping someone knows of a way i can root this phone or at least delete all the un needed apps for example i have Google maps go (came stock) i put the org google maps which is better plus offers sat view.
Edit i did some math and converting and the useless apps 11 out of 58 come out to 349.72mb which is a lot if your phone only has 16gb of space. Also note i don't have hardly anything.
Worst case i can Hotspot to my note10+ for multitasking but not sure of data limit.

@TexasPride
a phone's Android can get considered "rooted" as soon as in Android the SU-binary is present. Hence you at any time at your own can install the appropriate SU-binary onto your phone's Android by means of ADB.

I heard about adb methods but i haven't messed with it in forever since apk/ios apps came out

jwoegerbauer said:
@TexasPride
a phone's Android can get considered "rooted" as soon as in Android the SU-binary is present. Hence you at any time at your own can install the appropriate SU-binary onto your phone's Android by means of ADB.
Click to expand...
Click to collapse
Are you sure it will always work?
I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb
As a result, I got my phone eternally showing the boot logo and not booting.
Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.
If you could give a link to some other method how SU could be installed, I'll give it a try of course.

vp1117 said:
Are you sure it will always work?
I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb
As a result, I got my phone eternally showing the boot logo and not booting.
Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.
If you could give a link to some other method how SU could be installed, I'll give it a try of course.
Click to expand...
Click to collapse
I spoke of SU-binary and NOT of SuperSU installer package
Example:
Code:
adb devices
adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
adb shell "chmod 0777 /sdcard/Downloads/su"
Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.

TexasPride, sorry I stepped in your thread.​
jwoegerbauer said:
I spoke of SU-binary and NOT of SuperSU installer package
Click to expand...
Click to collapse
I see. It is often mixed in numerous materials one can find in the net. Subject is SU-binary update, but the ultimate goal is to install supersu.
jwoegerbauer said:
Example:
Code:
adb devices
adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
adb shell "chmod 0777 /sdcard/Downloads/su"
Click to expand...
Click to collapse
What should be result of running this code? SU-binary located in Downloads with 777 permission? What is the practical sense/use of it?
What software/application would use SU in that location?
Sorry for my questions. I'm not arguing. I try to understand the idea.
jwoegerbauer said:
Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.
Click to expand...
Click to collapse
Somehow, with my almost zero knowledge of edify and linux command line I got the same conclusion: SuperSU zip has to be modified in order to install it via adb on devices that do not have TWRP for sideload. I failed to find any examples of SuperSU modding...

@vp1117
Answering your questions from last to first:
Installing SuperSU.zip via ADB
The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Making use of SU-binary
The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
Running in Android via ADB a command that requires super-user ( root ) rights is done as follows
Example:
Code:
adb devices
adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"

jwoegerbauer said:
Answering your questions from last to first:
Installing SuperSU.zip via ADB
The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
Click to expand...
Click to collapse
OK. I guess, I can repack zip to tar.
Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?
jwoegerbauer said:
Making use of SU-binary
The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
Running in Android via ADB a command that requires super-user ( root ) rights is done as follows
Example:
Code:
adb devices
adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"
Click to expand...
Click to collapse
Interestingly, I can execute all commands I need without having su-binary (~100 KB) uploaded to my phone. It is strange but I see #-prompt after I ran <adb shell>. This happens on my UNrooted phone, running stock ROM. I guess, it's a specifics of my phone, no need to try explain it.

I done failed trying to read i dont really understand linux all that well. But if anyone has any links so i can download it and try it

vp1117 said:
Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?
Click to expand...
Click to collapse
Of course it's your decision how you transfer the SuperSU package onto phone: many ways lead to Rome.
My decision was to push SuperSU package repacked as TAR-file onto phone, extract it there, and finally run the modified update-binary.sh when phone is booted into recovery mode:
Code:
adb shell "$(cat < %supersu_dir%/update-binary.sh); echo $?"

So I rebooted to stock recovery and then uploaded following from UPDATE-SuperSU-v2.82-20170528234214.zip package to my phone's folder /tmp:
/arm64
/common
/META-INF
update-binary.sh
Here is what I got:
Z:\android\adb>adb shell "$(cat < /tmp/update-binary.sh); echo $?"
127
/system/bin/sh: #!/sbin/sh: not found
And here's what I got running same command from # command line:
# $(cat < /tmp/update-binary.sh); echo $?
/system/bin/sh: #!/sbin/sh: not found
127
In response to # ls -al /sbin I get lots of lines one of them is as follows:
lrwxrwxrwx 1 root root 7 1970-01-01 00:00 sh -> busybox
I feel that I'm doing something wrong, but what exactly?
In attached txt-file I put some more details I got in command line.

jwoegerbauer said:
... and finally run the modified update-binary.sh when phone is booted into recovery mode:
Click to expand...
Click to collapse
Am I right the only modification needed is to rename update-binary to update-binary.sh ?

@vp1117
NO.
When I said modified then I didn't mean simply rename it: The contents of original update-binary file must be rewritten / deleted in some parts. Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above. Take also note that, if device's Android isn't rooted yet, the location for unpacked SuperSU mandatory must be /data/local/tmp.
BTW:
I can see BusyBox is installed on your device's Android. Take note that BusyBox by default comes with the SU-binary. Hence your device's Android is rooted! Wondering why you waste your time with trying to completely install SuperSU from scratch?

jwoegerbauer said:
Wondering why you waste your time with trying to completely install SuperSU from scratch?
Click to expand...
Click to collapse
Good question.
Probably, because I see this when phone restarts from recovery to normal android:

jwoegerbauer said:
Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above.
Click to expand...
Click to collapse
OK, no problem, I can re-pack zip into tar.
However, what you demonstrated above was a screenshot showing update-binary.sh being inside the tar. At the same time you don't tell how update-binary.sh must be amended. Is it OK?

TexasPride​
I'm very sorry I put so much spam in your thread. Please forgive me. If I knew how to delete my posts here I would deleted them.

vp1117 said:
TexasPride​
I'm very sorry I put so much spam in your thread. Please forgive me. If I knew how to delete my posts here I would deleted them.
Click to expand...
Click to collapse
Its ok, i dont mind at all.

@TexasPride
FYI: I no longer participate this hijacked thread.

Universal custom recovery

Hi, I'm kind of a noob when it comes to rooting devices (I've done it, but only with tutorials I can't do it on my own). Recently I got stuck with my device as I can't find a custom recovery for it.
My question is, is there a universal custom recovery for all smartphones or some kind of temporary custom recovery that can help me just to root my decide?

To root a device's Android a Custom Recovery is NOT needed.

jwoegerbauer said:
To root a device's Android a Custom Recovery is NOT needed.
Click to expand...
Click to collapse
Thank you for replying, the metod without custom recovery requires me to have boot.img which i don't have because there is none online for my specific device.
I tried to Google my way around (extract the image from my own device) but that requires custom recovery

Nikola.L said:
Hi, I'm kind of a noob when it comes to rooting devices (I've done it, but only with tutorials I can't do it on my own). Recently I got stuck with my device as I can't find a custom recovery for it.
My question is, is there a universal custom recovery for all smartphones or some kind of temporary custom recovery that can help me just to root my decide?
Click to expand...
Click to collapse
There is no such thing as a universal custom recovery that works with all devices. There is only custom recovery built for each specific device model number or custom recovery that is compatible with your specific CPU chipset.
Have you considered using Magisk to root your device?
First, you need to find out if your bootloader is locked or unlocked, if it is locked, you'll have to find a method to unlock the bootloader on your specific model number. If it is unlocked, you can use the Magisk method to root your device. You can't use TWRP or Magisk if your bootloader is locked.

Droidriven said:
There is no such thing as a universal custom recovery that works with all devices. There is only custom recovery built for each specific device model number or custom recovery that is compatible with your specific CPU chipset.
Have you considered using Magisk to root your device?
First, you need to find out if your bootloader is locked or unlocked, if it is locked, you'll have to find a method to unlock the bootloader on your specific model number. If it is unlocked, you can use the Magisk method to root your device. You can't use TWRP or Magisk if your bootloader is locked.
Click to expand...
Click to collapse
I managed to unlock my bootloader, that part is done. The problem with magisk is that I need boot image for my device like I mentioned above and there is none online.

Nikola.L said:
Thank you for replying, the metod without custom recovery requires me to have boot.img which i don't have because there is none online for my specific device.
I tried to Google my way around (extract the image from my own device) but that requires custom recovery
Click to expand...
Click to collapse
To root device's Android Magisk - or whatever else 3rd-party tool - is NOT needed if Android version is 6 and up: one only have to replace the merged restricted Toybox by an unrestricted version ( e.g. 0.8.5 ) what comes with SU embedded.

jwoegerbauer said:
To root device's Android Magisk - or whatever else 3rd-party tool - is NOT needed if Android version is 6 and up: one only have to replace the merged restricted Toybox by an unrestricted version ( e.g. 0.8.5 ) what comes with SU embedded.
Click to expand...
Click to collapse
I haven't heard of this metod before, do you have a guide for this or any directive?

jwoegerbauer said:
To root device's Android Magisk - or whatever else 3rd-party tool - is NOT needed if Android version is 6 and up: one only have to replace the merged restricted Toybox by an unrestricted version ( e.g. 0.8.5 ) what comes with SU embedded.
Click to expand...
Click to collapse
I'm assuming that the restricted toybox that you are talking about is part of the system partition. The problem with this idea is that root is required BEFORE you can remove, replace or install anything to or from system partition.
I did a search for:
"Root android merge Toybox"
And I got absolutely no results of any kind discussing how to root android by this method. However, I did see discussions of doing what you mentioned AFTER the device had already been rooted prior to attempting to merge Toybox.
I'm not sure that you understand its usage properly. If that is the case, don't suggest things that you don't understand in depth.

Droidriven said:
I'm not sure that you understand its usage properly. If that is the case, don't suggest things that you don't understand in depth.
Click to expand...
Click to collapse
Why do you troll me? That you lack imagination, I can't help that.
I have several phones' Android rooted the way mentioned above. Also someone in another thread some weeks ago has reported he/she successfully managed it, too.
All you need is a copy of unrestricted Toybox suitable to phone's Android, a working ADB connection and of course knowledge of ADB commands & Linux shell scripting.
FYI: Toybox is located either in /system or /vendor.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I will reconsider if I want to be active here at all ...

jwoegerbauer said:
Why do you troll me? That you lack imagination, I can't help that.
I have several phones' Android rooted the way mentioned above. Also someone in another thread some weeks ago has reported he/she successfully managed it, too.
All you need is a copy of unrestricted Toybox suitable to phone's Android, a working ADB connection and of course knowledge of ADB commands & Linux shell scripting.
FYI: Toybox is located either in /system or /vendor.
View attachment 5415783
I will reconsider if I want to be active here at all ...
Click to expand...
Click to collapse
Can you provide me with download link for this program? Also any kind of pointers would be helpful if you have any. Thanks a lot!

jwoegerbauer said:
Why do you troll me? That you lack imagination, I can't help that.
I have several phones' Android rooted the way mentioned above. Also someone in another thread some weeks ago has reported he/she successfully managed it, too.
All you need is a copy of unrestricted Toybox suitable to phone's Android, a working ADB connection and of course knowledge of ADB commands & Linux shell scripting.
FYI: Toybox is located either in /system or /vendor.
View attachment 5415783
I will reconsider if I want to be active here at all ...
Click to expand...
Click to collapse
I wasn't trolling, I looked into what you were talking about and I didn't find anything at all about how to use this to root a device, nothing about devices that have been rooted using this method and nothing about which devices it works on or doesn't which made me have doubts, so I questioned you about it.
How is this able to inject anything that isn't stock into system without already being rooted? In my experience, unlocking bootloader allows applying custom software but doesn't allow applying anything to a stock system without being rooted first. If it were that easy, there wouldn't be so many devices on this website that do not have working root methods. If what you say is true then this would work on all devices but it obviously does not. I'll grant that it may work on certain devices but not all. There are many devices since Marshmallow that have not found root by any method, no matter what has been tried. If it were that easy, this method would be more popular and more people would be using it and there would be many, many threads here describing how those users used this method to root this device. My thoughts are that this method must have some kind of limitations on what it works on what it doesnt, which would explain why this method isn't more known or more popular. I've been on this website for many years, including being a Recognized Contributor and a Forum Moderator, I know this website very well and I've seen many different rooting methods come and go, each time there is a breakthrough in rooting methods, that breakthrough immediately becomes more popular and used by everyone and I don't see this happening with the method you mention. I'm just saying there has to be more to this method than what you think.
What kinds of devices have you used this on?

@Droidriven
that the method I mentioned is not popular probably has to do with people not knowing how Android works, people not really knowing what rooting means, people not being able to think EASILY, people not being willing to use ADB ( wrapped into a Windows command script ) or EDIFY ( wrapped into an updater-script ) but people always expecting an app they can click / touch around in.
BTW: I hate all those 3rd-party tools that promise to root Android, especially if they are not open-sourced, I can't see what the programs actually do.
The method I mentioned DOES NOT INJECT additional binaries but simply replaces an existing one - namely Toybox: Toybox is integral part of any Android version 6 and higher, it's independet of a device's brand / model.
As said above: This can get achieved by either a Windows command script utilizing ADB commands and a temporay root or an updater-script utilizing EDIFY commands. IMO using an updater-script ( stored in OTA file ) of course is the more elegant way, it even can get flashed via ADB Sideload method from within Stock Recovery.
See also here:
Been trying for over a month and can't get root on LG Phoenix 5
So I've always had a rooted heavily moded android phone but the situation I find my self in all I'm probably going to have acsses to is a cheap LG Phoenix 5 LM-K300AM and very limited acsses to a PC. I could handle that if this phone was rooted...
forum.xda-developers.com

jwoegerbauer said:
@Droidriven
that the method I mentioned is not popular probably has to do with people not knowing how Android works, people not really knowing what rooting means, people not being able to think EASILY, people not being willing to use ADB ( wrapped into a Windows command script ) or EDIFY ( wrapped into an updater-script ) but people always expecting an app they can click / touch around in.
BTW: I hate all those 3rd-party tools that promise to root Android, especially if they are not open-sourced, I can't see what the programs actually do.
The method I mentioned DOES NOT INJECT additional binaries but simply replaces an existing one - namely Toybox: Toybox is integral part of any Android version 6 and higher, it's independet of a device's brand / model.
As said above: This can get achieved by either a Windows command script utilizing ADB commands and a temporay root or an updater-script utilizing EDIFY commands. IMO using an updater-script ( stored in OTA file ) of course is the more elegant way, it even can get flashed via ADB Sideload method from within Stock Recovery.
See also here:
Been trying for over a month and can't get root on LG Phoenix 5
So I've always had a rooted heavily moded android phone but the situation I find my self in all I'm probably going to have acsses to is a cheap LG Phoenix 5 LM-K300AM and very limited acsses to a PC. I could handle that if this phone was rooted...
forum.xda-developers.com
Click to expand...
Click to collapse
Well that explains it, the method you are talking about uses temp ROOT, it is like I said from the beginning, root(whether temporary or permanent) is required in order to inject anything (and yes, this method DOES inject additional binaries, the su binaries, they weren't there to begin with so they are "additional binaries", they are just included with the replaced file). That part about temp root leads me to believe that may be a factor in some way that limits what devices the method will work on or not.
I've used a similar method to this to root an Intel Atom based device years ago.
I'll try this on a couple of devices that I have that haven't been rooted and see what happens, though I'm not expecting positive results considering the many different methods and tricks that I've learned over the years on them.

To clarify things:
A temporary root is only required if ADB ( Windows command script ) is used.
FYI:
If using ADB ( Windows command script ) then temporary root ( read: matching SU binary, ~100 KB ) by serious programmers gets temporarily stored in /data/local/tmp what by default is mounted as RW on any Android and gets deleted if no longer used.

jwoegerbauer said:
To clarify things:
A temporary root is only required if ADB ( Windows command script ) is used.
FYI:
If using ADB ( Windows command script ) then temporary root ( read: matching SU binary, ~100 KB ) by serious programmers gets temporarily stored in /data/local/tmp what by default is mounted as RW on any Android and gets deleted if no longer used.
Click to expand...
Click to collapse
Yes, I know what temp root is, I've used it myself by different methods. But, I also know that existing temp root solutions don't necessarily work on all devices, as all things android, YMMV, nothing is universally applicable to all android devices except for the fact that they all have a power button.