Related
The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
I'm fairly noobish w.r.t. Android (but rapidly less so!), but long in the tooth with unix and linux.
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
For the life of me, examing the output of mount, I can't figure out what device path to use in the command,
mount -o rw -o remount <device> /
I'm guessing it probably isn't this simple, and there is some convoluted loop config with mount or something as part of the Android security mechanism.
You can mount it as r/w with Root Explorer...
SubnetMask said:
You can mount it as r/w with Root Explorer...
Click to expand...
Click to collapse
ES File explorer will also allow you mount as writable. Under Menu>Settings>Root options.
It's a little flaky though, I have to turn on the root options then shut down the app and restart it to get it to work. It's free and available in the Android Market.
dwallersv said:
The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
Click to expand...
Click to collapse
You can remount / as read-write with:
Code:
mount -wo remount rootfs /
and read-only again with:
Code:
mount -ro remount rootfs /
However, the root filesystem is actually a ram disk (initramfs), so any changes to it aren't persistent across reboots. You can modify the initramfs, but it requires rebuilding it and packaging it with a kernel, and flashing the kernel containing the new initramfs.
dwallersv said:
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
Click to expand...
Click to collapse
Can you get away with placing it in /data or even /system? If you can't recompile bash, you'll have to invoke it with "bash --init-file /data/local/.bashrc" or something.
If you're using ConnectBot Local, you can do that automatically with "Post-login automation", e.g., "exec bash --init-file /whatever/.bashrc".
I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.
DiGi760 said:
I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.
Click to expand...
Click to collapse
That's for "/system", OP is asking about "/".
You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot.
The only way you can accomplish what you want, in this circumstance, is the method listed above, or to modify the initramfs.
Thanks everyone, for all the great information... Man, I love this place!
@mkasick: Crap!! Well, that torpedoes this one.
I've already used the various "workarounds" you cited (use connect automation with ConnectBot, for example). My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
I'm not going to go to all the trouble to rebuild a custom initramfs for just this.
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Once again, mkasick, you are a most helpful fellow around here. I must say -- and it may make you blush -- I am a big fan and admirer of yours, with the things you've found and fixed for the community. You are unique among the devs in my view, given the nature of what you have looked into and fixed. I'm a pretty experienced, knowlegable software guy myself, and fancy learning enough about Android to make contributions in the not-too-distant future like you have.
As I mentioned in another thread, I'm looking at a major driver re-design for the keyboard based on your analysis and patch for the dropped keypress problem... I plan to have some discussions with you (if your interested) sometime in the next few weeks about what I'm planning, just to get your feedback, if nothing else. Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Keep up the good work, friend. You are a uniquely valuable member of this community, in my judgement
-- And that's not to shortchange any of the other devs here, it's just that the nature of your work resonates with me especially, given my own background, career, interests, and past work in software.
Dameon87 said:
You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot
Click to expand...
Click to collapse
Spot-on, and very good point. However, there are ways around that:
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Click to expand...
Click to collapse
In fact, in a more generalized sense, this approach can be used to make any changes to the rootfs that "persists" across boots, without the pain of rebuilding initramfs and repackaging the kernel. This is especially messy to track and manage when you take advantage of one of the excellent custom ROMs here (in my case, Bonsai).
FWIW, and maybe helpful to others, I already have organically evolved as "reinstall" framework/process for doing some customizations to the system after installing a new/updated ROM. I use shell scripting for a lot of little things, and keeping this stuff working became a challenge across ROM releases, because necessary components -- like shells, busybox versions, whether busybox of toolbox is being called by the default path, and a bunch of other things (like the ALSA tools) are present in places like the /system filesystem.
All this gets mucked up with each ROM/kernel update. Now, I'm slicing this bologna even thinner by messing with rootfs, so I've got to get things to persist across boots!
I have a simple, one-step process for fixing all this after a new ROM. Nothing fancy -- just a flashable, Edify zip of my stuff that I hit right after a ROM update. Found a template zip with very generic Edify script in it that simply copies the file tree. I keep my custom stuff updated there.
dwallersv said:
My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
Click to expand...
Click to collapse
How about setting BASH_ENV or HOME in telnetd's environment? Or is the environment not preserved?
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only.
Click to expand...
Click to collapse
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
There's also using gscript, maybe Tasker, or another program that hooks ACTION_BOOT_COMPLETED. Those won't run at root privileges, but a tie in to "su -c" should work.
dwallersv said:
You are unique among the devs in my view, given the nature of what you have looked into and fixed.
Click to expand...
Click to collapse
Thanks!
I think of my contributions as complementary though. I don't really have the time or patience for "maintaining stuff" that other folks do here very well.
dwallersv said:
Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Click to expand...
Click to collapse
I suppose discussion elsewhere is appropriate. Sounds ambitious, but a good idea. The existing keyboard driver architecture could be improved for certain. To date though, I've tried to make my kernel changes relatively non-invasive, even if not ideal, for maintenance sake.
In a perfect world, a rewritten driver would make it back to Samsung and that would be the "end of it" for us. Personally, I wouldn't want to expend the effort to do so unless I knew it would be merged. But if that something you feel like attempting, there's no harm in trying and seeing what results.
mkasick said:
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
Click to expand...
Click to collapse
I'm not 100% certain at this point, but from what I've found investigating this, it looks like the "user scripts" /etc/init.d/<scripts> mechanism is a standard part of the Android system. I'll see if I can find where I saw that and post a link.
I don't think I have seen any mention of this idea yet. Sorry if I missed it...
In a recent thread about the 6.2.2 update and people wanting to prevent it, I thought I read that someone saw the file show up in the update directory. I'm assuming this means the same 'kindleupdates' directory you could manually drop the update into -- but if not, the idea is the same. Why not just take some step to prevent access to this directory?
The exact step to take would depend on how smart the developers were about dealing with problems in the update process
The easiest step would be to chmod 555 it. But of course if the update process is running as root it is under no requirement to honor those permissions! (My experience in the unix world tells me that about half the time, programs running as root do honor the permissions even though technically root overrides them).
Another easy step would be to delete it altogether. But they probably thought of that (if it's /mnt/sdcard/kindleupdates where someone could easily accidentally delete it) and recreate it if it's missing.
One trick that is often done is to replace the directory with a file. Some programmers do not think to check this kind of condition - they see there is something there, but they get an error opening it as a directory, and they just declare it's an error.
A more subtle trick would be to replace the directory with a symlink that points to a read-only directory (such as /system). In this case, they could open it as a directory, and just fail to write there. The programmer probably would not have thought to check whether it's a link vs. a real directory. One possible gotcha is if you point to /system, and /system is r/w, then the update could screw something up under /system. So maybe mount /system r/w, mkdir /system/kindleupdates, remount /system r/o, then link the update dir to /system/kindleupdates.
And finally, I don't know if Android has any kind of loopback filesystem capability, but loopback-mounting something read/only on that directory would certainly fake the OS into thinking there was a directory there; it would definitely be read/only, and I don't think they would ever think to check whether there is actually some filesystem mounted there! (and if there was, all you need is an app that constantly accesses some file you put there, which would make it busy so that it couldn't be unmounted).
The first method won't work because the sdcard partition is fat32 and doesn't accept unix permissions.
it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...
well, i just deregistered my kindle acount and i'm still in 6.2.1...
b63 said:
it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
Click to expand...
Click to collapse
Ah, that makes this less practical. Still, perhaps when the next update comes out I can try a variation on this but it requires the filename to be known.
If the update is downloaded as a single file to /cache, which is named the same as the file you can manually grab, then someone who hasn't gotten 6.2.2 (and is not averse to this failing) can try this in a root shell:
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin/blah
The purpose here is to put something unremovable in the way of the file it wants to download. Most likely if the update sees something with the existing name there it would probably want to blow it away (after determining it's incomplete) - and since any update there would normally be a regular file, they probably would do nothing more complicated than a simple unlink syscall to delete it before re-downloading. However, since it's a directory with something in it, that unlink will fail. In actuality, making the subdirectory (second command above) should be unnecessary because the unlink should not work for directories; there's a special rmdir syscall for them.
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...
Click to expand...
Click to collapse
I did read a lot of that last time and I don't think I actually saw a definitively successful method. If there is one it should be stickied
My interest in this is a little different from most of you guys - I have very limited satellite internet and I don't like these unscheduled 185-meg downloads so I want to be able to update only when I want mostly to control that. This kind of means looking for the least-intrusive way to accomplish this.
/cache/update-kindle-6.2.2_D01E_3205220.bin is exactly where it downloads
if you find a way to even prevent the download, that would be greatly appreciated
Unfortunately I already got the update so I can't try it this time.
at least you could try your method with a dummy file of an other name and try to overwrite it with adb - if you can't overwrite it there's a good chance
I think I'm about the only one who prevented 6.2.1. I did it by constantly checking the cache folder. Found the update by chance and deleted it before it updated. Waited over a week for it to come back. Never did. An app that watched the cache folder for the updates and then moved/deleted them would work fine
Sent from my SGH-I897 using xda premium
jcase already work a way around this automatic OTA update, so when FIREMOD is ready to replace burrito I think we will have no more problem with this OTA issue. (you can find jcase announcement in the kindle developer section)
Heres what I have done to prevent this.
1) Droidwall (white list only the apps you want to allow internet access)
2) Removed "otacerts.zip" from /system/etc/security/otacerts.zip.
3) I removed "OTASilentInstall.apk" /system/app
4) Installed this 6.2.2 based Rom http://forum.xda-developers.com/showthread.php?t=1439916
Hopefully this eliminates the OTA. I had my Fire rooted on 6.2.1 with twrp and it OTA'd on its own, broke root and twrp. So I rerooted with burritoroot2 and installed CWM based recovery.
Is there a way to root the Streak 5 or install custom recovery without using USB connection? The USB charger port is broken so I am unable to connect through USB. I´ve tried to root the phone with GingerBreak and Z4Root without success. Maybe it´s possible to root the phone or flash recovery with Flash_image in Terminal Emulator but I am unable to find a guide to do so. Any help would be apreciated, I´ve searched the forums here but am unable to find the answer I´m looking for.
edit:
I´m on Android 2.2.2, 360 stock ROM, build 17397.
Well, if the answer you were looking for is "yes it can be done", then it's obvious why you haven't found the answer you were looking for.
You have to have a working port on the Streak to install CWM since installing a custom recovery requires being in the Streak's Fastboot mode. Rooting may be possible, but unlikely since you have to copy files to the \system directory, which isn't writable unless you've rooted using CWM to install the files or ADB to push them.
Short of finding an exploit to root with, he might(?) be able to by disassembling it and pushing root to /data/local and setting permissions with a pc.
TheManii said:
Short of finding an exploit to root with, he might(?) be able to by disassembling it and pushing root to /data/local and setting permissions with a pc.
Click to expand...
Click to collapse
ah.. i see... by taking out innerSD and manually push root into it.. it seems possible that way...
Rooting is ultimately getting SU somewhere runnable and changing it's permissions to 06755.
It just makes the most sense to place it in /system/xbin 99.95% of the time.
it seems the guy doesnt read the forum thorough enough.. because there is solution to it already..
http://forum.xda-developers.com/showpost.php?p=29190631&postcount=12
Dont recall gingerbreak working on 350+ as dell pretty much patched everything.
I believe it works on 318 or thereabouts, but OP is on 360 he already stated it didnt work (but not which exact version of gingerbreak)
well.. at least he can try first... but it seems not possible is it?
Gingerbreak version 1.2 works on stock 351 but not on stock 360.
Sent from my Dell Streak using xda premium
TheManii said:
Short of finding an exploit to root with, he might(?) be able to by disassembling it and pushing root to /data/local and setting permissions with a pc.
Click to expand...
Click to collapse
That sounds like a good idea since I have already cutted out for access to the internal SD card. What would be the best program for Windows 7 to push root to the SD card and change the permissions?
You would need to be able to read ext3 partitions and modify the file permissions.
I've never bothered trying under windows, the simplest way is to do it under linux.
You can install it in a VM if you wish, or you can try and figure out how to do it with additional software under windows.
Regardless you should try pushing su to /data/local/ and setting it's permissions to 06755 (rws--r-s-r-x).
If you get that far we'll continue from there
Would it be possible to get a repacked 360 stock ROM (apk or zip package) that is already rooted, and then install it on the Streak using the 360 stock recovery? Maybe that´s not possible because of the signature verification but I wonder if it would be possible. Then I would have to find someone with a rooted 360 ROM to make the package for me.
TheManii said:
Regardless you should try pushing su to /data/local/ and setting it's permissions to 06755 (rws--r-s-r-x).
If you get that far we'll continue from there
Click to expand...
Click to collapse
sorry to bust in. /data is mounted nosuid for a reason. Don't know whether this is so on the 360, but at least check ($ mount |grep /data) before you open your device and risk hardware damage.
Hi all,
has anyone been able to do this? Following the guide here, no longer works for Android N. The phone boots, but ignores all changes to system. How do I modify both build.prop and hosts? It seems that there are now possibly two system partitions?
Thanks!
Same issue on Nexus 5X
No answer on this? How is it that nobody else seems to be having this issue?
What I've done
It looks to me like everyone has moved to systemless and the /system partition cannot be adequately modified in this way anymore.
Maybe this will help others:
I was modifying the system directory for two reasons: 1. modify /system/etc/hosts to remove ads and modifying build.prop to increase lcd.density. I found that here are the alternatives for each:
Removing Ads
Using something similar to AdAway_systemless_hosts_v2.zip (google it for a copy) and modifying the hosts file in that zip file to be the one I use (and rezipping, deploying on the Android device). This basically mounts over /system/etc/hosts with a custom hosts file instead of actually modifying the system specific hosts file which is no longer writable.
The alternative is to use Netguard which routes non https network traffic through a private VPN where you can block ads according to a hosts file. This seems to work OK, but I have noticed that websites seem to take longer to load.
Modifying lcd.density
You can use the same trick as AdAway_systemless_hosts_v2.zip uses, but modify it to also mount a modified copy of build.prop. Alternatively just use the Android N Display settings that are small (what I did anyhow).
I have been able to edit build.prop and still maintain systemless root.
Sent from my Nexus 6P using XDA-Developers mobile app
I was able to modify my system partition; by installing busy box to /su/xbin and running "su busybox mount -o rw,remount system" (no quotes) in material terminal with root
ArminasAnarion said:
I was able to modify my system partition; by installing busy box to /su/xbin and running "su busybox mount -o rw,remount system" (no quotes) in material terminal with root
Click to expand...
Click to collapse
Have you been able to do this with simply fastboot boot <twrp-image>, mounting system in rw mode and modifying it? I did that as I didn't want to root the phone, and while it looks like it did the write, it does not affect the system partition that is used by the phone after boot. I think there are two system partitions, and twrp mounts only one in rw mode. It does seem like it may be possible to do what you say using adb though after the phone is fully booted up. I'll try that!
dontblinkwatchout said:
Have you been able to do this with simply fastboot boot <twrp-image>, mounting system in rw mode and modifying it? I did that as I didn't want to root the phone, and while it looks like it did the write, it does not affect the system partition that is used by the phone after boot. I think there are two system partitions, and twrp mounts only one in rw mode. It does seem like it may be possible to do what you say using adb though after the phone is fully booted up. I'll try that!
Click to expand...
Click to collapse
I had the same problem. I don't want to root but I do make a few changes to my /system partition through adb in recovery such as the hosts file and some font files (namely the Emoji font file). I had modified stock boot image to not enforce encryption. I would boot back up into the system and couldn't see any changes made. The only thing I found that worked was installing a custom kernel (I use ElementalX). After that, changes I made to /system in TWRP were reflected in the OS. I don't know enough about kernel development to understand why on (mostly) stock kernel my changes couldn't be seen but on a custom one they were.
I never had this "problem" prior to Nougat.
Same issue here. Something has changed with how this is handled in Nougat.
I don't want to root just to overwrite the hosts file...
I'll keep debugging but my capability in this is definitely limited!
I use a similar approach as described in the OP's linked guide except I use my own recovery image that I compiled as an engineering build from source, and I am also experiencing the same behavior. Modifying the hosts file seems to have no impact on the system though the changes persist. Comparing the host file I installed and the host file from the latest Nexus 5X image with 'ls -lZ' the SELinux info looks to be the same. The only information that appears to differ is the modified date and one additional line in the file itself for testing. I thought I was doing something wrong with my hosts file, even though I have been using this approach since Android 6.0. However, I agree, it appears that changes to system are being ignored. Further, changing the system partition no longer shows the red warning at boot about the system being corrupted.
---------- Post added at 09:58 PM ---------- Previous post was at 09:38 PM ----------
DanRyb;68654939 I would boot back up into the system and couldn't see any changes made.[/QUOTE said:
Oooh. You're right. Neither /etc/hosts or /system/etc/hosts is modified in the booted OS after I modify it from live image, but the change is retained when I reboot into live image and mount system. Hmm, so either:
1) Need to figure out where the the system files are being loaded from and modify them from live image if possible
2) Use a mechanism similar to what dontblinkwatchout described AdAway is using of having a custom mount setup (have to reverse engineer AdAway I guess to see what it's doing)
3) ?
Click to expand...
Click to collapse
There's absolutely no way to modify or mount system partition r+w unless you disable dm-verity
Enviado desde mi Nexus 6P mediante Tapatalk
alexiuss said:
There's absolutely no way to modify or mount system partition r+w unless you disable dm-verity
Enviado desde mi Nexus 6P mediante Tapatalk
Click to expand...
Click to collapse
dm-verity has been around since Android 4.4. Are you saying there is something new around this in Android 7.0?
You can modify the system partition by compiling an engineering build of Android and booting it, then mounting the system partition and modifying it. I've been doing this to update the hosts file since Android 6.0 for every OTA update (since more recently OTA updates bomb out unless you reflash the clean "uncorrupted" system.img first). Changing the system image before Android 7.0 did result in an extra screen with a red warning about a corrupted something or other (I'm sure because dm-verity checking failed). Regardless, you can still change the system partition, the information just no longer seems to be used, which is a bit perplexing to me atm.
crashenx said:
dm-verity has been around since Android 4.4. Are you saying there is something new around this in Android 7.0?
Click to expand...
Click to collapse
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.
sfhub said:
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.
Click to expand...
Click to collapse
That's good info and makes total sense. Thanks! Pretty neat actually, just a bummer for me.
Yeah so SuperSU path is not really one I want to pursue. I could learn how to update the dm-verity shas used for verification. That'd probably be the most secure, but it's gonna be a PITA I bet. I imagine I'd need to compile my own image similar to how I made my live image and update a few things. Might have to deal with encryption which is probably an even bigger headache. Also, I bet it would break OTA and have to reflash to update, though that's true now.
I'm really curious what AdAway is doing. Maybe I should pursue reverse engineering that.
I really appreciate you pointing us in the right direction.
I am glad found this thread..willing to assist here without permanent root..
Ericarthurc said:
I was able to modify my system partition; by installing busy box to /su/xbin and running "su busybox mount -o rw,remount system" (no quotes) in material terminal with root
Click to expand...
Click to collapse
I was trying to create a /system/xbin/post-boot but couldn't remount /system, and so I added busybox to the front of my command. I am not using adb so I cut that part off. Thanks a lot!
ROOT w/o UNLOCKING BOOTLOADER:
Few of Qualcomm Devices have been found to have engineering mode software preinstalled on the device, which has root access. Using the same exploit root can be achieved in OP3, OP3T, OP5 and others, without unlocking the bootloader. Here is a full story: OnePlus Accidentally Pre-Installed an App that acts as a Backdoor to Root Access
The exploit was found by the user Elliot Alderson. An application has been promised by the author soon, to gain root access.
I have tested the method in OnePlus 3T and it works perfectly and passes SafetyNet check, furthermore you do not get DM-Verity error either.
Please follow the guide from here: OnePlus 3T Root w/o unlocking bootloader
Note: Do not modify system files though it won't let you, doing so will trigger Dm Verity.
Magisk Modules do not work, i,e you won't be able to use any modules.
Root and hide root works.
You will get system update but updating might kick you out of the root and you won't be able to gain access to root again.
It works on latest Oreo Beta, as you see in the screenshot.
Disclaimer: Follow the guide at your own risk, it is working fine for me, that in no way means it will work the same for you. Neither me nor the people envolved in this takes any responsibility. You and only you are responsible if anything goes wrong.
Note: I am not the developer or the person who found this exploit or root method. All credits go to them.
SCREENSHOTS ATTACHED
Update 1:
An app has been realsed by Oğuzhan Yiğit here is the link, the full credit goes to him for the same. Here is the link to the post:
Oneplus 3T Root Via App, further it installs SuperSU
This step is required every time you reboot:
adb shell
cd /data/magisk/
./magisk --mountimg xbin.img /system/xbin
magisk --post-fs
magisk --post-fs-data
magisk --service
I haven't tried doing the same, but theoretically, it shouldn't work.
[deleted]
casual_kikoo said:
...OnePlus 2...
Click to expand...
Click to collapse
That phone does not have dm-verity. That's why it works.
DOING THIS ON A ONEPLUS 3 OR NEWER WILL NOT WORK AND YOU WILL BRICK UNTIL YOU QUALCOMM UN-BRICK THE PHONE
Edit: I suggest deleting that and posting it in the OnePlus 2 section since someone will likely try it and brick.
SpasilliumNexus said:
That phone does not have dm-verity. That's why it works.
DOING THIS ON A ONEPLUS 3 OR NEWER WILL NOT WORK AND YOU WILL BRICK UNTIL YOU QUALCOMM UN-BRICK THE PHONE
Edit: I suggest deleting that and posting it in the OnePlus 2 section since someone will likely try it and brick.
Click to expand...
Click to collapse
Ok, as I thougth something else enter into account.
Thanks a lot !
As a newbie can u plz provide me the steps how to gain root access.?
Thanks in advance.
anuajayan said:
As a newbie can u plz provide me the steps how to gain root access.?
Thanks in advance.
Click to expand...
Click to collapse
Please do the necessary steps, I will assist you wherever you get stuck, you can also reach me at telegram on @apurvak
coolstoneapurva said:
Please do the necessary steps, I will assist you wherever you get stuck, you can also reach me at telegram on @apurvak
Click to expand...
Click to collapse
I don't know from where or how to start with? Please guide me accordingly..
replace hosts file
OK, so I decided to take advantage and replace my hosts file. I gain adb root, but then
Code:
@~/Downloads/oneplus[20:56:04]~: adb push hosts /system/etc/hosts
adb: error: failed to copy 'hosts' to '/system/etc/hosts': remote couldn't create file: Read-only file system
hosts: 0 files pushed. 73.3 MB/s (327680 bytes in 0.004s)
trying without success
Code:
@~/Downloads/oneplus[21:00:48]~: adb remount
remount failed
and from within
Code:
@~/Downloads/oneplus[21:00:51]~: adb shell
OnePlus3T:/ # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:su:s0
OnePlus3T:/ # mount -o rw,remount /system
'/dev/block/dm-0' is read-only
What am I doing wrong or need to do to replace my hosts file, please?
mitkko said:
OK, so I decided to take advantage and replace my hosts file. I gain adb root, but then
trying without success
and from within
What am I doing wrong or need to do to replace my hosts file, please?
Click to expand...
Click to collapse
It's a good thing something is stopping you, because you shouldn't be modifying any file on the partitions. Again, dm-verity is enabled. You modifying any file directly will result in getting a corrupt error after a reboot. Use Magisk for systemless modifications.
Please write in first post if OTA will still work on next update. And if possible specify if this woks also on oxygen os open beta with Android Oreo.
That said, anyone know if possible to unlock bootloader state, without trigger the factory reset??
SpasilliumNexus said:
It's a good thing something is stopping you, because you shouldn't be modifying any file on the partitions. Again, dm-verity is enabled. You modifying any file directly will result in getting a corrupt error after a reboot. Use Magisk for systemless modifications.
Click to expand...
Click to collapse
How do I do that? Assume I have already introduced magisk to my phone.
mitkko said:
How do I do that? Assume I have already introduce magisk to my phone.
Click to expand...
Click to collapse
Isn't there a systemless host option for adblock in Magisk's settings? If so, turn it on, install AdAway, turn on systemless hosts in that, apply the adblock.
SpasilliumNexus said:
Isn't there a systemless host option for adblock in Magisk's settings? If so, turn it on, install AdAway, turn on systemless hosts in that, apply the adblock.
Click to expand...
Click to collapse
Never used it before. Is that persistent? I mean after reboot and magisk root gone will it persist? I don't need persistent root, I just want to patch hosts one time only if possible.
mitkko said:
Never used it before. Is that persistent? I mean after reboot and magisk root gone will it persist? I don't need persistent root, I just want to patch hosts one time only if possible.
Click to expand...
Click to collapse
It's not persistent. The last steps for root access in that guide needs to be done after every reboot, which is also needed for AdAway to apply the block. Applying the adblock after root doesn't need a reboot.
You're better off just doing the traditional unlock and root instead.
Hope that makes sense.
Deodexed and Patched EngineeringMode.apk for restore default Privilege
I played a little with Angela`s Root and wanted to restore the previous level of privilege. In the application there is a special button rollback changes, but it is Invisible
Code:
this.mPrivilege = this.findViewById(2131493042);
this.mPrivilege.setOnClickListener(((View$OnClickListener)this));
this.mPrivilege.setVisibility(4); //this.mPrivilege.setVisibility(View.INVISIBLE);
So I did the application deodex and patched the application, changing it to
Code:
this.mPrivilege.setVisibility(0); //this.mPrivilege.setVisibility(View.VISIBLE);
After that I changed the original application to patched
Code:
adb remount
adb push EngineeringMode_SIGNED_ALIGNED.apk /system/app/EngineeringMode/EngineeringMode.apk
And start them
Code:
adb shell am start -n com.android.engineeringmode/.qualcomm.DiagEnabled --es "code" "angela"
Result Screenshort:
After click on the button, the phone restarts and all privileges are restored
mitkko said:
OK, so I decided to take advantage and replace my hosts file. I gain adb root, but then
Code:
@~/Downloads/oneplus[20:56:04]~: adb push hosts /system/etc/hosts
adb: error: failed to copy 'hosts' to '/system/etc/hosts': remote couldn't create file: Read-only file system
hosts: 0 files pushed. 73.3 MB/s (327680 bytes in 0.004s)
trying without success
Code:
@~/Downloads/oneplus[21:00:48]~: adb remount
remount failed
and from within
Code:
@~/Downloads/oneplus[21:00:51]~: adb shell
OnePlus3T:/ # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:su:s0
OnePlus3T:/ # mount -o rw,remount /system
'/dev/block/dm-0' is read-only
What am I doing wrong or need to do to replace my hosts file, please?
Click to expand...
Click to collapse
You shouldn't make any changes to system partion doing to will render you unable to boot, as dm verity is enabled.
andQlimax said:
Please write in first post if OTA will still work on next update. And if possible specify if this woks also on oxygen os open beta with Android Oreo.
That said, anyone know if possible to unlock bootloader state, without trigger the factory reset??
Click to expand...
Click to collapse
Yes it will work on next update as system files are intact, further it works on Beta Oreo as you can see the screenshot. I will further update the post with the same.
seems not working on Android 8 /OOS 5