Related
I saw in the SDK this permission for apps to request:
public static final String FACTORY_TEST
Run as a manufacturer test application, running as the root user. Only available when the device is running in manufacturer test mode.
Constant Value: "android.permission.FACTORY_TEST"
Click to expand...
Click to collapse
Our current model with superuser whitelist is not very secure because a malicious person could bundle their own su binary and circumvent the restrictions. It would seem that having our custom roms run in test mode would provide a great solution: using Android's own permission/security model for apps to run as root. This should force all apps to visibly request root permissions at install time.
I am in favor of anything that will improve the security of my phone. It concerns me that anyone who knows what they are doing can so easily boot into recovery mode on my phone, wipe and flash any ROM they want. Granted, they would not have access to my information if the wipe and flash. But, it makes it trivially simple to hijack my phone. I would like to have some password protection for Recovery and Fastboot.
i am by no means a dev, but it seems to me that this probably just has to do with the adp devices
what's a adp device? and explain how they could possibly do this again?
android developer phone.
jaaronmoody said:
i am by no means a dev, but it seems to me that this probably just has to do with the adp devices
Click to expand...
Click to collapse
well, technically, if we have root, dont have an "ADP" device?
when I do a fresh install, it says welcome to Android Developer Phone 1 (in most ROMs)
the adp device was a specific phone release for developers to be used with the sdk.
jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
I know that, but the hardware is the same as ours (they just get the awesome battery cover)
jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
Most roms especially cyanogen Roms are based on SDK/ADP1 directly and thus making our devices recognizable as ADP Devices.
Simple solution could be to restore the original su binary at boot.
1) keep a copy in the boot image ramdisk
2) scan the path at boot for su
3) compare md5sum with the original
4) delete if md5sum is different
5) restore original trusted su
and also just for paranoia:
6) scan system for setuid binaries and report to the user
This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
lbcoder said:
This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
Thanks for clearing that up.
The idea posted earlier about recovery menu password should be lofted at Cyanogen (or anyone willing to take that on). Should we make a thread for it?
Keep in mind that it is physically impossible to secure your phone against somebody who gets their hands on the actual device. You can only make it harder to get at it. If somebody wanted to they could just read the flash chip directly or use JTAG to get at it. However, I agree that adb could be made a bit more secure.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how
nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
I have one thing to say to you:
http://en.wikipedia.org/wiki/Setuid
Now that you've made a complete and utter fool of yourself, how do you feel?
FYI: your regular user can NOT chown root. Go ahead and try it.
alapapa said:
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how
Click to expand...
Click to collapse
It is a moot point whether the setuid bit can be restored since a regular user doesn't have the ability to change the owner to anything but self, which means that the best they could do is create an su binary that will give other users THEIR OWN permissions.
A regular user can change ownership *only* to self -- i.e. if they have group or other write permission, then they can chown the file. They can also change the group, but only to groups to which they are members -- and this requires that they already have some form of write permission on the file.
Note that extracting a file is no different than actually *creating* the file, which means that if the user couldn't simply MAKE the file, then they can't *extract* the file either.
If any of this was untrue, there would be nothing to stop any user from doing something like this to take over any Linux computer (except from within a chroot jail, but that doesn't apply here);
cp `which sh` ~/su; chown root:root ~/su; chmod 4755 ~/su
** but that most definitely won't work.
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.
Has a write-up ever been released on exactly how SuperSu works? After searching around for a while I found mostly guides on who to use the app, no the implementation details.
I did, however, find this official resource that is mostly directed at explaining how to use the root privileges programmatically, but explained things fairly well. The article gives information about SELinux, but not so much how its enforcement is circumvented.
There appears to be a lot of context switching to allow execution of certain events (from the point of view of those using SuperSu) otherwise denied under SELinux, but how did SuperSu get to the point at which it was able to "legally", as far as SELinux is concerned, patch SELpolicies?
It seems that the objective is to force the init process to spawn a new shell that runs the su daemon, but there does not appear to be any patching of the init process, but from the article linked:
On firmwares that use SELinux, su is generally implemented as a proxy to a daemon started from init
Click to expand...
Click to collapse
and
You might wonder why - if we're already running as the init context, as the root user ..
Click to expand...
Click to collapse
-------------------------------------------
tl;dr; How does SuperSu execute in the context of the init process?
Given as:
u:r:init:s0 - Highest init context
u:r:init_shell:s0 - Shell started from init
Click to expand...
Click to collapse
modify init.rc
update-binary in supersu.zip may help
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.
I have looked into rooting, and I don't understand how it works, but from what I can tell, shouldn't people be able to root using adb to change a file that is run regularly in /system, so that whenever it runs it would grant a given app root perms, and that app would then be able to give others root perms? would you have to change the file another way because adb doesn't run commands as root? wouldn't this be alot more simple than what has been being done?
Rooting a phone''s Android technically is simply adding standard Linux function SU ( read: Switch User ) to Android's ecosystem.
Once SU got added and you run the file without any other parameters it switches your credentials and permissions from a normal user to that of the superuser ( comparable to Administrator on Windows OS ). You are then in complete control and can add anything, remove anything and access functions on your phone that you couldn't reach before.
BTW:
With Android versions 6 and higher all what is needed is to replace the pre-installed ( restricted ) Toybox binary with an unrestricted Toybox binary ( e.g. 0.8.5 ) that contains the SU-cmdlet.
If I am understanding this, than you need to grant an app SU, but first you have to install the command that allowes giving of SU? or turn on that command (on android 6+), and grant a manager app permission to use it?