Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[WARNING][URGENT] N7 grouper (2012 WiFi) bootloader .img files from Google

OP bftb0

17th December 2013, 01:52 AM   |  #1  
OP Senior Member
Thanks Meter: 824
 
2,148 posts
Join Date:Joined: Feb 2010
Executive Summary:

1) There are at least THREE different bootloader files from Google/Asus that are all labeled with the identical version number "4.23". The versions distributed with the JWR66Y, KOT49H, KUT48L, KUT48P, and LRX21P Google factory images are INVALID. If you want a 4.23 bootloader ".img" file, get it from any of the (JWR66V, KRT16O, KRT16S) Google factory images

2) The "bootloader.raw" files contained in the OTA update .zip files ARE PREFIXED WITH A 76-byte PREAMBLE, and thus are NOT identical to the bootloader ".img" files distributed by Google in their full factory image distros. They should never be used with fastboot.

3) Somebody from Google/Asus screwed up royally and put the OTA (preamble-prefixed) bootloader file into the JWR66Y (full) factory Image; similarly the bootloader ".img" file in the KOT49H image is also screwed up - it starts with "BOOTLDR!" rather than an arm objcode near branch ("ea000010 == b[ranch] 48"). It is also a wildly different size than prior bootloader .img files. What's up Google?


I didn't examine any of the tilapia full factory images or OTA zip files to check them. You've been warned!

details:

Code:
GROUPER (N7 Wifi-Only, 2012) BOOTLOADERS 

DERIVED FROM Google "Factory Images":

BYTES    MD5SUM				           ROM     FACTORY_IMAGE_FILENAME                       strings *.img | grep BOOTLOADER

2142784  f5f8c0dd160ef92c601311a0c9054118  JZO54K  ./nakasi-jzo54k/bootloader-grouper-3.41.img   BOOTLOADER VERSION - 3.41

2146892  a119629c89ad06c7e49bebd260df9cf3  JOP40C  ./nakasi-jop40c/bootloader-grouper-4.13.img   BOOTLOADER VERSION - 4.13
2146892  a119629c89ad06c7e49bebd260df9cf3  JOP40D  ./nakasi-jop40d/bootloader-grouper-4.13.img   BOOTLOADER VERSION - 4.13

2146892  bffa744a6847b5bede2bf445427ef80e  JDQ39   ./nakasi-jdq39/bootloader-grouper-4.18.img    BOOTLOADER VERSION - 4.18

2150992  df53028033c9eccf4fe5ba7bc198ce24  JWR66V  ./nakasi-jwr66v/bootloader-grouper-4.23.img   BOOTLOADER VERSION - 4.23
2151068  5bdb2e87370cdb1a7ea14bb0c3e21390  JWR66Y  ./nakasi-jwr66y/bootloader-grouper-4.23.img   BOOTLOADER VERSION - 4.23
2150992  df53028033c9eccf4fe5ba7bc198ce24  KRT16O  ./nakasi-krt16o/bootloader-grouper-4.23.img   BOOTLOADER VERSION - 4.23
2150992  df53028033c9eccf4fe5ba7bc198ce24  KRT16S  ./nakasi-krt16s/bootloader-grouper-4.23.img   BOOTLOADER VERSION - 4.23
4005632  797a8ddfe19bfe4c485f8a8c119f1bdd  KOT49H  ./nakasi-kot49h/bootloader-grouper-4.23.img   BOOTLOADER VERSION - %s
2151068  5bdb2e87370cdb1a7ea14bb0c3e21390  KTU84L ./nakasi-ktu84l/bootloader-grouper-4.23.img  BOOTLOADER VERSION - 4.23
2151068  5bdb2e87370cdb1a7ea14bb0c3e21390  KTU84P ./nakasi-ktu84p/bootloader-grouper-4.23.img  BOOTLOADER VERSION - 4.23
2151068  5bdb2e87370cdb1a7ea14bb0c3e21390  LRX21P ./nakasi-lrx21p/bootloader-grouper-4.23.img  BOOTLOADER VERSION - 4.23
What sloppiness. Hard to say whether this is a Google fumble or an Asus fumble; perhaps something fell in the cracks between them.


What are the OTA 76-byte preambles of the "bootloader.raw" files? I'm not sure exactly. Perhaps they are nothing more than a signature used to "alert" the existing bootloader that a replacement bootloader has been dropped into the USP partition. (I suppose that all versions of the bootloader look at the USP partition when they first boot up to check for the presence of an update; the same technique may also be used by tilapia devices for radio firmware, but that's speculation) These prefixes are also not identical to each other; they seem to vary in only a few bytes from version to version, e.g.:

