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

EDIT 12/8/2015 - THIS THREAD IS NOW OBSOLETE.

In Early April 2015, Google retroactively changed a large number of prior factory images for nakasi/grouper (possibly nakasig too). Read this thread from post #57 onward.

Thank to wugfresh for noticing the changes.

Note that because previous binary images are now "in the wild" (or, you might have retained your own archives) you still need to be aware of what you are flashing - cross-check your checksums, folks.



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:


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.:


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?

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:

GedBlake said:

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.

Click to expand...

Click to collapse

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

Xcandescent said:

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-

Click to expand...

Click to collapse

... 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]

GedBlake said:

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.

Click to expand...

Click to collapse

Thanks!

iamelton said:

i have fastboot flashed the bootloader image from KOT49H, and it *seems* to be working fine..
what could be the potential issue here, a possible future brick?
is it better to flash back the bootloader image from KRT16S as suggested by the OP?

tia..

Click to expand...

Click to collapse

Are you sure it actually got flashed?

Others have reported "signing errors" relating to bootloader flashing in the past, so I suppose it is possible that some form of sanity checking is performed by the existing bootloader. Meaning, that the fastboot flash command actually does transfer the image file to the tablet (probably into RAM because it is a fairly small file) but if it doesn't pass those sanity checks, it never really gets burned to the eMMC chip by the pre-existing bootloader. Unfortunately, because the bootloader is proprietary, we don't really know what is checked and what isn't.


(I think most folks who hard-bricked their tablet either *erased* their bootloader using fastboot and then rebooted before they had flashed something, or else they accidentally over-wrote /dev/block/mmcblk0p{0,1} from a root-privileged process inside a booted ROM or recovery)

If your tablet is working I wouldn't fix something that isn't broke.

But as I said, I'm pretty confident that whatever that thing is in the KOT49H factory image, it is NOT a valid bootloader.


(Interpreting the above: there are 1797 unique ASCII strings (out of 1935) of length 8 or greater in the KRT16O version of the file; and there are 3839 unique ASCII strings (out of 4363) of length 8 or greater in the KOT49H version. And only 25 matching strings between the two of them!)

There's really only two plausible explanations for that:

- That Google/Asus completely replaced their bootloader code - and gave it the same name! -OR-
- That blob in KOT49H isn't a bootloader.


cheers

Thanks @s107ken

It is reassuring to know that the pre-existing bootloader performs signature checking against the file blobs when using fastboot.

I presume the same thing happens when the OTA version of the bootloader is dropped into the staging partition - the pre-existing bootloader has the opportunity to examine it for validity.

But if someone were to flash a bad blob directly from a root shell using "dd" they will certainly hard-brick their N7.

@andogeek10

Some preliminaries - are 2012 versions of the N7 still being sold? If you are talking about the 2013 N7, then you are in the wrong forum. A lot of this stuff is device dependent (as you are finding out), so you should consult owners who have experience with the specific device you intend to purchase.

andogeek10 said:

i) If I update my android version using the OTA feature to 4.4.2 (KOT49H), it would also flash/update my bootloader, right?

Click to expand...

Click to collapse

Well, you didn't say which version of bootloader you will be on. The OTAs are patch bundles, so if you already had the most recent bootloader, the OTA process would not apply it again.

Having said that, there is no evidence that Google/Asus got any of the OTA bundles wrong - they are different from the "factory images" hosted by Google. So, first: this thread doesn't apply to OTAs, and second (see posts just above), the pre-existing bootloaders appear to do a sanity/crypto signing check before they allow the bootloader to be flashed into place for reals, so there is very little danger involved in an OTA. (Based on the recent reports, it isn't even obvious to me how folks would have been able to bork their bootloaders, unless they manually flashed it into place using a root shell and the dd command (either with the OS running or with a custom recovery running).

andogeek10 said:

So, according to this thread the bootloader included in that update is not right (or doesn't work properly? ) and then would I be required to flash the bootloader image from the KRT16S update?

Click to expand...

Click to collapse

See above. If you were somehow able to flash a dud bootloader to the device, as soon as you power-cycled it, it would be a hard brick. I haven't been paying attention to the 2012 N7 forum recently, but I think the only thing that will save someone in that situation is that if they had previously prepared for the eventuality of a hard brick by using the flatline method.

andogeek10 said:

ii)I was reading through the flatline thread, and initially it seemed amazing that by generating a few blobs, you could unbrick your device. But, after reading a few pages ahead it seemed that many people were facing problems and it now seems a dangerous procedure. So my question is: Is it really recommended that an individual generate those blobs and by doing so, follow that nerve racking procedure?

Click to expand...

Click to collapse

Folks will have different opinions about this, but honestly the only people who bork their bootloader are people that have extremely sloppy habits*. (Grab files from anywhere, never check file MD5 sigs, etc). Given that the set of instructions provided by the flatline devs are frankly quite vague on several points, you have to wonder if it is a good idea for folks with sloppy habits to be performing vaguely-described procedures, especially since the procedures involve the dangerous operation in question (flashing a bootloader).

