Related
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
bowtieduece said:
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
Click to expand...
Click to collapse
Even though I didn't really think it would work, I gave it a shot anyway. Naturally, it was unsuccessful. The Eris take FOREVER to load that website, and it never triggers the shell script to ask for a reload, therefore permission is denied for the second part when you reboot with adb shell.
Interesting exploit, though. I wonder if there is some way to modify it for the Eris. Maybe you could contact the devs.
Really, nobody else is interested in this?
MyFixofAndroid said:
Yep that's what I expected. Yea there's gotta be someone here that can do the changes to the EVO files so they work with Eris, and upload the proper files to file sites and have us downloading in no time, so we can get root finally. Yes please anyone here up and willing
Click to expand...
Click to collapse
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
sickbox said:
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
Click to expand...
Click to collapse
Thanks for the tip. I sent him a PM. Will report back when I find something.
Anyone with an Eris can help out - rooted or unrooted.
I looked at those scripts last night - what seems like the necessary conditions for the beginning of the exploit (part1) are:
(1) there is a directory read/write/traversal permission security flaw in the data area for flash-lite;
(2) apparently, when flash-lite is running it must have root privilege at a moment when it performs a file "chmod" operation
So, an unprivileged user goes in, and makes a symlink (at the correct moment in time) in flash-lite's data area that points to a mtd partition - moments later, flash-lite "chmods" what it thinks is a file in it's data area, but instead, it is chmod'ing the target of a symlink - the normally protected mtd partition.
This allows use of flash_image to write whatever is wanted to that partition - even as an unprivileged user.
It should be easy enough for someone with Linux/Unix command line scripting experience to test to see if these conditions prevail on the Eris. You don't even need to be root - make your symlink point to something in /data/local if you are worried about something bad happening to a mtd partition. Chmod it initially to 600, and see if it get's changed by flash-lite when (and if) you drop the symlink into place.
I would do it, but I've got to go buy all the parts for ( & build) a new computer (no dev station as of last night ).
bftb0
bftb0 said:
Anyone with an Eris can help out - rooted or unrooted.
bftb0
Click to expand...
Click to collapse
Thank you for the detailed explanation. I'll have a look at the scripts, though it's more about learning new things for me, as this exceeds the current state of my unix knowledge. Hope others with more immediate knowledge of the subject will take a crack at it.
The shell script points to sharedobjects within /data/data/com.android.browser/flashlite, but sharedobjects, nor any folder for that matter, exists within that directory on the Eris. Is there a different place this could point; does the Eris have the same objects stored in a different location?
UPDATE: I'm searching my filesystem on my Eris right now to find it. I will report back later with results.
Also If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
MyFixofAndroid said:
Maybe the "sharedobjects" folder and other missing folders are really on the Eris, one of you should look for them. Use ASTRO or a different file manager and search most of the whole filesystem and see if you can find "sharedobjects" on your Erises.
In the meantime I'll try the same thing. Maybe there's a search engine for the file system of the Eris that you can get in the Android Market, that would do the trick. A file and/or folder search engine.
If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
Click to expand...
Click to collapse
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
I checked on my other Eris which is rooted. It seems that these may be the directories that we are looking for. However I don't find anything in an app-cache directory.
# find / -name *flashlite
find / -name *flashlite
/data/data/com.android.browser/flashlite
find: /proc/851: No such file or directory
# find / -name com.android.browser
find / -name com.android.browser
/data/data/com.android.browser
Well this appears to be the deal breaker then. Because non-root users of Eris cannot access /data as non-root, they cannot see anything in app-cache, and therefore cannot root yet, at least with this particular method unless there's another way to do it.
We should think of a way to still exploit Flash Lite on Eris, but use a different folder/folders in the Part? scripts that they point to for the operations of the script. This may be possible to do, however, still unlikely to work, and it is still going to be hard at this point.
But does anyone want to give my modified EVO method but for Eris a try? One of you should, so that we can root this thing and get it over with.
jimbonj said:
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
Click to expand...
Click to collapse
I dont think we would need read write permissions to begin with to use this root, if we had them to start we would be rooted
Because is he using a exploit in flash lite to write to a restricted folder, hes not just found a folder where the permissions aren't set correctly.
If flash lite can invoke admin access and we can exploit it there should be a way to root this.
I am going to the bar going to get some beers for my friends birthday, when I get home I am going to see if I can modify this into an eris root
Yeah JVWARD!
On your rooting effort, all the better, try modifying it for Eris and let all of us know if you succeed, hope you can, so we can get root too. Keep trying it with different changes until you get it to work.
Thanks.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
Click to expand...
Click to collapse
Yes sickbox, by all means, keep trying stuff, and finding that "flashlite" directory etc. till you get it to root. Hope your touchscreen returns to normal, and that you can create the directory that you mentioned in your previous post by using a flash site.
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
hey can someone with a rooted Eris using a an almost 100% stock Rom setup dump there file system and post it. Anyone using a highly customized Rom don't bother.
Sent from my Eris using Tapatalk
lostpilot28 said:
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
Click to expand...
Click to collapse
Link to the Evo instructions is in the OP. Currently working to see if it's possible on the Eris, so that's a no-go for now.
Stay tuned.
Team,
I've been working with the scripts with the awesome folks on IRC and have currently gotten thus far:
Part1 - http://pastebin.com/FUJWM3zW
Part2 - http://pastebin.com/6h07zrdm
I believe at this point I've screwed up my FlashLite plugin with my testing, so I'm going to try to recover that and keep moving along.
LR
Hey guys. I'm trying to push a libwebcore.so file from one .zip onto my current MyTouch phone that has CM 6 on it. The reason why I'm doing this is to have the Arabic browser support. This file causes the letters to be connected which they are in text messages, but not the browser. I heard pushing the libwebcore.so from a downloaded source (or from a rom .zip that has it from another rom) will do the trick.
However, everytime I try to push it to /system/lib it gives me an error saying that there is no room on the device. That's pretty unprobable since I'm sure I have a lot of space. How do I fix this and sucessfully push the file?
Shadowafs8 said:
Hey guys. I'm trying to push a libwebcore.so file from one .zip onto my current MyTouch phone that has CM 6 on it. The reason why I'm doing this is to have the Arabic browser support. This file causes the letters to be connected which they are in text messages, but not the browser. I heard pushing the libwebcore.so from a downloaded source (or from a rom .zip that has it from another rom) will do the trick.
However, everytime I try to push it to /system/lib it gives me an error saying that there is no room on the device. That's pretty unprobable since I'm sure I have a lot of space. How do I fix this and sucessfully push the file?
Click to expand...
Click to collapse
Do "adb shell df -h" to see how much room is available in your system partition. You may have to remove some unused system apps to make room.
I'm trying that now...but is it safe to delete the current libwebcore.so now and add the new one? If so what's the command. Also, if the libwebcore.so was for a testing version of CM 6 (specifically RC3), will it still work?
Also, is there a way to take some space from other parts of the system?
First of all, i'm going to move this to General since I fail to see how this is regarding the Development of anything. Some good information, but not related to Development.
Secondly, have you considered performing a nandroid backup, booting to recovery, mount the /system directory, then 'adb shell rm /system/lib/webcore.so' to remove your file then 'adb push webcore.so /system/lib'
Also, if you use the file directly from SOURCE it may not work since it may need to be compiled first. I'm not sure about that though since I've never tried it.
If any of the above goes wrong you can always nandroid restore and try again.
I personally use Clockwork Recovery since you can restore specific partitions individually (such as System) so it saves time.
Good luck.
I'm pretty much done trying...unless somebody can comply the file for me and test it. I'm really done trying this when all it does is fail over and over again. Hopefully somebody can come up with something
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.
I recently switched over to team win recovery from cwm. I do like the ui and functionality way better then cwm. The problem I'm having is that I cannot access my back up files from my PC via USB. When I use the file browser that is built into twrp I can see the back up files in the twrp folder. When I plug my tablet into my PC via USB and open the twrp folder it is empty. Also when I open the twrp folder in es file browser it is empty there too. I would like to store the back up on my PC rather then on my tablet. Am I missing something? I was having this same problem with titanium with backed up apps so I upgraded to the paid version and uploaded my back ups to Google drive. After that I looked in the titanium back up folder again on my PC and all the sudden the files were there when before they were not. Its very frustrating. Please help.
Sent from my Nexus 7 using Xparent Green Tapatalk 2
I had this same problem with TWRP when I started using it a couple of days ago. I'm not rooted, just unlocked and using fastboot to load the recovery image temporarily to do backups. And when I went looking for the backup files to move to my computer, I couldn't find them. It turns out to be a permissions issue, with TWRP creating the files/directories owned and visible only to root. Not a problem if backing up to a FAT formatted sdcard, but it is a problem with the Nexus 7 since it honors permissions and ownership of all files on the "sdcard".
Two fixes that I know of, though I have only used one so far:
1) After you do the backup, open up the psuedo terminal in TWRP and manually change the permissions or owner of the files recursively. Just set the starting directory in TWRP to "/sdcard/TWRP" and do "chown -R media_rw.media_rw BACKUPS" to change the owner, or do "chmod -R og+rw BACKUPS" to change the permissions. You really only have to do one of those, and I went with the owner change. I was then able to see the backup when connected to my computer, copy the files off, and then delete them to avoid taking up space on the tablet.
2) Although I haven't tried it yet, supposedly you can backup and restore directly to/from a USB thumb drive connected via OTG cable. This would be the easiest method for me, since I want backup and restore capability but without actually storing anything on the Nexus 7. I'm going to try it with a backup tomorrow, but I read about someone doing just that thing for the same reasons in a comment on reddit.
Hopefully that answers your question and gives you a way around it.
Just wanted to bump and let you know that the permissions issue seems to be properly resolved in the 2.2.1.5 version of TWRP. If you update then you shouldn't have to go through any crap to get at the backups.
Additionally, I tried doing a backup to a USB drive and it worked perfectly, so if you prefer that route it is definitely an option. Just make sure that you have the USB drive connected before you boot into TWRP, otherwise it doesn't notice the drive.
mtrs said:
I had this same problem with TWRP when I started using it a couple of days ago. I'm not rooted, just unlocked and using fastboot to load the recovery image temporarily to do backups. And when I went looking for the backup files to move to my computer, I couldn't find them. It turns out to be a permissions issue, with TWRP creating the files/directories owned and visible only to root. Not a problem if backing up to a FAT formatted sdcard, but it is a problem with the Nexus 7 since it honors permissions and ownership of all files on the "sdcard".
Two fixes that I know of, though I have only used one so far:
1) After you do the backup, open up the psuedo terminal in TWRP and manually change the permissions or owner of the files recursively. Just set the starting directory in TWRP to "/sdcard/TWRP" and do "chown -R media_rw.media_rw BACKUPS" to change the owner, or do "chmod -R og+rw BACKUPS" to change the permissions. You really only have to do one of those, and I went with the owner change. I was then able to see the backup when connected to my computer, copy the files off, and then delete them to avoid taking up space on the tablet.
2) Although I haven't tried it yet, supposedly you can backup and restore directly to/from a USB thumb drive connected via OTG cable. This would be the easiest method for me, since I want backup and restore capability but without actually storing anything on the Nexus 7. I'm going to try it with a backup tomorrow, but I read about someone doing just that thing for the same reasons in a comment on reddit.
Hopefully that answers your question and gives you a way around it.
Click to expand...
Click to collapse
Thank you for the tip. I went everywhere yesterday...
Best buy, radio shack, staples etc looking for an otg cable and had no luck. I'm going to order one online today. I will give the other techniques a try today though. I'm not familiar with pseudo terminal but I'm gonna dig in anyway. That's the best thing about these gadgets for me is hacking in and figuring out. Thanks again for your help!
mtrs said:
Just wanted to bump and let you know that the permissions issue seems to be properly resolved in the 2.2.1.5 version of TWRP. If you update then you shouldn't have to go through any crap to get at the backups.
Additionally, I tried doing a backup to a USB drive and it worked perfectly, so if you prefer that route it is definitely an option. Just make sure that you have the USB drive connected before you boot into TWRP, otherwise it doesn't notice the drive.
Click to expand...
Click to collapse
When I first started out with twrp I flashed 2.2.1.2 via adw. That was before I knew about the goo option in the play store. I've since upgraded to 2.2.1.5 and still having the same issue.
Sent from my Nexus 7 using Xparent Green Tapatalk 2
norcal61 said:
When I first started out with twrp I flashed 2.2.1.2 via adw. That was before I knew about the goo option in the play store. I've since upgraded to 2.2.1.5 and still having the same issue.
Click to expand...
Click to collapse
I think that it only works with newly created files. So your existing backups will still have the wrong permissions, but new ones will be correct.
It's the old permissions on directory structure that will mess you up though. If you delete the "/sdcard/TWRP/BACKUPS" directory through TWRP, you will lose your existing backups, but then the next backup that you do should recreate the full directory path with the correct permissions on all of the files and directories. After that you shouldn't have any trouble accessing the backups. I tested that on mine just to be sure that it worked and it did fine for me.
If you don't want to lose your existing backups then just do the owner/permissions change that I mentioned before and you will have access to the old backups as well as having the new ones created with the correct permissions from the start.
mtrs said:
I think that it only works with newly created files. So your existing backups will still have the wrong permissions, but new ones will be correct.
It's the old permissions on directory structure that will mess you up though. If you delete the "/sdcard/TWRP/BACKUPS" directory through TWRP, you will lose your existing backups, but then the next backup that you do should recreate the full directory path with the correct permissions on all of the files and directories. After that you shouldn't have any trouble accessing the backups. I tested that on mine just to be sure that it worked and it did fine for me.
If you don't want to lose your existing backups then just do the owner/permissions change that I mentioned before and you will have access to the old backups as well as having the new ones created with the correct permissions from the start.
Click to expand...
Click to collapse
Cool, that totally makes sense. Can't believe I didn't try that all ready. I will definitely make a new back up with the latest version of twrp. I'm running the same ROM and kernel as the back up that I currently have stored. Gonna give it a shot right now and let you know how it works.
Sent from my Nexus 7 using Xparent Green Tapatalk 2
mtrs said:
I think that it only works with newly created files. So your existing backups will still have the wrong permissions, but new ones will be correct.
It's the old permissions on directory structure that will mess you up though. If you delete the "/sdcard/TWRP/BACKUPS" directory through TWRP, you will lose your existing backups, but then the next backup that you do should recreate the full directory path with the correct permissions on all of the files and directories. After that you shouldn't have any trouble accessing the backups. I tested that on mine just to be sure that it worked and it did fine for me.
If you don't want to lose your existing backups then just do the owner/permissions change that I mentioned before and you will have access to the old backups as well as having the new ones created with the correct permissions from the start.
Click to expand...
Click to collapse
No luck. That's weird. I deleted the folder SD/twrp/backups containing the back up, did another back up and still not visible on my PC or in es file browser.
norcal61 said:
No luck. That's weird. I deleted the folder SD/twrp/backups containing the back up, did another back up and still not visible on my PC or in es file browser.
Click to expand...
Click to collapse
Hmm, you may have to delete "/sdcard/TWRP" as well, and just let it recreate everything. I might have changed the permissions on it already on mine, which is why it worked for me just deleting BACKUPS. I'll double-check that when I get back home and make sure.
mtrs said:
Hmm, you may have to delete "/sdcard/TWRP" as well, and just let it recreate everything. I might have changed the permissions on it already on mine, which is why it worked for me just deleting BACKUPS. I'll double-check that when I get back home and make sure.
Click to expand...
Click to collapse
It worked! I deleted the twrp folder all together and it worked like a charm. I'm now able to see and move the backups to my PC. Thank you very much for your help. It is greatly appreciated!
Sent from my Nexus 7 using Xparent Green Tapatalk 2
Some path is :
/data/media/TWRP/BACKUPS/
You need copy to /sdcard/TWRP/BACKUPS and connect to pc will see it.
trungdtdev said:
Some path is :
/data/media/TWRP/BACKUPS/
You need copy to /sdcard/TWRP/BACKUPS and connect to pc will see it.
Click to expand...
Click to collapse
I had the same issue and tried searching for "TWRP" to locate every instance of that folder. Turns out that I had previous backups in:
/mnt/shell/emulated/TWRP/BACKUPS/
I am happy to report that I was able to delete several past and hidden backups and recovered over 9gb of space!
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?