Code:
nakasi-JZO54K-from-JRO03S.d41da8f6 bootloader.raw   (v 3.41)

00000000  4d 53 4d 2d 52 41 44 49  4f 2d 55 50 44 41 54 45  |MSM-RADIO-UPDATE|
00000010  00 00 01 00 3c 00 00 00  3c 00 00 00 01 00 00 00  |....<...<.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 45 42 54 00  |............EBT.|
00000040  4c 00 00 00 40 b2 20 00  01 00 00 00              |L...@. .....|
0000004c


nakasi-JOP40D-from-JZO54K.c01f18e0 bootloader.raw (v 4.13)

00000000  4d 53 4d 2d 52 41 44 49  4f 2d 55 50 44 41 54 45  |MSM-RADIO-UPDATE|
00000010  00 00 01 00 3c 00 00 00  3c 00 00 00 01 00 00 00  |....<...<.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 45 42 54 00  |............EBT.|
00000040  4c 00 00 00 4c c2 20 00  01 00 00 00              |L...L. .....|
0000004c


nakasi-JDQ39-from-JZO54K.da55f917 bootloader.raw  (v 4.18)

00000000  4d 53 4d 2d 52 41 44 49  4f 2d 55 50 44 41 54 45  |MSM-RADIO-UPDATE|
00000010  00 00 01 00 3c 00 00 00  3c 00 00 00 01 00 00 00  |....<...<.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 45 42 54 00  |............EBT.|
00000040  4c 00 00 00 4c c2 20 00  01 00 00 00              |L...L. .....|
0000004c


nakasi-JWR66V-from-JDQ39.ab67ca07 bootloader.raw    (v "4.23" rev0)

00000000  4d 53 4d 2d 52 41 44 49  4f 2d 55 50 44 41 54 45  |MSM-RADIO-UPDATE|
00000010  00 00 01 00 3c 00 00 00  3c 00 00 00 01 00 00 00  |....<...<.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 45 42 54 00  |............EBT.|
00000040  4c 00 00 00 50 d2 20 00  01 00 00 00              |L...P. .....|
0000004c
The differences that appear in these preambles are the 4-bytes sequence (shown highlighted above) which are exactly the (little-endian) length of the corresponding (non-preamble-prefixed) bootloader of the same "version".


Recommendations:

- Be extremely aware of where you get bootloader files from. The authoritative place to get the unadorned (no preamble) bootloaders are from the Google Factory Images. In the event you need older factory images which are not available from Google any longer, oldblue910 maintains a historical archive of both the factory images and individual OTA patch bundles.

- "bootloader.raw" files should NEVER be flashed with fastboot.

- bootloader ".img" files from the factory full-image distros won't do anything if flashed to the USP - they don't have the preamble that the (pre-existing) bootloader looks for.

- If you must flash a bootloader, avoid the "4.23" bootloader .img files from the JWR66Y and KOT49H factory images. A valid 4.23 bootloader ".img" file has an MD5 signature of df53028033c9eccf4fe5ba7bc198ce24

cheers


* not sure what this file is; but it isn't a bootloader. While there is plenty of arm object code in there, It has almost 0% overlap of ascii strings greater than length 8 with the valid 4.23 bootloader from (e.g.) JWR66V. Possibly worth a look by folks that enjoy disassembly?
Last edited by bftb0; 14th November 2014 at 02:14 AM.
The Following 25 Users Say Thank You to bftb0 For This Useful Post: [ View ]
17th December 2013, 06:31 AM   |  #2  
vorcers's Avatar
Senior Member
Thanks Meter: 108
 
141 posts
Join Date:Joined: May 2012
More
Thumbs up
Thank you Sir for this fine explanation and hints. You prooven my thoughts I had about flashing bootloaders with fastboot. (See my signature ; the posts are still need to be updated for your hints)

I think, that we should "flash" the bootloader only at one point: if we get via ota. Flashing the bootloader is so damn risky... I think, it shouldn't be done three times day and only if there is an update...
Last edited by vorcers; 17th December 2013 at 06:33 AM.
17th December 2013, 06:56 AM   |  #3  
AndDiSa's Avatar
Senior Member
Flag Heidelberg
Thanks Meter: 345
 
