Related
Hi,
I'm new to the business and I spent some time to learn the environment trying different applications and different approaches for almos every action I took. Today, I have not much bigger knowledge, but I finally decided to take few things in my own hands because existing software is not fulfilling my wishes.
I started with this simple script which eases the pain of reinstalling all applications after ROM upgrade. There are few such tools already, but I found those quite bloated with unnecessary thing for my own approach.
With this script I assume:
1. There is/was SSHDroid installed (or any tool with busybox and you can access shell command line) both in old and new ROMs and your ROM have bash installed in /system/bin/.
2. Backup/restore operation includes only INTERNALLY installed applications, it completely ignores SYSTEM and SDCARD installed ones.
3. This is TEMPORARY backup so it should be as fast as possible not caring about occupied space (!). Althought I added -zip parameter to enable compression if you are running out of space on your sd.
4. Installed ROM is clean with no additional apps installed (excluding those needed by the script)
5. You have basic knowledge about bash scripting, because I take NO RESPONSIBILITY of the script behavior or data loss it can do.
So, basically it is simple. It runs like this:
1. On old ROM type: sbackup -backup
2. Flash your ROM
3. On new rom type: sbackup -restore
Just like that. The applications data is tar'ed in one file per application so if you want to get rid of any, just delete it from backup directory. The directory name is same as script name on sdcard but you can change it adding a parameter without a '-' sign at runtime (first non-option parameter is treated as backup directory path). The file is zipped because this forum disallows files without an extension so... it is zipped ;D
It was tested on my fresh LeeDroid 3.3.3 GB AFTER i installed some apps. I backed them up and then restored. All seems to be perfect right now, but I will test it more thoroghly very soon because I'm planninig to have CM7 based ROM too just to choose that I need Sense or not (two nandroids for fast switch weekly ;P).
With this script and MyBackup functionality of backing up contacts, sms, history and similar it should be quite complete approach to restore all the data needed on the fresh ROM. In the future maybe I will look at the MyBackup part too. Maybe.
Feel free to comment, use, suggest or anything you like, and have fun ;P.
How do I run this script? Do i run it from sdcard or from system /bin? When i do it from system bin it says cannot create directory. When i run it from sdcard/sbackup it says permissions denied?
Sent from my ADR6400L using Tapatalk
jgrimberg1979 said:
How do I run this script? Do i run it from sdcard or from system /bin? When i do it from system bin it says cannot create directory. When i run it from sdcard/sbackup it says permissions denied?
Sent from my ADR6400L using Tapatalk
Click to expand...
Click to collapse
And thats why I mentioned in topic about not being a newbie (and I meant not forum newbie but more a linux newbie). The thing is, it's a simple script - without any user-proof capabilities, comments inside or something BUT...
But ok, I will try to help you run it. First of all, you have to set permissions to the script. It has to have executable permission to be run by the system (and I mean filesystem permission). This can be done by chmod instruction of busybox. Most of the times it's done like this:
chmod 755 filename
This is a reason of not running form sdcard if your sdcard is NOT ext filesystem (it is usually windows fat filesystem not to generate problems with reading it under windows).
Second thing to run is to have /system/bin/bash because first line of the script (a comment like this: #!/system/bin/bash) instructs busybox to execute script using bash. This can be simply changed by modifying this line, but you have to remember that changing the shell executing script have consequences. Differens shells have sometimes different syntax, althoght i wrote this script simply so it should run on most of them, especially sh.
Third thing is to have write permissions to the directory in which the backup will be created. In original version of the script it is /sdcard, because backup is made in /sdcard/sbackup. So, you have to check it (second error - problems with creating directory).
And a last tip - it can be run from ANYWHERE. Even if your partition does not alolow executing, you can do it like this:
bash-3.2# /sdcard/test
bash: /sdcard/test: /system/bin/bash: bad interpreter: Permission denied
bash-3.2# . /sdcard/test
OK
bash-3.2#
First try does not succeded, but second did. The trick is a dot which means to execute file with a shell not caring about why or permissions.
And thats most simple introduction I could write. It applies to ANY script you want to run.
Please anyone - if you want me to help, paste your results here because without a precise error message it can be very hard to deduce what caused for example permission denial or anything usual.
For now, I won't add any more error handling, but if there will be more users caring about, I will add it.
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.
THIS METHOD IS NO LONGER WORKS as of update version 2.0.5 and higher.
Please visit this thread instead for the current rooting method.
Posting in this thread will get you nowhere, let it RIP.
ANNOUNCEMENT:
If you have a new Nook HD/HD+ and want to root and get the GAPPS running, you should follow the guide at the All-in-One thread instead. That said, I won't copy all the information here to there, so you should continue to read on.
Let me start by saying that I didn't come up with the working root method. The original root instruction came from verygreen in this thread. And I am not a developer, I merely have a few linux background and even less so in the Android. I worked on this on my spare time by myself.
I merely take what was working, but unusable to make it usable. I found something that he is missed. This may actually be working on Nook HD (non-plus) also, but since I don't own one I can't say that it will.
Disclaimer:
If something gone wrong, it's all your fault. I take ZERO responsibility for what happen to your device, your life, your wife/husband, your kids, your unborn child and etc. You get the idea.
Background:
When I found out the root doesn't actually work past a reboot, I start looking what actually cause the Nook to be pissed and factory reset itself. Well, it seem that the /system and anything in there is basically coming from a /dev/block/mmcblk0p8 And if something got change, Nook get pissed and do a FULL FACTORY RESET(I'll explain in a moment). Well, at least I start investigated under that idea.
What I found:
What I found, or at least what I think I found is that, probably just adding file, or increase in the size(maybe there is a threshold for this), will cause it to do a full factory reset. What I also found is that there is a $PATH for /system/sbin but not pointing to anywhere. So I come up with the idea of making another ext4 file system in a file and loop mount it to /system/sbin I guess that work(very well). What I also found is that, there are two kind of factory resets. The one that you perform yourself, which is actually not a full factory reset and the one that Nook get pissed and do the full one.
A factory reset that you perform yourself, whether from the GUI or button combination will basically clean the partition /data while a full blown one will basically restore other partition such as /system
What is included:
basically a zip file, inside that zip file are 6 files.
boot_complete_hook.sh.bak this is basically a modified version of verygreen's
busybox & su are basically from his thread
superuser.apk well I found this one floating around and seem like a good idea to stick it in there (not even sure if it gonna work w/ Nook)
makeroot.bat this is basically what do most of the work. It's base on verygreen original rooting instruction.
sbin_mount This is basically an ext4 file system which have su and another version of busybox all setup nice and tidy for you all. This version of busybox is 1.20.2r2 which I grabbed from here.
Prerequisite:
ADB, it's your responsibility to have adb up and running, meaning not just have it install, but it can see your nook also.
leapinlar wrote a post to help you getting ADB to work here.
Now to get root:
all you have to do is unzip it and run makeroot.bat (obviously you run this in windows command prompt). Yub that's all. The batch file will do the rest, including reboot the nook and wait for it to reboot and stuff. Won't make a coffee for you though.
The manual and hard way:
well, I will only explain this in a summarize way. Basically this start with verygreen rooting method. It basically take advantage of the exploit and run /data/boot_complete_hook.sh which you adb push yourself(with correct permission) with root privilege. What you can run in there is basically up to your creativity. So obviously in this case, you mount the sbin_mount as an ext4 filesystem in the /system/sbin You can make this file yourself if you want to, in linux using dd and mkfs command. Basically using dd to create a file volume to the size you want and mkfs to format it to ext4. Mount it and start uploading stuff you want in there. You will have to correct all the file permission as well. Since all of this will be mounted to /system/sbin you should be aware what you gonna put in there. I guess I could make this thing 100MB, but for this specific purpose 10MB is enough. I my case, just the su and busybox and the symbolic links for the busybox. I'm doing this for the long term. I'm too lazy to point to busybox everytime I wanna do something.
What to do afterward:
Now that you have root, you can Enable Unknown Source to allow you to install app from within the device and install GAPPS. Follow the two guides below if you interested.
Enable Unknown Source: Again, I make an easy little tool for you here.
GAPPS: here.
Did I missed something:
Well, as I said I'm no coder so if I didn't do a clean job, you can refine it. If I didn't document or give proper credit, then I guess I missed that. Sorry about that, again I'm no coder and never done this. And finally:
If this thing work for you, feel free to hit that "THANKS" button. I spent many hours trying to come up with this solution.
FAQ:
Q: My so and so application when attempting to have root access get freeze up, or superuser doesn't work?
A: Well, I'm not sure if this is dued to how the Nook side-loading work or not, but it seem for some reason superuser won't start by itself. So you have to start it manually the first time.
Q: I type in "adb root" and I can't get in as root, it doesn't work?
A: yes it does, it's just not working with adb root. You can get in via "adb shell" once you get in, type in "su" and you can see that you now should have root access.
Thank you so much! This works perfectly. Survives reboot.
here's the Linux version.
Thanks someone0 for getting this started.
Haven't fully tested the linux version, but it loads and starts up, so should work.
extract, and open up terminal and navigate to the dir you extracted to, and type
./makeroot.sh and then enter.
This sounds like a good idea initially.
It is true that the B&N does not just check for /system/xbin/su directly like they did in the past.
This time they check for something else and I just had no time to look into it more deeply to find out what is it they are actually checking for. I plan to figure this out on Friday when I am back home.
Also wanted to tell you that having Linux background is a great thing when tinkering with Android (at a low level, anyway). I don't have much Android background to speak of as well.
This works really well, and thanks to Someone (and mad props too) for getting persistent root working on this.
I may be being very naive, but my suspicion on the reboot is around the manifest file that's present at root.
It seems to be generated by the boot process and it might provide a quick and dirty list of what's permitted on the device to check. With persistent root, lots of investigation becomes a lot less painful. I expect that by end of day we'll have install unsigned running.
Early in my experimenting with the HD+, I noted:
- some versions of the Google Services Framework can be installed via adb
- when I launched the native calendar app after installing gsf, it wanted to sync to a google account, and was able to add the google account
- one version of the Play store installed and launched as far as throwing the 'you must accept the terms of service' before crashing
What BN most likely does is calculating the hash value (or digest, if you prefer) of certain system files that they think shouldn't be tampered with, then during reboot, the values of these files must match, or they will do a factory reset.
The key point is to find out where they do these checks and fool the check.
This sound simple but it depends on how they implement it. If they use binary decisions (like if the hash_value == calculated), then it is easy to get around. If not (e.g. using white box algorithm to hide keys), then it get more complicated.
excellent and very elegant solution. Kudos!
I'm heading out to work, and if you think your theory is right, try poking around with it. Now that your have root, you can try to dd those bootloading partitions out to user area and upload them out to PC and inspect them.
looking at the vold.fstab
Code:
xloader -> /dev/block/mmcblk0p1
bootloader -> /dev/block/mmcblk0p2
recovery -> /dev/block/mmcblk0p3
boot -> /dev/block/mmcblk0p4
rom -> /dev/block/mmcblk0p5
bootdata -> /dev/block/mmcblk0p6
factory -> /dev/block/mmcblk0p7
system -> /dev/block/mmcblk0p8
cache -> /dev/block/mmcblk0p9
userdata -> /dev/block/mmcblk0p10
Be extra careful when touching those partition if you not sure, don't touch them. But making a block copy of them and taking them out should be relatively easy and safe. Obviously you gonna need a Linux box to do this. I setup a VM on one of my PC last night because I need to get a ext4 partition and put all the goodies in there.
krylon360 said:
here's the Linux version.
Thanks someone0 for getting this started.
Haven't fully tested the linux version, but it loads and starts up, so should work.
extract, and open up terminal and navigate to the dir you extracted to, and type
./makeroot.sh and then enter.
Click to expand...
Click to collapse
Just wonder why do use a zip file for the linux version? Wouldn't this kinda messup the permission when compress/uncompress? meaning, makeroot.sh may not have the proper permission when unzip. Please double check.
someone0 said:
Just wonder why do use a zip file for the linux version? Wouldn't this kinda messup the permission when compress/uncompress? meaning, makeroot.sh may not have the proper permission when unzip. Please double check.
Click to expand...
Click to collapse
works just fine.
I chmod a+x'd the script before putting it into the zip.
heh, yeah, it works. Forgot I had my touchpad pluged in and it rebooted it....
whoops.
thanks for posting the location of the /recovery partition. I want to put a copy of htat on ice to prevent BN from undoing any of my work in a future update - I may want some of the fixes they have, but I want to be able to roll them back if needed.
Someone0 are you around can you pm me, Your root works, I installed nook color tools ver .02 in system/app folder and was able to see it in my sideloaded launcher, was able to uncheck/check install non market apps which sets the setting for US to be able to install .apk files from the nook itself, ONLY ISSUE is since I put that file in the system/app folder and the nook didnt like it I got stuck in a bootloop and get to start this process all over again! (nook resetted to ground zero)
maybe we temporary can leave it there get us the permission to install non market apps then remove the file and we will be ok or maybe stuck in another bootloop.
---------- Post added at 09:20 PM ---------- Previous post was at 08:52 PM ----------
GOT IT WORKING NOW:
1. Once rooted, get a file manager with root support and enable read/write permission to /system
2. temporary copy nook tools ver .02 .apk to the system/app folder
3. have a sideloaded launcher and check the app drawer youll see nook tools, run it, first screen uncheck and check the install non market apps box couple of times make sure its checked afterwards
4. have a test .apk to run the BN installer on and see you can now install .apks from the NOOK HD and HD+
5. remove the nook tools.apk file from the system/app folder and quit your file explorer which should reset everything for the system folder back to the way it orginally is!
6. reboot, if you reboot successfully with no boot loop 8 times, your GOLDEN FOR NOW! once again load up a file manager go select an .apk file and see you can now install it! Next step is trying to get amazon market working! then google somehow, but for google you need files in system/app folder permanently!
7. YOU CAN NOW SUCCESSFULLY DOWNLOAD .APK FILES through web, email, any other app and install through the NOOK HD or HD+ BN installer for .apk files. Watch what you install, if it gets put into /system or /system/app folder DREADED BOOT LOOP which resets everything! AMAZON MARKET WORKS!!!! and apps from there install fine to the BUILT IN MEMORY.
** Hopefully amazon market dont install stuff to the system/app folder and if it does hopefully you do not get the dreaded boot loops where you got to start this whole process over again so be forwarned!!! you will loose all data on NOOK HD and HD+ if u get stuck in the bootloops! BACKUP STUFF before messing with root and this kind of thing! DEVELOPMENT!
Aside from moving the actual apk to /system/app/ temporary (since you only do it once), putting a symbolic link there may work also without creating a reset loop. But can't you just side load the apk and run it in other folder?
someone0 said:
Aside from moving the actual apk to /system/app/ temporary (since you only do it once), putting a symbolic link there may work also without creating a reset loop. But can't you just side load the apk and run it in other folder?
Click to expand...
Click to collapse
when you sidelaod it OR install or have it installed to another folder or ran from another folder it cant modify the setting to allow non market apps to install!!
has to be in the /system/app folder THEN RAN from app drawer then you can set the setting uncheck and check box quit program and for now YOU HAVE to remove the .apk from the system/app folder and then you can reboot and the setting sticks! I GOT AMAZON MARKET INSTALLED right now installing apps! NOW WE GOT A KINDLE ladys and gentleman!
Amazon apk installs in internal memory. Apps downloaded from Amazon get installed in internal memory. You can then move them to SD card or leave them in internal memory. System apps are provided in the ROMs by the developers or vendors. ALWAYS back up before making system changes.. Now rooted - use Titanium Backup. System/app should be static throughout ROM lifecycle unless modified by user.
skyhawk21 said:
7. YOU CAN NOW SUCCESSFULLY DOWNLOAD .APK FILES through web, email, any other app and install through the NOOK HD or HD+ BN installer for .apk files. Watch what you install, if it gets put into /system or /system/app folder DREADED BOOT LOOP which resets everything! AMAZON MARKET WORKS!!!! and apps from there install fine to the BUILT IN MEMORY.
** Hopefully amazon market dont install stuff to the system/app folder and if it does hopefully you do not get the dreaded boot loops where you got to start this whole process over again so be forwarned!!! you will loose all data on NOOK HD and HD+ if u get stuck in the bootloops! BACKUP STUFF before messing with root and this kind of thing! DEVELOPMENT!
Click to expand...
Click to collapse
This is why I put the /system back to ro, at least that is what I think I did.
Amazon Store working on ROOTED Nook HD
Proof of Concept:
http://youtu.be/wCyd730L74Y
skyhawk21 said:
Proof of Concept:
http://youtu.be/wCyd730L74Y
Click to expand...
Click to collapse
LOL, your internet is slow. Could have cut the video time by 1/2 if not 2/3 if you switch to faster ISP.
skyhawk21 said:
Someone0 are you around can you pm me, Your root works, I installed nook color tools ver .02 in system/app folder
Click to expand...
Click to collapse
What exactly did you install? I cannot find "nook color tools" in Google Play or on APKTOP. Thanks for your hard work!
NEVERMIND! I found the thread that has the link for the app: http://forum.xda-developers.com/showthread.php?t=868366 Thanks again.
does this root method work on Nook HD+2.0.2?
if not how I can downgrade to 2.0.0?
Hey guys! This my first post on XDA, I'm a new member. I'm fluent with scripting and general OS. I hear often the phrase of a dirty flash, which I'm understanding to be flashing a new ROM without wiping the system first. I assume that may include not wiping the data partition as well. It's my understanding that is accomplished by editing the updater script within the ROM to be flashed. I understand that can easily be accomplished by unzipping file, making edits and then zipping back up. It's my understanding that can be accomplished without unzipping the entire ROM, by editing the contents in place using a PC and even with some native Android apps. relative to Android app that does one that does that extremely well, I'd appreciate that feedback is one point of this post. What I'm looking for is a way to zip the existing flash file into a new flashable ROM with a pre-built script that in essence calls the previous lines of the script and executes the code sequentially, while watching for the "delete" entries for partition like system or data and avoid executing those lines of code. My main purpose would be to avoid having to save two copies of a ROM on my sd card, one that wipes and one that doesn't, for purposes of space. Additional info. I'm currently using safestrap on a Samsung, I am not asking about aroma or a kitchen solution as they are not compatible but standard update.zip scripting type code. this seems easy with standard shell commands, but I must move out how that would relate back to the update.zip commands available. it may not be possible, and/or there may be a simpler solution I have not heard of otherwise. What is the standard practice for other people wanting to do a dirty flash on a ROM that they've downloaded that white partitions by default?
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!