Database Info

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

Terminal and SSH access

As a new Android user but experienced in Linux I wanted to explore the command shell. I've wanted to change passwords and have use the usual commands I would normally expect to be available.
I'd like to share my experience for any other new user and open the discussion for for additions and corrections. What I say here works on a Galaxy Mini S5570 but should be pretty generic. This really does need the phone to be rooted or much will be inaccessible.
Comparing 3 methods Terminal Emulator, DigiSSHD which is run from DigiControl and SSHDroid.
There is no concept of a root password as access is granted via superuser app. When you connect your id is set from the id of the app you are using to connect.
The simplest connection is via Terminal Emulator. It requires no network connection and gives direct access to the phone. The first thing is that you have no home directory so you are dumped into / the top directory. There is no .bash_profile, .bashrc or .profile so it's customisation is not obvious.
I tested SSHDroid and DigiSSHD using wi-fi. My ssh client was the excellent Putty on Windows7.
As default SSHDroid uses port 22 while DigiSSHD uses port 2222.
For a rooted phone SSHDroid has user "root" with password "admin". This is not your device's root password. You can think of it as an access password for SSHDroid. This access password can be changed in the options for SSHDroid. It is a good idea to do so stop others getting in just as you have done.
You arrive in a home directory data/data/berserker.android.apps.sshdroid/home and inside there you will find a .profile file so you can do some customisations there. The good news is that all the usual linux functions are available in ~/bin via the PATH variable it gives you and its own busybox.
Neither Terminal Emulator nor DigiSSHD give you these functions but this is a good way to do it.
Terminal Emulator by default gives you a PATH which includes /data/local/bin. This is set by Initial Command in the Preferences but I'm taking it as it is.
There was no directory /data/local/bin. This is good because we can create it and put our own stuff in there wihout having inconsistent clashes. Create it with the correct permissions. Copy the permissions of another directory in the path in my case I used /system/bin. To check the permissions:
cd /system
ls -l
The permissions were for bin are drwxr-xr-x with Owner/Group of root and Shell. So create the new directory.
cd /data/local
mkdir bin
chmod 755 bin
chown root.Shell bin
Now you can start creating your utilities. Before you do check that each is not already available by trying to run it. It might already be provided by Toolbox. To see what busybox can do type
busybox --help
To get your utility, assuming it is available in busybox create a symlink to busybox with the name of the utility. As an example this is how to create 'more' and 'less' and the standard 'vi'
cd /data/local/bin
ln -s /system/xbin/busybox more
ln -s /system/xbin/busybox/less
ln -s /system/xbin/busybox/vi
You can carry on activating your favourite utilities. Remember to check if it already there first and NEVER forget you are doing all this as root so take care...
Why do it this way and not use the functions provided by SSHDroid? Well as an ordinary user you may not have access and if you decide to uninstall SSHDroid you would probably lose it.
Now for DigiSSHD. The default user is android with a password of 123. I have not found how to change this yet so comments welcome. Your home directory will be something like /mnt/sdcard/Android/data/org.digimead.digi.ctrl/files/var/1d7a337e-7cf8-4b28-8039-baa894f7185f
There is a .profile file in your home directory that you can edit and add the line
export PATH=/data/local/bin:$PATH
This will give you access to the same utilities (so same versions) as you have with Terminal Emulator.
That's it. The rest is up to you. Which utilities you chose and which command line app suits you. I doubt that all the busybox functions will work on an Android system because it is not an ordinary Linux.
Which is better, SSHDroid or DigiSSHD? I don't know. I'll leave that for others to comment.

Are you the admin on this other site? Terminal and SSH Access Just curious as this is exact copy/paste post from that post with no links or attributions.

[BlueStacks Beta for Mac OS X] Getting root access - Experimental