[Edit]* There is one high risk way a borking can happen that is probably easy for even skilled folks to accidentally perform; but only if they are in a hurry and not paying attention. And that is to accidentally do a "fastboot erase bootloader" when the intended command was "fastboot erase boot". Even in this case though, the existing bootloader is still present an running in memory; so as long as the tablet continues to run and you can communicate with it in fastboot mode, this type of mishap is correctable if you immediately flash back into place a valid bootloader. But if you turn the tablet off, it's a brick at that point. I don't really know why fastboot allows you to perform the erasure of the bootloader partition - it should be sufficient to simply flash something over the pre-existing bootloader. Something could still go wrong - as erasure of blocks always happens when flashing new data into flash memory; otoh, there is no delay between wiping and replacement with a valid image in the normal case. [/Edit]

andogeek10 said:

iii)If I were to flash a custom kernel, would it include a custom recovery or would I have to install a custom recovery using fastboot. And if the custom kernel will include a custom recovery, will overwrite the existing custom recovery?

Click to expand...

Click to collapse

Custom kernels and recoveries are independent bootable images stored in different partitions. You don't get one with the other**, nor does one overwrite the other**. Generally, a conservative and safe 2012 N7 rooting sequence is

0) Install the Android SDK and necessary drivers on your PC (no drivers needed for OS/X or Linux)
1) unlock the bootloader using fastboot (this wipes any user data on the entire tablet)
2) soft-boot a custom recovery image using fastboot, e.g.
"fastboot boot openrecovery-twrp-2.6.3.1-grouper.img"
3) use the soft-booted recovery to immediately take a FULL STOCK Nandroid backup - including the STOCK recovery!
4) hard flash the custom recovery image (e.g. this time "fastboot flash recovery openrecovery-twrp-2.6.3.1-grouper.img", instead of "fastboot boot openrecovery-twrp-2.6.3.1-grouper.img")
5) Use a "flashable zip" install of SuperSU (push the file to the device using adb with the recovery running, or put it on a USB key and plug that to the device with a OTG cable)
6) If you want, you can make yet another Nandroid at this point to capture a baseline "lightly rooted Stock" backup.
7) Immediately - before you do anything else - get copies of those full stock & lightly rooted stock backups someplace off of the tablet. (Note: TWRP supports OTG USB devices - you could have written the Nandroids to a USB thumb drive in steps 3 and 6 if you had wanted to.)

8) Start doing what you will as far as rooting goes.


Now, why did I give you the instructions above? Simple - the only way I have ever updated my bootloader is by taking a Nandroid backup of my current ROM, restoring the FULL STOCK Nandroid backup - INCLUDING THE FACTORY RECOVERY. This results in a device which is 100% stock and not even rooted... (but the bootloader is still unlocked). Then I take the OTA, and let the OTA do the dirty business.

And when that completes, I repeat steps 2) - 6) all over - FOR THE NEW VERSION OF 100% STOCK INCLUDING THE STOCK RECOVERY.

And check this out - I don't even use stock or lightly rooted stock as a daily driver.

So why all the above nonsense?

First because the OTA process has a bunch of crypto checks built in that protect you from hazards like the one you are anticipating. Second because running OTAs against modified ROMs will many times result in OTA failure.

And third, so that I will have 100% stock Nandroid backups (including the stock recovery) for every stock release that has ever been issued for the tablet while I owned it. When I go to sell the thing, I can roll it back to 100% stock - for any release I want, lock the bootloader, perform a factory reset... and it will be as if it just came from the factory.

Fourth, those stock releases will be fully capable of accepting future OTAs - unlike customized ROMs.

good luck with your device(s)


** a boot image is = kernel + ramdisk. Both the "boot" and "recovery" images are boot images. In stock devices, the kernel used by the stock recovery is identical to the kernel used by the OS boot - they differ only in their ramdisk. So that means that when an OTA comes along that modifies the kernel used in the regular (Android) boot, the stock recovery partition will also get updated.

In the recovery, the booting does not depend on anything in the /system or /data partition (kinda), whereas the regular boot image chains into full-up Android UI, apps, etc. So the recovery allows you to do offline maintenance of /system and (portions of) /data. What you might have seen on other devices, is that during application of the OTA, the recovery image is actually generated by a patch set that operates on the stock boot image. Quite literally, the recovery is generated from the boot image with a process that looks like

/boot (image) + boot-to-recovery-patch.p -> recovery (image)

Some older android phones would flash the stock recovery back into place (using the above method or similar) *every time the phone booted*. This was done via some scripts in /system. IIRC, something similar to this is present in Stock N7 releases, perhaps at /system/boot-from-recovery.p (and related init.d scripts) It is possible that the custom recoveries are aware of this and will relocate or remove this gearing for you (in the same way that they will offer to install SuperSU for you). But, if you notice that your custom recovery keeps getting replaced with the stock recovery when you use lightly-rooted-stock, this is the mechanism that does this.

.