1,608 posts
Join Date:Joined: Dec 2009
Yes, I agree, flashing bootloaders is the most risky part, but flashing by OTA has always been more risky than flashing it by fastboot. Using fastboot you can control the flashing process and try to re-flash if anything fails, OTA is out of your control ...

Sent from my Nexus 7 using xda app-developers app
17th December 2013, 02:00 PM   |  #4  
vorcers's Avatar
Senior Member
Thanks Meter: 108
 
141 posts
Join Date:Joined: May 2012
More
Quote:
Originally Posted by AndDiSa

Yes, I agree, flashing bootloaders is the most risky part, but flashing by OTA has always been more risky than flashing it by fastboot. Using fastboot you can control the flashing process and try to re-flash if anything fails, OTA is out of your control ...

Sent from my Nexus 7 using xda app-developers app

This is maybe right, but as bftb0 stated, the bootloaders packed in the factory images can't really be trusted trusted anymore. You will never know what you get. I also can remember, that there were faulty JWR66(V/Y ? I don't know) nexus 7 factory image, which google replaced later. So I think, flashing via OTA is safer. Don't you think google tested this ota-flashing thing till the last bit? Don't you think google tested their ota-packages?

Is there a known ota-fail on stock, always-unmodified device (especially, with bootloader-dead devices following an ota-bootloader-flash)? I made recently a lot of updates of the stock ROM with ota - from Android 4.2.2 till 4.4.2 - none failed. I trust the google-ota mechanism more then all custom-recovery-flashes.... but only, if the device is completly unmodified.

I am excited about your answer!
The Following User Says Thank You to vorcers For This Useful Post: [ View ]
17th December 2013, 02:32 PM   |  #5  
AndDiSa's Avatar
Senior Member
Flag Heidelberg
Thanks Meter: 345
 
1,608 posts
Join Date:Joined: Dec 2009
Quote:
Originally Posted by vorcers

This is maybe right, but as bftb0 stated, the bootloaders packed in the factory images can't really be trusted trusted anymore. You will never know what you get. I also can remember, that there were faulty JWR66(V/Y ? I don't know) nexus 7 factory image, which google replaced later. So I think, flashing via OTA is safer. Don't you think google tested this ota-flashing thing till the last bit? Don't you think google tested their ota-packages?

Is there a known ota-fail on stock, always-unmodified device (especially, with bootloader-dead devices following an ota-bootloader-flash)? I made recently a lot of updates of the stock ROM with ota - from Android 4.2.2 till 4.4.2 - none failed. I trust the google-ota mechanism more then all custom-recovery-flashes.... but only, if the device is completly unmodified.

I am excited about your answer!

It's your decision to trust OTA more than flashing system image files by fastboot, but I think you are missing the point: If you are flashing a corrupt / wrong / ... image then the results by OTA and fastboot are the same. A bootloader update by OTA is nothing else then flashing an image file (like you do with fastboot) , only that it is done automatically on the next reboot of your device while a fastboot flash is done immediately.

I agree that the quality check of Google's system images does not take place at the moment and that the probability of getting a working OTA (at least for the moment) is most likely higher, but this does not influence the flashing process itself. fastboot is more secure than OTA ... if he file you are flashing is working ...
The Following User Says Thank You to AndDiSa For This Useful Post: [ View ]
17th December 2013, 02:51 PM   |  #6  
GedBlake's Avatar
Senior Member
Flag Ashton-under-Lyne, Manchester, UK
Thanks Meter: 401
 
663 posts
Join Date:Joined: Jan 2013
More
Quote:
Originally Posted by vorcers

This is maybe right, but as bftb0 stated, the bootloaders packed in the factory images can't really be trusted trusted anymore. You will never know what you get. I also can remember, that there were faulty JWR66(V/Y ? I don't know) nexus 7 factory image, which google replaced later. So I think, flashing via OTA is safer. Don't you think google tested this ota-flashing thing till the last bit? Don't you think google tested their ota-packages?

Is there a known ota-fail on stock, always-unmodified device (especially, with bootloader-dead devices following an ota-bootloader-flash)? I made recently a lot of updates of the stock ROM with ota - from Android 4.2.2 till 4.4.2 - none failed. I trust the google-ota mechanism more then all custom-recovery-flashes.... but only, if the device is completly unmodified.

I am excited about your answer!

Hi, vorcers...

Yep... I also think that flashing via OTA is safer. Given that this is how 99.9% of all Android users get their updates, (ie, not via the factory images). I would imagine there would have been a bit of an outcry, had faulty bootloaders delivered by OTA updates, bricked a lot of devices.

