[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?

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

.

This is not a help thread. It would be in the help section if that were the case.

If you take one thing away from this thread it is this:

YOU SHOULD NOT BE ATTEMPTING TO FLASH THE BOOTLOADER using a bootloader file from known bad sources.
(All the correct sources are listed in the OP.)


If you take away two things from this thread, the 2nd item should be this:

THERE IS NO NEED TO RE-FLASH THE 4.23 BOOTLOADER IF YOU ALREADY HAVE IT INSTALLED.


If you want to take a 3rd thing away from this thread, here's my suggestion:

THERE IS PROBABLY [size=+1]NEVER ANY REASON WHATSOEVER[/size] TO USE FASTBOOT TO **ERASE** THE BOOTLOADER.


Sorry, but I don't know how this can be made any clearer.


.

Hi, this weekend I flashed bootloader to my own N7 2012 3G(tilapia) many times.
Describes in summary (but too looong), attached full report.

I found JDQ39(4.2.2) and KRT16S(4.4) are only correct bootloader file?
Grouper and Tilapia uses same bootloader.img?
What happen google / asus software release?


JDQ39, KRT16S succeeded flash bootloader

JWR66Y, KOT49H failed flash bootloader

bftb0 said:

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

Click to expand...

Click to collapse

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.