Database Develop

Block future updates?

So, anyone come up with a way to block the NC from receiving its firmware updates from B&N? I can see Barnes releasing a update and it just installs itself and wipes out the root we have. I'm sure they cant be happy about all the stuff we are now doing on the nook, but I'm sure they are especially not happy about us being able to install the Kindle app! In my mind, its the best of both worlds, but I'm sure B&N wouldnt see it that way. They could (for all practical purposes), put out a 1.0.1 update that blocked that app and kills our root.

The "default way" of disabling OTA updates on Android might work (make sure your device is not currently updating or something):
Code:
mount -o remount,rw /dev/block/mmcblk0p5 /system
cd /etc/security
mv otacerts.zip otacerts.zip_DISABLED_OTA_UPDATES
Although the key contained in that ZIP file does not look like it's really used (its name is testkey.x509.pem).

Edit: Please disregard my mindless ramblings below (I feel like the noob I am, now). I took a closer look at the code once my mind had emerged from whatever haze had been blocking my deeper thought processes and realized what needed to be done to get it to work (I learned a little more about ADB, which helps). And what's more, I think I did it the right way. *grin* Now, if we knew for sure this would block updates, we'd be set. I suppose we'll find out soon enough.
Thanks for posting the code, Weichel.
weichel said:
The "default way" of disabling OTA updates on Android might work (make sure your device is not currently updating or something):
Code:
mount -o remount,rw /dev/block/mmcblk0p5 /system
cd /etc/security
mv otacerts.zip otacerts.zip_DISABLED_OTA_UPDATES
Although the key contained in that ZIP file does not look like it's really used (its name is testkey.x509.pem).
Click to expand...
Click to collapse
Just to make sure I'm on the right track (noob here), I'd want to do an "adb shell" then run the script above? Also, read-write access for the NC system partition is probably necessary, yes? I haven't enabled rw access yet, didn't want to take any chances of accidentally bricking my NC.
I tried the code above (without going through to proceedure to enable read-write access to the system partition), but it didn't return any messages confirming success or failure.

just looked in that /etc folder and I see install-recovery.sh I wonder what that does.

xboxexpert said:
just looked in that /etc folder and I see install-recovery.sh I wonder what that does.
Click to expand...
Click to collapse
Overwrites corrupted/custom recovery with stock one on boot. At least, that's what it did on the OG Droid.

disregard. wrong post

big.t_03 said:
Edit: Please disregard my mindless ramblings below (I feel like the noob I am, now). I took a closer look at the code once my mind had emerged from whatever haze had been blocking my deeper thought processes and realized what needed to be done to get it to work (I learned a little more about ADB, which helps). And what's more, I think I did it the right way. *grin* Now, if we knew for sure this would block updates, we'd be set. I suppose we'll find out soon enough.
Thanks for posting the code, Weichel.
Just to make sure I'm on the right track (noob here), I'd want to do an "adb shell" then run the script above? Also, read-write access for the NC system partition is probably necessary, yes? I haven't enabled rw access yet, didn't want to take any chances of accidentally bricking my NC.
I tried the code above (without going through to proceedure to enable read-write access to the system partition), but it didn't return any messages confirming success or failure.
Click to expand...
Click to collapse
I don't understand the confusion here. You have a rooted Color Nook. Install Root Explorer and go to /system/etc and click the Mount R/W button and then long press the ocacerts.zip file and rename it. It's that easy.

[HOW TO] Recover from a soft brick caused by freezing needed apps or services.

I recently soft bricked my phone due to freezing a /system/app in Titanium Backup that was needed by the system. Here is how I fixed it.
Run shell root from superoneclick in Early USB Enumeration
Once it says you have shell root, run the following commands:
adb shell
mount -o rw,remount /dev/block/mmcblk0p12 /system
cd /system/app
busybox chmod -R 755 *
Make sure you put the space then the star character (*) after 755, that tells the system to set the permissions of all the files/apps, in the /system/app directory.
Lastly, run the command:
adb reboot
Your phone should reboot and be back up and running.

what did you freeze so we don't make the same mistake?

Hey, amwbt, could I post a link to this thread in mine (the TiBU Freeze thread)?
I'm sure it would make things a lot easier for people if things go wrong when they're freezing stuff.
Oh, and I'd of course give you due credit.

xyrovice said:
Hey, amwbt, could I post a link to this thread in mine (the TiBU Freeze thread)?
I'm sure it would make things a lot easier for people if things go wrong when they're freezing stuff.
Oh, and I'd of course give you due credit.
Click to expand...
Click to collapse
Of course!
Sent from my MB860 using XDA App