Hi guys, i tried to root Bluestacks Apps Player Beta for Mac OS X on Windows by using a method similar to the one used to root BS for Windows.
But unfortunately i am not able to test the modded files as i do not actually own a Mac OS X device, and i am not familiar with the OS either.
So i am asking, any volunteer here willing to help me test this experimental modded files?
How to use
1) Download BlueStacks AppPlayer Beta .dmg for Mac OS X & install it.
2) Download modded files provided below, make sure the targeted version is same as your installed version.
3) Extract the downloaded zip and use the modded files to replace the following folders:
Code:
~/Library/BlueStacks App Player/Android/Root.sparsefs/
~/Library/BlueStacks App Player/Android/Prebundled.sparsefs/
~/Library/BlueStacks App Player/Android/Data.sparsefs/
~/Library/BlueStacks App Player/Android/SDCard.sparsefs/
Downloads & Changelogs:
Code:
[URL="http://goo.gl/wJYSR"][SIZE="3"]BSRoot_0.3.6.102d.zip[/SIZE][/URL] (99.88 MB, Pass: [COLOR="Red"][email protected][/COLOR], Last Update: [COLOR="Red"]03/04/2013[/COLOR])
~ Target: BlueStacks for Mac OS X v[URL="http://goo.gl/ILhtK"]0.3.6.102[/URL] Only (Released: 21/03/2013)
+ Allow /system rw
+ su (standalone/on the fly)
+ Google Play v3.10.14
+ Google Contacts/Calendar Sync
+ Flash Player v11.1
+ Holo Launcher v2.0.2 Free
+ Terminal Emulator v1.0.52 OS
- Most bloatware
Notes:
- By replacing above folders, your existing settings & data will be gone, you are advised to create a backup before trying the mod.
* Please note that all version prior to the 03/04/2013 update probably will not work, try the latest version.
* If you tried please at least COME BACK TO VOTE so that i can know how it goes. Thank you!

-Reserved-

I think this worked, still trying to find a way to test the "rooted-ness" of it. Do you know where bluestacks puts the apps it installs from the market? /data seems to be empty.
---------- Post added at 04:58 PM ---------- Previous post was at 04:41 PM ----------
typing su into terminal gets me a segmentation fault
SuperSu hangs or doesn't run.
ESFile Explorer can't use it's "root" features. (Test Fails)

efdisastet said:
I think this worked, still trying to find a way to test the "rooted-ness" of it. Do you know where bluestacks puts the apps it installs from the market? /data seems to be empty.
typing su into terminal gets me a segmentation fault
SuperSu hangs or doesn't run.
ESFile Explorer can't use it's "root" features. (Test Fails)
Click to expand...
Click to collapse
Hi, Thanks for the feedback.
Without SuperSU working properly, terminal is running as app user thus you will not be able to view contents of /data/ as the folder is owned by 'system'.
Not sure why SuperSU is not working. Anyway, I have updated the files to use Superuser 3.2 instead of SuperSU, now with the updated files,
Superuser can be uninstalled easily, and if the superuser still causing problem, try uninstall it & run su without the apk installed.
Appreciate if you can retry the new file & also provide me the output for 'mount'. Thank you.

codelover said:
Hi, Thanks for the feedback.
Without SuperSU working properly, terminal is running as app user thus you will not be able to view contents of /data/ as the folder is owned by 'system'.
Not sure why SuperSU is not working. Anyway, I have updated the files to use Superuser 3.2 instead of SuperSU, now with the updated files,
Superuser can be uninstalled easily, and if the superuser still causing problem, try uninstall it & run su without the apk installed.
Appreciate if you can retry the new file & also provide me the output for 'mount'. Thank you.
Click to expand...
Click to collapse
Superuser app opened, but then closed on its own before I could check the settings.
I cleared data and then it seemed to stay open, so that I can go through the settings.
here's the result of su (still Segmentation fault)
and then mount
(sorry that it's a picture, copy seems to be an option, but can't find a way to paste.)
why does xda resize the pictures so small?
{
"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"
}

Re: [Emulator][BlueStacks Beta for Mac] Getting root access - Testers wanted
Would love to try this, codelover, but am wondering if you are testing in your own environment first, or are you expecting us to QA it? Don't get me wrong... I really appreciate you taking the lead on this, I just need to understand what my effort and interest level need to be. Thanks.
Sent from my SAMSUNG-SGH-I317 using xda premium

efdisastet said:
Superuser app opened, but then closed on its own before I could check the settings.
I cleared data and then it seemed to stay open, so that I can go through the settings.
here's the result of su (still Segmentation fault)
and then mount
Click to expand...
Click to collapse
Thanks! Now i know that /system can be mounted rw, one step forward. Next step is to find a working copy of su then we are done.
Can you confirm the Segmentation fault still appear after the apk been removed/uninstalled? One more thing, can you test run su after cd to /sdcard?
Just checked the alpha root by @bitstra, looks like they faced the same problem with superuser apk, so they have su working alone without the apk, maybe i will get you a copy of the su to test.
Btw do you have adb for Mac? Might need it to push su to BS for testing.

