yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] DOHCtor:
I was assuming that (maybe not the Docomo version) all GSM versions had the same hardware and if that's the case, then it's software related as to why your data's are not being wiped. Maybe the bootloader that came with the imm30d before it updated to imm76i doesn't wipe the data upon unlocking? Do me a favor, go into bootloader mode and tell me if your bootloader version is primela03.

I didn't get a chance to look at the bootloader versions when I received my Galaxy Nexus because I oem unlocked all three of them right away and fastbooted the latest takju images via flash-all.sh script on all of them just to avoid waiting for ota. I didn't want my dad and brother come to me and ask me "why is it telling me to update? What is it?"
[Samsung Galaxy Nexus] ragnarokx:
Interesting. I did the OTA update before unlocking.

Sent from my Galaxy Nexus

Edit: you realize that flashing factory images will also wipe your device, right?
[Samsung Galaxy Nexus] bobsbbq:
Well sorry sir your wrong. At least I can say this for the first initial unlock and root using the Nexus tool kit. I have two of them and both of them did not wipe. When they booted up everything was the same as before I unlocked and rooted.

After reading some of the comments in the Tool Kit thread is is believed the USA version has a slightly different bootloader. Some think Google wanted to make it easier as they know people are going to root their phones.

There maybe other ways to unlock the bootloader which causes a wipe. But I can assure you using the tool kit doesn't.
[Samsung Galaxy Nexus] NCguy:
I wont say that its not possible but I have read all the way through the play store gsm thread and not a single purchaser reported a wipe after unlock.
[Samsung Galaxy Nexus] DOHCtor:
Yes, but after flashing the takju images for them, i loaded it up and did testing on the phone to make sure everything was okay. Afterwards, I would lock, unlock, and lock the bootloader again to wipe all data (including usb storage). How do I know it wipes? Because I am presented with the setup wizard again upon boot, and all the sample photos that I've taken to test the camera in the DCIM folder are gone.

Someone mention they unlocked bootloader and rooted with toolkit. For all those that did not have data wipe, which method did you guys use? I didn't use toolkit, I did it the old fashion way with setting up ADB. I'm use to doing that way since the G1 days.

edit: I'm not calling anyone a liars and this information about a no wipe bootloader unlock is all new to me. I'm just trying to find out why it's not wiping for some people...
[Samsung Galaxy Nexus] ragnarokx:
So you have no way of knowing if your device was wiped the first time you unlocked, since you flashed factory images immediately afterwards. Could there be a difference between unlocking the first time and subsequent times? I wouldn't know because I only unlocked once.

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] DOHCtor:
Then there's a possibility that all GSM Galaxy Nexus doesn't wipe the first bootloader unlock. Maybe people didn't take notice the first time they did it. Just a theory.

Can anyone that relocked and unlocked the bootloader chime in and let us know if it wiped their data?
[Samsung Galaxy Nexus] sarni84:
Dohctor maybe our play store versions are later revisions idk? All I know is I also have two galaxy nexuses from play store and when unlocking boot loader it did not erase the data that I had on my phone all of my apps were still there also. Obviously play store nexuses do not wipe data upon unlockingand who knows why. Anyways I will make a video to show the non believers I have no problem doing that.... I also relocked and unlocked boot loader because I tried starting dead fresh to get google wallet to work again let's just say that if u do not wipe or reset data inside the app your beat so I thought locking boot loader and unrooting then reflashing stock image would help. It didn't .... secure element is beat on my one device. So I unlocked the "relocked" boot loader ( this is what it says when u relock it) anyways it told me it would wipe data I proceeded. Rooted again threw touch recovery on booted into recovery and there was my aokp backup waiting for me :P ... so unlocked relocked and unlocked again...no data loss. Pretty cool I think of it as if u have data on your phone that is that important do not root then! So it not wiping data doesn't bother me. ....all using toolkit btw
[Samsung Galaxy Nexus] DOHCtor:
Even if you don't root, people can get access to your data if it doesn't wipe upon unlocking the bootloader. For example; you lose or someone steals your phone and wants your data for some reason. You never unlocked or rooted your phone, it's bone stock. The thief will hook it up to his or her computer and unlock the bootloader and boot up clockwork recovery and pull all your data, including files and pictures in your usb storage (unless you enable encryption). I'm not paranoid, I telling you guys what's possible.