franciscojavierleon said:
what did you freeze so we don't make the same mistake?
Click to expand...
Click to collapse
Unfortunately, I don't remember which ones they were. Once I got my phone back up I immediately unfroze everything that was not in the recommended apps to freeze list in the OP [HOW TO] Deal with Boat Safely & Properly {Freeze Method/ROOT} | BIGGER LIST(S)! 3/1
Sent from my MB860 using XDA App

Hello, thanks for posting this info! I asked a question in the atrix q&a area but perhaps it's best answered here.
My phone also got screwed up because of freezing something I shouldn't have.
How do I run super one click in early USB enumeration? I'm unfamiliar with super one click - on past phones I used other rooting methods, and I used aRoot and root v2 for the atrix.
My phone crashes during bootup when the moto logo begins the red dot animation - I don't know how to get super one click to recognize it at all, presumably because it's frozen.

Please note that this will NOT work on 1.57.

[SCRIPT] Root for 4.1.57 (Depreciated, use newer version)

HTML:
The new update blocks the current ways of attaining root for the device. However, if you have root before you update, it is possible to retain this during the upgrade.
Script is online!
A newer version is available here:
http://forum.xda-developers.com/showthread.php?p=12540398#post12540398

Yeah... I'll just wait for you
Thanks for this! been holding out on the update ever since I found out you lose root during the beta testings

if this works i guess it's time to get my desktop back up and running so i can flash back and use this. damn power supplies dying on me.

ill wait for ur auto script
will this b possible btw neone?
Flash the 1.5.7 sbf -> run gblur custom rom -> run the root scrip

No Gingerblur needs root to push its files, also if you need a host I can host

Scripts are online!
Run beforeupdate.bat, update, then run afterupdate.bat.

Haven't tried it yet but wanted to say thanks and great work!

--EDIT -- BELIEVE THIS IS FIXED--
you didn't package the bin folder with psneuter.. :X

In reference to "adb.exe push movesu.sh /data/local/tmp > NUL 2>&1"
movesu.sh is now backup.sh, yes?
Also busybox "mv /system/xbin/su /system/bin/frozenfish" clobbers the copy from system/bin, if there is a difference, i thought it was generally a symlink to /system/bin.
Other than that, good idea in renaming the binary file, I probably won't use frozenfish in case Motorola targets that now..

Sounds sweet! If I already updated can I flash back to old then re root? Then run script then update?
Sent from my MB860 using XDA App
Update: Yes You Can ! just finished..

Whoops - I based it from adeo without making the proper changes. Corrected one should be live in a few minutes.

all good take your time..
so far the only corrections were the movesu.sh in beforeupdate.bat
and the missing /bin folder :X .. well technically you just need psneuter in there.. and just change the /bin/psneuter.. to /psneuter saves you time lol

The new version is up. It depends on su being installed on the system. You'll also need to OK a request by Superuser for root before it will run on beforeupdate.bat.

curious as the previous workaround used webtop to retain root through LXterminal... with root on here, will we be able to re-apply the Webtop mod?
by the way, good work

"movesu.sh" is called but doesn't exist.

shawnbuck said:
The new version is up. It depends on su being installed on the system. You'll also need to OK a request by Superuser for root before it will run on beforeupdate.bat.
Click to expand...
Click to collapse
Do you have the su that does not require Superuser.apk installed?

Let me boot into my windows partition and I'll give it a try. Let me make sure I have the steps right:
Run beforeupdate.bat
Get OTA from system update
Run afterupdate.bat
Anything I'm missing? I'm rooted using aRoot fyi.

I think
adb.exe push movesu.sh /data/local/tmp > NUL 2>&1
is a typo and it should say backupsu

dLo GSR said:
curious as the previous workaround used webtop to retain root through LXterminal... with root on here, will we be able to re-apply the Webtop mod?
by the way, good work
Click to expand...
Click to collapse
Root here is a normal root, anything you could do before you'll be able to continue doing.
eval- said:
I think
adb.exe push movesu.sh /data/local/tmp > NUL 2>&1
is a typo and it should say backupsu
Click to expand...
Click to collapse
Thats right - I corrected that and added a new version.
OrangesOfCourse said:
Let me boot into my windows partition and I'll give it a try. Let me make sure I have the steps right:
Run beforeupdate.bat
Get OTA from system update
Run afterupdate.bat
Anything I'm missing? I'm rooted using aRoot fyi.
Click to expand...
Click to collapse
Exactly right. I'll clarify the directions in the OP.
lpsi2000 said:
Do you have the su that does not require Superuser.apk installed?
Click to expand...
Click to collapse
This doesn't come bundled with a copy of su, it uses the one already installed in the system.

will this work on flash sbf?

Manually Root w/ Zerg after 893 OTA

