Database Users

Rooting and OTA updates

I am looking into rooting my Nexus S so I can install an ICS ROM. This is my first time rooting so got a question.
How will OTA updates work for me? Will the ICS update just work or will I have to in root to get the official OTA update?
Sry if this has been asked before couldn't find a clear answer.
Sent from my Nexus S using XDA App

Don't do OTAs. Any update released by Google or your manufacturer will be released here, rooted, within hours.
If you take an OTA you will lose root and could even find your phone locked again (as unlikely as that is with the NS, better safe than sorry. Ask the EVO users who took the GB OTA )
Sent from my Nexus S 4G using Tapatalk

Rooting requires flashing custom recovery
OTA requires stock recovery to work properly
So if your phone has custom recovery the OTA will not work.

Alright, thanks alot for the quick responses guys.
Sent from my Nexus S using XDA App

Once the ota is downloaded.....
* Put the zip on sdcard
* Reboot into custom recovery
* Manually flash it
* Directly after that, in the same recovery session, flash latest superuser zip
* Wipe cache
* Reboot

I run stock, so i'll add my two cents into this conversations. A few key points:
OTA's will NOT lock the boot loader
OTA's will work with CWM installed (The OTA will however remove CWM and needs to be manually applied)
OTA's will remove root access (the permissions on the binary get changed)
I have never seen an OTA on XDA that was pre-rooted. i have seen ROM packages that incorporate the OTA that are pre-rooted (installing these usually means a wipe of the device is needed)
if you replace the ROM on the phone, you will not get OTA updated. you must remain mostly stock to obtain them.
Custom kernels or custom google apps on stock roms will cause the OTA update to fail, however you will notified that the update is available.
I hope this answers your questions.

Good points.
What i do in order to maintain the full software (removing system apps, any system changes) is change the permissions of whatever i dont want to "000"
This will allow the verifying of OTA to flash.

snandlal said:
Good points.
What i do in order to maintain the full software (removing system apps, any system changes) is change the permissions of whatever i dont want to "000"
This will allow the verifying of OTA to flash.
Click to expand...
Click to collapse
This does not always work, such as installing the "Black" version of gmail over top the original, the world-wide version of navigation or using market enabler to change the prop.build file. any of these changes will cause the OTA signature to fail.
Though if you are simply removing a system app, then yes, that would work well.
Also to be noted and this just occurred to me, if the OTA is a full ROM version, then the signature won't matter and it will just install. For ICS, this is what i'm expecting.

I'm on the fence about rooting. I know there are advantages like custom ROMs and added features, but I'm somewhat of a newb at this. While the instructions (for the Mac) seem simple enough, I always feel like something inevitably goes wrong or there's some variable I've either overlooked or don't understand that screws things up.
I definitely don't want to brick my phone.
I don't even know what I'm asking in my post, but I guess... what are some advantages of rooting? And if I root, is it fully reversible?
I'm also confused by some of the terminology. What is clockwork recovery? Is that a sort of ROM? I keep seeing that phrase every time I read instructions. Likewise, what's a bootloader? What's fastboot? Also, what's a kernel?
And after I root (as you can see, I am really tempted to), what happens next? How do I choose which ROM works for me? Is it a matter of flashing them and trying each of them out?
I'm afraid of entering the world of root, but I want to. Advice? Does it matter what baseband, or kernel or build number I have?
I'm on Android 2.3.6

Matridom said:
I run stock, so i'll add my two cents into this conversations. A few key points:
OTA's will NOT lock the boot loader
I hope this answers your questions.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1145056
I know it's not likely, particularly with this phone, but it can happen. I maintain that if you're going to go through the process of unlocking your phone and putting a rooted ROM on it that you might as well wait for a modified OTA ROM to get posted by a trusted dev before just installing what the carrier hands out to you.
I guess maybe I should have said "re-lock"?

