5,595,428 Members 48,397 Now Online
XDA Developers Android and Mobile Development Forum

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

Tip us?
 
bftb0
Old
#11  
Senior Member - OP
Thanks Meter 774
Posts: 2,120
Join Date: Feb 2010
Quote:
Originally Posted by GedBlake View Post
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.
Thanks!
"I'm gonna start coding placebo apps. That way I will be sure that the complaints are real and the praises hollow."
 
TToTT
Old
#12  
TToTT's Avatar
Member
Thanks Meter 16
Posts: 47
Join Date: Nov 2013

 
DONATE TO ME
Quote:
Originally Posted by bftb0 View Post
- 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
A download of that file can be found here, just as an FYI.
The Following User Says Thank You to TToTT For This Useful Post: [ Click to Expand ]
 
iamelton
Old
(Last edited by iamelton; 18th December 2013 at 09:07 PM.)
#13  
iamelton's Avatar
Senior Member
Thanks Meter 294
Posts: 842
Join Date: Feb 2011
Location: Hong Kong
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..
LG Nexus 5 (D821) : KitKat 4.4.2 (KOT49H) rooted (by bigxie), Xposed Framework (by rovo89, Tungstwenty)

LG Nexus 4 (E960) : KitKat 4.4.2 (KOT49H) rooted
ASUS Nexus 7 (ME370T) : KitKat 4.4.2 (KOT49H) rooted
Sony Xperia S (LT26i) : Jelly Bean 4.1.2 (6.2.B.1.96) rooted, DooMKernel (by DooMLoRD)
Huawei IDEOS X5 (U8800H) : Aurora ICS 5.0u21 (by dzo)


==================================================

[INFO] Disable OTA update notification
 
bftb0
Old
#14  
Senior Member - OP
Thanks Meter 774
Posts: 2,120
Join Date: Feb 2010
Quote:
Originally Posted by iamelton View Post
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..
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.

Code:
$ strings -8 nakasi-kot49h/bootloader-grouper-4.23.img  > kot49h-strings.txt
$ strings -8 nakasi-krt16o/bootloader-grouper-4.23.img  > krt16o-strings.txt

$ wc -l *-strings.txt
  4363 kot49h-strings.txt
  1935 krt16o-strings.txt
  6298 total

$ cat kot49h-strings.txt | sort | uniq > kot49h-strings-unique.txt
$ cat krt16o-strings.txt | sort | uniq > krt16o-strings-unique.txt

$ rm *-strings.txt

$ wc -l *-strings-unique.txt
  3839 kot49h-strings-unique.txt
  1797 krt16o-strings-unique.txt
  5636 total

$ cat *-strings-unique.txt | sort | uniq | wc -l
5611