meatlocker said:
Would love to try this, codelover, but am wondering if you are testing in your own environment first, or are you expecting us to QA it? Don't get me wrong... I really appreciate you taking the lead on this, I just need to understand what my effort and interest level need to be. Thanks.
Click to expand...
Click to collapse
Hi meatlocker, Thank you for your interest. The answer is no, i have no chance to test it because i do not actually own a Mac.
But i have been working with BS for Windows for months that i am pretty sure Mac version can be rooted too.
I am just trying to help, it's really up to Mac users effort if they really want to see it get rooted.
The more feedback the faster it can be done. If i got a Mac that would be easier since i got several test cases that i can run on my own.
For now, everything is based on my assumption.

codelover said:
Thanks! Now i know that /system can be mounted rw, one step forward. Next step is to find a working copy of su then we are done.
Can you confirm the Segmentation fault still appear after the apk been removed/uninstalled? One more thing, can you test run su after cd to /sdcard?
Just checked the alpha root by @bitstra, looks like they faced the same problem with superuser apk, so they have su working alone without the apk, maybe i will get you a copy of the su to test.
Btw do you have adb for Mac? Might need it to push su to BS for testing.
Click to expand...
Click to collapse
yup, I've got adb installed and it see bluestacks, haven't tried to run any commands or anything
still get the Segmentation Fault and never get a typical su request popup for any app.
uninstalled superuser.
tried su in terminal, still Segmentation fault
installed SuperSu from play store
same results... app didn't run very well... tried to update itself and failed.
uninstalled
installed superuser (3.1.3?) from the Play store
took some screenshots (looked kinda hopeful?)
still same errors in terminal, no access to /data

efdisastet said:
installed SuperSu from play store
same results... app didn't run very well... tried to update itself and failed.
uninstalled
installed superuser (3.1.3?) from the Play store
took some screenshots (looked kinda hopeful?)
still same errors in terminal, no access to /data
Click to expand...
Click to collapse
You cannot install Superuser/SuperSU directly from market because it will install an arm version of the binary instead of the x86 that we need.
Now we need to identify which su binary version works with BS for Mac.
Please download the attached su-test.zip that contains various versions of su, extract to adb folder and then run the following commands:
Code:
adb push su-test /data/local/tmp/
adb shell chmod 777 /data/local/tmp/su*
adb shell /data/local/tmp/su-3.1-x86 -v
adb shell /data/local/tmp/su-3.1.1-x86 -v
adb shell /data/local/tmp/su-3.2-x86 -v
adb shell /data/local/tmp/su-bin-3.1 -v
adb shell /data/local/tmp/su-1.25 -v
adb shell /data/local/tmp/su.x86 -v
adb shell /data/local/tmp/su.orig -v
* Also try to run above su without -v
We are expecting su to returns a version number or 'permission denied' message from a working copy, instead of segmentation fault.
Please let me know which version works. I think we can finalize this soon. Thank you again.

Re: [Emulator][BlueStacks Beta for Mac] Getting root access - Testers wanted
Also, how can we get into the contents of the Android disk image files on a Mac to extract android files, etc?
And how much space do we have in the simulated Android to install apps?

Code:
adb push su-test /data/local/tmp/
adb shell chmod 777 /data/local/tmp/su*
adb shell /data/local/tmp/su-3.1-x86 -v
[COLOR="Red"]returned 3.1[/COLOR]
adb shell /data/local/tmp/su-3.1.1-x86 -v
[COLOR="red"]returned Segmentation fault[/COLOR]
adb shell /data/local/tmp/su-3.2-x86 -v
[COLOR="red"]returned Segmentation fault[/COLOR]
adb shell /data/local/tmp/su-bin-3.1 -v
[COLOR="red"]hung[/COLOR]
adb shell /data/local/tmp/su-1.25 -v
[COLOR="red"]hung[/COLOR]
adb shell /data/local/tmp/su.x86 -v
[COLOR="red"]returned Segmentation fault[/COLOR]
adb shell /data/local/tmp/su.orig -v
[COLOR="red"]returned su: permission denied[/COLOR]
* Also try to run above su without -v
[COLOR="red"]same results as above except that I got Segmentation fault on the ones that hung with -v[/COLOR]

efdisastet said:
Code:
adb shell /data/local/tmp/su-3.1-x86 -v
[COLOR="Red"]returned 3.1[/COLOR]
.....
adb shell /data/local/tmp/su.orig -v
[COLOR="red"]returned su: permission denied[/COLOR]
Click to expand...
Click to collapse
Definately a good news! I will try to rebuild Root.sparsefs to include both working copies of su-3.1 & su.orig.
But if i am not mistaken su.orig only works alone thus not supporting Superuser apk for confirmation.
EDIT: Files updated, download HERE.
CHANGES: Using su.orig copy without any Superuser apk.
NOTE: Might need to replace all new .sparsefs files instead of just Root.sparsefs.
Kinda weird as all su in su-test can run in BS for Windows except su.orig that returned Seg. fault.
Anyway, hope to hear some good news soon.

I replaced the files and kill Bluestacks, then I re-open Bluestacks .... NOTHING HAPPENED, my data and apps still there, and NO ROOT. Why?

nudawa said:
I replaced the files and kill Bluestacks, then I re-open Bluestacks .... NOTHING HAPPENED, my data and apps still there, and NO ROOT. Why?
Click to expand...
Click to collapse
1) Make sure you are using the required version, as these rooted files only works for v0.3.6.102.
2) Once you have replaced Data & SDCard, non of your existing apps should remain; If the apps still there you probably did it wrong.
3) Make sure you close your Bluestacks before replacing those files.
* Please note that the 'rooted files' mentioned above are 4 folders that contains 2 files in each folder.

codelover said:
Definately a good news! I will try to rebuild Root.sparsefs to include both working copies of su-3.1 & su.orig.
But if i am not mistaken su.orig only works alone thus not supporting Superuser apk for confirmation.
EDIT: Files updated, download HERE.
CHANGES: Using su.orig copy without any Superuser apk.
NOTE: Might need to replace all new .sparsefs files instead of just Root.sparsefs.
Kinda weird as all su in su-test can run in BS for Windows except su.orig that returned Seg. fault.
Anyway, hope to hear some good news soon.
Click to expand...
Click to collapse
did you want me to run some more tests?
so far all I've done is load the new files, open terminal, and try su: got permission denied

efdisastet said:
did you want me to run some more tests?
so far all I've done is load the new files, open terminal, and try su: got permission denied
Click to expand...
Click to collapse
Have you tried executing 'su' from adb instead of Terminal?
I am not sure how the included su.orig from alpha should behave as i got segfault here on Windows.
Unlike the newer SuperSU that works without apk, the su-3.1-x86 that worked for you during the test needs superuser apk,
but non of the apks i tested here work with that binary (All hung), kinda weird, until we have a working su+apk, other apps cannot gain root.
So i was thinking maybe we should try other superuser app, like the opensource ClockworkMod Superuser since it support x86 too.
Please download the attached su to test, let's see whether this one still causing segfault or not.
Code:
adb push su /data/local/tmp/
adb shell chmod 777 /data/local/tmp/su
adb shell /data/local/tmp/su -v
As usual, we are expecting su to return some version info.
As i don't think it's a good idea to keep asking you to download & test a new 100M file for something unsure, i provide you an alternative:
By replacing with this modded initrd.img (~/Library/BlueStacks App Player/AppBundle/Contents/Android/initrd.img), if this work (hopefully), it will:
- Create the following public accessible folder if not exists: /data/root
- Create the following test files: /data/root/test
- Change ownership, group & permissions needed for su for all files found inside /data/root/ on every boot.
Click to expand...
Click to collapse
Once replaced initrd.img, reboot and if you see a new file /data/root/test and it's owned by root then you can proceed to the below tests, otherwise useless.
Code:
1) Install ClockworkMod [URL="https://play.google.com/store/apps/details?id=com.koushikdutta.superuser"]Superuser[/URL] or download [URL="http://download.clockworkmod.com/apks/Superuser.apk"]here[/URL].
2) adb push su /data/root/su
3) Restart Bluestacks to get the permissions needed by su.
4) Open terminal & type the following command: /data/root/su # Should get a prompt
* Note that you will be asked to update su binary but you won't be able to do so at the moment. leave that first.
If non of the above work i guess the only option is to test all su binaries and apks, which is very time-consuming.
But i guess i am to giving up instead as it's too hard for me to debug without actually owning a Mac to test it.

codelover said:
Have you tried executing 'su' from adb instead of Terminal?
Click to expand...
Click to collapse
tried running it from an adb shell, still permission denied
I am not sure how the included su.orig from alpha should behave as i got segfault here on Windows.
Unlike the newer SuperSU that works without apk, the su-3.1-x86 that worked for you during the test needs superuser apk,
but non of the apks i tested here work with that binary (All hung), kinda weird, until we have a working su+apk, other apps cannot gain root.
So i was thinking maybe we should try other superuser app, like the opensource ClockworkMod Superuser since it support x86 too.
Please download the attached su to test, let's see whether this one still causing segfault or not.
Code:
adb push su /data/local/tmp/
adb shell chmod 777 /data/local/tmp/su
adb shell /data/local/tmp/su -v
As usual, we are expecting su to return some version info.
Click to expand...
Click to collapse
tried this: segmentation fault
As i don't think it's a good idea to keep asking you to download & test a new 100M file for something unsure, i provide you an alternative:
By replacing with this modded initrd.img (~/Library/BlueStacks App Player/AppBundle/Contents/Android/initrd.img), if this work (hopefully), it will:
Once replaced initrd.img, reboot and if you see a new file /data/root/test and it's owned by root then you can proceed to the below tests, otherwise useless.
Code:
1) Install ClockworkMod [URL="https://play.google.com/store/apps/details?id=com.koushikdutta.superuser"]Superuser[/URL] or download [URL="http://download.clockworkmod.com/apks/Superuser.apk"]here[/URL].
2) adb push su /data/root/su
3) Restart Bluestacks to get the permissions needed by su.
4) Open terminal & type the following command: /data/root/su # Should get a prompt
* Note that you will be asked to update su binary but you won't be able to do so at the moment. leave that first.
If non of the above work i guess the only option is to test all su binaries and apks, which is very time-consuming.
But i guess i am to giving up instead as it's too hard for me to debug without actually owning a Mac to test it.
Click to expand...
Click to collapse
did all that. /data/root exists and seems writable (though trying to do an ls in /data still gives me permission denied)
but /data/root/su still gave me segmentation fault...
which version was that? Which versions did we get to give us a version number the other day?

efdisastet said:
tried running it from an adb shell, still permission denied
/data/root exists and seems writable (though trying to do an ls in /data still gives me permission denied) but /data/root/su still gave me segmentation fault...
which version was that? Which versions did we get to give us a version number the other day?
Click to expand...
Click to collapse
It was su-3.1-x86 that i got it from here but the site is down at the moment. You can still find the binary on my previous post, inside su-test.zip.
With that version i managed to get root with adb, but without a working apk you cannot gain root from other apps since it was designed to act like that.
But what makes me wonder is that the su.orig that worked without apk (anyone confirm?) on alpha supposed to work on this beta too.
Now that /data/root/ is working as expected, it's so much easier for you to test the binaries, just push to /data/root/ and reboot to get the required permissions.

codelover said:
It was su-3.1-x86 that i got it from here but the site is down at the moment. You can still find the binary on my previous post, inside su-test.zip.
With that version i managed to get root with adb, but without a working apk you cannot gain root from other apps since it was designed to act like that.
But what makes me wonder is that the su.orig that worked without apk (anyone confirm?) on alpha supposed to work on this beta too.
Now that /data/root/ is working as expected, it's so much easier for you to test the binaries, just push to /data/root/ and reboot to get the required permissions.
Click to expand...
Click to collapse
/data/root/ may be working as expected, but there still seems to be a "su" in the path somewhere, whose permissions are denied. Will that cause problems
I put the 3.1 file from the su-test folder into /data/root, restarted bluestacks, and then went to terminal, I've attached a screenshot of those results, including calling just "su" to note the difference
Maybe if I had a better handle on what we wanted all the permissions to be and where we wanted this executable su to be, and what su an app/apk like superuser tries to use, I could help more.

[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.

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.