onthecouchagain said:
I'm on the fence about rooting. I know there are advantages like custom ROMs and added features, but I'm somewhat of a newb at this. While the instructions (for the Mac) seem simple enough, I always feel like something inevitably goes wrong or there's some variable I've either overlooked or don't understand that screws things up.
I definitely don't want to brick my phone.
I don't even know what I'm asking in my post, but I guess... what are some advantages of rooting? And if I root, is it fully reversible?
I'm also confused by some of the terminology. What is clockwork recovery? Is that a sort of ROM? I keep seeing that phrase every time I read instructions. Likewise, what's a bootloader? What's fastboot? Also, what's a kernel?
And after I root (as you can see, I am really tempted to), what happens next? How do I choose which ROM works for me? Is it a matter of flashing them and trying each of them out?
I'm afraid of entering the world of root, but I want to. Advice? Does it matter what baseband, or kernel or build number I have?
I'm on Android 2.3.6
Click to expand...
Click to collapse
OK, let's clear a few things up here.
CWM or ClockWorkMod is a custom recover that can be installed on the phones. This step is needed because the default recovery on the nexus does not allow for updates to be installed that are unsigned. CWM does, so it's a necessary step to installing the SU binary (aka root your phone) or installing custom ROMs
The bootloader is the basic system on your phone that reacts to the power on and hands over operations to Android. The equivalent in the PC world would be a BIOS.
fastboot is a utility that is provided by google that allows you to send commands to the bootloader and direct it's operations. It's needed to unlock the bootloader (so you can replace parts of it.. like recovery with CWM)
Interestingly enough, you can boot your phone to a custom recovery WITHOUT replacing your existing stock recovery by using fastboot.
Rooting your phone is simply installing and providing the proper rights to the SU binary to allow you to have full administrative rights to the phone, the superuser application is almost always bundled with it as it allows for a form of control as to what applications can use root access. Rooting your phone allows you to install some very interesting application, most popular are titanium backup (let's you back up app data and restore them after a reset) and removing advertising (adfree/adaway or it's like) Root can also be used by some applications that allow you to "cheat" at games.
rooting your phone is reversable, though not always the easiest to do. With the stock ROMS, it's fairly easy, you just re-apply the latest OTA and it will kill Root access on your device.
When it comes to custom ROMs the vast majority come pre-rooted to save you the hassel of doing it yourself.
On other phones where the bootloader remains locked, you have to use an exploit to gain root access, this then allows you to modify the OS and install custom roms and CWM while keeping the bootloader locked. Since the Nexus line can be unlocked, it's not needed.
Please note, root access is NOT required to install a custom ROM.
---------- Post added at 02:02 PM ---------- Previous post was at 01:56 PM ----------
MaxCarnage said:
http://forum.xda-developers.com/showthread.php?t=1145056
I know it's not likely, particularly with this phone, but it can happen. I maintain that if you're going to go through the process of unlocking your phone and putting a rooted ROM on it that you might as well wait for a modified OTA ROM to get posted by a trusted dev before just installing what the carrier hands out to you.
I guess maybe I should have said "re-lock"?
Click to expand...
Click to collapse
That's a link to a non-nexus phone. The question here is in regards to the nexus device and i believe my statement stands 100% true. Since it's a self proclaimed "newby" asking questions, i don't want to confuse the post with un-needed and non-relevant information.

Matridom, wow thanks. That clarifies a few things.
So, you say root access isn't required to flash custom ROMs? Let's say for example, I want to flash an ICS ROM, or even a ROM that allows me to have Backlight Notifications?
I don't need root? If I don't need root, how do I flash those ROMs?

Matridom said:
That's a link to a non-nexus phone. The question here is in regards to the nexus device and i believe my statement stands 100% true. Since it's a self proclaimed "newby" asking questions, i don't want to confuse the post with un-needed and non-relevant information.
Click to expand...
Click to collapse
I'm not sure why it's so invalid to advise that he wait for someone to post an OTA that has been vetted for those of us who have unlocked our phones; I respect your opinion (even if you clearly don't mine), but your statement that I am providing "un-needed" and "non-relevant" information is a bit harsh.
The fact of the matter is that Sprint has had at least one OTA released (for the EVO 4G) that re-locked bootloaders and caused a lot of consternation for people who took the OTA on their unlocked phones and found themselves waiting months for a new exploit to be found. Those who waited had a rooted version of the OTA available on the forums very quickly, so if those who took the OTA had just waited they wouldn't have been stuck.
tl;dr: If you went to the trouble of unlocking your phone in the first place I don't see why you would rush to take an un-vetted update OTA.

MaxCarnage said:
I'm not sure why it's so invalid to advise that he wait for someone to post an OTA that has been vetted for those of us who have unlocked our phones; I respect your opinion (even if you clearly don't mine), but your statement that I am providing "un-needed" and "non-relevant" information is a bit harsh.
The fact of the matter is that Sprint has had at least one OTA released (for the EVO 4G) that re-locked bootloaders and caused a lot of consternation for people who took the OTA on their unlocked phones and found themselves waiting months for a new exploit to be found. Those who waited had a rooted version of the OTA available on the forums very quickly, so if those who took the OTA had just waited they wouldn't have been stuck.
tl;dr: If you went to the trouble of unlocking your phone in the first place I don't see why you would rush to take an un-vetted update OTA.
Click to expand...
Click to collapse
The key here is that SPRINT released an OTA for a SPRINT branded device. This has zero relevance to updates provided by Google for Nexus devices.

MaxCarnage said:
I'm not sure why it's so invalid to advise that he wait for someone to post an OTA that has been vetted for those of us who have unlocked our phones; I respect your opinion (even if you clearly don't mine), but your statement that I am providing "un-needed" and "non-relevant" information is a bit harsh.
The fact of the matter is that Sprint has had at least OTA released (for the EVO 4G) that re-locked bootloaders and caused a lot of consternation for people who took the OTA on their unlocked phones and found themselves waiting months for a new exploit to be found. Those who waited had a rooted version of the OTA available on the forums very quickly, so if those who took the OTA had just waited they wouldn't have been stuck.
tl;dr: If you went to the trouble of unlocking your phone in the first place I don't see why you would rush to take an un-vetted update OTA.
Click to expand...
Click to collapse
The issue at heart here is that fact that the OTA for the nexus line of phones comes straight from google and are not "tweaked" in any way by the carriers. (exception nexus 4g has additional applications required for CDMA support)
One of the selling features of the nexus phones is the fact that unlocking the bootloader is officially supported.
In regards to other phones getting their bootloader locked, I've experienced first hand the pains of that, having a galaxy S and the 2.3 installing a new bootloader and really screwing things up for me. In those cases, i agree with you whole heartily and to wait for pre-cracked roms that can be installed.
My question to you would be to please show an example of a nexus S getting it's booloader locked due to an OTA update as that is the phone we are discussing.
---------- Post added at 02:49 PM ---------- Previous post was at 02:47 PM ----------
onthecouchagain said:
Matridom, wow thanks. That clarifies a few things.
So, you say root access isn't required to flash custom ROMs? Let's say for example, I want to flash an ICS ROM, or even a ROM that allows me to have Backlight Notifications?
I don't need root? If I don't need root, how do I flash those ROMs?
Click to expand...
Click to collapse
All you would need to do is to unlock the bootloader, install CWM, then apply the .zip associated with the ROM you wish to install. I would however carefully read the installation instructions for the rom as in some cases, it might be a multi-step process (such as going from a 2.2 rom to a 2.3).
Many ROMS also do not come with the google apps and secondary zip file needs to be applied to get those running (cyanogenMod does this)
I wanted to add, that the process of unlocking your bootloader will erase EVERYTHING on the phone, including the SDcard partition. So make sure you back up anything of importance.

Matridom said:
My question to you would be to please show an example of a nexus S getting it's booloader locked due to an OTA update as that is the phone we are discussing.
Click to expand...
Click to collapse
I can't provide an example because, as I have already stated, this was a precautionary suggestion only.
I'm not going to get into a debate with you over this; I've made my point and you've made yours. Thanks.

Matridom said:
This does not always work, such as installing the "Black" version of gmail over top the original, the world-wide version of navigation or using market enabler to change the prop.build file. any of these changes will cause the OTA signature to fail.
Though if you are simply removing a system app, then yes, that would work well.
Also to be noted and this just occurred to me, if the OTA is a full ROM version, then the signature won't matter and it will just install. For ICS, this is what i'm expecting.
Click to expand...
Click to collapse
Good point again but the trick is to put your apps in /system/framework
Along with framework-res.apk.
This will add a dex file to /data/dalvik-cache, which is needed for saving upon reboot

Does flashing another radio that's different from your original radio impact the ability to apply an OTA?

suksit said:
Rooting requires flashing custom recovery
OTA requires stock recovery to work properly
So if your phone has custom recovery the OTA will not work.
Click to expand...
Click to collapse
Rooting doesn't require flashing custom recovery.

iboj007 said:
Does flashing another radio that's different from your original radio impact the ability to apply an OTA?
Click to expand...
Click to collapse
No. It doesnt

[Q] Unlock bootloader, still get updates?

Does having my bootloader unlocked affect getting updates? I have no interest in installing custom roms(for now), and mainly just want root to block ads, install seeder to fix this damn lag, and possibly connect a ps3 controller to play games. Figured I'd just unlock and root. I didn't plan on installing cwm so I could still get updates straight from google. I know an update would just overwrite root, but not sure if the bootloader would affect it. My galaxy nexus I always installed custom roms so I don't know how the bootloader affected OTA's. thanks guys.

In principle it should not affect updates.
Have a look at a prior OTA update's installer script
./META-INF/com/Google/android/updater-script
The OTAs perform binary patching on individual files, one by one. (That is why OTAs can be so small.) Before they perform the patching, a checksum is performed on every file on the tab/phone targeted for patching. If even one of those checksums fail, the entire install is aborted.
In addition the version of the recovery is sometimes checked, too - so merely having a custom recovery can trip up an OTA if that type of assert() check is performed.
To put that in general terms, you could say that an OTA update will almost always succeed if you merely add things to a ROM and leave the stock recovery in place.
If you want to flash stuff without altering the stock recovery just use a soft boot of a custom recovery, e.g. "fastboot boot custom-recovery-image-file.img"
If an OTA fails, don't get scared - you can simply unpack it, modify the updater-script file to remove the failing assert(), re-zip it and flash it. This would need to be done with a custom recovery, though as the modified OTA would no longer be correctly signed.
HTH

Yes but don't remove any of the Google apps that come preinstalled, don't edit the build prop, and that might be it.
Sent from my Nexus 7 using Tapatalk 2

BrianDigital said:
Yes but don't remove any of the Google apps that come preinstalled, don't edit the build prop, and that might be it.
Click to expand...
Click to collapse
yep.
The most recent OTA had the boot image file as one of its patching targets, so it was also subject to checksum verification during the initial assert() sequence of "updater-script".
I guess that means that if you hook anything into the boot sequence that needs to be in the ramdisk, that will trip up the OTA, as it is pretty typical for OTA updates to diddle the kernel or ramdisk. I guess that if you want to stay on a near-factory base distro including new ota updates, that puts the onus on you to either
(a) check the installers of the stuff you flash to make sure the boot image is not being re-packed -or-
(b) maintain a chain of pure stock backup sequences: then you can then restore them, run the OTA patch kit on them, make a new nandroid backup, and re-run your custom flashes. Probably use TiB to restore your apps on top of that, too. Almost like an OS re-install sequence, frankly.
cheers

thanks guys! Does an update from google relock the bootloader? I'm guessing not since its a nexus and they're okay with us unlocking it but just wondering. Just trying to decide if its worth it. I feel myself using my nexus 7 less cause of the latest update. It's smooth once its running but turning the screen on after its been sitting, it take some time to get together.

tu3218 said:
thanks guys! Does an update from google relock the bootloader? I'm guessing not since its a nexus and they're okay with us unlocking it but just wondering. Just trying to decide if its worth it. I feel myself using my nexus 7 less cause of the latest update. It's smooth once its running but turning the screen on after its been sitting, it take some time to get together.
Click to expand...
Click to collapse
Whoops (old timers disease) I said "bootloader" in that post above where I should have said "boot partition" or "boot image". (Now corrected.)
Updates typically don't touch the bootloaders. Interesting question though - if you replace a bootloader via fastboot, does it change the lock status? To that Q I don't know the answer from direct experience.
Maybe I'll give it a try. Ugh that's gonna be a lot of backup/restore ops.
In the meantime, have you seen a page with links to (older) *full* ROM install bundles that Google no longer has on their site? I only got a N7 in early Jan '13, so I don't have any of those older full-ROM+bootloader fastboot-based install bundles.

bftb0 said:
Whoops (old timers disease) I said "bootloader" in that post above where I should have said "boot partition" or "boot image". (Now corrected.)
Updates typically don't touch the bootloaders. Interesting question though - if you replace a bootloader via fastboot, does it change the lock status? To that Q I don't know the answer from direct experience.
Maybe I'll give it a try. Ugh that's gonna be a lot of backup/restore ops.
In the meantime, have you seen a page with links to (older) *full* ROM install bundles that Google no longer has on their site? I only got a N7 in early Jan '13, so I don't have any of those older full-ROM+bootloader fastboot-based install bundles.
Click to expand...
Click to collapse
Nah I haven't seen that. To be honest I've been so busy with flashing roms on my sgs3. I finally have settled down on a rom for my phone so I figured I'd give my nexus 7 a go. But I'd rather not be performing the whole backing up/flashing/modding on both. Its so much lol Plus my tablet I need to be dependable when I need it. That's why I hadn't planned on running roms, just basic root for blocking ads, etc. Before the last update this thing was so fast and enjoyable to use. It still is but its not to where it use to be. I was going to go back but I don't like knowing I'm not on the latest.

and mainly just want root to block ads, install seeder to fix this damn lag, and possibly connect a ps3 controller to play games.
Click to expand...
Click to collapse
Seeder doesn't fix lag. Doesn't work. If your n7 is lagging then there is another cause.
Sent from my Nexus 7 using Tapatalk HD

A way to find OTA filename for those who already installed any OTA and are rooted

There is a procedure to fool OTA system in order to make it receive the OTA again. So you have a second chance to grab the filename and make a lot of people here happy
Update: Thanks to @Sleeepy2 we know this method works in the nexus 6 :good:
DISCLAIMER: It's an unharmed procedure, but be warned, you will change build.prop so anything (bad) should happen if you do it incorrectly, most probably a bootloop. If you have doubts, don't do it.
Needs to be rooted.
So if there is a brave enought one, the procedure is just to change two values of the /system/build.prop file to make it looks a previous android version for the OTA system.
For instance, If you have received to OTA to LMY47M your build.prop file will have these values:
ro.build.date.utc=1425686543
and
ro.build.fingerprint=google/shamu/shamu:5.1/LMY47M/1774234:user/release-keys
If you change these lines by the equivalent lines from another version of android, the OTA system will check the OTA availability with the other android version. So, If before receiving the OTA your android version was 5.0.1 LRX22C you can change both lines with:
ro.build.date.utc=1416527965
and
ro.build.fingerprint=google/shamu/shamu:5.0.1/LRX22C/1602158:user/release-keys
That are the LRX22C version lines.
Save build.prop file and reboot your nexus 6.
Once rebooted check for OTA updates (It will be checked as LMY47D) and download it, if it's not downloading yet (don't apply the OTA, just download it).
While it's downloading, or even after it's download, open a terminal emulator (for instance this one: https://play.google.com/store/apps/details?id=jackpal.androidterm) and execute these two commands (will ask for superuser permission):
su
logcat | grep zip
And wrote down the OTA link for us
When you finish just revert the build.prop changes done and delete the file /cache/update.zip (it's the OTA downloaded, and you don't need it), then reboot your system to leave it in it's normal situation.
Thank you very much in advance.
And, If you are kindly enough, you may check for the rest of OTAs from other android versions (the LMY47E OTA to LMY47M should be very useful too). Here are all known versions build.prop lines to play with:
Code:
LMY47M
ro.build.date.utc=1425686543
ro.build.fingerprint=google/shamu/shamu:5.1/LMY47M/1774234:user/release-keys
LMY47I:
ro.build.date.utc=1425442825
ro.build.fingerprint=google/shamu/shamu:5.1/LMY47I/1767468:user/release-keys
LMY47E:
ro.build.date.utc=1424577649
ro.build.fingerprint=google/shamu/shamu:5.1/LMY47E/1748839:user/release-keys
LMY47D:
ro.build.date.utc=1424322888
ro.build.fingerprint=google/shamu/shamu:5.1/LMY47D/1743759:user/release-keys
LRX22C:
ro.build.date.utc=1416527965
ro.build.fingerprint=google/shamu/shamu:5.0.1/LRX22C/1602158:user/release-keys
LRX21O:
ro.build.date.utc=1415319727
ro.build.fingerprint=google/shamu/shamu:5.0/LRX21O/1570415:user/release-keys
LNX07M:
ro.build.date.utc=1414346119
ro.build.fingerprint=google/shamu/shamu:5.0/LNX07M/1543455:user/release-keys
-----
KXH21.6-F1.12:
ro.build.date.utc=1416355004
ro.build.fingerprint=motorola/shamu_factory/shamu:4.4.4/KXH21.6-F1.12/25:userdebug/release-keys
Most of them will give you old and known OTAs, but some will give new OTAs for all of us. And the final test build probably doesn't give any OTA
Thanks and best regards.

I changed by build.prop and rebooted and no update which I checked.

xpack90 said:
I changed by build.prop and rebooted and no update which I checked.
Click to expand...
Click to collapse
But you previously installed the LMY47M/E, no?
If yes, Please, wait several minutes and keep checking, you eventually must receive the OTA again before the rest of people.
Check too if build.prop file was correctly changed (sometimes a number is missing or something).
Thanks and best regards.

No sorry I thought this was for people who wanted the update not those who had it

xpack90 said:
No sorry I thought this was for people who wanted the update not those who had it
Click to expand...
Click to collapse
Don't worry and thanks for trying.

Rogers Canada
http://android.clients.google.com/p...ed-shamu-ota-LMY47D-from-LRX22C-fullradio.zip

Sleeepy2 said:
Rogers Canada
http://android.clients.google.com/p...ed-shamu-ota-LMY47D-from-LRX22C-fullradio.zip
Click to expand...
Click to collapse
First of all, thank you very much. Unfortunately that's one of the known OTAs.
You can see all known OTAs here:
http://forum.xda-developers.com/nexus-6/general/ref-nexus-6-stock-ota-urls-t2906493
But as I said, thank you very much. You demonstrated the method works for Nexus 6 too

oops, yeah it is know. I didn't fully read and thought you just wanted confirmation that it works on the N6.
And yes it does

OK, I got the OTA you're looking for (47M) but am currently unlocked and not rooted. If I oem unlock and perform this, how do we know for sure that it will prompt me again for the OTA?
I'm certainly willing to try when I get home later this evening (if no one has posted it by then), but would hate for my data to get wiped for nothing ...

YankInDaSouth said:
OK, I got the OTA you're looking for but am currently unlocked and not rooted. If I oem unlock and perform this, how do we know for sure that it will prompt me again for the OTA?
I'm certainly willing to try when I get home later this evening (if no one has posted it by then), but would hate to for my data to get wiped for nothing ...
Click to expand...
Click to collapse
Unfortunately I cannot guarantee that you receive the OTA again.
In my opinion it shouldn't work because the GMS/GCS ID is used to check OTAs, and if you perform an "oem unlock" you will lose your data so a new GMS/GCS ID will be assigned to your device, making it a totally different device for google.
If I were you I shouldn't try. It's a pity, but I'm being sincere.
Thanks and best regards.

VivaErBetis said:
Unfortunately I cannot guarantee that you receive the OTA again.
In my opinion it shouldn't work because the GMS/GCS ID is used to check OTAs, and if you perform an "oem unlock" you will lose your data so a new GMS/GCS ID will be assigned to your device, making it a totally different device for google.
If I were you I shouldn't try. It's a pity, but I'm being sincere.
Thanks and best regards.
Click to expand...
Click to collapse
I appreciate you being straight up about it! I will hold off as I'd prefer not to lose my data and not be able to get the community what they want/need.
If only I had know that it would be this long before people started receiving the OTA I definitely would have held off on installing it!! Don't know why I was the "chosen one" LOL

YankInDaSouth said:
I appreciate you being straight up about it! I will hold off as I'd prefer not to lose my data and not be able to get the community what they want/need.
If only I had know that it would be this long before people started receiving the OTA I definitely would have held off on installing it!! Don't know why I was the "chosen one" LOL
Click to expand...
Click to collapse
Don't worry, the OTA will eventually show up, sooner or later. The real problem is our lack of patience

I've added the build.prop info for 5.1 LMY47I build. The OTA seems to be delivered for Australian users.

Would it be plausible to use JTAG to rewrite an unlocked firmware?

I know that the Verizon bootloader is almost impenetrable as is, but would it be plausible to completely go over the head of the firmware and directly write an image with JTAG that would allow for custom software? If so, would it be possible to use the firmware from another carrier like USC or would it have to be a custom image?
EDIT: summary of the method and everything I have thusfar discovered
So, this method after a bit of evolution, got to the point it basically entailed the following: Using the SD Card debrick method (popularized by the galaxy s3 LTE variants) a modified firmware image would be written to an SD Card, and the phone would boot from that image. The main problem I ran into: it would not let me flash anything that could brick the phone, nor was I able to pull the usb cord at the right moment and try and manually brick it. I was able to flash firmware and stock tars from other variants of the phone (such as the one that runs on T-mobile), but what I found out through that is a couple things:
1. The stock tars seem mostly carrier independent, and I was without any modification able to flash a T-mobile bootloader, system image, and pit file, but within recovery and download mode it would show that because of integrated CSC, it would still change back to the original variant. This could have implications for a very simple method of removing bloat from the phone, but I'm not so sure
2. It must have a very low level method of injecting information and file verification that is not located anywhere on eMMC
The latter led me to research a TON, eventually finding that the most likely culprit is the use of Qualcomm Qfuses, non-volatile pre-set memory located directly on the SoC, to check how the bootloader is signed. They consist of a couple blocks of registers, and definitely aren't readily writable. The trusted base of the entire secure system, the same system that KNOX invokes on other systems, is within a series of Qfuses. From what I have deduced, however, they must be at some software level writable, as although the Knox counter is an e-fuse, the others (such as the warrantee bit) have been both changed upon their void and reverted when brought back to a service center. This must mean that the entire block is possible to modify in both directions, unlike a fuse or breaker; It seems to act more like flash memory than a "fuse." This is very good, mainly because if the service center can change it it means that jtag has not been disabled by those flags, and is enabled in at least some form. What this also means is that without another MAJOR exploit within unfortunately simple, clean code or a leak of several RSA keys from verizon, either current workarounds such as safestrap are the answer for the foreseeable future, or a method of manually changing a simgle Qfuse (the one that controls the "Qualcomm Secureboot" flag) could be used.
What I'm hopefully going to start at some point here is research into finding a way of accessing and changing that Qfuse via JTAG. I have no money for a JTAG box at the moment, so it'll have to wait, but if anyone who already has one wants to use it, hopefully this info helps
P.S. I figured out exactly what T-flash does in odin: it flashes the files that you input into odin to the currently inserted SD Card (or so it seems, I could be wrong but that's what it did for me)
P.P.S. Verizon, I respectfully request that...oh never mind, profanity is definitely frowned upon here
Also, I'm in ongoing discussion with the FCC as to block C violations by Verizon of aspects of the regulations that upon research have not really been argued to any substantial extent, so if that comes to fruition hopefully there'll be simple ODIN flashable patches for this stuff :fingers-crossed:
UPON REFLECTION: if the phone could be bricked, either by very subtly corrupted file or by interrupting a flash at the right moment, then could the debrick image from a tmobile galaxy s5 with an unlocked bootloader be used as not a method of flashing the on-board bootloader but as a kind of external boot, so a permenantly installed SD Card that would be permissive of modified kernels and such but still accepted as a boot device by the phone?

I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.

tr4nqui1i7y said:
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
Click to expand...
Click to collapse
what was done with the droix x? Did they use a direct JTAG patch?

I just realized something. From reading here: http://forum.gsmhosting.com/vbb/f200/how-fix-samsung-galaxy-s5-sm-g900f-dead-boot-1813266/
It seems to show that the S5 has a "alternative boot upon init fault" method similar to that that allows the galaxy s3 debrick to work (I have a guide I made with details) so would it be possible to somehow corrupt a very important part of the bootloader in an official update (would one or two bits still mess with the signature?), apply that, and have an insecure bootloader on a microsd card in the phone allowing it to boot into that, then use that with odin to flash an insecure bootloader to the s5 itself?

Now I have to ask an interesting question somewhere (since he: http://forum.xda-developers.com/verizon-galaxy-s5/help/g900v-hard-brick-t2914847 seems to have done it): "guys how do I brick my sm-g900v?"

They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.

tr4nqui1i7y said:
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
Click to expand...
Click to collapse
I think it might actually be easier
So long as a couple conditions are met for it:
1. The bootloader alone determines if an image is "signed" or not (like when flashed in odin)
2. The same UnBrick exploit from the S3 LTE variants works in some form (secondary storage, fault-triggered boot)
3. It is possible to get it to load a modified bootloader from that secondary boot (this is why number 1 is important)
4. KNOX is completely firmware based, and doesn't have any chip based verification
5. I or someone else actually knows how to modify the bootloader such that it will allow unsigned images (even if not removing it all together, then changing the key to one they publicize so people can sign their rom with it)
If all of these are met, then we might actually have free root! Basically all it would involve would be bricking the device badly enough it boots from secondary storage, have that secondary boot have a "back door" that allows a custom image to be flashed, that allows a bootloader image to be flashed that allows for a signed recovery (signed with that publicly available code) to be flashed without having to deal with safestrap or anything like that. Just full root like on any other phone. Anyone want to offer an opinion? Will this work? I would love to try this out, though I'm a bit unwilling to offer my s5 as a sacrifice just yet as I don't have a JTAG unit on site. I know the bounty is probs gone but I'm ok just getting my bootloader unlocked an' $#*+

The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.

Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting

tr4nqui1i7y said:
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Click to expand...
Click to collapse
Have you found anything yet?

dreamwave said:
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
Click to expand...
Click to collapse
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.

tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom

dreamwave said:
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
Click to expand...
Click to collapse
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.

tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
that's why I'm hoping the debrick image method will work

tr4nqui1i7y said:
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
Click to expand...
Click to collapse
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom. Also, safestrap didn't do a thing with the bootloader, it was done during kernel init, right after firmware finishes. If a phone is hard bricked then adb won't work, and what I'm getting at is hard bricking it then using the debrick image thing

dreamwave said:
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom
Click to expand...
Click to collapse
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?

tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Click to expand...
Click to collapse
I don't know, I got it to go back to when root was still possible to get via an app. I don't see why there's a need to downgrade the bootloader if the debrick image thing works

tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
Click to expand...
Click to collapse
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.

dreamwave said:
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
Click to expand...
Click to collapse
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.

tr4nqui1i7y said:
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
Click to expand...
Click to collapse
but that has already been done I think, root on a system with any bootloader so long as a root exploit exists for the OS
That's safestrap. It doesn't allow custom kernels or a full custom recovery though, that's why I'm trying to modify the bootloader

[WARNING] DO NOT Install PRIME V6.6 OTA Update

It has come to light that a new update has been released for the Prime version stock ROM. This update is called V6.6 (duh), and the update replaces the preloader. Some people have reported bootloops, one has gotten a brick, and I am all but certain that Amazon is trying to patch the preloader to remove any chance of rooting or converting to OEM ever again. It also replaces the boot image, which we believe is a way to re-lock the bootloader, or possibly even make fastboot ignore the unlocked status. This could also destroy your ability to root, run TWRP, or run any custom ROM ever again. If you are on the Prime stock ROM, DO NOT take the OTA to V6.6. It's really not worth it for the security patch. I also encourage all users of V6.1, V6.4, or V6.5 to go ahead and convert your phone to the non-Prime variant while you have the chance. Amazon is known for jamming updates down people's throats so I would not be surprised if they have a way of installing that update without your approval.
The conversion guide is here: http://forum.xda-developers.com/r1-hd/how-to/guide-convert-to-prime-rollback-ota-t3432499
There is some discussion about the OTA in the last few pages of the general discussion thread here: http://forum.xda-developers.com/r1-hd/how-to/blu-r1-hd-t3418354/post68565531#post68565531
We can use this thread to further dissect and discuss the update.

The boot img can lock the Bootloader.

Thanks for the warning. I would have taken it as I think V6.5 was a good update and improved performance (at the expense of battery life).

DarkBlood. said:
The boot img can lock the Bootloader.
Click to expand...
Click to collapse
No, but some kernel/ramdisk shenanigans could lock it at boot.

We've now confirmed that this update breaks SPFT. It is currently unknown if we will be able to recover from this, but I'm hoping we can.
http://forum.xda-developers.com/showpost.php?p=68578922&postcount=1319
It doesn't appear to relock the bootloader or break fastboot in any way, so if your bootloader is already unlocked you might be okay. I still highly recommend against it.

With the fire tablet they disabled the preloader and changed the pid

ColtonDRG said:
We've now confirmed that this update breaks SPFT. It is currently unknown if we will be able to recover from this, but I'm hoping we can.
http://forum.xda-developers.com/showpost.php?p=68578922&postcount=1319
It doesn't appear to relock the bootloader or break fastboot in any way, so if your bootloader is already unlocked you might be okay. I still highly recommend against it.
Click to expand...
Click to collapse
So, I wonder then, if we dont get a custom rom soon, can the security updates be pulled from the prime OTA and be incorporated into non Prime. I bet if 6.6 plugged SPFT and makes it near impossible for new users to switch to non prime or debloat, that will be the last OTA we see for awhile.

I installed V6.6 OTA update...not sure if I'll regret it. The amazon ads haven't bothered me because I always have notifications, and the ads are smaller than them...plus I was on a CHEAP phone ($10.00) from best buy via slickdeals ad about a year ago...so now I feel like I'm on a contender...it's all relative...Compared to http://www.lg.com/us/cell-phones/lg-LS620-realm I'm flying.

I am sticking to the prime version. I had disabled OTA. Bootloader unlocked. Hopefully someone can see if 6.6 has anything to offer.

DarkBlood. said:
With the fire tablet they disabled the preloader and changed the pid
Click to expand...
Click to collapse
You cannot simply "disable" the preloader. We discussed what exactly Amazon did with the Fire a little bit in the private hangout the other day. The bottom line is that we still don't know exactly what shenanigans Amazon is up to, or what tricks they have up their sleeve. Knowing Amazon, it can't be good for us.

jacewt said:
I am sticking to the prime version. I had disabled OTA. Bootloader unlocked. Hopefully someone can see if 6.6 has anything to offer.
Click to expand...
Click to collapse
It has the August security patch and some things that lock things down. Nothing else that I'm aware of.

bionictoothpick said:
I installed V6.6 OTA update...not sure if I'll regret it. The amazon ads haven't bothered me because I always have notifications, and the ads are smaller than them...plus I was on a CHEAP phone ($10.00) from best buy via slickdeals ad about a year ago...so now I feel like I'm on a contender...it's all relative...Compared to http://www.lg.com/us/cell-phones/lg-LS620-realm I'm flying.
Click to expand...
Click to collapse
If you unlocked your bootloader (fastboot style) via one of the methods before, you should still be able to gain root. If not, you are probably hosed, at least for now. Weather or not you will end up regretting that is up to you, but I certainly would.

kal250 said:
So, I wonder then, if we dont get a custom rom soon, can the security updates be pulled from the prime OTA and be incorporated into non Prime. I bet if 6.6 plugged SPFT and makes it near impossible for new users to switch to non prime or debloat, that will be the last OTA we see for awhile.
Click to expand...
Click to collapse
I agree. By the way, I will be releasing a TWRP version of the image for people who did manage to unlock their bootloader to use to convert after taking the update. I will also try to get a TWRP image of the old-school preloader image working once I've figured out if it's safe.
As for mixing the ROMs, I've considered doing it before. I worry about breaking some of the advantages of the OEM ROM. If this continues for too much longer, I'll consider it more seriously and start looking into it, but I think for now it remains a case of "there are more important things to do".

ColtonDRG said:
I agree. By the way, I will be releasing a TWRP version of the image for people who did manage to unlock their bootloader to use to convert after taking the update. I will also try to get a TWRP image of the old-school preloader image working once I've figured out if it's safe.
As for mixing the ROMs, I've considered doing it before. I worry about breaking some of the advantages of the OEM ROM. If this continues for too much longer, I'll consider it more seriously and start looking into it, but I think for now it remains a case of "there are more important things to do".
Click to expand...
Click to collapse
Fortunately, I had OTA blocked and as I said the other day when i get downtime(hopefully Sunday), I'm back to OEM, to hell with security patches!!

@ColtonDRG, @DarkBlood., @waingro808, @kal250, @ jacewt
Do we have the zip file for the OTA update yet ?
It's usually very trivial to repackage the update zip in order to make it update only /boot and /system, and nothing else (I've done this back with V6.5 since I wanted to keep the oldest bootloaders available). This way one gets all the updates, without any impact on the preloader, unlock status, etc.
This is kind of similar to how it's done for Fire 7 :
http://forum.xda-developers.com/amazon-fire/general/howto-install-fireos-5-1-1-root-gapps-t3265594

bibikalka said:
@ColtonDRG, @DarkBlood., @waingro808, @kal250, @ jacewt
Do we have the zip file for the OTA update yet ?
It's usually very trivial to repackage the update zip in order to make it update only /boot and /system, and nothing else (I've done this back with V6.5 since I wanted to keep the oldest bootloaders available). This way one gets all the updates, without any impact on the preloader, unlock status, etc.
This is kind of similar to how it's done for Fire 7 :
http://forum.xda-developers.com/amazon-fire/general/howto-install-fireos-5-1-1-root-gapps-t3265594
Click to expand...
Click to collapse
The zip is available in https://na.mirrors.coltondrg.com/coltondrg/r1hd/stockota/prime/

bibikalka said:
@ColtonDRG, @DarkBlood., @waingro808, @kal250, @ jacewt
Do we have the zip file for the OTA update yet ?
It's usually very trivial to repackage the update zip in order to make it update only /boot and /system, and nothing else (I've done this back with V6.5 since I wanted to keep the oldest bootloaders available). This way one gets all the updates, without any impact on the preloader, unlock status, etc.
This is kind of similar to how it's done for Fire 7 :
http://forum.xda-developers.com/amazon-fire/general/howto-install-fireos-5-1-1-root-gapps-t3265594
Click to expand...
Click to collapse
Go for it, but I'm not interested in taking any of Amazon's **** either way.
As @DarkBlood. said, the zip file is mirrored on https://na.mirrors.coltondrg.com/coltondrg/r1hd/stockota/prime/

I am curious, and we may already know, but did they fail to properly implement the version check in their OTA updater script? Just looking at the reviews on Amazon, it seems a few have suddenly been borked, and only able to boot to stock recovery since Sept 6th or so. I am curious as one of the recovery system check failure messages appears to be hanging up on the v6.1 files and refusing to boot saying they were modified. Was wondering if those are devices that updated from v6.1 straight to v6.6 whereas it seems Amazon/Blu should have ensured the updater abort if device was not v6.5. Thoughts? They may have created a real mess for themselves....

ariesgodofwar said:
I am curious, and we may already know, but did they fail to properly implement the version check in their OTA updater script? Just looking at the reviews on Amazon, it seems a few have suddenly been borked, and only able to boot to stock recovery since Sept 6th or so. I am curious as one of the recovery system check failure messages appears to be hanging up on the v6.1 files and refusing to boot saying they were modified. Was wondering if those are devices that updated from v6.1 straight to v6.6 whereas it seems Amazon/Blu should have ensured the updater abort if device was not v6.5. Thoughts? They may have created a real mess for themselves....
Click to expand...
Click to collapse
A handful of people around here actually got their phone bootlooped just after taking the upgrade straight from 6.5 to 6.6. At first I figured it was a fluke because their phones were altered, but at this point it's getting very suspicious (almost like it's a hit or miss thing for everyone, even those that haven't touched anything). I hope this doesn't damage the device's reputation too bad, and Amazon better get their **** together. Chopping off their nose in spite of their face. I guess I shouldn't be surprised at this point. This is Amazon we're talking about here.

bibikalka said:
@ColtonDRG, @DarkBlood., @waingro808, @kal250, @ jacewt
Do we have the zip file for the OTA update yet ?
It's usually very trivial to repackage the update zip in order to make it update only /boot and /system, and nothing else (I've done this back with V6.5 since I wanted to keep the oldest bootloaders available). This way one gets all the updates, without any impact on the preloader, unlock status, etc.
This is kind of similar to how it's done for Fire 7 :
http://forum.xda-developers.com/amazon-fire/general/howto-install-fireos-5-1-1-root-gapps-t3265594
Click to expand...
Click to collapse
If the zip can be modified, can we inject the 6.1 preloader and bootloader into the 6.6 OTA and modify it to run over current 6.6 installs allowing those who have been locked to at least unlock themselves?? I'm not savy enough to try....