That sucks that relocking and unlocking the bootloader didn't wipe data for you. Don't have to make a video because I believe you. And about having a later version, that's not true. I ordered mines the first day Google made it available in the Play Store.

It sucks that Google Wallet still has that SE error. I always reset data within the app every time I switch roms. Glad my Wallet still works :)
[Samsung Galaxy Nexus] efrant:
I've attached my sbl and xloader partitions from my unlocked non-Play Store GNex running PRIMELA03.
[Samsung Galaxy Nexus] segv11:
You're right that sbl and xloader would be the first things to check.

If they are not fruitful, then we might want to check efs. We know that it has your IMEI, but it might ALSO store and indication for wipe-on-unlock. Fortunately, it is NOT a raw partition: it is a filesystem which mounts on /factory. Before we even try analyzing the raw efs partition, we could make a tar (or zip) file from the /factory tree and analyze it file-by-file.

After that, we should look at mmcblk0boot0 and mmcblk0boot1. I think one of those is where Chainfire found the flash counter in the SGSII (for Triangle Away), so we know that Samsung puts _some_ stuff there.

It's too bad that the bootloader is not open source... but then AdamOutler commented earlier on the thread that we should "thank the Samsung source code" for the hint to look in the param partition. I wonder if that means the source is available somewhere -- even if not in AOSP.
[Samsung Galaxy Nexus] efrant:
You're right, AdamOutler did say that! I wonder where he got it from. It would be awesome if it was available somewhere (although I would find it hard to believe that Samsung would prove the source for that).

[aside]

Although not very related to our discussion, rolle3k managed to disassemble the bootloader for the Nexus One. See here. Not sure how he managed to do that, but he did. :) Which leaves me optimistic.

[/aside]

EDIT: I've looked here, but I couldn't find anything related to the bootloader.
[Samsung Galaxy Nexus] segv11:
Your sbl is exactly the same as mine (same MD5), and I'm on a toro.

EDIT:

Your xloader is also exactly the same as mine. (I previously did the wrong comparison: I'm revising this post to correct my error.)

I've attached my xloader (as a bzip2 file) in case anyone is interested.

It's still possible that the wipe-on-unlock flag is there: we'll need a Play Store dump of sbl and xloader to be sure. But it's awfully suspicious that toro, which is a _very_ different device, has the exact same files.
[Samsung Galaxy Nexus] efrant:
Well, not really given the the bootloader image that flashes to those two partitions is identical for maguro and toro.
[Samsung Galaxy Nexus] segv11:
I think all the Play Store Galaxy Nexus owners are too busy flashing the leaked Jelly Bean to help us hack on their bootloader.
[Samsung Galaxy Nexus] efrant:
LOL.

Archpope just told me he will help out. :good:
[Samsung Galaxy Nexus] harveydent:
Here's locked and unlocked Play store zips following the instructions from efrant a few pages ago

Oh, and I unlocked using fastboot to get the unlocked zip: still no wipe
[Samsung Galaxy Nexus] efrant:
Excellent! Thank you.

By the way, which bootloader was on your device when you dumped these?

"Sorry, you are limited to 8 thanks per day" :( I'll hit you up tomorrow.
[Samsung Galaxy Nexus] harveydent:
Bootloader says PRIMELA03

Stock ROM, Franco's Kernel, UGLA radio, rooted, if any of that is relevant/important
[Samsung Galaxy Nexus] Mach3.2:
Here's a cookie for you:)

Pressed from my Galaxy Nexus.
[Samsung Galaxy Nexus] segv11:
sbl and hexloader

So far, we have the following sbl and xloader dumps:

segv11 (toro, unlocked)

efrant (non-play-store maguro, unlocked)

harveydent (play-store maguro, unlocked)

harveydent (play-store maguro, locked)

All four sets are identical, right down to the same md5 hashes.

Sorry, efrant, I don't think the flag we seek is here. Now it's time to look deeper. Like Chainfire said about the SGSII flash counter "it has to be stored on the device somewhere" -- where do we want to look next?
[Samsung Galaxy Nexus] efrant:
Alright. At least that's out of the way. Thanks for looking into it.

I'll dump my mmcblk0boot0 and mmcblk0boot1 and post them hopefully tonight.

If we get nothing from that, then I guess we'll need to compare efs. Maybe I'll even .tar it up anyway and send you a link.
[Samsung Galaxy Nexus] segv11:
If you can get it to me this evening, I'll do a quick compare.

After that, I will be unavailable Friday and most of the weekend. I will respond to all queries when I am able to get back on XDA: probably Monday.
[Samsung Galaxy Nexus] efrant:
I've attached my mmcblk0boot0 and mmcblk0boot1 partitions.

This is how to do it:

adb shell

su

dd if=dev/block/platform/omap/omap_hsmmc.0/mmcblk0boot0 of=/sdcard/mmcblk0boot0.img

dd if=dev/block/platform/omap/omap_hsmmc.0/mmcblk0boot1 of=/sdcard/mmcblk0boot1.img

exit

exit

adb pull /sdcard/mmcblk0boot0.img

adb pull /sdcard/mmcblk0boot1.img
[Samsung Galaxy Nexus] efrant:
So if anyone with a Play Store GNex is willing to share the contents of his/her /factory directory, I will do the same, and maybe we can solve this mystery.
[Samsung Galaxy Nexus] harveydent:
My system's a mess since I dirty flashed a JB ROM. Or that won't affect the factory directory?
[Samsung Galaxy Nexus] efrant:
Nope it won't affect /factory. That directory is never touched by flashing ROMs or anything. It ususaly stays as is, from the... factory. :)

For those that are willing to share it with segv11, just copy the files and subfolders in /factory. (If you have root explorer, just long-press on /factory and create a tar. Then copy it to /sdcard and then on your computer type adb pull /sdcard/factory.tar

Note: Do not post those files on this board. PM segv11 a link to them.
[Samsung Galaxy Nexus] segv11:
Your mmcblk0boot0.img and mmcblk0boot1.img are both 524288 bytes of zeros.

My mmcblk0boot0.img and mmcblk0boot1.img are both 2097152 bytes of zeros.

It's possible that someone with a Play Store nexus has something different here, but it seems unlikely.

---

Maybe there are more hidden partitions, or maybe it's in /factory (or raw in efs)?
[Samsung Galaxy Nexus] efrant:
The possibilities are narrowing!! Still would like to see a Play Store dump to make sure for these two partitions, in case there is a lone "1" somewhere. :)
[Samsung Galaxy Nexus] segv11:
So fare we have 2 boot blocks ad 13 paritions:

boot0: all null

boot1: all null

p1 = xloader: identical

p2 = sbl: identical

p3 = efs: this is /factory -- under investigation

p4 = param: this is a fun partition, but no wipe-on-unlock flag

p5 = misc: identical

p6 = dgs: identical

p7 = boot

p8 = recovery

p9 = radio

p10 = system

p11 = cache

p12 = userdata

p13 = metadata: identical

It's interesting that the device nodes (not the symlinks) for p4 (param) and p9 (radio) are owned by radio and all the others are owned by root. Dunno why radio needs to own param.

Let's make sure we're not overlooking anything.

We have left: efs (which we will look at, I hope) as well as some partitions which we _think_ we know well: boot, recovery, radio, system, cache, userdata.

I hope we find it in efs, because I don't see how it could be hiding in the remaining six. I mean, we flash recoveries, radios, and ROMs all the time, and we wipe cache and userdata all the time, and it doesn't change this behavior.
[Samsung Galaxy Nexus] Archpope:
OK, here are my sbl and xloader files. I was unlocked, pulled the files, then I re-locked, and pulled the files again. The MD5's were the same for the locked and unlocked files. I included what they were in the unlocked.zip. Hoep this helps. I'm probably going to flash the Jellybean bootloader pretty soon, though.
[Samsung Galaxy Nexus] Cistoran:
Hey guys, I bought a play store nexus a few weeks ago (6 maybe) and I decided now to unlock my bootloader/root it so I could update to JB and my phone didn't get wiped either. If you need any files from my phone just let me know real quick and I'll give em to you.
[Samsung Galaxy Nexus] segv11:
Archpope's locked and unlocked images are the same as each other. (No surprise there.) His xloader is the same as everyone else, which fits the pattern, too.

His sbl is different. harveydent (who also has a Play Store gnex, which does not wipe-on-unlock) has the same sbl that we do.. but Archpope's is different.

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.

----------

I'm offline for the night ... and the next few days. See you all on Monday; I can review more data then, especially if a Play Store GNEX owner sends a tarball of their /factory.

Happy Hacking!
[Samsung Galaxy Nexus] efrant:
Great, thanks! If you would be ok with it, segv11 could use the files in your /factory directory.

I guess this is where the boot image is stored? A way to change that via an app would be quite interesting... but not as interesting as solving our original mystery!
[Samsung Galaxy Nexus] spaceman860:
If your talking about changing the Google image there's an app for that https://play.google.com/store/apps/details?id=aperture.ezekeel.logome

Sent from my Gnex {GSM}
[Samsung Galaxy Nexus] efrant:
Thanks. What I was more getting at is that I would like to know how it is done, more so than change my boot image.
[Samsung Galaxy Nexus] Cistoran:
Here is the /factory folder in a ZIP after I flashed to JB.

I have a bak file (along with recovery and boot .img files) from when I backed up my phone before the flash with GNex Tool Kit so if someone can tell me how to open that or wants the whole file just let me know.
[Samsung Galaxy Nexus] Mach3.2:
I assume a EFS backup is just the /factory folder in the root of the phone.

If that is the case, i will pm segv11 my EFS backup, don't like to flash my IMEI around in public:p
[Samsung Galaxy Nexus] efrant:
Great, thanks. If we can't find the appropriate flag in /factory, then we will see if we can do anything with an efs dump. segv11 already has my /factory.
[Samsung Galaxy Nexus] Mach3.2:
Will PM him now so he can get back to us when he come back:)
[Samsung Galaxy Nexus] segv11:
/factory

OK folks, I'm back. I've been looking at the following four /factory images

Cistoran: maguro, Play Store

Mach3.2: maguro, Play Store

efrant: maguro, non-Play Store

segv11: toro

I was not surprised that my toro image was different than the maguro images. But I was surprised at how different the maguro images were from each other, even between Play Store devices.

There are the obvious differences: addresses (bluetooth/bt_addr, wifi/.mac.info), keys (hdcp.keys, wv.keys), carrier code (mps_code.dat, same as in param), logs (nv.log), and +md5s (.nv_core.bak.md5, .nv_data.bak.md5, nv_data.bin.md5).

There are LARGE differences in the binary files, .nv_core.bak, .nv_data.bak, nv_data.bin... larger than just a few bytes for the IMEI and related stuff. I have two Play Store devices and one Non-Play-Store maguro, so I might be able to figure out which differences are device dependent, and which (if any) are Play-Store dependent. But it will take a while, so please have patience. Not all reverse-engineering is as simple as what we did with the param partition.
[Samsung Galaxy Nexus] Mach3.2:
Wait, i'm having a NON-Play Store phone:silly:

Sorry for not highlighting it out when i PMed you.:silly:
[Samsung Galaxy Nexus] segv11:
It's OK - I've not started the detailed comparison yet. Now that I know, I won't make a mistake.

So we have 2 non Play Store and 1 Play Store devices. Any chance of getting another Play Store one? If you want to volunteer one, PM it to me for privacy - a tar or zip of /factory is easier for me to work with than an image of the whole efs partition.
[Samsung Galaxy Nexus] harveydent:
I just noticed something while installing jellybean. "fastboot erase userdata" does not erase the SD card at all. I have a takju Play Store GNex
[Samsung Galaxy Nexus] efrant:
Interesting! Thanks for posting.
[Samsung Galaxy Nexus] XBIRDIE98:
I agree with efrant: this is interesting. While the bootloader version probably has nothing to do with this behavior, it would be great if you could determine which bootloader you were using when preforming this operation, (i.e. PRIMELA03, PRIMELC03, etc.) as well as anything else you think might be relevant.

Incidentally, has anyone with the Jelly Bean bootloader (PRIMELC03) installed on a shipped-takju device, or one that just shipped with Jellybean installed from the factory, encountered the no-wipe behavior? (I think if Google/Samsung has changed things relating to this, it would be now, with the OS update, I/O, and the price change.)

Thanks,

XBIRDIE98

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.:)
[Samsung Galaxy Nexus] harveydent:
Bootloader was PRIMELA03. I posted some dumps before in this thread and they were identical to other Play Store takjus

I also noticed that I have both an "\sdcard" folder and a "\storage\sdcard0" folder (while on the leaked JB build), both of which contained my SD data. This was why I wanted to erase my SD and start from scratch when installing the OTA takju JB. Factory reset didn't wipe data, as expected. "fastboot flash userdata userdata.img" did.
[Samsung Galaxy Nexus] segv11:
That's very interesting; if I understand correctly it _should have_ reformatted the userdata partition, including /sdcard. Of course "fastboot oem unlock" should have done the same.

On a Play Store device, doesn't "fastboot oem unlock" _say_ it is going to erase data, then not actually do so? I wonder if that erase is done behind-the-scenes with the same mechanism as "fastboot erase userdata". If so, what we are looking for is not a flag that says "don't wipe on unlock" but rather a hardware or software hack that breaks "erase" entirely.

Maybe Adam Outer was right that hit has something to do with the SGS II bug that fried the eMMC when the ERASE command was used, even though the GNex uses a very different (larger) eMMC chip.

I'm still curious _how_ the phone knows wether to disable "erase". I'm digging through those /factory dumps to see if there is anything interesting: so far I have found a lot of device-to-device differences (as would be expected due to IMEI, MAC Address, keys, etc...), but I have not found any useful patterns of things that differ only based on play-store / non-play-store status.

I'll keep you posted, but it's slow work because I'm fairly busy these days and the differences I need to sift through are many. I just hope this turns out to be software, and not a jumper/fuse on the motherboard.
[Samsung Galaxy Nexus] XBIRDIE98:
As far as I can tell, it seems like /storage/sdcard0 is new in Jelly Bean, and another thread, while not having the most accurate post helps explain this: (NOTE: As far as I know, /sdcard is not a symbolic link, it's a FUSE filesystem - It was stated by an Android team member on Reddit in the context of ICS. Also, I've censored the quote - as per XDA's Forum Rules, Section 2.1. There are a few issues with spelling and grammar, but I thought it best to leave the text intact. :) )
[Samsung Galaxy Nexus] segv11:
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.
[Samsung Galaxy Nexus] segv11:
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.
[Samsung Galaxy Nexus] 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
[Samsung Galaxy Nexus] segv11:
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.
[Samsung Galaxy Nexus] MikeyMike01:
Yes, from the Play Store.

Sent from my Galaxy Nexus
[Samsung Galaxy Nexus] 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)...
[Samsung Galaxy Nexus] efrant:
We've already figured out where the lock/unlock flag is stored: http://xdaforums.com/showpost.php?p=27079685&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.