I claim no credit for this but after the 893 OTA you wont have root and you will have to go this way to get it back.
Original post I robbed this from [HERE]
You will need adb to do this. You can get the download here depending on your operating system. ADB
Download the follow file: it contains the exploit, su, Superuser
Download exploit -->Exploit.zip
1) Unzip contents of folder to your Desktop
2) open a command terminal and navigate to the folder (cd Desktop/Exploit)
3) type the following commands
---> adb push zerg /data/local
---> adb push su /data/local
---> adb push Superuser.apk /data/local
---> adb shell
---> cd /data/local
---> chmod 777 zerg
---> ./zerg
4) Wait for the root to be gained
5) type the following commands
---> adb shell (only type this if you are no longer in [email protected])
---> mount -o rw,remount /dev/null /system
---> cat /data/local/su > /system/bin/su
---> cat /data/local/Superuser.apk > /system/app/Superuser.apk
---> chmod 4755 /system/bin/su
---> chmod 4755 /system/app/Superuser.apk
---> reboot
This is from P3Droid.
Click to expand...
Click to collapse

Worked like a charm. Thanks!

want to do this for my brother, you just connect the phone to the computer with usb debugging mode enabled right?

Fyi if you correctly root and forever root prior to the ota you will retain root. The update does not remove root if it was forever rooted.
Sent from my DROID BIONIC using XDA App

I used this method on a used Bionic I bought that has 5.7.893. It worked perfectly.

Why do you guys make it so difficult? All you need to do is use R3L3AS3DRoot to restore, root, and forever root your Bionic. And, POW! You will have a rooted Bionic once again, without D/L unnecessary software and typing commands. Props to DHacker.

charlie310 said:
Why do you guys make it so difficult? All you need to do is use R3L3AS3DRoot to restore, root, and forever root your Bionic. And, POW! You will have a rooted Bionic once again, without D/L unnecessary software and typing commands. Props to DHacker.
Click to expand...
Click to collapse
Because R3L3AS3DRoot restores a 886 system and not an 893 system, which is the reason you would "D/L unnecessary software."
So, sure you'll be rooted with an 886 system which isn't current.

you forgot last step....then update and youll still have forever root

I restored and forever rooted my bionic, then did OTA, and still have root. I was on rooted stock previously, but restored because I wasn't able to get or pull the OTA update due to "error try again later".
Sent from my DROID BIONIC using Tapatalk

Terror_1 said:
Because R3L3AS3DRoot restores a 886 system and not an 893 system, which is the reason you would "D/L unnecessary software."
So, sure you'll be rooted with an 886 system which isn't current.
Click to expand...
Click to collapse
Let's think about this logically:
D/L and unzip R3L3AS3DRoot and use 3 clicks to restore/forever root your phone, then D/L the update using a 3 clicks.
Or, D/L and install ADB, D/L and install Java SE, and D/L & unzip the Exploit Zip and type in 15 command lines to root your phone.
It's pretty obvious what is considered easier and requires less unnecessary software.
BTW, if you are flashing a ROM, then option 1 is always the best way to go since you don't have to D/L the OTA update since most ROMs have the update built in (and you already have the updated radio).

getting replacement bionic for radio issues tomorrow hopefully. will i have to use this most likely or will it unrootable? any info would be great thanks!

charlie310 said:
D/L and unzip R3L3AS3DRoot and use 3 clicks to restore/forever root your phone, then D/L the update using a 3 clicks.
It's pretty obvious what is considered easier and requires less unnecessary software.
Click to expand...
Click to collapse
You forget that some of us already have all the prerequisites. I personally can't say if your method works or not. It failed several times for me, so I gave up and zerg worked.
luke1333 said:
getting replacement bionic for radio issues tomorrow hopefully. will i have to use this most likely or will it unrootable? any info would be great thanks!
Click to expand...
Click to collapse
I am partial to doing things manually myself but I guess 43v3r does it too.
I personally had no luck with it.
Sent from my DROID BIONIC using XDA App

what version could you not root?

Does zerg work on 5.9.901 ?

luke1333 said:
what version could you not root?
Click to expand...
Click to collapse
893 43v3r doesn't work on, if you restore the 886 then root you should be fine. Just doing the update then trying to gain root isn't going to work.
kris7778 said:
Does zerg work on 5.9.901 ?
Click to expand...
Click to collapse
I don't know for sure but I am pretty confident that it would.

THANKS!
Flawless victory!
Binarality!

Has anyone rooted a previously unrooted device running version 5.9.901? Who's process?

This method worked for me, but I notice that my 3g service was weak and my 4g was gone. Even if i restarted the phone I couldn't get my 4g to work. This was after the 4g issue with VW braking it. Has anyone else had this problem?

1 click method
is there any 1 click method out there that can be used to do this ,,i used 4ever root a couple of time to restore my phone after screwing it up .. but now even that wont work .. so yeah i have the update but no root ...no matter how i try to do it before or after ..
and i unfortunately do not know how to connect to adb to push anything to my phone .. im not that technical with it ....dont have a clue .ive tried but not easy for me that is thanking you in advance Robb

