Related
Update: One click root has been using this "simple" method since version 2.2.7. If you're rooting your phone for the first time, please try that first. Consider this thread to be purely informational for those who want step-by-step details of how the process works.
I've been suspicious of the joeykrim root method since it was first posted at SDX. I finally got my Epic yesterday and confirmed that is, indeed unnecessary. I don't fault joeykrim though, he ported the working root method from the Moment to the Epic without actually having access to an Epic himself.
Anyways, the joeykrim root method is unnecessarilly complex becuase it works around an RFS permissions bug which loses the setuid bit on the Moment. It appears the Galaxy S phones have this bug fixed, which is why the root methods on the I9000, Vibrant, Captivate, Fascinate, etc., are much simpler.
So, for the simple root:
First, make sure joeykrim root is not installed.
Upgrade to DI18 (not strictly necessary, but you'll want to do it).
Setup a working adb from the Android SDK and whatever drivers are necessary for your platform.
Download rageagainstthecage-arm5.bin from the C skills blog (link removed due to my newbieness) or from any of the one-click root packages.
Download su-2.3.6.1-ef-signed.zip and extract "system/bin/su" and "system/app/Superuser.apk" to a temporary directory you'll be working from.
Enable USB debugging on your phone and connect it to your computer.
Now, open a command prompt/shell on your computer and cd to the appropriate temporary directory. Run:
Code:
adb push rageagainstthecage-arm5.bin /data/local/tmp
adb shell chmod 755 /data/local/tmp/rageagainstthecage-arm5.bin
adb shell /data/local/tmp/rageagainstthecage-arm5.bin
and confirm you have a working root shell. Then continue with:
Code:
adb push su /system/xbin
adb shell chmod 4755 /system/xbin/su
adb install Superuser.apk
That's it! You should have a working root via su & the Superuser package. At least, I did.
Note that the preceeding steps installs Superuser.apk to /data, which is what I prefer to do. This means if you do a "Factory data reset" su will be temporarilly broken until you reinstall the Superuser.apk package. Since installing the package itself doesn't require root, this is easily done after a /data reset.
Also note that I did not perform a /system remount-rw anywhere. At least on my Epic, /system appears to always be mounted read-write so it's an unnecessary step. It's actually the "joeykrim-root.sh" script that remounts /system read-only during the boot process, which is why folks who don't use root kernels have run into this problem before. I'm not sure why joeykrim's script does that, I guess he probably assumed /system is mounted read-only by default. There's arguments that /system should be read-only, but I didn't touch it in case some Samsung stuff depends on it being read-write.
Finally, if you're already rooted via joeykrim or are running a root kernel, there's nothing really to be gained by doing this. I'm just throwing this out there as I perfer to make the minimum invasive changes possible to obtain root.
Wow, that was really informative. To check for Super user you:
Type: adb shell
then type: SU
You should get a # sign if you have root. Correct?
In the original Noobln post method would the Epic keep root even after a wipe therefore not needing to re-apply the superuser apk again? That might be a reason why folks would want to go the more invasive route (considering rooters seems to change ROMS fairly often which requires wipes sometimes). Either way, keeping a copy of the apk file on your SD card is no big deal.
mkasick said:
Also note that I did not perform a /system remount-rw anywhere. At least on my Epic, /system appears to always be mounted read-write so it's an unnecessary step. It's actually the "joeykrim-root.sh" script that remounts /system read-only during the boot process, which is why folks who don't use root kernels have run into this problem before. I'm not sure why joeykrim's script does that, I guess he probably assumed /system is mounted read-only by default. There's arguments that /system should be read-only, but I didn't touch it in case some Samsung stuff depends on it being read-write.
Click to expand...
Click to collapse
This explains a lot of problems! thanks
EDIT- another noob question- why do you prefer to have superuser installed to /system/data- why not put it in /system/app? Also if I want to install busybox where is the best location to put it?
ZenInsight said:
Wow, that was really informative. To check for Super user you:
Type: adb shell
then type: SU
You should get a # sign if you have root. Correct?
Click to expand...
Click to collapse
Once you run rageagainstthecage-arm5.bin, you should get a root-shell automatically every time you run "adb shell" after until you reboot the phone. Yes, you can tell it's a root shell since it uses the "#" prompt. This is the important part to check, since if the exploit doesn't work, you'll have to run it again. But I haven't seen it not work.
After su is installed and you reboot, your steps are correct: run "adb shell", run "su", then you'll be prompted on the phone scren to authorize access and once you allow it you'll end up with a "#" prompt.
ZenInsight said:
In the original Noobln post method would the Epic keep root even after a wipe therefore not needing to re-apply the superuser apk again?
Click to expand...
Click to collapse
noobnl installs Superuser.apk to /system, you can do that here too. Just replace the "adb install Superuser.apk" step with "adb push Superuser.apk /system/app". It's independent of the joeykrim scripts.
With my captivate we have many update.zip root methods to choose from. Any chance this will be coming to the epic? Have a friend with an epic and command lines would be too much and one click didn't work.
Sent from my SAMSUNG-SGH-I897 using XDA App
jimmyz said:
why do you prefer to have superuser installed to /system/data- why not put it in /system/app?
Click to expand...
Click to collapse
I prefer to keep consistent with the idea that user-installed applications go in /data, and stock-installed-and-unmodified applications remain in /system/app. This way, upgrading Superuser.apk doesn't require a root-shell/root-explorer, you can remove it or upgrade it the way you do with any user installed application--adb install, side-loading via an sdcard, or downloading it from the market.
Plus, in general I prefer to keep my /system as untouched as possible. For example, I don't remove stock apps either. The "su" binary has to be installed in /system to persist after a /data wipe, and busybox is best installed to /system so it's in PATH (haven't looked into modifying the default PATH yet). Otherwise I try to keep /system alone.
jimmyz said:
Also if I want to install busybox where is the best location to put it?
Click to expand...
Click to collapse
Android's default PATH provides four places for busybox to be installed: /sbin, /system/bin, /system/sbin, and /system/xbin. /sbin is part of the initramfs, in other words it's controlled by the kernel you're running. You can install busybox to any of the three /system/*bin directories, but I prefer /system/xbin.
In the traditional Unix conventions, "/usr/bin" is for user-runnable stock-installed programs, and "/usr/sbin" is for root-requiring (superuser-runnable) stock-installed programs. "xbin" isn't part of the standard convention, but I'd guess it's intended for "extra binaries" that are not part of the stock installation (much like /usr/local/bin), thus it seems like an appropriate location for a user-added "su" and "busybox" programs.
The second reason is that "xbin" is relatively empty, so if you want to create the applet symlinks (i.e., so that you can call "cp" instead of "buybox cp") it won't overwrite the stock toolbox symlinks. Also, since "xbin" is last on the default PATH, any programs provided by both toolbox and busybox will default to the toolbox version--which would be important for stock system scripts that might run into compatibility issues if they were to use the busybox versions instead.
To install busybox, grab a copy of the binary from somewhere (one click packages, a copy of stericson.busybox.apk, etc.). Then, once rooted run:
Code:
adb push busybox /data/local/tmp
adb shell
su # Authorize on phone screen
cat /data/local/tmp/busybox > /system/xbin/busybox
chown root.shell /system/xbin/busybox
chmod 755 /system/xbin/busybox
rm /data/local/tmp/busybox
/system/xbin/busybox --install -s /system/xbin
jhnstn00 said:
With my captivate we have many update.zip root methods to choose from. Any chance this will be coming to the epic?
Click to expand...
Click to collapse
I don't believe so. The I9000/Vibrant/Captivate have recoveries that don't check the signature of update.zip (as I understand, or maybe they do but only require test keys) which makes rooting-via-recovery possible. Unfortuntaely the Epic and Fascinate do perform signature checks, so we can't enable root via stock-recovery.
That said, the Fascinate one-click methods should also work on the Epic. Although depending on why your friend couldn't get the Epic one-click to work, the Fascinate one may not work either.
mkasick said:
I prefer to keep consistent with the idea that user-installed applications go in /data, and stock-installed-and-unmodified applications remain in /system/app. This way, upgrading Superuser.apk doesn't require a root-shell/root-explorer, you can remove it or upgrade it the way you do with any user installed application--adb install, side-loading via an sdcard, or downloading it from the market.
Plus, in general I prefer to keep my /system as untouched as possible. For example, I don't remove stock apps either. The "su" binary has to be installed in /system to persist after a /data wipe, and busybox is best installed to /system so it's in PATH (haven't looked into modifying the default PATH yet). Otherwise I try to keep /system alone.
Android's default PATH provides four places for busybox to be installed: /sbin, /system/bin, /system/sbin, and /system/xbin. /sbin is part of the initramfs, in other words it's controlled by the kernel you're running. You can install busybox to any of the three /system/*bin directories, but I prefer /system/xbin.
In the traditional Unix conventions, "/usr/bin" is for user-runnable stock-installed programs, and "/usr/sbin" is for root-requiring (superuser-runnable) stock-installed programs. "xbin" isn't part of the standard convention, but I'd guess it's intended for "extra binaries" that are not part of the stock installation (much like /usr/local/bin), thus it seems like an appropriate location for a user-added "su" and "busybox" programs.
The second reason is that "xbin" is relatively empty, so if you want to create the applet symlinks (i.e., so that you can call "cp" instead of "buybox cp") it won't overwrite the stock toolbox symlinks. Also, since "xbin" is last on the default PATH, any programs provided by both toolbox and busybox will default to the toolbox version--which would be important for stock system scripts that might run into compatibility issues if they were to use the busybox versions instead.
To install busybox, grab a copy of the binary from somewhere (one click packages, a copy of stericson.busybox.apk, etc.). Then, once rooted run:
Code:
adb push busybox /data/local/tmp
adb shell
su # Authorize on phone screen
cat /data/local/tmp/busybox > /system/xbin/busybox
chown root.shell /system/xbin/busybox
chmod 755 /system/xbin/busybox
rm /data/local/tmp/busybox
/system/xbin/busybox --install -s /system/xbin
Click to expand...
Click to collapse
You sir are a true gentleman! Thank you for the informative answers- its great to have you over here! I have one more question- why can't I usually push directly to /system ?
jimmyz said:
why can't I usually push directly to /system ?
Click to expand...
Click to collapse
Pushing directly to /system requires running the adb service on the phone as the root user, so that it has permissions to write to that directory. Usually adb runs on the phone unprivileged, so you can only push to world-writable directories.
Running rageagainstthecage-arm5.bin actually changes this. The exploit forces the adb service to run as the root user, which is why "adb shell" gives you a root shell and "adb push" to /system does work, until the phone is restarted.
Interesting enough, the adb service also runs as root by default in the Android emulator. So there's probably a configuration setting, somewhere, to make it do that. In general it's safer to run adb unprivileged though, and "su" to move files to /system once uploaded elsewhere on the phoe.
mkasick said:
Pushing directly to /system requires running the adb service on the phone as the root user, so that it has permissions to write to that directory. Usually adb runs on the phone unprivileged, so you can only push to world-writable directories.
Running rageagainstthecage-arm5.bin actually changes this. The exploit forces the adb service to run as the root user, which is why "adb shell" gives you a root shell and "adb push" to /system does work, until the phone is restarted.
Interesting enough, the adb service also runs as root by default in the Android emulator. So there's probably a configuration setting, somewhere, to make it do that. In general it's safer to run adb unprivileged though, and "su" to move files to /system once uploaded elsewhere on the phoe.
Click to expand...
Click to collapse
I am learning a lot!!! Could you take a look at koush's kernel here, with it I noticed that when using adb I got the # prompt right away and was able to push to /system- maybe he was able to figure out the config settings? Once again thanks!!!
one more ? (feel free to ignore this one) what actually happens when you do
Code:
adb shell /data/local/tmp/rageagainstthecage-arm5.bin
and how does that give you permanent root?
mkasick said:
Pushing directly to /system requires running the adb service on the phone as the root user, so that it has permissions to write to that directory. Usually adb runs on the phone unprivileged, so you can only push to world-writable directories.
Running rageagainstthecage-arm5.bin actually changes this. The exploit forces the adb service to run as the root user, which is why "adb shell" gives you a root shell and "adb push" to /system does work, until the phone is restarted.
Interesting enough, the adb service also runs as root by default in the Android emulator. So there's probably a configuration setting, somewhere, to make it do that. In general it's safer to run adb unprivileged though, and "su" to move files to /system once uploaded elsewhere on the phoe.
Click to expand...
Click to collapse
It is indeed a config option in default.prop. However, this is in the initramfs and you can't change it on the fly, so you need to rebuild the kernel to change it. With some work you can modify the stock kernel to do it, but I personally haven't tried it.
Sent from my Epic 4G using XDA App
Thank you, this worked perfectly for me, running stock DI18 ROM that I flashed tonight!!! I confirmed by installing the wireless tethering pre-9 apk, and successfully ran the wireless tethering without any errors.
Quick question: do we need to do this after root or is it not needed?
NEEDED?? ===> SuperUser App to help with Security Concerns for the Epic - h**p://forum.sdx-developers.com/epic-development/superuser-app-to-help-with-security-concerns/
Also, Titanium Backup failed to work - it gave an error of denied root access, and said busybox was not installed. What needs to be done to make it work? Do I need to install clockwork mod (not exactly sure what it does though) or a custom ROM?
AndroidSPCS said:
Quick question: do we need to do this after root or is it not needed?
Click to expand...
Click to collapse
Not sure exactly what you're asking. This is an alternative to the joeykrim-based one-click roots and rooted kernels. If you already have one of those this isn't really necessary.
AndroidSPCS said:
NEEDED?? ===> SuperUser App
Click to expand...
Click to collapse
Yes, the su binary used here requires the Supruser appto be installed to authorize su requests. Otherwise they'll always be denied. Other su binaries might not require it, but then all apps have root access which isn't really a good thing.
AndroidSPCS said:
Also, Titanium Backup failed to work - it gave an error of denied root access, and said busybox was not installed. What needs to be done to make it work?
Click to expand...
Click to collapse
Did you authorize Titanium Backup when the Superuser prompt came up (requies the Superuser app to be instald too)?
Titanium Backup has an option to download and install it's preferred version of busybox. Follow the prompts to do that.
mkasick said:
Not sure exactly what you're asking. This is an alternative to the joeykrim-based one-click roots and rooted kernels. If you already have one of those this isn't really necessary.
Click to expand...
Click to collapse
Thanks, actually this was referring to the thread where the instructions for going to adb shell or terminal and typing in the following commands:
adb shell
su
mount -t rfs -o remount,rw /dev/block/stl9 /system
cp /system/bin/su /system/bin/jk-su
exit
Yes, the su binary used here requires the Supruser appto be installed to authorize su requests. Otherwise they'll always be denied. Other su binaries might not require it, but then all apps have root access which isn't really a good thing.
Click to expand...
Click to collapse
Yes same as above, the question is not whether we need SU app (I know we do), but whether we needed to type the additional commands:
adb shell
su
mount -t rfs -o remount,rw /dev/block/stl9 /system
cp /system/bin/su /system/bin/jk-su
exit
What do these commands do? It seems to me my Superuser app is working fine with wifi tether - popping up with allow / disable permission boxes, etc. Do these commands add something else to Superuser?
Did you authorize Titanium Backup when the Superuser prompt came up (requies the Superuser app to be instald too)?
Titanium Backup has an option to download and install it's preferred version of busybox. Follow the prompts to do that.
Click to expand...
Click to collapse
There was no Superuser prompt during the install of the app, nor anytime when it said it had a failure with root access. However there is an option to install BusyBox, which I have not done yet, because I am not sure what busybox is, or what it does. I'd like to find out why I need it and what it does, so I can feel comfortable with installing it.
Thanks again.
echo "root::0:0:root:/data/local:/system/bin/sh" > /etc/passwd
echo "root::0:" > /etc/group
you need to do that in a shell to make sure su works properly.
I'm updating the one click root right now to be less silly.
http://forum.xda-developers.com/showpost.php?p=8543226&postcount=455
I just cleaned up the one click root to not do many of the silly things joeykrim's root does. It also means your system will be mounted as rw after a reboot and it won't overwrite your su with jk-su every boot (no more modified playlogo).
Cleaned up all the old stuff from the root so it should work fine even if you were using one of the older one clicks. I made sure su works, incl titanium backup.
I'm still installing superuser.apk to /system/app because I think it belongs there.
Thanks for doing the footwork, mkasick!
Firon said:
http://forum.xda-developers.com/showpost.php?p=8543226&postcount=455
I just cleaned up the one click root to not do many of the silly things joeykrim's root does. It also means your system will be mounted as rw after a reboot and it won't overwrite your su with jk-su every boot (no more modified playlogo).
Cleaned up all the old stuff from the root so it should work fine even if you were using one of the older one clicks. I made sure su works, incl titanium backup.
I'm still installing superuser.apk to /system/app because I think it belongs there.
Thanks for doing the footwork, mkasick!
Click to expand...
Click to collapse
Firon- why are these lines still needed?
Code:
adb push playlogo /system/bin/playlogo
what is playlogo? Does this just put the stock one back in case you used the joeykrim method in the past?
Code:
adb push remount /system/xbin/remount
Are the remount scripts still needed?
Code:
adb shell ln -s /system/xbin/su /system/bin/su
why is this link needed? why cant su just be in xbin
thanks in advance!
Code:
jimmyz said:
Firon- why are these lines still needed?
Code:
adb push playlogo /system/bin/playlogo
what is playlogo? Does this just put the stock one back in case you used the joeykrim method in the past?
Click to expand...
Click to collapse
This is just pushing the stock playlogo, since joeykrim's method overwrites it with some custom script.
Code:
adb push remount /system/xbin/remount
Are the remount scripts still needed?
Click to expand...
Click to collapse
The script allows you to easily remount system as ro or rw at will. Why not?
Code:
adb shell ln -s /system/xbin/su /system/bin/su
why is this link needed? why cant su just be in xbin
Click to expand...
Click to collapse
I don't know if any apps depend on it being in a particular location. It is in xbin, but I'm also linking it to /system/bin to be safe.
AndroidSPCS said:
What do these commands do? It seems to me my Superuser app is working fine with wifi tether - popping up with allow / disable permission boxes, etc. Do these commands add something else to Superuser?
Click to expand...
Click to collapse
These commands were necessary to get Superuser working with the old joeykrim root method. They're not necessary with this method (or the newly released one-click). In other words, if wifi-tethering is already working for you, nothing further is needed to be done.
AndroidSPCS said:
There was no Superuser prompt during the install of the app, nor anytime when it said it had a failure with root access.
Click to expand...
Click to collapse
I don't actually use TitaniumBackup. I'm not sure why its superuser-requirements would be different from other apps, but I guess it is. The new one-click appears to address this.
AndroidSPCS said:
However there is an option to install BusyBox, which I have not done yet, because I am not sure what busybox is, or what it does. I'd like to find out why I need it and what it does, so I can feel comfortable with installing it.
Click to expand...
Click to collapse
Busybox is a suite of "familar" Unix command-line utilites (things like cp (copy), mv (move), ls (list), etc.). It targets embedded platforms by being very featureful, yet relatively small. It's installed and used on a wide variety of embedded devices including wireless routers, print servers, phones, even televisions.
Oddly enough, Android does not include busybox by default. Instead it comes with it's own utility-programs-package called "toolbox" that isn't nearly as featureful, and quickly becomes a pain to use. Some programs, like TitaniumBackup depend on busybox programs/features, and thus require it's installation. It's safe.
The only problem with busybox is that there's not one single version of it. There's multiple builds of it from the same source code with different sets of features turned on and off. In the past, some folks had a version of busybox installed that didn't contain all the features necessary to support TitaniumBackup, so they added the option to install their own version. It's installed in a separate location, so it won't overwrite any version you do have installed, and it's safe to do. But if you've already installed another version of busybox that does work, then it may be unnecessary.
I did the Jokeyrim method a few days ago. I installed a new kernal and now a new ROM. All seems ok, but ow when I do the "whoami" command in adb shell I get whoami not found. I don't think I'm really rooted anymore. Any attempt to reinstall the Jokeyrim root script results in failure (mostly "device not found" errors). When in adb shell, most commands I type now are either "not found" or "permission denied", so I'm not confident that I'm really rooted now.
Since I have / had Jokeyrim installed, how can I "uninstall" it so that I can use this method of rooting instead? BTW, the newest Clockworkmod is installed and working.
Do I need to flash to stock first? Sorry, but I'm a VERY STOOPID NOOB.
Here's (almost) the process I used
change settings on device
"Unknown Sources"
"USB Debugging"
Find which device is mounted as "/system"
On my stock ICS .26 system this is "/dev/block/mmcblk0p1", but this might be something different (?)
adb shell mount | grep " /system"
copy files to device
copy debugfs to device
adb push debugfs /data/local/
copy su to device
adb push su /data/local/
copy debugfsinput to device
adb push debugfsinput /data/local/
setup temp directory
rename /data/local/tmp to /data/local/tmp.bak
make a new /data/local/tmp that is a symlink to /system device (as determined in step B)
ln -s /dev/block/mmcblk0p1 /data/local/tmp
reboot tablet
mark debugfs program executable
adb shell chmod 777 /data/local/debugfs
run debugfs using "/data/local/debugfsinput" script
adb shell "/data/local/debugfs -w /dev/block/mmcblk0p1 < /data/local/debugfsinput"
cleanup
remove /data/local/tmp symlink
move /data/local/tmp.bak to /data/local/tmp
remove /data/local/su
remove /data/local/debugfs
remove /data/local/debugfsinput
reboot
test superuser (see if "su" command works [no output, especially no error message])
install superuser app
adb install Superuser.apk
One thing I did different in some places was to just do "adb shell", and then issue commands one-by-one in the remote shell.
Related threads:
How to root TF700 Jelly Bean from Linux without unlocking?
[description of process updated and moved to first post]
It occurs to me that steps D through J should be doable on the device using the Terminal Emulator app that I've got installed.
Thoughts, anyone? See any dangerous pitfalls ahead on the path I'm about to undertake?
I'm going to hold off on actually doing this until tomorrow. This will to give people a chance to respond, and I need to attend to other matters (dinner, chores, etc...)
bsammon said:
It occurs to me that steps D through J should be doable on the device using the Terminal Emulator app that I've got installed.
Click to expand...
Click to collapse
Another thought.... step C obviously doesn't need adb, and step K could be done with the "pm" command in the Terminal Emulator.
It seems I could do this without using adb at all--- not sure why I'd bother, unless I have problems getting it to work, or just to prove that I can.
I rooted my TF700 under Linux by reading the batch file and doing the steps manually - similar as you describe in your second post, but I even typed the input to debugfs manually. The whole process depends on getting at least "shell" user access, so I am not sure that it could be done without adb - a local terminal app would run under its own, more restricted user account.
_that said:
I rooted my TF700 under Linux by reading the batch file and doing the steps manually - similar as you describe in your second post, but I even typed the input to debugfs manually. The whole process depends on getting at least "shell" user access, so I am not sure that it could be done without adb - a local terminal app would run under its own, more restricted user account.
Click to expand...
Click to collapse
There is also a shell script version around for that famous rooting batch file. Technically obviously the same as reading the commands and typing them manually ... but still
FordPrefect said:
There is also a shell script version around for that famous rooting batch file. Technically obviously the same as reading the commands and typing them manually ... but still
Click to expand...
Click to collapse
But doing it manually is so much more l33t.
FordPrefect said:
There is also a shell script version around for that famous rooting batch file. Technically obviously the same as reading the commands and typing them manually ... but still
Click to expand...
Click to collapse
Got a link?
Just wondering if the new Dirty Cow exploit means all those previously unrootable phones can now (or very soon) be rooted.
http://www.cyberciti.biz/faq/dirtyc...local-privilege-escalation-vulnerability-fix/
kennonk said:
Just wondering if the new Dirty Cow exploit means all those previously unrootable phones can now (or very soon) be rooted.
http://www.cyberciti.biz/faq/dirtyc...local-privilege-escalation-vulnerability-fix/
Click to expand...
Click to collapse
Based upon the early research into this, YES it would appear that this also has widespread affect into the Android Linux Kernel
https://www.nowsecure.com/blog/2016/10/21/dirty-cow-vulnerability-mobile-impact/
https://www.theguardian.com/technol...ow-linux-vulnerability-found-after-nine-years
(Bottom of Article Google confirms Android is susceptible)
PoC Code which would probably need to be slightly refactored for use in Android, but still highly relevant
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
The bug affects the Android Linux kernel. I already tested it, and yes, you can change any file owned by root to whatever you want.
But that doesn't mean you can actually root the phone (that is, gain root access). Maybe it is possible, but I don't think is trivial. The thing is: you can modify root owned files, yes. But you need that some process owned by root executes your file, so you can gain root access. Editing init scripts won't work since they are recreated every time you boot your phone, and after the phone boots, as far as I know, nothing else is executed by root.
I don't mean that it can't be done, maybe there's some file that is executed by root after boot out there that you can modify, but I wouldn't know which one.
Scorpius666 said:
The thing is: you can modify root owned files, yes. But you need that some process owned by root executes your file, so you can gain root access.
Click to expand...
Click to collapse
Doesn't that mean you can install a custom su binary and just execute that as any user?
This exploit only allows you to replace the content of existing files with their existing mode/permissions, and the way su operates you need the setuid (set-user-ID) bit set in the mode, and from a brief look at the system I wanted to get root on, android doesn't seem to have any setuid binaries.
I'm thinking replacing something like wpa_supplicant could let us execute the payload as root, just disable and re-enable wifi, but I can't seem to get the exploit itself to work at the moment.
On further inspection (at least on this device), wpa_supplicant isn't readable by non-root (which I think the exploit requires). app_process is, but that's an executable I'd prefer not to mess with
Update:
Got the exploit itself working.
Tried replacing /system/bin/fsck_msdos's content to trigger it to be run as root by inserting a microSD card,
but something on this device (Amazon Fire 5th gen) keeps rebooting and restoring the system partition if any file is changed.
a___ said:
This exploit only allows you to replace the content of existing files
Click to expand...
Click to collapse
Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
https://gist.github.com/scumjr/17d91f20f73157c722ba2aea702985d2
I'd like to port that to an apk using the ndk, but my pc is too old.
The /system partition is mounted read only by default. Because of this, you can't overwrite them. But I saw a exploit which used /sys/kernel/uevent_helper to execute a shell script as root. This would probably also work with the dirty cow exploit.
KillahKiwi said:
Doesn't that mean you can install a custom su binary and just execute that as any user?
Click to expand...
Click to collapse
You can't create a new file. You can modify an existing file. The su binary needs the setuid bit and there are no files in the Android filesystem with that bit set.
The only way to root a phone with this bug is to modify an executable that will change the owner of the su binary to root and set the setuid bit on this file. This part is trivial and very easy.
The difficult part is to find a binary that will be executed as root after you have booted. If somebody knows any file in /system/bin for example that will be executed as root doing some action on the phone tell me and the phone will be rooted in seconds.
---------- Post added at 11:32 AM ---------- Previous post was at 11:28 AM ----------
a___ said:
Got the exploit itself working.
Tried replacing /system/bin/fsck_msdos's content to trigger it to be run as root by inserting a microSD card,
but something on this device (Amazon Fire 5th gen) keeps rebooting and restoring the system partition if any file is changed.
Click to expand...
Click to collapse
I copied the su binary in /data/local/tmp. I can modify files in /system/bin for example and the phone does not reboot, but i don't have fsck_msdos in my phone.
---------- Post added at 11:35 AM ---------- Previous post was at 11:32 AM ----------
DP FH said:
Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
https://gist.github.com/scumjr/17d91f20f73157c722ba2aea702985d2
I'd like to port that to an apk using the ndk, but my pc is too old.
Click to expand...
Click to collapse
I'm compiling on the phone using UXTerm, then apt install clang, and then using gcc. It's the quickest way to compile a single .c file on it.
Scorpius666 said:
. It's the quickest way to compile a single .c file on it.
Click to expand...
Click to collapse
I'd like to create a standard Android app that uses jni to run exploit and then roots the device. I can't test on my real phone because I need warranty and Knox counter to 0.
DP FH said:
Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
https://gist.github.com/scumjr/17d91f20f73157c722ba2aea702985d2
I'd like to port that to an apk using the ndk, but my pc is too old.
Click to expand...
Click to collapse
At first try doesn't work for me:
Code:
[email protected]:/data/local/tmp $ ./dirtyc0w-mem b6dc0000 b6dc1000
[*] range: b6dc0000-b6dc1000]
[*] getuid = b6f79b18
[*] mmap 0xb6dd5000
[*] exploiting (patch)
./dirtyc0w-mem: failed to execute "su": Permission denied
[*] exploiting (unpatch)
[*] unpatched: uid=2000 (madviseThread)
[*] unpatched: uid=2000 (procselfmemThread)
But I'll modify a little bit to see if I can get it to work.
Scorpius666 said:
doesn't work for me.
Click to expand...
Click to collapse
I don't think you have su on the phone ????
By the way I'm trying to install some emulator on my pc so I can try
DP FH said:
I don't think you have su on the phone ????
By the way I'm trying to install some emulator on my pc so I can try
Click to expand...
Click to collapse
I do have the su, in /data/local/tmp, with users permission. The idea is to do a chown root:root and a chmod 4755.
But I know what the problem is. The SHELLCODE in the file is for x86, which seems to be a XOR AX, AX and a RET. I have to do the same for an ARM v7L in THUMB I think...
DP FH said:
Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
<URL>
I'd like to port that to an apk using the ndk, but my pc is too old.
Click to expand...
Click to collapse
Well that assumes we have a setuid su already, this variant of the exploit won't help us.
julianwi said:
The /system partition is mounted read only by default. Because of this, you can't overwrite them. But I saw a exploit which used /sys/kernel/uevent_helper to execute a shell script as root. This would probably also work with the dirty cow exploit.
Click to expand...
Click to collapse
Somehow it did manage to overwrite it, but maybe the reboot and reset are caused by it being read-only and not actually writing the changes to persistent storage.
Will look into /sys/kernel/uevent_helper though, thanks
Scorpius666 said:
...
I copied the su binary in /data/local/tmp. I can modify files in /system/bin for example and the phone does not reboot, but i don't have fsck_msdos in my phone.
...
Click to expand...
Click to collapse
Just about any would work, you probably have some other fsck or mkfs utility you could do it with, then trying to format an SD card should run mkfs
a___ said:
Just about any would work, you probably have some other fsck or mkfs utility you could do it with, then trying to format an SD card should run mkfs
Click to expand...
Click to collapse
The thing is all my fsck* files are not readable, only by root, at least in my device. The exploit needs a readable file.
a___ said:
Well that assumes we have a setuid su already, this variant of the exploit won't help us
Click to expand...
Click to collapse
Nope. The su command is executed as root, and when you execute su as root it gives you a root shell. Try to execute sh instead of su.
DP FH said:
Nope. The su command is executed as root, and when you execute su as root it gives you a root shell. Try to execute sh instead of su.
Click to expand...
Click to collapse
No, it merely makes libc report that the user is root even though it isn't, it needs su to already have setuid to switch to the real root, and then running the shell. In this case (simplified) the exploit just bypasses the password prompt.
a___ said:
No, it merely makes libc report that the user is root even though it isn't, it needs su to already have setuid to switch to the real root, and then running the shell. In this case (simplified) the exploit just bypasses the password prompt.
Click to expand...
Click to collapse
I just noticed that. Using sh instead of su, the dirtycow-mem works in the phone and it spawns a shell, but with the same privileges than the user that executed it. So it's useless at least with that libc approach.
Scorpius666 said:
I just noticed that. Using sh instead of su, the dirtycow-mem works in the phone and it spawns a shell, but with the same privileges than the user that executed it. So it's useless at least with that libc approach.
Click to expand...
Click to collapse
Strange, on normal x86 works like a charm so something needs to be fixed
DP FH said:
Strange, on normal x86 works like a charm so something needs to be fixed
Click to expand...
Click to collapse
Of course it works on x86. If you read the code you'll see that it changes the function getuid() of libc (that is already loaded in memory) to return 0. The x86 su binary uses getuid() to know if it should ask for a password or not. Since getuid() is patched, it doesn't ask a password and spawn a root shell.
So basically for dirtycow-mem to work you need:
A su binary with setuid root
That su binary should ask for a password
The Android su binary doesn't ask for a password and doesn't have the setuid root so this exploit won't work.
hey there
did anyone try the dirtycow-vdso exploit? it works on SELinux (which AOSP uses) and doesn't require a SUID see
github . com/scumjr/dirtycow-vdso
I bought a phone (ZTE 2050) that has next to nothing as far as development goes. I have tried to install TWRP recovery but it had never actually worked. I have tried using various tools that port recovery to MTK devices. None of them have worked. I have been able to achieve root through Magisk. However, when I do, I no longer have the stock recovery either. There are several other problems that happen as well, but nothing I cannot work around. What could I be doing that is causing me to lose recovery? The chipset is MTK6771 and it is an ARM-V8 64 bit and it is running Android 9. Literally the only things I'm able to find online regarding this phone is the sites that I believe only copy and paste from other phones whether the root method actually works out not. Almost everything tells me to use MTK Tool but that definitely doesn't work. I have issues with Smart Phone Flash Tool working as well despite all drivers being installed correctly. The only way I have been able to achieve root is through unlocking the Bootloader and flashing. And even though I follow the instructions on commands, I still lose the stock recovery. Any help would be greatly appreciated.
Reflash phone's stock ROM.
xXx yYy said:
Reflash phone's stock ROM.
Click to expand...
Click to collapse
I have flashed the stock system at least 50 times by now. I have tried flashing everything in different orders as well. When I have root, it always removes the recovery. When I open my file manager, I use Solid Explorer, it tells me there is no root file system. I have tried other root file managers as well. They all tell me the same thing.
Android is rooted if su cmdlet is present in Android's filesystem
I've got a $100 Chinese MTK phone and the one redeeming feature is that once the bootloader is unlocked, you can fastboot over USB (bootstrap).
I used SP flash tool to backup the ROM and WwR_MTK to extract the partitions allowing me to make my own custom recovery to boot with fastboot. Briefly, I found a twrp recovery online for another MTK phone and just played around with zImage & initrd.
Shell commands, dmesg, cat /proc/partitions & blkid on the phone come in handy to track down in partition layout. No need to flash anything so don't get issues with /system/bin/install-recovery.sh
xXx yYy said:
Android is rooted if su cmdlet is present in Android's filesystem
Click to expand...
Click to collapse
I got it to hang on to the stock recovery. However, the bootloader remains unlocked. If I lock it again in fastboot, it will not allow me to boot the phone. When I try to flash vbmeta, it tells me there is no such file on the system.
xdabookam said:
I've got a $100 Chinese MTK phone and the one redeeming feature is that once the bootloader is unlocked, you can fastboot over USB (bootstrap).
I used SP flash tool to backup the ROM and WwR_MTK to extract the partitions allowing me to make my own custom recovery to boot with fastboot. Briefly, I found a twrp recovery online for another MTK phone and just played around with zImage & initrd.
Shell commands, dmesg, cat /proc/partitions & blkid on the phone come in handy to track down in partition layout. No need to flash anything so don't get issues with /system/bin/install-recovery.sh
Click to expand...
Click to collapse
I'll give that a shot. I just tried to open my root file system and it told me that BusyBox isn't installed. I thought I had read that BusyBox wasn't necessary with Magisk. Last time I tried to install a BusyBox, it screwed the whole system up. Is there one you would suggest? I've seriously messed with this phone 1000x's now and it's made me giggle shy to do anything to it at the moment.
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
finnroth69 said:
the whole system up. Is there one you would suggest? I've seriously messed with this phone 1000x's now and it's made me giggle shy to do anything to it at the moment.
Click to expand...
Click to collapse
xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
Ok, yeah I just checked it and it says toybox.
xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
I just installed the BusyBox and my whole system froze and started acting up.
xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
I rebooted and it started acting ok once again. When I tried to open my file manager to access to root file system, this is still the message I got even though I have not uninstalled the BusyBox.
xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
I just opened the BusyBox app and it says it isn't installed even though I have not uninstalled it either.
cm
xXx yYy said:
Android is rooted if su cmdlet is present in Android's filesystem
Click to expand...
Click to collapse
"cmdlet" not found. Yet Magisk is installed and I am able to access root.
If you can successfully apply su ( read: Switch User cmdlet ) then it got installed by whatever method.
finnroth69 said:
I just opened the BusyBox app and it says it isn't installed even though I have not uninstalled it either.
Click to expand...
Click to collapse
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.
xXx yYy said:
If you can successfully apply su ( read: Switch User cmdlet ) then it got installed by whatever method.
Click to expand...
Click to collapse
Ok, I understand that. What I don't understand is why I am now being told that vbmeta cannot be found and installed and my bootloader must remain unlocked. Or why I cannot install recovery without losing recovery.
xdabookam said:
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.
Click to expand...
Click to collapse
I can't copy it it. It won't allow me into the root file system.
xdabookam said:
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.
Click to expand...
Click to collapse
I can't copy it it. It won't allow me into the root file system.
xdabookam said:
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.
Click to expand...
Click to collapse
I just installed another BusyBox and the system is running fine afterwards, but this is the message I get when trying to open the root file system.
xdabookam said:
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.
Click to expand...
Click to collapse
I pulled up the currently installed binary installed through shell.
This has not been tested on any other version other than Android 12.1. If you have issues please report them here or open an issue on GitHub.
I just upgraded to LineageOS 19 from 18.1 and as usual I want to apply my own modifications on top of it but the NanoDroid script that I previously used doesn't seem to work on 19. I couldn't find an answer neither on r/LineageOS, r/fossdroid or even XDA so I wrote a way to install Bromite SystemWebView in a way that's a lot more elegant and doesn't need Magisk or root.
Method 1 (preferred):
Download the flashable package and install it in recovery mode either by placing it on the SD card or by sideloading, then reboot:
Bash:
adb sideload BromiteSystemWebViewOverlay.zip
Download the latest Bromite SystemWebView release and install it as you would a regular app.
Navigate to Settings > Developer options > WebView implementation and select Bromite SystemWebView.
Method 2 (legacy):
Enable Rooted debugging by navigating to Settings > Developer options > Rooted debugging.
Connect your phone to your PC and type
Bash:
adb root
Mount the vendor folder:
Bash:
adb shell mount -o rw,remount /vendor
Copy the package downloaded from here to the overlay directory:
Bash:
adb push treble-overlay-bromite-webview.apk /vendor/overlay
Mount the system as read-write:
Bash:
adb shell mount -o rw,remount /
Copy the OTA survival script to the appropriate location:
Bash:
adb push 99-bromite-webview.sh /system/addon.d
Make the script executable:
Bash:
adb shell chmod 755 /system/addon.d/99-bromite-webview.sh
Reboot the device:
Bash:
adb reboot
Download the latest Bromite SystemWebView release and install it as you would a regular app.
Navigate to Settings > Developer options > WebView implementation and select Bromite SystemWebView.
For a more in-depth explanation check the GitHub repository.
It is worth mentioning that after installing Bromite SystemWebView, developers will not provide any support when their banking applications are not functioning properly. Proven in practice.
ze7zez said:
It is worth mentioning that after installing Bromite SystemWebView, developers will not provide any support when their banking applications are not functioning properly. Proven in practice.
Click to expand...
Click to collapse
I never encountered a mobile banking app that uses WebView (at least for the main functionality), but your mention is most welcome.
I've been debloating and degoogling and old HTC 10 running android 8. I've been wanting to get bromite installed because chrome is installed as the webview. I'm rooted, but unfortunately the webview manager magisk module fails to install.
I just found this thread and would love to give this approach a try.
I have the /system/addon.d directory. I have /vendor but not /vendor/overlay. I have /mnt but not /mnt/system. The scripts I have in /system/addon.d (fdroid and minmicrog) only reference the system app and priv-app directories so no help there, unless those locations are fallback options. Can your instructions be adjusted for android 8?
I also have a rooted microg LOS 19 moto g7 that's served as a reference with my debloating/degoogling effort. I looked at the contents of /vendor/overlay there and found that all but one of the apk's in there had "vendor" in the name, so I searched recursively from / on my HTC and didn't find any apk's with "vendor" in the name. Do you have any other ideas on how I might identify the equivalent directory on my HTC?
TheShanMan said:
I have /vendor but not /vendor/overlay.
Click to expand...
Click to collapse
Then try looking into /system/product/overlay.
TheShanMan said:
I have /mnt but not /mnt/system.
Click to expand...
Click to collapse
Your path will be /mnt/system only if you mount the root from recovery mode.
TheShanMan said:
all but one of the apk's in there had "vendor" in the name
Click to expand...
Click to collapse
The name doesn't matter, you can call the apks anything and they will still work.
Can you attach the output of the following command?
Bash:
adb shell cmd overlay list
arovlad said:
Then try looking into /system/product/overlay.
Click to expand...
Click to collapse
I don't have a /system/product directory. Here are the contents of my /system directory:
Code:
addon.d
app
bin
build.prop
compatibility_matrix.xml
customize
etc
fake-libs
fake-libs64
fonts
framework
lib
lib64
lost+found
manifest.xml
media
priv-app
tts
usr
vendor
xbin
And since "vendor" is part of the discussion, here are the contents of my /system/vendor directory:
Code:
app
bin
compatibility_matrix.xml
etc
firmware
framework
lib
lib64
manifest.xml
media
radio
rfs
ueventd.rc
arovlad said:
Can you attach the output of the following command?
Bash:
adb shell cmd overlay list
Click to expand...
Click to collapse
The output from that command is nothing.
I'm happy to try as much as you'd like, including experimentation (I've gotten very used to nandroid backups and restores while degoogling and debloating ). Thanks for the help!
Try it out:
Installing SystemWebView
Bromite is a Chromium fork with ad blocking and privacy enhancements; take back your browser! - bromite/bromite
github.com
Yeah I've seen that. It's a bit complicated, which is why I was hoping to either do it via the magisk manager module or via these steps. Ultimately if all else fails, I may give that a try. Hoping @arovlad will have the magic touch here, but I totally understand if there's no desire to invest time figuring out how to do this on an old device and android version.
TheShanMan said:
I totally understand if there's no desire to invest time figuring out how to do this on an old device and android version.
Click to expand...
Click to collapse
I am all for supporting old hardware. The thing is I actually thought every device running Project Treble (TL;DR Android 8 and above) use overlays of some kind.
I have the following ideas:
Do steps 1-3 as explained above and then make a folder called overlay inside the vendor partition:
Bash:
adb shell mkdir -m 755 /vendor/overlay
Do step 4 and then run the following command:
Bash:
adb shell cmd overlay enable com.arovlad.bromite.webview.overlay
TheShanMan said:
The output from that command is nothing.
Click to expand...
Click to collapse
Does it output nothing or does it output cmd: Can't find service: overlay? If the service cannot be found then the device may not be Treble-enabled. Please check if it is.
If it is try running:
Bash:
adb shell cmd overlay dump
and paste the output here.
TheShanMan said:
Thanks for the help!
Click to expand...
Click to collapse
Thank you for your patience and investing time in this.
Edit: added link for Treble support
It outputted nothing, and the treble check app says it's not enabled. Does that mean I'm out of luck or is there anything else to try? Thanks!
TheShanMan said:
It outputted nothing
Click to expand...
Click to collapse
You mean the first command, the second, or both? Please use quotes accordingly so I can know what you're referring to.
TheShanMan said:
the treble check app says it's not enabled. Does that mean I'm out of luck...?
Click to expand...
Click to collapse
You may be. You mentioned earlier that the Magisk module fails to install and that may be because your ROM is not Treble-enabled.
TheShanMan said:
is there anything else to try?
Click to expand...
Click to collapse
Have you tried creating the overlay folder manually and then enabling it via ADB as I wrote above?
Sorry, when I said it outputted nothing, it was in response to your question about the command "adb shell cmd overlay list". I tried creating the overlay folder and enabling it. The enable command gave no output so I don't know if it worked or not. I tried rebooting and then checking the webview setting in dev options, but it's still not there.
I'm guessing you assumed I would also then do steps 6 and 7. Is that right? If so, I'll have to try creating a magisk module to put the script in that location and hope it runs. I can't touch the actual system partition because doing so causes VoLTE to stop working on my phone, so I'm doing all my debloating/degoogling through magisk modules. I don't mind giving this a try, but since my phone isn't treble enabled, I'd like to verify that you think I ought to before I spend the time creating a magisk module for it.
Appreciate the help!
TheShanMan said:
The enable command gave no output so I don't know if it worked or not. I tried rebooting and then checking the webview setting in dev options, but it's still not there.
Click to expand...
Click to collapse
Run the following command:
Bash:
adb shell dumpsys webviewupdate
and if it outputs org.bromite.webview is NOT installed then it works.
TheShanMan said:
I'm guessing you assumed I would also then do steps 6 and 7. Is that right?
Click to expand...
Click to collapse
If your phone is old and doesn't receive official updates anymore, there's no need for addon.d, so no.
May I have the contents of the / (root) folder? Is there any partition called oem or odm? If so, what do they contain?
I'm a little confused by you saying it works if it says "NOT installed", but no, it doesn't say anything about bromite. Here's the output:
Current WebView Update Service state
Fallback logic enabled: true
Current WebView package (name, version): (com.google.android.webview, 62.0.3202.84)
Minimum WebView version code: 320208452
Number of relros started: 2
Number of relros finished: 2
WebView package dirty: false
Any WebView package installed: true
Preferred WebView package (name, version): (com.google.android.webview, 62.0.3202.84)
WebView packages:
Valid package com.android.chrome (versionName: 62.0.3202.84, versionCode: 320208452, targetSdkVersion: 27) is NOT installed/enabled for all users
Valid package com.google.android.webview (versionName: 62.0.3202.84, versionCode: 320208400, targetSdkVersion: 27) is installed/enabled for all users
And the contents of / are:
acct
bt_firmware
bugreports
cache
carrier
charger
config
cota
crashdump.d
cwkeys
d
data
default.prop
dev
devlog
dsp
etc
fataldevlog
file_contexts.bin
firmware
fstab.qcom
init
init.environ.rc
init.hosd.cradio.rc
init.hosd.htc_pme.rc
init.hosd.usb.configfs.rc
init.hosd.usb.rc
init.hosd_fusion.usb.rc
init.htc.storage.exfat.rc
init.htc.storage.mocana.rc
init.rc
init.recovery.common.rc
init.recovery.htc_pme.rc
init.usb.configfs.rc
init.usb.rc
init.zygote32.rc
init.zygote64_32.rc
mnt
nonplat_file_contexts
nonplat_hwservice_contexts
nonplat_property_contexts
nonplat_seapp_contexts
nonplat_service_contexts
oem
persist
plat_file_contexts
plat_hwservice_contexts
plat_property_contexts
plat_seapp_contexts
plat_service_contexts
preload
proc
res
root
sbin
sdcard
sdcard2
sepolicy
storage
sys
system
tombstones
ueventd.htc_pme.rc
ueventd.rc
vendor
vndservice_contexts
vzw
vzwqualitylogger
/oem is empty.
TheShanMan said:
I'm a little confused by you saying it works if it says "NOT installed"
Click to expand...
Click to collapse
Yeah, it's a little confusing, but if the overlay was successfully installed it should output NOT installed.
TheShanMan said:
but no, it doesn't say anything about bromite. Here's the output:
Click to expand...
Click to collapse
Then it doesn't work.
TheShanMan said:
/oem is empty.
Click to expand...
Click to collapse
Then try putting the overlay package inside, enable it (even if there is no output, just in case) and reboot the phone.
If it doesn't work, then you are out of luck as far as I know and your only option is to patch framework-res.apk manually.
Edit: clarification
Not only did that not work, but the /oem directory got wiped out after booting up. It must get populated by something during boot. Thank you very much for putting in this much effort to figure out how to make this work in my case. I wish I could've reported victory, but maybe I'll get it figured out via framework-res. I've tried one approach with that unsuccessfully so far (which hung during boot). I'll try more things and hopefully get it figured out! Best of luck with your project and thanks for offering it to people!
TheShanMan said:
Thank you very much for putting in this much effort to figure out how to make this work in my case.
Click to expand...
Click to collapse
Don't sweat it! Thank you for your patience and sorry I couldn't find a proper solution.
TheShanMan said:
I'll try more things and hopefully get it figured out!
Click to expand...
Click to collapse
If you actually DO find a way, it would be awesome if you could report back. Maybe it will help others in the same situation. Good luck!
Hi. Thank you for that step by step process of installing Bromite Webview.
I am a little confused about the 'vendor' part. What does that mean and why is it there? And as a consequence of that, I do not understand steps 6 & 7 beyond adb 'push' or 'shell'.
Any help is massively appreciated!
arovlad said:
This has not been tested on any other version other than Android 12.1. If you have issues please report them here or open an issue on GitHub.
I just upgraded to LineageOS 19 from 18.1 and as usual I want to apply my own modifications on top of it but the NanoDroid script that I previously used doesn't seem to work on 19. I couldn't find an answer neither on r/LineageOS, r/fossdroid or even XDA so I wrote a way to install Bromite SystemWebView in a way that's a lot more elegant and doesn't need Magisk or root.
Prerequisites:
adb
Rooted debugging or a custom recovery
Installation guide:
Enable Rooted debugging by navigating to Settings > Developer options > Rooted debugging.
Connect your phone to your PC and type
Bash:
adb root
Mount the vendor folder:
Bash:
adb shell mount -o rw,remount /vendor
Copy the package downloaded from here to the overlay directory:
Bash:
adb push treble-overlay-bromite-webview.apk /vendor/overlay
Mount the system as read-write:
Bash:
adb shell mount -o rw,remount /
Copy the OTA survival script to the appropriate location:
Bash:
adb push 99-bromite-webview.sh /system/addon.d
Make the script executable:
Bash:
adb shell chmod 755 /system/addon.d/99-bromite-webview.sh
Reboot the device:
Bash:
adb reboot
Download the latest Bromite SystemWebView release and install it as you would a regular app.
Navigate to Settings > Developer options > WebView implementation and select Bromite SystemWebView.
For custom recoveries: skip the first two steps, enable ADB from recovery mode and follow steps 3-10 replacing /vendor/overlay with /mnt/system/vendor/overlay and /system/addon.d with /system/system/addon.d.
For a more in-depth explanation check the GitHub repository.
Click to expand...
Click to collapse
Hi, @arovlad thanks for this workaround. I'm running the exactly same LOS version than you on a OP6. But at step 5 i'm getting the following error : /dev/root is read-only any idea what can i do ? Thx for your help !
amanajosh said:
I am a little confused about the 'vendor' part. What does that mean and why is it there?
Click to expand...
Click to collapse
Starting Android Oreo, the vendor partition is a separate partition containing proprietary manufacturer code not part of AOSP. This separation ensures that the Android system can be updated without recompiling the device-specific software. The vendor partition is typically overlayed over the system partition, making it easy to apply tweaks and modifications without actually touching the system. These modifications are typically named systemless.
Did you install Bromite WebView successfully?
bre75 said:
at step 5 i'm getting the following error : /dev/root is read-only any idea what can i do ?
Click to expand...
Click to collapse
Try the following command instead of step 5 and see if works for you:
Bash:
adb remount