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.

[SECURITY] Multiple Android Superuser vulnerabilities

Well, I was going to hold off until all of the vendors had new releases posted, but now that the cat is out of the bag and the evildoers have sufficient information to figure out what got fixed:
[size=+1]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.[/size]
This is expected to impact the vast majority of rooted devices and custom ROMs.
Details follow:
[size=+2]Superuser unsanitized environment vulnerability on Android <= 4.2.x[/size]
Vulnerable releases of several common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root without notifying the device owner:
ChainsDD Superuser (current releases, including v3.1.3)
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of third-party ROMs include one of these packages.
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. In the course of its normal duties, and prior to making the allow/deny decision, /system/xbin/su invokes external programs under a privileged UID, typically root (0) or system (1000):
/system/bin/log, to record activity to logcat
/system/bin/am, to send intents to the Superuser Java app
/system/bin/sh, to execute the /system/bin/am wrapper script
/system/bin/app_process, the Dalvik VM
The user who invokes /system/xbin/su may have the ability to manipulate the environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items belonging to any of these subprocesses. At least two vulnerabilities are readily apparent:
- On ClockWorkMod Superuser, /system/xbin/su does not set PATH to a known-good value, so a malicious user could trick /system/bin/am into using a trojaned app_process binary:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > app_process ; chmod 755 app_process
PATH=`pwd`:$PATH su -c 'true'
The PATH vulnerability is being tracked under CVE-2013-6768.
- Other environment variables could be used to affect the behavior of the (moderately complex) subprocesses. For instance, manipulation of BOOTCLASSPATH could cause a malicious .jar file to be loaded into the privileged Dalvik VM instance. All three Superuser implementations allowed Dalvik's BOOTCLASSPATH to be supplied by the attacker.
The BOOTCLASSPATH vulnerability is being tracked under CVE-2013-6774.
[size=+2]Android Superuser shell character escape vulnerability[/size]
Vulnerable releases of two common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root, either without prompting the user or after the user has denied the request:
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of recent third-party ROMs include one of these packages. Older ROMs may use the ChainsDD Superuser package, which is not affected but is no longer maintained.
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.
If the user invokes "su -c 'COMMAND'" and the request is denied (or approved), ClockWorkMod Superuser constructs a command line to pass to a root shell:
Code:
snprintf(user_result_command, sizeof(user_result_command), "exec /system/bin/am " ACTION_RESULT " --ei binary_version %d --es from_name '%s' --es desired_name '%s' --ei uid %d --ei desired_uid %d --es command '%s' --es action %s --user %d",
VERSION_CODE,
ctx->from.name, ctx->to.name,
ctx->from.uid, ctx->to.uid, get_command(&ctx->to),
policy == ALLOW ? "allow" : "deny", ctx->user.android_user_id);
get_command() would return "COMMAND", unescaped, through "/system/bin/sh -c". By adding shell metacharacters to the command, the root subshell can be tricked into running arbitrary command lines as root:
Code:
su -c "'&touch /data/abc;'"
Upon denial by the operator, "touch /data/abc" will be executed with root privileges. The Superuser variant of this problem is being tracked under CVE-2013-6769.
SuperSU prior to v1.69 removes quote and backslash characters from the string passed to /system/bin/sh, but backticks or $() can be used instead for the same effect:
Code:
su -c '`touch /data/abc`'
su -c '$(touch /data/abc)'
The SuperSU variant of this problem is being tracked under CVE-2013-6775.
ChainsDD Superuser v3.1.3 does not appear to pass the user-supplied input on the /system/bin/am command line.
[size=+2]Superuser "su --daemon" vulnerability on Android >= 4.3[/size]
Current releases of the CyanogenMod/ClockWorkMod/Koush Superuser package may allow restricted local users to execute arbitrary commands as root in certain, non-default device configurations.
Android 4.3 introduced the concept of "restricted profiles," created through the Settings -> Users menu. A restricted profile can be configured to allow access to only a minimal set of applications, and has extremely limited abilities to change settings on the device. This is often used to enforce parental controls, or to protect shared devices set up in public places. The OS requires an unlock code to be entered in order to access the owner's profile to administer the system.
/system/xbin/su is a setuid root executable, and any user may invoke it in client mode ("su -c 'foo'" or just "su"), or in daemon mode ("su --daemon"). In either mode of operation, the user who invokes this program has the ability to manipulate its environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items. By adding new entries at the front of the PATH for commonly-executed root commands, then re-invoking "su --daemon", an attacker may be able to hijack legitimate root sessions subsequently started by other applications on the device.
"su --daemon" is normally started up very early in the boot process, as root, from /init.superuser.rc (CM) or from /system/etc/install-recovery.sh (other ROMs). The fact that unprivileged users are allowed to restart the daemon later, under EUID 0, appears to be an oversight.
Successful exploitation requires a number of conditions to be met:
- The attacker must have ADB shell access, e.g. over USB. This is disabled by default, and normally restricted to trusted ADB clients whose RSA key fingerprints have been accepted by the device administrator. Root access via ADB (i.e. Settings -> Developer Options -> Root access -> Apps and ADB) is not required. Note that ADB shell access is typically considered a security risk, even in the absence of this problem.
- The attacker must have a way to assume a non-shell (non-2000), suid-capable Linux UID in order to prevent /system/xbin/su from creating infinitely recursive connections to itself through the daemon client UID check in main(). One way to do this would involve uploading an app with the "debuggable" flag and using /system/bin/run-as to assume this UID. "adb install" can probably used for this purpose. However, due to a bug in Android 4.3's "run-as" implementation[1], this does not currently work. This bug was fixed in Android 4.4, so CM11 will probably be able to satisfy this requirement.
- The device owner must have granted root permissions to one or more applications via Superuser. The restricted profile does not need to be able to run this app from the launcher.
Sample exploit:
The restricted local user can reboot the tablet, run "adb shell" when the boot animation shows up, then invoke the following commands:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > /data/local/tmp/trojan
chmod 755 /data/local/tmp/trojan
for x in id ls cp cat touch chmod chown iptables dmesg; do ln -s trojan /data/local/tmp/$x ; done
PATH=/data/local/tmp:$PATH setsid run-as.422 my.debuggable.package /system/xbin/su --daemon &
(Note the use of "run-as.422" as a proxy for a working Android 4.3 run-as binary, and the installation of "my.debuggable.package" with the debuggable flag set.)
At this point the USB cable may be disconnected.
The next time a root application successfully passes the Superuser check and invokes one of the trojaned shell commands, /data/local/tmp/trojan will be executed under UID 0.
An ideal candidate for exploitation is a package which runs privileged commands on boot, e.g. AdBlock Plus or AFWall+, as this allows for instant access. Another possibility is to hijack an app which the device's operator runs frequently, such as Titanium Backup.
Note that this can NOT be exploited by malicious applications, as zygote-spawned processes (apps) always access /system in nosuid mode[2] on Android 4.3+. The ADB shell was used as the attack vector as it is not subject to this restriction.
ChainsDD Superuser v3.1.3 does not have an Android 4.3+ client/server mode at all, and SuperSU aborts if an existing "daemonsu" instance is already bound to the abstract @"eu.chainfire.supersu" socket.
Proposed resolution: on Android 4.3 and higher, install all Superuser-related binaries with mode 0755 (setuid bit unset).
This problem is being tracked under CVE-2013-6770.
[1] https://code.google.com/p/android/issues/detail?id=58373
[2] http://source.android.com/devices/tech/security/enhancements43.html

Did you report that to @Chainfire?

SecUpwN said:
Did you report that to @Chainfire?
Click to expand...
Click to collapse
Yes, he's been very responsive.
I contacted all three developers last Saturday, and posted the advisory after there was enough public information available to deduce what the problems were.
In case you're curious, there's been some additional discussion about exploiting ChainsDD Superuser on BUGTRAQ.

Is there a way we can patch this maybe using xposed framework

milojoseph said:
Is there a way we can patch this
Click to expand...
Click to collapse
There are new releases of SuperSU and CWM Superuser posted:
https://play.google.com/store/apps/details?id=eu.chainfire.supersu&hl=en
http://forum.xda-developers.com/showthread.php?t=1538053
https://play.google.com/store/apps/details?id=com.koushikdutta.superuser&hl=en
I haven't seen any updates to ChainsDD Superuser, and AFAICT the project is no longer maintained.
maybe using xposed framework
Click to expand...
Click to collapse
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.

cernekee said:
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.
Click to expand...
Click to collapse
There's always Substrate, that can be used even for patching native code, but still in this case not applicable I guess.

Where you able to find any patch to fix them?

thank you for sharing ...

I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78

diabolicalprophecy said:
I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78
Click to expand...
Click to collapse
Did you get an answer for this? I have the same issue on 4.4.4

Vankog said:
Did you get an answer for this? I have the same issue on 4.4.4
Click to expand...
Click to collapse
No I didn't, I reflashed the rom and it solved the problem.

is rooting this simple?

I have looked into rooting, and I don't understand how it works, but from what I can tell, shouldn't people be able to root using adb to change a file that is run regularly in /system, so that whenever it runs it would grant a given app root perms, and that app would then be able to give others root perms? would you have to change the file another way because adb doesn't run commands as root? wouldn't this be alot more simple than what has been being done?

Rooting a phone''s Android technically is simply adding standard Linux function SU ( read: Switch User ) to Android's ecosystem.
Once SU got added and you run the file without any other parameters it switches your credentials and permissions from a normal user to that of the superuser ( comparable to Administrator on Windows OS ). You are then in complete control and can add anything, remove anything and access functions on your phone that you couldn't reach before.
BTW:
With Android versions 6 and higher all what is needed is to replace the pre-installed ( restricted ) Toybox binary with an unrestricted Toybox binary ( e.g. 0.8.5 ) that contains the SU-cmdlet.

If I am understanding this, than you need to grant an app SU, but first you have to install the command that allowes giving of SU? or turn on that command (on android 6+), and grant a manager app permission to use it?

What does "the su binary is out of date " actually mean? Is there a way to manually fix this?

Quick background: I want to start fresh with my Nook Tablet and leave out GApps this time, opting for microG instead. I'm familiar with all that entails and have done it on other devices.
The problem, in a nutshell: After wiping and reflashing the custom AOSP 7.0 ROM, I flash a small zip which contains and places the su binary (as far as I understand). Then I reboot and install a Superuser control app. I get "the su binary is out of date" message and do not have root.
I am following my own instructions from here when I first flashed the ROM with GApps. But now they don't work! Later in that thread a few people express problems with the same thing.
So...what does this "out of date" business actually mean? Is there a "use by" date on the su or something? That seems unlikely. I've tried all kinds of orders of operation with this thing but keep coming up with the same result. Searching around on line I can't seem to find any sort of explanation, just a lot of schemes, many dubious.
I've looked at SuperSU zip packages, but every one I try seems to be wanting system-less root and there is no way I know to unlock the bootloader.
I know that Magisk exists, but have never gotten into using it. I'd rather not, if possibe. I just don't see why something that worked a few years ago does not work now. It's not like it needs to contact a remote source for information.
As a last resort I could return to a backup and try to manually remove GApps but I'd really rather start with a clean ROM install and go from there. I need root to do what I want or I wouldn't bother with any of this.
Suggestions, explanations?

Uninstall / delete SuperSU app.
FYI:
The SU binary is a Android shell command typically incorporated in Toybox, the Linux commands suite merged with Android since its version 6, but left off by almost all OEMs - for good reasons.
The SU binary is available as standalone cmdlet at various locations in Internet. It also comes with Magisk.

