Originally Posted by XBIRDIE98

[ Snip... ]
PS: efrant's most likely right about the whole "Google logo/boot logo" change thing. It's probably another aspect of this mystery, like the lock/unlock state and this wipe behavior. I remember that in my Glacier days, there was a way to flash the 'splash screen' using fastboot. While the HTC 'splash screen' is probably a very different method of doing this, (considering we don't have a splash1 partition as far as I know) I thought it might be interesting to have a frame of reference for the kind of stuff that we're playing with - the (relatively) low-level pieces of software that support the kernel and Android and make basic, essential stuff work.

There are some JFIF tags (JPEG images) embedded in the sbl partition dump. It would not be too hard get the correct positions and offsets, and then use "dd" to flash images of the same or smaller size over top of them. Somebody might even want to write an app to do that; but I am much more interested in solving this mystery of the non-erasing bootloader.

---------- Post added at 10:13 PM ---------- Previous post was at 09:36 PM ----------

I am curious to know if the erase functionality has been removed only within the bootloader, or at a lower level. One way to find out (if anyone knows the commands to do this) is to try to format the userdata partition under a running kernel (ie: from android or recovery).

If the erase works, it will mess up your phone to the point where you will need to flasboot flash a new userdata.img, so I don't know if anyone wants to try it. If the erase doesn't work, then we know that the functionality is disabled at a very low level.

Folks, I'm sorry to report that I've hit the wall with analyzing those EFS dumps. I had hoped that I could eliminate the device-specific files by comparing the two non-Play-Store images uploaded, and that there remaining differences between those two images and the Play-Store image would be small and easy to analyze.

Unfortunately, there are just too many such differences to begin to figure out which ones might be relevant. Also, the recent discovery that Play Store devices do not erase as expected with adb erase commands makes me wonder if this difference is lower-level, like in hardware, nvram, or fuses.

I'm going to throw in the towel on the efs approach for now, and devote my hacking time to other protects like my app or flashing Jelly Bean. If any of us has any new ideas, either of other data to analyze or of a better way to analyze efs data, I'd be happy to try hacking on this some more.

Anyone have access to bootloader source code? :P

Sent from my BANNED Unified-Search-enabled Galaxy Nexus.

Mine didn't wipe the first time I unlocked, but it wiped everything as it should after I had relocked and then unlocked again.

Sent from my Galaxy Nexus

Originally Posted by MikeyMike01

Mine didn't wipe the first time I unlocked, but it wiped everything as it should after I had relocked and then unlocked again.

Sent from my Galaxy Nexus

Galaxy Nexus from the Play Store? Very, very interesting. I wish I (or one of us) had Adam Outler's tools and skills to single-step what the bootloader is actually doing, and (since the bootloader images are identical between all the Galaxy Nexus variants) where it is looking to make wipe/don't-wipe decisions.

Sent from my BANNED Unified-Search-enabled Galaxy Nexus.

Originally Posted by segv11

Galaxy Nexus from the Play Store?

Yes, from the Play Store.

Sent from my Galaxy Nexus

Originally Posted by segv11

...
However, the differences I can find appear to be two embedded jpeg images... Archpope, I assume you are running PRIMELA03, as you are on 4.0.4... but did you tweak your boot logos? Because the differences I am finding between your sbl and ours are two jpeg images.

Did anyone check what these JPEG image differences were? (And if these differences are also present in other/same service providers.) IMHO, I'd think that would be a reasonable way to hide the bootloader lock/unlock bit(s)...

Originally Posted by E:V:A

Did anyone check what these JPEG image differences were? (And if these differences are also present in other/same service providers.) IMHO, I'd think that would be a reasonable way to hide the bootloader lock/unlock bit(s)...

We've already figured out where the lock/unlock flag is stored: http://forum.xda-developers.com/show...&postcount=131

Changing that flag will lock/unlock your bootloader (and without wiping data).

What we haven't figured out is what causes some devices to wipe when unlocking using fastboot, while others do not.

Good read, very interesting stuff. Too bad the thread ends 'open' without a conclusive answer. I hope someone can and will resolve this mystery.

Originally Posted by Petrovski80

Good read, very interesting stuff. Too bad the thread ends 'open' without a conclusive answer. I hope someone can and will resolve this mystery.

I agree. This was probably one of the best threads I've seen in a long time. The collaboration among the posters seen here is, in my opinion, an excellent example of how working together can achieve something that would have taken one individual significantly longer to accomplish.

Originally Posted by efrant

I agree. This was probably one of the best threads I've seen in a long time. The collaboration among the posters seen here is, in my opinion, an excellent example of how working together can achieve something that would have taken one individual significantly longer to accomplish.

Yes, exactly. Good efforts from several posters.

Sent from my Galaxy Nexus using Tapatalk 2