$ cat *-strings-unique.txt | sort | uniq -d | wc -l
25
(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
"I'm gonna start coding placebo apps. That way I will be sure that the complaints are real and the praises hollow."
 
iamelton
Old
#15  
iamelton's Avatar
Senior Member
Thanks Meter 294
Posts: 842
Join Date: Feb 2011
Location: Hong Kong
the strange thing is that i flashed both the JWR66Y and KOT49H version bootloaders..
the JWR66Y one did give me a flash error (something like unable to overwrite) during the process, however, the KOT49H gave me a success result..
therefore before finding this thread i was under the impression that my n7 was using the KOT49H bootloader happily..
but now im a bit confused..

anyway as u suggested, theres no need to fix something thats not broken..
and probably in future i shall not flash bootloaders so promptly (or maybe better not to flash at all unless necessary..)
LG Nexus 5 (D821) : KitKat 4.4.2 (KOT49H) rooted (by bigxie), Xposed Framework (by rovo89, Tungstwenty)

LG Nexus 4 (E960) : KitKat 4.4.2 (KOT49H) rooted
ASUS Nexus 7 (ME370T) : KitKat 4.4.2 (KOT49H) rooted
Sony Xperia S (LT26i) : Jelly Bean 4.1.2 (6.2.B.1.96) rooted, DooMKernel (by DooMLoRD)
Huawei IDEOS X5 (U8800H) : Aurora ICS 5.0u21 (by dzo)


==================================================

[INFO] Disable OTA update notification
 
s107ken
Old
#16  
Senior Member
Thanks Meter 168
Posts: 134
Join Date: Apr 2013
Location: Fukushima

 
DONATE TO ME
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?

Code:
TILAPIA (N7 3G, 2012) BOOTLOADERS 
DERIVED FROM Google "Factory Images":
BYTES    MD5SUM				   ROM     FACTORY_IMAGE_FILENAME                        strings *.img | grep BOOTLOADER

2146892  bffa744a6847b5bede2bf445427ef80e  JDQ39   ./nakasig-jdq39/bootloader-tilapia-4.18.img   BOOTLOADER VERSION - 4.18
- - -    - - -                             JWR66V  (I don't have this factory image)             - - -
2151068  5bdb2e87370cdb1a7ea14bb0c3e21390  JWR66Y  ./nakasig-jwr66y/bootloader-tilapia-4.23.img  BOOTLOADER VERSION - 4.23
- - -    - - -                             KRT16O  bootloader & radio image didn't contain!!     - - -
2150992  df53028033c9eccf4fe5ba7bc198ce24  KRT16S  ./nakasig-krt16s/bootloader-tilapia-4.23.img  BOOTLOADER VERSION - 4.23
4005632  797a8ddfe19bfe4c485f8a8c119f1bdd  KOT49H  ./nakasig-kot49h/bootloader-tilapia-4.23.img  BOOTLOADER VERSION - %s
JDQ39, KRT16S succeeded flash bootloader
Code:
nakasig-jdq39# fastboot flash bootloader bootloader-tilapia-4.18.img 
sending 'bootloader' (2096 KB)...
OKAY [  0.338s]
writing 'bootloader'...
OKAY [  1.230s]
finished. total time: 1.569s

(bootloader screen left-top) "Signature match."
JWR66Y, KOT49H failed flash bootloader
Code:
nakasig-jwr66y# fastboot flash bootloader bootloader-tilapia-4.23.img 
sending 'bootloader' (2100 KB)...
OKAY [  0.335s]
writing 'bootloader'...
FAILED (remote: (InvalidState))
finished. total time: 0.469s

"Signature mismatch."
Attached Files
File Type: txt tilapia-bootloader.txt - [Click for QR Code] (16.4 KB, 5 views)
Nexus - Galaxy Nexus(GT-I9250), Nexus 4, Nexus 7 3G(2012), Nexus 10
Phone - Galaxy S2(GT-I9100), Galaxy Note(SC-05D, jp), IS01(jp)
Tablet - ONDA Vi40 DC
Other - NVIDIA Shield, GameStick, OUYA, MK802
Board - AM335x, BeagleBone Black, pcDuino, Raspberry PI, Wandboard Quad
Give me a candy, paypal link: http://www.geocities.jp/s107ken/paypal.html
Want - Nexus 5, Nexus 7 2013, Pandaboard ES, Radxa Rock
The Following 2 Users Say Thank You to s107ken For This Useful Post: [ Click to Expand ]
 
bftb0
Old
#17  
Senior Member - OP
Thanks Meter 774
Posts: 2,120
Join Date: Feb 2010
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.
"I'm gonna start coding placebo apps. That way I will be sure that the complaints are real and the praises hollow."
 
andogeek10
Old
#18  
andogeek10's Avatar
Senior Member
Thanks Meter 451
Posts: 997
Join Date: Apr 2012
Location: New Delhi
Post Doubts

Hey guys, I've got a few questions relating to the bootloader, its versions and nvflash.
Hopefully by the next week I'm going to be a proud owner of the Nexus 7. I'm not new to the android world or flashing. But, it'll be a new experience for me to own a nexus device. I own a Xperia Mini Pro (Sony Ericsson) where the only fastboot command used is the command used to flash kernels, so all this talk about using fastboot to flash bootloaders, baseband etc. is definitely a big change. So pardon me if make a mistake or ask a wrong question.

I'm confused about a few things :
i) If I update my android version using the OTA feature to 4.4.2 (KOT49H), it would also flash/update my bootloader, right? 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?
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?
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?

Thanks a lot.
 
bftb0
Old
(Last edited by bftb0; 28th January 2014 at 07:48 PM.)
#19  
Senior Member - OP
Thanks Meter 774
Posts: 2,120
Join Date: Feb 2010
@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.

Quote:
Originally Posted by andogeek10 View Post
i) If I update my android version using the OTA feature to 4.4.2 (KOT49H), it would also flash/update my bootloader, right?
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).


Quote:
Originally Posted by andogeek10 View Post
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?
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.

Quote:
Originally Posted by andogeek10 View Post
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?
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]

Quote:
Originally Posted by andogeek10 View Post
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?
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.

.
"I'm gonna start coding placebo apps. That way I will be sure that the complaints are real and the praises hollow."
The Following 3 Users Say Thank You to bftb0 For This Useful Post: [ Click to Expand ]
 
andogeek10
Old
#20  
andogeek10's Avatar
Senior Member
Thanks Meter 451
Posts: 997
Join Date: Apr 2012
Location: New Delhi
Thanks a lot for clearing these doubts of mine. Yes, the 2012 version is still sold ( at least in India it is ) and is much cheaper than the 2013 version.
2012 Nexus 7 - INR 9100
2013 Nexus 7 - INR 21000
And yes, i do know the difference between Nexus 7 2012 and 2013 (at least the major ones :P).
About the nvflash blobs generation, I've decided to not do it as I would be directly updating via OTA to 4.4.2 and then unlock the bootloader. Also, I would be updating via OTA only in the future, so I will not flash the bootloader by fastboot ( and hopefully reducing the risk of achieving a brick).
I was confused about the kernel and recovery as in the 2011 Xperia devices, there is no separate recovery partition and thus the recovery changes with every kernel flash.

I had read through most of the sticky topics and these were the only doubts remaining. Thanks again for clearing them.

Sent from my Xperia Mini Pro using XDA Premium 4 mobile app

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes