Related
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
Hi!
I'm not sure that this is the right place ti post my question
(if not please advice me).
I'm looking for a script able to start a process when I switch on my phone. On linux e.g if there is the process "my_proc"
that start automatically, you can also stop and restart
using
/etc/init.d/my_proc stop
and
/etc/init.d/my_proc start.
I'm looking for same script like this that is able to
manage automatically and also on request the process
my_process.
TIA
It varies somewhat from ROM to ROM, however the underlying mechanism is different from the approach you describe, that being common to many linux distros on PC.
As far as launching a process on boot, it's probably easiest to look through /init.rc & follow it to find an init script stored in /system or /data which is launched at boot; then just tack on a line, to launch your process, to that file. More correctly you could launch it from /init.rc directly (*)
For example I'm running MCR 3.2 on my Hero. / contains init.rc which I can easily examine on the device with Root Explorer. This file contains towards the final third:
service init /system/bin/sh /data/init.sh
user root
group root
oneshot
You could in this case launch your process from /data/init.sh
(*) If you want to explore this thoroughly or implement a proper mechanism, I think you need to look into services in Android. Here's some useful info on the [URL="http://androidenea.blogspot.com/2009/08/init-process-and-initrc.html]format of init.rc in Android[/URL].
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.
I'm evaluating MDM system which says that relays on Android system mechanisms to detect root.
1. Does this mean SELinux policies or any API for that?
2. How exactly daemonsu binary work? If I understand corectly it start with system by some hook, and by another registers channel to communicate with su binary. Do I understand this process correctly? If yes what exactly are those hooks?
I renamed /system/xbin/su and busybox to my own names. But there is
/system/xbin/daemonsu
Click to expand...
Click to collapse
which won't work if I rename it. I have read that it's due to pass SELinux filters. But I want to rename it, is there source of it avalible anywhere or option to rename some symbols? As far as I understand linux we can remove privileges from daemonsu, but stat call on it will beahave different privileged aplications
Please don't forward me to Xposed or backed apk's for this purpuses, I want to understand mechanisms behind this.
In this post, I'm not telling any tricks or methods. I am just providing my thoughts and possibilities. Recently I was trying to root my phone and I did a little bit of research on it. By the way, note one thing here that my phone is part of the Android One project and made by Xiaomi, so it's much harder to root than any other phone. If you have also tried to root your phone, then you might have also heard these words... (Magisk manager, Superuser, Busybox, SU Binary, TWRP Custom recovery, root file, System file, Custom Rom), etc. In this thread, if I am right you can root your phone just by using ADB Shell. Rooting your phone means...
Rooting (Android)
From Wikipedia, the free encyclopedia
Rooting is the process of allowing users of smartphones, tablets, and other devices running the Android mobile operating system to attain privileged control (known as root access) over various Android subsystems. As Android uses the Linux kernel, rooting an Android device gives similar access to administrative (superuser) permissions as on Linux or any other Unix-like operating system such as FreeBSD or macOS.
Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices. Thus, rooting gives the ability (or permission) to alter or replace system applications and settings, run specialized applications ("apps") that require administrator-level permissions, or perform other operations that are otherwise inaccessible to a normal Android user. On Android, rooting can also facilitate the complete removal and replacement of the device's operating system, usually with a more recent release of its current operating system.
Root access is sometimes compared to jailbreaking devices running the Apple iOS operating system. However, these are different concepts: Jailbreaking is the bypass of several types of Apple prohibitions for the end-user, including modifying the operating system (enforced by a "locked bootloader"), installing non-officially approved (not available on the App Store) applications via sideloading, and granting the user elevated administration-level privileges (rooting). Many vendors such as HTC, Sony, LG, Asus, and Google explicitly provide the ability to unlock devices and even replace the operating system entirely. Similarly, the ability to sideload applications is typically permissible on Android devices without root permissions. Thus, it is primarily the third aspect of iOS jailbreaking (giving users administrative privileges) that most directly correlates to Android rooting.
Rooting is distinct from SIM unlocking and bootloader unlocking. The former allows removing the SIM lock on a phone, while the latter allows rewriting the phone's boot partition (for example, to install or replace the operating system).
Source: Wikipedia
So, as much as I've noticed (I could be wrong) mainly all rooting processes does one of those two things,
1. Edits your boot.img
or
2. Adds a SU binary file to your system & more specifically to your system/bin file.
So if that's true and every Android phone or at least the same brands or same models or at least same Android versions or maybe all of them requires the exact same SU binary file(Superuser binary file). Now, if you don't want to change your boot.img there is only one is remaining and that is adding the SU binary file. Now you might ask how to do that...
Just use your ADB shell to give writing system files permission to your file manager. And then put the SU file to your system.
So, that's all I was just trying to say. Now if I am right please let me know and thanks for reading until now. And also if I am right, please someone provide me the SU binary file of Xiaomi MI A3, code name: laurel_sprout . Thank you once again, All developers, take care of your health. For further inquiries and helping me out, message me on XDA personally.
Writer: Samiullah Ridoy.
Samiullah Ridoy said:
...
Just use your ADB shell to give writing system files permission to your file manager. And then put the SU file to your system.
...
Click to expand...
Click to collapse
Absolutely errleading ( i.e. wrong ) statement:
1. To mount Android's partition /system as RW - so you can copy SU-binary onto it - you need superuser ( SU ) rights.
2. Modern Android versions have SELinux enabled, and most also DM-verity and/or AVB. These safety-features lock the /system partition to get tampered, what at least with regards to SELinux and/or DM-verity only can be disabled by superuser ( SU ).
3. With regards to AVB one has to unlock device's bootloader, too, in order to disable this lock.
@Samiullah Ridoy
As above post said,
-You can't simply give writing system files permission.
-Only emulators have that ability(since they are not production builds)
Here is your device specific guide at Mi A3 forum https://forum.xda-developers.com/t/...-root-mi-a3-with-magisk-without-twrp.3958509/
Rooting your device is same as any other device if we use Magisk rooting method. It does not take additional steps to root your specific device.
Thanks
You need to disable DM-verity.
You can do it from ADB. You need to modify Stock boot image file. Patch it and disable DM-Verity.
HemanthJabalpuri said:
@Samiullah Ridoy
As above post said,
-You can't simply give writing system files permission.
-Only emulators have that ability(since they are not production builds)
Here is your device specific guide at Mi A3 forum https://forum.xda-developers.com/t/...-root-mi-a3-with-magisk-without-twrp.3958509/
Rooting your device is same as any other device if we use Magisk rooting method. It does not take additional steps to root your specific device.
Thanks
Click to expand...
Click to collapse
I have already seen that post & I don't want to do it that way. You said, " You can't simply give writing system files permission. ", I've already mentioned but saying it once again that I could be wrong but we can give writing system files permission by using these code...
Code:
adb shell pm grant [package name] android.permission.WRITE_SETTINGS
adb shell pm grant [package name] android.permission.ACCESS_MEDIA_LOCATION
adb shell pm grant [package name] android.permission.WRITE_INTERNAL_STORAGE
Tell me if I am wrong & thanks for your compliment.
Samiullah Ridoy said:
I have already seen that post & I don't want to do it that way. You said, " You can't simply give writing system files permission. ", I've already mentioned but saying it once again that I could be wrong but we can give writing system files permission by using these code...
Code:
adb shell pm grant [package name] android.permission.WRITE_SETTINGS
adb shell pm grant [package name] android.permission.ACCESS_MEDIA_LOCATION
adb shell pm grant [package name] android.permission.WRITE_INTERNAL_STORAGE
Tell me if I am wrong & thanks for your compliment.
Click to expand...
Click to collapse
I didn't tried those but I am sure those are NOT for writing read-only partitions.
Those are for accessing internal storage and changing settings like brightness I think.
jwoegerbauer said:
Absolutely errleading ( i.e. wrong ) statement:
1. To mount Android's partition /system as RW - so you can copy SU-binary onto it - you need superuser ( SU ) rights.
2. Modern Android versions have SELinux enabled, and most also DM-verity and/or AVB. These safety-features lock the /system partition to get tampered, what at least with regards to SELinux and/or DM-verity only can be disabled by superuser ( SU ).
3. With regards to AVB one has to unlock device's bootloader, too, in order to disable this lock.
Click to expand...
Click to collapse
Absolutely correct.
It seems to me OP has never tried this, simply has copied from other sources. That is why the nonsense.