Also, it's my understanding that OTA's updates bootloaders by 'dropping' a temporary copy (BOOTLOADER.RAW) into a sort of a temporary 'holding' partition (USP/Staging)... prior to it being 'copied' to the bootloader partition proper. I'm guessing some sort of checksum or other similar test is performed on the two bootloaders... the current (old) one, and the (potentially) new one (held in the USP partition), to ensure compatibility.

However, when you fastboot flash a bootloader, you're directly writing OVER the current one... if it's garbage you're writing, you have a dead Nexus. Still, having said that, it's probably a bit more complicated than my possibly over simplified account.

One things for sure, though... never fastboot flash a bootloader... unless you really need to.

I ran the flatline procedure a couple of months ago, and it was a hugely nerve wracking experience. Fortunately, it went without a hitch, and I'm back on bootloader v4.23 (from build JWR66V)... and I now have my 'wheelie' blobs, safely stashed away in a variety of locations.

Testing them though, is something I won't be doing... for tolerably obvious reasons.

Rgrds,
Ged.
Last edited by GedBlake; 17th December 2013 at 03:12 PM.
17th December 2013, 03:30 PM   |  #7  
AndDiSa's Avatar
Senior Member
Flag Heidelberg
Thanks Meter: 345
 
1,608 posts
Join Date:Joined: Dec 2009
Quote:
Originally Posted by GedBlake

...
Also, it's my understanding that OTA's updates bootloaders by 'dropping' a temporary copy (BOOTLOADER.RAW) into a sort of a temporary 'holding' partition (USP/Staging)... prior to it being 'copied' to the bootloader partition proper. I'm guessing some sort of checksum or other similar test is performed on the two bootloaders... the current (old) one, and the (potentially) new one (held in the USP partition), to ensure compatibility.

Flashing a bootloader by fastboot will not overwrite the current one immediately, but it will be flashed on reboot, i.e. the bootloader updating process between fastboot and OTA is almost the same ... beside the possibility to correct a mistake (i.e. flashed a wrong bootloader) as log as you do not reboot your device.
The Following 2 Users Say Thank You to AndDiSa For This Useful Post: [ View ]
17th December 2013, 03:51 PM   |  #8  
GedBlake's Avatar
Senior Member
Flag Ashton-under-Lyne, Manchester, UK
Thanks Meter: 401
 
663 posts
Join Date:Joined: Jan 2013
More
Quote:
Originally Posted by AndDiSa

Flashing a bootloader by fastboot will not overwrite the current one immediately, but it will be flashed on reboot, i.e. the bootloader updating process between fastboot and OTA is almost the same ... beside the possibility to correct a mistake (i.e. flashed a wrong bootloader) as log as you do not reboot your device.

Thanks, AndDiSa...

You know... I'd quite forgotten about that.

But isn't that because the new faulty bootloader (or some other random garbage) HAS actually been written to the eMMC chip, but the old working bootloader is still loaded into memory/RAM (ie., you're still in fastboot mode)... affording you a very slight window of opportunity to reverse or correct the mistake... providing the device isn't rebooted.

The old bootloader is still there, but it's now only stored in 'volatile' memory...

Rgrds,
Ged.
Last edited by GedBlake; 17th December 2013 at 03:56 PM.
17th December 2013, 06:47 PM   |  #9  
OP Senior Member
Thanks Meter: 824
 
2,148 posts
Join Date:Joined: Feb 2010
Hi Ged

First, I should say that your comments here were what encouraged me to check all the (grouper) bootloader images from the Google "factory images" - it triggered a recollection that I had noticed a length difference between the OTA and fastboot versions of the bootloader files some time ago, so I went back and took a look. Thanks for giving me the incentive.

Warning - a bit of a [thread-jack] ahead:

Quote:
Originally Posted by GedBlake

I ran the flatline procedure a couple of months ago, and it was a hugely nerve wracking experience. Fortunately, it went without a hitch, and I'm back on bootloader v4.23 (from build JWR66V)... and I now have my 'wheelie' blobs, safely stashed away in a variety of locations.

There is a comment in that Flatline - Unbrickable Nexus 7 (Wi-Fi + 3G) thread to the effect of:

Quote:
Originally Posted by Xcandescent

There should also be a warning that flashing the bootloader with nvflash prevents it from ever being flashed with fastboot again. I found that out the hard way. I suspect there's a way to get that working again (i.e. flashing in secure boot mode), but you would need to post instructions for doing that.

-XCN-

... but trying to read between the lines, I can not determine if Xcandescent's claims only apply if you leave the "patched" version of the AndroidRoot.Mobi bootloader on the device, rather than using nvflash itself to put back a "stock" bootloader. Reading between the lines, it sounds like subsequently you have not tried using fastboot for flashing a bootloader... do I have that right?

I guess I will put up a question on that thread and see if rayman or lilstevie respond... [/thread-jack]
Last edited by bftb0; 17th December 2013 at 07:18 PM.
17th December 2013, 07:29 PM   |  #10  
GedBlake's Avatar
Senior Member
Flag Ashton-under-Lyne, Manchester, UK
Thanks Meter: 401
 
663 posts
Join Date:Joined: Jan 2013
More
Quote:
Originally Posted by bftb0

Hi Ged

First, I should say that your comments here were what encouraged me to check all the (grouper) bootloader images from the Google "factory images" - it triggered a recollection that I had noticed a length difference between the OTA and fastboot versions of the bootloader files some time ago, so I went back and took a look. Thanks for giving me the incentive.



There is a comment in that Flatline - Unbrickable Nexus 7 (Wi-Fi + 3G) thread to the effect of:



... but trying to read between the lines, I can not determine if Xcandescent's claims only apply if you leave the "patched" version of the android.mobi bootloader on the device, rather than using nvflash itself to put back a "stock" bootloader. Reading between the lines, it sounds like subsequently you have not tried using fastboot for flashing a bootloader... do I have that right?

I guess I will put up a question on that thread and see if rayman or lilstevie respond...

Hi, bftb0...

It's good to see you around again. I must admit, that most of the stuff you post, I really, really don't understand... but I always learn something new.

Concerning flatline... Well, I ran it sometime back in October...

I knew beforehand that there where known issues concerning fastboot flashing the bootloader from build JWR66Y (ie, it won't fastboot flash) so now I ALWAYS keep a copy of the v4.23 bootloader from build JWR66V stored on my laptop... which came in useful for the flatline procedure.

The whole procedure revolves around flatlines Custom Recovery...

Once I'd fastboot flashed the specially modified Flatline Custom Recovery (which is based on CWM) to the recovery partition, I then went into the ADVANCED option... and selected option 1: flash AndroidRoot BL... this flashes the AndroidRoot Custom Bootloader - (you don't actually flash this yourself - the Flatline Custom Recovery does it for you).

Following the instructions to the letter, I then booted normally into Android.

I shutdown my Nexus 7 completely, and rebooted into this modified AndroidRoot bootloader in fastboot mode... to discover that the version number had been 'downgraded' to v4.13. Nothing there signifies or indicates it is in fact the flatline AndroidRoot BL... it just looks like a regular v4.13 bootloader.

After selecting the RECOVERY option in this modified bootloader, as you would normally, to get into either standard CWM or TWRP, it boots back into the Flatline Custom Recovery again.

Selecting the ADVANCED option again... I now choose option 2: generate wheelie blobs... these blobs were then generated, which I subsequently found in /data/media/AndroidRoot on the Nexus 7 itself. Having made multiple copies of them, it was then just a matter of closing the operation by doing two things...

*** fastboot flashed back to the normal v4.23 bootloader from build JWR66V...

...and after a normal reboot...

*** fastboot flashed back to the version of TWRP I was using at the time...

A summary

1). I fastboot flashed the special Flatline Custom Recovery.
2). In this special Custom Recovery, in the Advanced menu option, I selected option no.1... it flashed the AndroidRoot v4.13 bootloader.
3). I rebooted normally into Android.
4). I rebooted into the Flatline Custom Recovery again (via the bootloader).
5). In the Advanced menu option, I selected 'generate wheelie blobs'.
6). Once generated, I copied them from /data/media/AndroidRoot .

-- Now to return everything back to normal...---

7). I fastboot flashed the regular v4.23 bootloader from build JWR66V.
8). I fastboot flashed the version of TWRP I was using at the time.

I didn't need to use nvFlash to restore the standard bootloader... I just used the standard fastboot flash bootloader bootloader.img syntax, to reflash v4.23.

And that's pretty much it really... obviously I haven't had the opportunity to test out those 'blobs'... and hopefully, I'll never have cause to.

Hope this helps.

Rgrds,
Ged.
Last edited by GedBlake; 17th December 2013 at 07:32 PM.

The Following 2 Users Say Thank You to GedBlake For This Useful Post: [ View ]
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes