Ok, so there seems to be some issues with installing the recent 4.2.1 OTA update with custom recoveries (ie: CWM or TWRP). I ran into this issue myself, and I've seen many other posts with similar problems. I've found the solution and explained it in multiple threads, but due to the nature of the issue, I thought it deserved it's own thread to make sure everyone is aware of the problem and the workaround.
Details:
The 4.2.1 OTA update comes in two flavors - nakasi and nakasig. The former is for WiFi devices (8, 16, 32), and the latter is for 3G devices. In turn, they each have their own device types - grouper and talapia, respectively. While the hardware differences between the WiFi and 3G models is negligible, and most things are interchangeable (ie: kernels, recoveries, etc.), the updates are NOT, and you need to pick the correct one for your platform. For the 3G models, this means the 'nakasig' version.
However, the first thing the OTA update does is validate the integrity of the system. In addition to checking about 200 files in the /system partition, it also looks at the device itself. Specifically:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2/JOP40C/527662:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2.1/JOP40D/533553:user/release-keys");
assert(getprop("ro.product.device") == "talapia" ||
getprop("ro.build.product") == "talapia");
While the first part checks the build.prop file to see what the "ro.build.fingerprint" has defined, the latter (bolded) assert examines what the RECOVERY says the system is. This is where the problem lies. AFAIK, there are no 'talipia' versions of CWM or TWRP. All 3G users running custom recoveries are using the 'grouper' (ie: Wi-Fi only) version. And this is fine 99% of the time. But this is the 1% of the time when they are not compatible. As a result, when the updater script checks recovery, and is told that the system is 'grouper', it aborts the update.
I ran into this issue on both the latest versions of TWRP and CWM. I wasn't sure why, since I thought it just looked at build.prop which was OK. After speaking with oldblue910, he explained that it is getting that information not from build.prop, but from the custom recovery, which is why the update was failing (thanks to oldblue910 for the info!).
SO, I was left with one of two options. I could either restore the stock talipia recovery or modify the update zip to ignore this information. I chose the latter. I'm not sure why Google decided to even but this redundant check in place, since the build.prop fingerprint check should suffice to validate the hardware. Not to mention that the next part of the update is to assert check the majority of files in 'system' anyway, which would fail if it wasn't a 3G device. In any case, by removing the above bolded lines out of the updater-script, my tablet was able to be successfully updated to 4.2.1.
Since many other XDA users run custom recoveries, it is safe to say many other users will run into this issue as well. So I put my custom update online for anyone else to use.
You can download it here:
http://core.routed.com/CUSTOM_RECOVERY-65880f56b1c0.signed-nakasig-JOP40D-from-JOP40C.65880f56.zip
MD5SUM: b0adff6a04ca2ca6234a9678476d329e
A couple notes:
1) This update zip is completely identical to the Google version, outside of the talipia check removed.
2) This update should ONLY BE USED ON 3G NEXUS 7 MODELS. It will NOT work on Wi-Fi only versions.
3) All the other asserts are left in-tact, as they should be. So your 'system' needs to be mostly stock. It checks and patches about 200 files, and if any of them are modified, removed, frozen, etc., the update will fail.
4) The OTA update does NOT check or update the bootloader or kernel, so modifications or non-4.2-stock versions in those areas are fine. However, as stated in #3, mostly everything else should be stock.
5) If the update fails on a specific assert, it will explain what the problem is (ie: the specific apk or odex file). You will need to fix that before proceeding. If you run into an issue and require assistance, you will need to explain the exact error message.
6) As this is almost completely stock OTA update, you WILL lose root/custom recovery unless you take precautions to prevent them from being overwritten. To preserve root, you can use RootKeeper or a similar app to back it up. The latest version of CWM also will warn you if root is lost and apparently restore it for you. For the recovery side of things, the update puts that recovery-recovery file on the system. You can either manually remove it via adb shell (BEFORE REBOOTING AFTER THE UPDATE), or in CWM (and possibly TWRP's case), it should warn you that you might lose custom recovery after the update and ask if you want it to fix it for you (say yes).
Hopefully this helps others who ran into the same error as me. Enjoy!
phonic said:
Ok, so there seems to be some issues with installing the recent 4.2.1 OTA update with custom recoveries (ie: CWM or TWRP). I ran into this issue myself, and I've seen many other posts with similar problems. I've found the solution and explained it in multiple threads, but due to the nature of the issue, I thought it deserved it's own thread to make sure everyone is aware of the problem and the workaround.
Details:
The 4.2.1 OTA update comes in two flavors - nakasi and nakasig. The former is for WiFi devices (8, 16, 32), and the latter is for 3G devices. In turn, they each have their own device types - grouper and talapia, respectively. While the hardware differences between the WiFi and 3G models is negligible, and most things are interchangeable (ie: kernels, recoveries, etc.), the updates are NOT, and you need to pick the correct one for your platform. For the 3G models, this means the 'nakasig' version.
However, the first thing the OTA update does is validate the integrity of the system. In addition to checking about 200 files in the /system partition, it also looks at the device itself. Specifically:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2/JOP40C/527662:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2.1/JOP40D/533553:user/release-keys");
assert(getprop("ro.product.device") == "talapia" ||
getprop("ro.build.product") == "talapia");
While the first part checks the build.prop file to see what the "ro.build.fingerprint" has defined, the latter (bolded) assert examines what the RECOVERY says the system is. This is where the problem lies. AFAIK, there are no 'talipia' versions of CWM or TWRP. All 3G users running custom recoveries are using the 'grouper' (ie: Wi-Fi only) version. And this is fine 99% of the time. But this is the 1% of the time when they are not compatible. As a result, when the updater script checks recovery, and is told that the system is 'grouper', it aborts the update.
I ran into this issue on both the latest versions of TWRP and CWM. I wasn't sure why, since I thought it just looked at build.prop which was OK. After speaking with oldblue910, he explained that it is getting that information not from build.prop, but from the custom recovery, which is why the update was failing (thanks to oldblue910 for the info!).
SO, I was left with one of two options. I could either restore the stock talipia recovery or modify the update zip to ignore this information. I chose the latter. I'm not sure why Google decided to even but this redundant check in place, since the build.prop fingerprint check should suffice to validate the hardware. Not to mention that the next part of the update is to assert check the majority of files in 'system' anyway, which would fail if it wasn't a 3G device. In any case, by removing the above bolded lines out of the updater-script, my tablet was able to be successfully updated to 4.2.1.
Since many other XDA users run custom recoveries, it is safe to say many other users will run into this issue as well. So I put my custom update online for anyone else to use.
You can download it here:
http://core.routed.com/CUSTOM_RECOVERY-65880f56b1c0.signed-nakasig-JOP40D-from-JOP40C.65880f56.zip
MD5SUM: b0adff6a04ca2ca6234a9678476d329e
A couple notes:
1) This update zip is completely identical to the Google version, outside of the talipia check removed.
2) This update should ONLY BE USED ON 3G NEXUS 7 MODELS. It will NOT work on Wi-Fi only versions.
3) All the other asserts are left in-tact, as they should be. So your 'system' needs to be mostly stock. It checks and patches about 200 files, and if any of them are modified, removed, frozen, etc., the update will fail.
4) The OTA update does NOT check or update the bootloader or kernel, so modifications or non-4.2-stock versions in those areas are fine. However, as stated in #3, mostly everything else should be stock.
5) If the update fails on a specific assert, it will explain what the problem is (ie: the specific apk or odex file). You will need to fix that before proceeding. If you run into an issue and require assistance, you will need to explain the exact error message.
6) As this is almost completely stock OTA update, you WILL lose root/custom recovery unless you take precautions to prevent them from being overwritten. To preserve root, you can use RootKeeper or a similar app to back it up. The latest version of CWM also will warn you if root is lost and apparently restore it for you. For the recovery side of things, the update puts that recovery-recovery file on the system. You can either manually remove it via adb shell (BEFORE REBOOTING AFTER THE UPDATE), or in CWM (and possibly TWRP's case), it should warn you that you might lose custom recovery after the update and ask if you want it to fix it for you (say yes).
Hopefully this helps others who ran into the same error as me. Enjoy!
Click to expand...
Click to collapse
I compiled a CWM image for tilapia, so now users can flash updates and roms for their device without trying to by-pass the safety checks. With everyone recommending flashing grouper recovery, people are going to keep flashing grouper roms and wonder why things aren't working correctly.
The two devices differ in more respects than a simple assert check, including having different recovery.fstab files, which are used to make and configure recovery.
Better to have proper recovery for our (unique) device instead of a grouper port. The CWM image is not touch, the touch sources are not open source and koush's online builder is not producing a working image at this time. I ported one by hand, but it is too buggy to release.
I'll add twrp to the post sometime later.
mateorod said:
I compiled a CWM image for tilapia, so now users can flash updates and roms for their device without trying to by-pass the safety checks. With everyone recommending flashing grouper recovery, people are going to keep flashing grouper roms and wonder why things aren't working correctly.
Better to have proper recovery for our (unique) device instead of a grouper port. The CWM image is not touch, the touch sources are not open source and koush's online builder is not producing a working image at this time. I ported one by hand, but it is too buggy to release.
I'll add twrp to the post sometime later.
Click to expand...
Click to collapse
Thanks, that's definitely a better solution versus a work around.
Though the safety check bypassed in the OP wouldn't cause any issues since it was redundant and unnecessary. The OTA update already checks build.prop for the model info and all the apks/odexes it updates, so it would be impossible to flash it on a non-compatible device. But you raise a very valid point about incorrect ROMs and other things. The 3G unit probably needs it's own forum.
Did you have to make any real modifications to CWM outside of changing grouper to talapia?
The 3G unit probably needs it's own forum.
Click to expand...
Click to collapse
Its already done here; http://forum.xda-developers.com/forumdisplay.php?f=2022
Ather said:
Its already done here; http://forum.xda-developers.com/forumdisplay.php?f=2022
Click to expand...
Click to collapse
Woohoo! Thanks.
I had some issues when I did the update. It gave me some errors, and aborted, but then I found a link that had the update and I got it to update. This happened on my n4 and n73g. Well, for some reason, the recoveries got deleted so I had to reinstall them. I was able to use the goo manager to restore TWRP on my N4, but it wasn't working on my N7 so I had to side load it. After this, I noticed that google now wasn't working on my n4, and the volume rocker on my n7 had some issues. I went in and wiped the cache and dalvik cache and rebooted. Google now works on my N4, and while the volume gets adjusted on my N7, it won't make the beep every time I push up or down on the rocker indicating the volume level. I haven't noticed any other issues, but I haven't really delved into my devices. I may try to do a factory wipe and return everything to stock just to see what went wrong in the first place and to see if I can do anything different I still can't figure out how to get ADB running on my computer, so yes I used one of the tool kits to load everything. I know the OP's position on tool kits, but I just can't figure out how to get ADB running manually, AND it takes so long to download and install everything unless I am installing things I don't even need.
Nexus 7 takju firmware update
Hi, while this is a very detailed description, I am still in need of help.
I just got a Google Nexus 7 from Google play store and it came with JVP15S firmware.
I understand that this is takju version of th edevice - I would like to upgrade it with the latest firmware but going through all the posts, I am totally lost.
I see upgrade files to upgrade from JOP40C to JOP40D - and see al ldifferent update combinations - but cannot fined one for JVP15S to JOP40D.
Also, all the updates are for different version "tilapia" and other fishes -- but none for takju (whatever that means)
Can someone direct me to right place to get the right updates/
Also I see a lot of posts and articles stating that Google is "pushing" the 4.2.1 Firmware JOP40D to Nexus 7 devices - how is this "pushing" manifest itself? What is the procedure for OTA update? Do I need to go to a place on Google to get it? Is it supposed to be downloaded automatically?
Hope someone can help.
Do you have the Galaxy Nexus or Nexus 7? If Galaxy Nexus, you of course would want to check those forums. As for the updates, you should normally see a notification alerting you of the update, but you can also check for it in settings/about phone/system updates. Otherwise the appropriate forum for your device will have links to the update files. Good luck!
lil help please
I updated to 4.2.1 with the OTA zip file using TWRP and voodoo root keeper installed. It flashed just fine. Rebooted with update. My root access is funky though. SuperSU is still there and I can access root file threw root explorer but I can't mount it as writable and when I install a new app that needs root access it never asks for it. Does superSU need to be updated? There is no update available for it.
Vlad7777 said:
Hi, while this is a very detailed description, I am still in need of help.
I just got a Google Nexus 7 from Google play store and it came with JVP15S firmware.
I understand that this is takju version of th edevice - I would like to upgrade it with the latest firmware but going through all the posts, I am totally lost.
I see upgrade files to upgrade from JOP40C to JOP40D - and see al ldifferent update combinations - but cannot fined one for JVP15S to JOP40D.
Also, all the updates are for different version "tilapia" and other fishes -- but none for takju (whatever that means)
Can someone direct me to right place to get the right updates/
Also I see a lot of posts and articles stating that Google is "pushing" the 4.2.1 Firmware JOP40D to Nexus 7 devices - how is this "pushing" manifest itself? What is the procedure for OTA update? Do I need to go to a place on Google to get it? Is it supposed to be downloaded automatically?
Hope someone can help.
Click to expand...
Click to collapse
Is your device rooted? Is this your first android device? You will get a little notification in the notification bar at the top saying your deivce has an update.. If you have not rooted, you will receive the first OTA in a day or two that will go from JVP15S to JOP40C. Then later, you will receive the update for JOP40D. Some people have had success at forcing the update by going to settings, apps, all, google framework services, and selecting force stop then clearing the data. You then go back into settings, about device, check for updates and check for update.
Vlad7777 said:
Hi, while this is a very detailed description, I am still in need of help.
I just got a Google Nexus 7 from Google play store and it came with JVP15S firmware.
I understand that this is takju version of th edevice - I would like to upgrade it with the latest firmware but going through all the posts, I am totally lost.
I see upgrade files to upgrade from JOP40C to JOP40D - and see al ldifferent update combinations - but cannot fined one for JVP15S to JOP40D.
Also, all the updates are for different version "tilapia" and other fishes -- but none for takju (whatever that means)
Can someone direct me to right place to get the right updates/
Also I see a lot of posts and articles stating that Google is "pushing" the 4.2.1 Firmware JOP40D to Nexus 7 devices - how is this "pushing" manifest itself? What is the procedure for OTA update? Do I need to go to a place on Google to get it? Is it supposed to be downloaded automatically?
Hope someone can help.
Click to expand...
Click to collapse
The N73G ships with an interim 4.2 build, which is JVP15S. There are some significant differences between this and JOP40C, which is the first update you will get out of the box. I imagine 4.2 wasn't fully finalized prior to hardware production, and they didn't want to hold it up until they were ready (wise choise!). In my case, within an hour after opening my N73G and turning it on, I had the 40C update notification. I applied this prior to rooting/modding/etc. ONLY after you are on 40C can you get the upgrade to 40D (4.2.1). Google pushes out incremental patch updates, so you can't skip a version.
So you have two options:
1) Apply update #1 and wait for #2 and then root/etc.
2) If you don't want to wait, and your device is still basically brand new and not setup (too much), AND assuming you want to root, customize, etc., just download the 4.2.1 system image from Google and fastboot flash it. You'll need to unlock the bootloader anyway, which will wipe your system, so now's a perfectly good time to do everything at once. Unlock bootloader, flash 4.2.1 stock (40D FULL IMAGE), flash custom recovery, install su zip, install any other mods (which is limited really to basic stuff and a custom kernel right now), enjoy.
Andoid 4.2.1 update
adamhlj said:
Is your device rooted? Is this your first android device? You will get a little notification in the notification bar at the top saying your deivce has an update.. If you have not rooted, you will receive the first OTA in a day or two that will go from JVP15S to JOP40C. Then later, you will receive the update for JOP40D. Some people have had success at forcing the update by going to settings, apps, all, google framework services, and selecting force stop then clearing the data. You then go back into settings, about device, check for updates and check for update.
Click to expand...
Click to collapse
Thanks!
It is my first Android device.
I am trying to root it (unsuccessfully).
I was able to get the FASTBOOT unlock - but cannot root because of the drivers interface...
I did update the firmware by forcing via framework system. Had to do in two steps as it only upgrades one generation at a time.
By the way - I had the "takju" - now it is "tilapia" after "official OTA update.
I hope to get the rooting problem resolved - all instructions on the net are for older ROMs and I already screwed up my work laptop installing obsolete PDANET drivers which replaced the original drivers - so my device manager which originally saw my Nexus 7 as "Nexus 7" now sees it as "Android Phone Device". I do not know how to recvert back.
So now I am going to try my other laptop for rooting.
Hopefully I could find just a "professional step by step procedure - unlike many that I found on the net. Many people just happy to get on YouTube to show themselves off but the advice is half ass.
Thanks again for your help though I am half way through.
Best regards
Vlad7777 said:
Thanks!
It is my first Android device.
I am trying to root it (unsuccessfully).
I was able to get the FASTBOOT unlock - but cannot root because of the drivers interface...
I did update the firmware by forcing via framework system. Had to do in two steps as it only upgrades one generation at a time.
By the way - I had the "takju" - now it is "tilapia" after "official OTA update.
I hope to get the rooting problem resolved - all instructions on the net are for older ROMs and I already screwed up my work laptop installing obsolete PDANET drivers which replaced the original drivers - so my device manager which originally saw my Nexus 7 as "Nexus 7" now sees it as "Android Phone Device". I do not know how to recvert back.
So now I am going to try my other laptop for rooting.
Hopefully I could find just a "professional step by step procedure - unlike many that I found on the net. Many people just happy to get on YouTube to show themselves off but the advice is half ass.
Thanks again for your help though I am half way through.
Best regards
Click to expand...
Click to collapse
I think you are either looking at really bad guides or simply making the rooting process much harder on yourself.
While some Android devices have more complicated unlocking/rooting/etc. requirements, that is not the case with Nexus devices - certainly not the Nexus7. The process couldn't be more simple. If you've already unlocked the bootloader, you are 1/3 of the way there. All you need to do is copy over a compatible "su" app zip to the device, install or run a custom recovery, install the su zip and voila - rooted.
If you already have fastboot running, that's the only tool you need. Download a custom recovery (CWM or TWRP) from a thread in this forum that is compatible, reboot into bootloader mode and install it:
fastboot flash recovery <recovery.img>
Then reboot into recovery mode (you can do this from bootloader), and you should be in CWM/TWRP. Then you simply install the SU zip using the menu on the screen.
It's a very simple process and does not require a special toolkit or anything like that.
phonic said:
I think you are either looking at really bad guides or simply making the rooting process much harder on yourself.
While some Android devices have more complicated unlocking/rooting/etc. requirements, that is not the case with Nexus devices - certainly not the Nexus7. The process couldn't be more simple. If you've already unlocked the bootloader, you are 1/3 of the way there. All you need to do is copy over a compatible "su" app zip to the device, install or run a custom recovery, install the su zip and voila - rooted.
If you already have fastboot running, that's the only tool you need. Download a custom recovery (CWM or TWRP) from a thread in this forum that is compatible, reboot into bootloader mode and install it:
fastboot flash recovery <recovery.img>
Then reboot into recovery mode (you can do this from bootloader), and you should be in CWM/TWRP. Then you simply install the SU zip using the menu on the screen.
It's a very simple process and does not require a special toolkit or anything like that.
Click to expand...
Click to collapse
Thank you for your reply and advice.
How do I place the "su zip" in the device and into which directory - I can try download directly to Nexus but needs to know where to place it.
Also what are "CWM" or "TWRP" And where do I place them for custom recovery procedure.
I apologize for my ignorance but Android is a complete new experience for me.
Vlad7777 said:
Thank you for your reply and advice.
How do I place the "su zip" in the device and into which directory - I can try download directly to Nexus but needs to know where to place it.
Also what are "CWM" or "TWRP" And where do I place them for custom recovery procedure.
I apologize for my ignorance but Android is a complete new experience for me.
Click to expand...
Click to collapse
You can place the "su zip" anywhere you like on the internal storage. When you get into custom recovery (CWM or TWRP), you can select "Install ZIP" (or something along those lines) and it will bring up a file system explorer that will let you select the one you want to install.
CWM and TWRP are both custom recoveries. They replace the stock, and very useless, recovery and give you many more advanced features. Things like flashing zip files, making nandroid backups, etc. You need to flash them to your "recovery" partition. It's a very easy process, but will require some specialized software. There are many guides and toolkits (if that's what you want to use) online. Just make sure you use the Talipia recovery (which exists now in the 3G forum).
(Please don't ask me to search the forum--that isn't working right now, it just gives an error.)
Several months ago, I bought a Nexus 6 phone, used from eBay. I have been using it with an AT&T SIM card for several months. However, it is stuck on build MOB30I and patch level "May 1, 2016". I thought that AT&T was simply months behind on updates, but today I learned the real problem: AT&T uses the MMB update tree, whereas my phone is (for some reason) on the MOB update tree. Apparently:
- My phone will not accept AT&T's MMB updates because the phone is on a different update tree
- My phone will not accept MOB updates (from Project Fi or Sprint or whomever) because an AT&T SIM card has been installed.
I tried removing the AT&T SIM card and checking for an update, but got nothing.
How do I switch to an update tree that will actually give me updates? I'd rather not install adb and sideload. In fact, rather than do that, I would instead enroll in the Android Beta program, install Android 7.0 beta, and let Google itself update me to Android 7.0 final when the time comes.
lgmayka said:
(Please don't ask me to search the forum--that isn't working right now, it just gives an error.)
Several months ago, I bought a Nexus 6 phone, used from eBay. I have been using it with an AT&T SIM card for several months. However, it is stuck on build MOB30I and patch level "May 1, 2016". I thought that AT&T was simply months behind on updates, but today I learned the real problem: AT&T uses the MMB update tree, whereas my phone is (for some reason) on the MOB update tree. Apparently:
- My phone will not accept AT&T's MMB updates because the phone is on a different update tree
- My phone will not accept MOB updates (from Project Fi or Sprint or whomever) because an AT&T SIM card has been installed.
I tried removing the AT&T SIM card and checking for an update, but got nothing.
How do I switch to an update tree that will actually give me updates? I'd rather not install adb and sideload. In fact, rather than do that, I would instead enroll in the Android Beta program, install Android 7.0 beta, and let Google itself update me to Android 7.0 final when the time comes.
Click to expand...
Click to collapse
Any reason not to use a Google Factory image? It looks like MMB29V is the most recent.
According to the instructions, installing a "Google Factory Image" would be a lot of risky work, and would erase all my data and apps. I was hoping for something simpler and safer. As I mentioned, joining the Android Beta program actually seems to be the easiest solution, if the current beta (NPD30G) is stable enough.
Frankly, I am surprised that Google/Motorola/AT&T (or any cell phone designer/manufacturer/carrier) allows a working cell phone to get into this state where the phone refuses to accept security updates.
For the Nexūs 6, the beta is quite stable (I didn't update my daily driver until I was sure it was stable on my other devices). You should be fine and back on track with NPD90G.
That's half the fun of owning a Nexus, not waiting for updates. Dl the factory image, unzip it and the zip file inside and flash the system. IMG only and you'll lose nothing but root. If, of course, you are rooted.
http://forum.xda-developers.com/showthread.php?p=59561445/ You may give it a try..... prerooted lite stock rom.
lgmayka said:
According to the instructions, installing a "Google Factory Image" would be a lot of risky work, and would erase all my data and apps. I was hoping for something simpler and safer.
Click to expand...
Click to collapse
As already suggested, just install the system image. The simplest way to do that is via fastboot. Nothing gets erased unless you flash the userdata.img. Using Google's script to flash everything would overwrite the userdata partition.
The version you are on (MMB) is released to provide updates without updating the radio. The MOB release is the same as the equivalent MMB plus the package includes the updated radio. This is a requirement of the carriers who want to approve the radio before it's released.
You will be unable to take any *incremental* OTA if there is any differential between what's on your system partition and what the OTA is expecting. You can not hop over incremental OTA updates. They must be sequentially applied. Therefore, the safest way to get to a known state is with a factory image.
If fastbooting a factory image is unacceptably risky, then maybe an eBay phone wasn't a great choice.
Or, as you say, you go straight to N. If the beta program is still available now that N is released.
stevemw said:
For the Nexūs 6, the beta is quite stable (I didn't update my daily driver until I was sure it was stable on my other devices). You should be fine and back on track with NPD90G.
Click to expand...
Click to collapse
I decided to do this. NPD90G is running well enough for me, and before long Google will release Android 7.0 Final.
Can I flash SGS5 SM-G900A ROM with Baseband Version (G900AUCU2ANCE) on SGS5 SM-G900A with Baseband Version (G900AUCU4BOF3)? Or any other baseband version?
FrankAm20177 said:
Can I flash SGS5 SM-G900A ROM with Baseband Version (G900AUCU2ANCE) on SGS5 SM-G900A with Baseband Version (G900AUCU4BOF3)? Or any other baseband version?
Click to expand...
Click to collapse
https://forum.xda-developers.com/att-galaxy-s5/general/guide-merry-christmas-heres-t3516196
FrankAm20177 said:
Can I flash SGS5 SM-G900A ROM with Baseband Version (G900AUCU2ANCE) on SGS5 SM-G900A with Baseband Version (G900AUCU4BOF3)? Or any other baseband version?
Click to expand...
Click to collapse
Really it depends on what baseband you're trying to work with. To better understand the answer I'm giving, I'm going to tell you about Samsung Knox and Qualcomm Secure Boot.
For Samsung Galaxy S devices after the S3, Samsung implemented a new security suite called Knox, which served to make devices enterprise-compatible by providing extensive anti-corruption and anti-tampering functions. One part of this was the locking of the bootloader, which is actually facilitated by Qualcomm Secure Boot, we'll get to that in a minute.
Another thing that Knox provides is this thing called Anti-Rollback Protection, which serves to prevent the exploitation of patched security flaws by defining exactly how far back the system can be downgraded. This is controlled by a thing called a qFuse (or an eFuse depending on who you ask). When you upgrade (or downgrade) to a new version of Android, the system checks that fuse value to see if it should accept the update or not. If the version's fuse value is the same as the value on the device, the update is accepted and nothing else happens. But when you upgrade to a version of Android with a higher qFuse version, the fuse on the device is "blown", and increments to that version, and the update is accepted.
If you try to downgrade lower than the fuse version, the update will fail the check, and the update will be rejected with an error saying "FAIL! (fuse x binary y)", with x representing the value on the device, and y representing the value of the update.
Now, this is a bit confusing, so I'll illustrate an example using our firmware.
The first thing you should know is that you can find the qFuse version of a firmware binary from the baseband version:
Example: G900AUCU4COI5, the qFuse version is 4
Example: G900AUCU2ANCE, the qFuse version is 2, so you would not be able to flash this over OI5.
Now, to your example, flashing a baseband from G900AUCU2ANCE over G900AUCU4BOF3, the update would not flash due to the binary's fuse value being lower than the value on the device.
And now you would ask something like "well why not just use FlashFire instead of ODIN and bypass the fuse check?" Well in theory that could work, but in practice it really doesn't, and this is where Qualcomm Secure Boot comes in.
When you flash something with FlashFire, it circumvents Knox's fuse check temporarily, and directly writes its payload to the target partition.
But both Samsung and Qualcomm foresaw something like this occurring, and they put in boot-time protections to shut that down.
When your device boots, it uses something called Chain-Of-Trust to boot the device in a sequence. It all starts with an RSA key held in a read-only part of the device. This key is used to verify the signature of every binary that comprises the bootloader, which is actually made of a whole bunch of different parts. The read-only key verifies a sub-bootloader. That sub-bootloader verifies another sub-bootloader, which verifies another part of the bootloader, and so on until you get to the application bootloader (aboot). The aboot is responsible for verifying and executing the Android Kernel, which is the first part of the system that's actually Android. Now the cool thing about the aboot is that you could break the chain of trust between it and the Kernel if the bootloader is unlocked, and the device would still boot. But since the bootloader on our devices is locked, the aboot verifies the Kernel, and then the kernel boots the system (that's right, no signature checking for the system itself, only the kernel).
That's the Qualcomm side of things, now here's where Samsung comes in, and things get a little weird.
In theory, Samsung reinforced Secure Boot further by making the bootloaders check qFuse versions along with signatures. BUT, I have seen some instances where the system allows an older kernel to boot. This is the case with NCE flasher and Safestrap, what NCE flasher does is flash the NCE kernel on the device so you can boot into Safestrap on newer versions of Android, with the requirement that you have to re-flash your old kernel before you can boot back into Android. You could in theory flash the /system partition from NCE along with the kernel, and leave everything else alone, but you would probably run into issues very quickly, mainly with the other bootloaders because they also check if the kernel has SELinux set to Enforcing, and the NCE kernel would fail the check because its SELinux is set to Permissive (you would get an error saying "KERNEL IS NOT SEANDROID ENFORCING")
TL;DR: If you wanted to flash just the kernel, it might work through FlashFire but you wouldn't be able to boot into OF3, you would have to flash the /system partition to NCE, and at that point there's not enough research to tell us what would happen next.
I want to flash the same android version with a different baseband.Is it possible
So in theory, if the qFuse versions were the same in both but the last 4 characters were different would the flash succeed?
AptLogic said:
and the device would still boot. But since the bootloader on our devices is locked, the aboot verifies the Kernel, and then the kernel boots the system (that's right, no signature checking for the system itself, only the kernel).
That's the Qualcomm side of things, now here's where Samsung comes in, and things get a little weird.
In theory, Samsung reinforced Secure Boot further by making the bootloaders check qFuse versions along with signatures. BUT, I have seen some instances where the system allows an older kernel to boot. This is the case with NCE flasher and Safestrap, what NCE flasher does is flash the NCE kernel on the device so you can boot into Safestrap on newer versions of Android, with the requirement that you have to re-flash your old kernel before you can boot back into Android. You could in theory flash the /system partition from NCE along with the kernel, and leave everything else alone, but you would probably run into issues very quickly, mainly with the other bootloaders because they also check if the kernel has SELinux set to Enforcing, and the NCE kernel would fail the check because its SELinux is set to Permissive (you would get an error saying "KERNEL IS NOT SEANDROID ENFORCING")
Click to expand...
Click to collapse
I'm still thinking that just like the same & related source branch(s) of the other samsung android flagships circa 2015/16 we should be able to backport the exploits made on newer devices to this old EOL device. I've seen the same kind of FW on the Note5, which has the same SoC as the the GS6 line too. If it worked on the generation after what you(we) are discussing, why couldn't be even more applicable to and older generation of source & hw? I had what seemed like the Combination Rom Kernel for my Rev3 Note5, it allowed official ODIN to bypass the revision rollback protection check for all pieces except cm.bin & param.bin ad still boot up.
We actually just need the stock custom rom put together compiled for the device and has all the version codes updated for a spoof. Dot the T's and Cross the I's. I can work if setup prior to a check and is diligently prepared. But is on a per device basis.
With so many Encryption Collision algorithms now though, I bet if we really revisited the S5 and the S3 red models, we can get farther into diverting and re-routing the chain of trust. They are EOL of devices anyhows that could use some ability to update still. And people wouldn't use them as daily drivers anymore anyways.
Samsung devices needed a System Root up until Nougat builds though. Everyone else upgraded to system-less style with 5.1 kinda yeah. Samsung, GIVEN YOU VERIFIED NO SYSTEM PARTITION signature check, we can dirtycow and persistent payload to defeat DM-Verity. Including the Recovery kernel here. I don't see why we couldn't hijack the Secure Boot PRocess and have it issue an unlock command, even temporally.
MattMadness said:
So in theory, if the qFuse versions were the same in both but the last 4 characters were different would the flash succeed?
Click to expand...
Click to collapse
Also look at the original package case-sensitive file name, the build.props, the system's(app/priv-app/*.rc) date/version #/version codes, file sizes, and default timestamps w/noatime, and then maybe use 7-Zip and it's CRC analyzer, as well the packages compression level, compression format, and the date of the compression algorithm itself too. Newer 7-Zip version 1909 will lzma/lz4 compress something in a slight different hex format than say the older versino 1806, we see this problem when compiling the "simg2img" packages as well. Same problem, fixed the same way though.
We can mod the early 6.0.1 CSC FW's this way with the Cache, we have the PoC's out there, they need integrated together though. An emmc flasher could maybe change the fuse value. Or we can replace all the build fingerprints from an older build and try and to flash it as a spoof at Run-Time. I've seen parts of it work with DirtyCow and the S6 Edge and Note5. So the S5 is older. Without the same problems and hurdles.
ATT and Verizon were the only ones that locked the bootloader of the S5