One question, if I update and then for any reason I can't get root can I go back to stock rom you know the one before ota and start over? ???
Sorry for my english lol
Sent from my DROID BIONIC using XDA App

S-off with Firewater

Another S-Off script that was sent to me by coremark. Successfully s-off my device and supercid.
http://firewater-soff.com/
Thanks to @coremark.

After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?

edorner said:
After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?
Click to expand...
Click to collapse
I'm afraid you'll need a custom recovery for this. The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this. To work around it, you'd need a custom kernel (which is not feasible at the moment since HTC haven't released the full source tree yet, unfortunately) or the wp-mod hack (which I would be afraid of using, to be honest).
Also, why avoid custom recovery when you're already S-OFF and you can flash the stock recovey anytime?

koniiiik said:
The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this.
Click to expand...
Click to collapse
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?

edorner said:
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Click to expand...
Click to collapse
To be honest, no idea. All I do know is that on my phone the write protection works the way it does and I don't really see a feasible way around it. Also, I haven't tried these exact steps. It's possible that adb remount does some extra work or something. Moreover, I'm not sure about the adb shell chmod ... command – that would require root, wouldn't it? But since I haven't tried it, I can only guess.
If you don't mind trying it, I'd be interested in the results.
edorner said:
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?
Click to expand...
Click to collapse
The way I understand wp_mod works is that it monkey-patches the running kernel's filesystem driver to skip the check for the /system partition. In other words, it rewrites the code of the running kernel in-memory. This by itself is reason enough to be extremely careful around such code as it has potential for a major disaster. Missing the right memory location by any nonzero number of bytes can result in the kernel doing practically anything (most likely a crash).
Now, to make matters worse, these seem to be only a few binary versions of the kernel module and people seem to just take a binary compiled for one kernel, modify the version information within the file to make it match other kernels and load it on a completely different kernel. This, to me, is borderline insane, considering that the kernel binaries depend on the version of the kernel, used compiler and even compiler flags used when building.
Again, though, I haven't actually looked at the module's source code; can't say I'm suffering from a surplus of free time and I'm also not *that* interested in it. Most likely it's written in a robust enough way to have a high chance of success. (This seems to be backed up by anecdotal evidence – the thing appears to work for people, which is a small wonder for me.) All of the above is actually just my interpretation of stuff I read in some threads here on XDA-developers and I haven't even tried to confirm it myself.
Still, for me, using the recovery for any such changes is a sufficient and acceptable workaround, since I don't need to modify /system that often.

Wow! Thanks for the exhaustive expanation about WP-mod!
If you don't mind trying it, I'd be interested in the results.
Click to expand...
Click to collapse
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.

edorner said:
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.
Click to expand...
Click to collapse
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.

koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
Ah, I see. In that case I will definitely try it!
Truth is I am still an Android noob, I used ADB maybe on two occasions so far, and did not have the time yet to properly check out the documentation for these particular commands.
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?

edorner said:
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?
Click to expand...
Click to collapse
No idea, I haven't used firewater, but my guess would be that it won't wipe anything…
As for backing up /data/preload, you can for example use temproot to get access to the directory, copy it somewhere on your sdcard and adb pull it. In case it gets wiped, you can just push it back again and voilà. It's going to require some shell-fu, however.
Alternately, you can just download my ZIP of the latest stock ROM and extract it, it contains the latest /data/preload.
And yes, just copying the APK files into /data/preload should suffice *– Dalvik and its package manager is intelligent enough to detect something has changed in there and perform any installation steps necessary. If it doesn't work right away, a reboot should fix things.

Edorner. It won't wipe. I tried it already.
Sent from my GT-I9305 using XDA Premium 4 mobile app

koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.

edorner said:
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.
Click to expand...
Click to collapse
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.

koniiiik said:
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.
Click to expand...
Click to collapse
Thanks
Hm... Strange...
Instead of manually remounting /system as "ro", I simply rebooted the device. (What can I say, I am hopelessly lazy ) After the reboot I checked the permissions of /system by issuing the "mount" command without any parameters. It showed that it was remounted using the original settings:
Code:
/dev/block/mmcblk0p38 /system ext4 ro,noatime,data=ordered 0 0
So in theory, rebooting instead of manually remounting as "ro" should not make any difference. But who knows
After the reboot, I checked the changes I made to /system previously, and fortunately they did not disappear. (su was still there, I could successfully copy it, and execute it.)
Since then, I've performed a couple more reboots and at least one full shutdown-startup cycle as well. And I still have not lost any changes.
Please let me know if you find something out! I am very interested.