every rooting solution's su binary is different from traditional linux su.
it simply means the su binary does not fit the Superuser app. according to support thread you still can grant root and just update su binary straight from within the app (won't work with foreign su)
https://forum.xda-developers.com/t/...linux-capable-superuser.3216394/post-64823952

aIecxs said:
every rooting solution's su binary is different from traditional linux su.
it simply means the su binary does not fit the Superuser app. according to support thread you still can grant root and just update su binary straight from within the app (won't work with foreign su)
https://forum.xda-developers.com/t/...linux-capable-superuser.3216394/post-64823952
Click to expand...
Click to collapse
Yeah, but it (the apk) doesn't do anything. And the links in the thread you reference to updated zips, etc., all give 403 errors.
I "understand" the concept of matching the su binary with the superuser controller app, but I can't see how a combination that once worked now does not. That's what is frustrating. Like it's magic.

most likely there is a foreign leftover su (chainfire's SuperSU or something else?) which is not granting access to phhusson's Superuser.

aIecxs said:
most likely there is a foreign leftover su (chainfire's SuperSU or something else?) which is not granting access to phhusson's Superuser.
Click to expand...
Click to collapse
Could be. A TWRP examination of /system/bin shows no sign of su (no wonder it needs "updating"). Meanwhile, /system/superuser is chock full of SuperSU stuff and the phh stuff, including a copy of su. So clear all that out and start again.
I guess I need to check if su is actually placed in /system/bin after flashing the zip package. Otherwise...maybe just put it there myself?

afaik all custom binaries belong to /system/xbin which is also in path. what's wrong with systemless-root in boot?
latest official SR3-SuperSU-v2.79-SR3-20170114223742.zip by Chainfire is capable of.

aIecxs said:
afaik all custom binaries belong to /system/xbin which is also in path. what's wrong with systemless-root in boot?
latest official SR3-SuperSU-v2.79-SR3-20170114223742.zip by Chainfire is capable of.
Click to expand...
Click to collapse
Before flashing the su zip there is an su already present in /system/xbin. After flashing, there is also an su present in /system/bin. And yes, I wiped thoroughly (twice).
I was surprised at the su already in /system/xbin. Out of curiosity I booted up another tablet running CM 13. It, too contains su in both locations, but the dates on the files are very different. The one in /system/bin is today's date, while the one in /system/xbin is sometime back in 2009 (like when the ROM was perhaps cooked up). Turns out even my ancient Nook Simple Touch (which is rooted) has an su in both locations.
Anyway, I see there is clearly an su newly placed in /system/bin now that I've flashed the su zip package. So it should work when the controller app is installed...
None of the Chainfire zips I have tried will work. They all seem to want the bootloader unlocked and so each one fails.

you can flash modified system on locked bootloader? Now you have root and TWRP, I guess bootloader is unlockable. I bet @AdamOutler can. at least, another guy managed it obviously...
https://forum.xda-developers.com/t/barnes-noble-nook-tablet-10-1-bntv650-working.3873476

aIecxs said:
every rooting solution's su binary is different from traditional linux su.
Click to expand...
Click to collapse
Wrong, as so often:
1. The su ( read: Substitute User ) shell command allows users to become other users. This command is thought to escalate privileges by becoming a privileged user; therefore, the default user is the root if no user-id is specified.
2. This is true for su shell command as it comes with Linux and/or Android ( where su since Android version 6 is included in Toybox command suite - and su might also be integral part of 3rd-party Linux commands suite named BusyBox )
3. All 3 mentioned su shell commands equally allows users to become other users. With no arguments passed, USER is root. Only difference is the way and order arguments get passed to su.

@jwoegerbauer you have no clue what you're talking about. I have already tried to explain you here, furthermore I have proofed you wrong there (your linked binaries were not even build with -fPIE)
I get the feeling you don't even know what a Superuser app actually is.

To my knowledge SuperUser app is predecessor of Magisk Manager app.

yes, Magisk app also includes Superuser app (second tab on bottom). how is that related to my question? Did you finally read about what su daemon is, and how the Superuser app grants requesting apps to hook up to daemon?
or do you still insist every Superuser app can just work with every su, or root access can be achieved by just toybox su (like linux su)? if so, please link the toybox used for, so I can test it myself.

I'm surprised that you're not able to find Toybox on the Internet, but you expect a link from me.
I'm also surprised that you obviously take pleasure in disparaging others here if they don't think or act as you do.
BTW:
When I'm mentioning SU at XDA threads, then I really mean the SU binary itself - as it's well known from Linux - and NOT the supersu daemon, what grant root to apps, as you do. Why exactly do one need an app to have root permissions? To enter protected user-space?

I have asked clear question, please tell us which toybox or su binary will work for getting root shell.
where shoud I place it? what permissions should I set, and how?
Spoiler
official toybox
{
"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"
}
BTW:
wasn't it you the one who called me an idiot two times when confronted with your false claims?

You have used the NON-ROOT version of Toybox.
The full version of Toybox you find here:
Index of /toybox/downloads/binaries
It's on you to replace the mangled Toybox version with the full version: shouldn't be too difficult for an Android guru as you are.

First, this toybox is missing important applets without android smartphone wouldn't work properly anymore. That's why one must not replace toybox.
second, you still haven't answered the question which location and permissions one must set.

[Vulnerability] Bluestacks root access via adb

On GitHub: https://github.com/KDVB/BlueStacks-ADB-root-access​​Disclaimer​For informational purposes only. The author does not call for further actions. Created to warn users who use this product
Background​ADB (Android Debug Brigde) - is a versatile command-line tool that lets you communicate with a device. The adb command facilitates a variety of device actions, such as installing and debugging apps. adb provides access to a Unix shell that you can use to run a variety of commands on a device.
Research Walkthrough​For default, in Bluestacks, ADB port is open, but we can't to use shell command (output "error: closed")
Searching for information in the emulator files found the following file ".adbcmd" in Root.vnhd image. Path to file "dataFS\downloads". In this file we can see adb commands that we can run without connection to shell
For example, "getprop" command, that gives us information about android propetries
As we can see, interaction with android shell is working. So, I think "if I can interact with unix shell, maybe tryed to use pipe operators" and pwn i can interact with file system, but with shell-user privilage.
As a result i continue my search to find su command to get root access. SU file is in "/boot/android/android/system/xbin/bstk/su". I tryed pipe operator to get root access, but get error and shell didn't open(
After that i tryed list terminator ";" and it works. I get root shell
Result​Bluestacks have this vulnerability and people involved in its development know about it and are engaged in its elimination.

The real test is to see if you can actually do anything. Sure, you've ID'd as root, but will it actually let you change anything?

V0latyle said:
The real test is to see if you can actually do anything. Sure, you've ID'd as root, but will it actually let you change anything?
Click to expand...
Click to collapse
Thanks for your reply. Actually you can change in current session, but when emulator reboot, all changes remove. If we speak about system folders. In sdcard folders changes save. Sorry, I didn't mention it in the post.
When i searched information on the virtual disk, i found some scripts that build a system. That takes information from .conf files, but that works only for local work. For example, when you using OpenVPN Connect that port still open and you can interact with it.