[APP][2015-01-12][root][GNex/Dev] BootUnlocker for Nexus Devices -- version 1.6.1

Cheater912 · Jan 13, 2015

segv11 said:
Weird. So we can unlock, but not lock?

It is interesting to note that the non-common change at 0x042c-0x043b is exactly 16 bytes long; a convenient length for a hash.

Sent from my Manta

Or a UUID. I'd be surprised if anybody is still using MD5 or similar.

osm0sis · Jan 13, 2015

segv11 said:
Weird. So we can unlock, but not lock?

It is interesting to note that the non-common change at 0x042c-0x043b is exactly 16 bytes long; a convenient length for a hash.

Not that weird, to unlock all we have to do is zero a few sections, but to lock, unfortunately, it appears we would need to reverse engineer the security tokens.

So the only way we could handle it officially would be my idea for having BootUnlocker allow a power user (after a serious disclaimer and an Advance Option toggle perhaps) to capture the dumps in the two states and then tie flashing them whole to the app buttons. Basically what I suggested for the N7 2012.

osm0sis · Jan 13, 2015

chef_christoph said:
I had the same result when starting from unlocked.

However, I did get what looks like a promising result when running the script immediately after flashing the locked image.

The script identified the BL state as locked and proceeded to unlock it. When I reboot into the system as well as the BL it remains unlocked.

Hmm thinking some more, does flashing it again allow you to relock? It should leave the tokens intact, so might be possible. That would mean as long as a rooted user started with a locked bootloader BootUnlocker could do its thing. BootUnlocker could check for the existence of the tokens and if they don't exist request the user oem lock before using it.

segv11 · Jan 13, 2015

osm0sis said:
Hmm thinking some more, does flashing it again allow you to relock? It should leave the tokens intact, so might be possible. That would mean as long as a rooted user started with a locked bootloader BootUnlocker could do its thing. BootUnlocker could check for the existence of the tokens and if they don't exist request the user oem lock before using it.

This might work, but it is definitely getting complicated.

Now we need to know: which of the locations in a locked bootloader need to be cleared in order to unlock, and which of those need to be saved for relocking.

And I need to read up on how to save user data, and disallow backups (we wouldn't want people restoring a BootUnlocker backup from one N6 onto a different one).

I hope the N9 is easier, if we can get some dumps.

Sent from my Manta

segv11 · Jan 13, 2015

What happens if a user writes a bad lock token to an unlocked device? Does it brick, or does it simply fail to lock?

Also, I wonder what the situation looks like before the first unlock. Does the first unlock just clear some tokens from sp like second unlocks do, or does it blow a qFuse like it does on the Moto X (according to the page I linked to earlier)?

Sent from my Manta

chef_christoph · Jan 13, 2015

osm0sis said:
Hmm thinking some more, does flashing it again allow you to relock? It should leave the tokens intact, so might be possible. That would mean as long as a rooted user started with a locked bootloader BootUnlocker could do its thing. BootUnlocker could check for the existence of the tokens and if they don't exist request the user oem lock before using it.

Yes, flashing the script a second time immediately after the first relocks the bootloader

osm0sis · Jan 14, 2015

segv11 said:
What happens if a user writes a bad lock token to an unlocked device? Does it brick, or does it simply fail to lock?

Also, I wonder what the situation looks like before the first unlock. Does the first unlock just clear some tokens from sp like second unlocks do, or does it blow a qFuse like it does on the Moto X (according to the page I linked to earlier)?

chef_christoph said:
Yes, flashing the script a second time immediately after the first relocks the bootloader

I'm just saying we could leave the tokens alone. As long as there's root and the tokens exist we can write the common changes around them and control the lock state as long as the initial state was locked.

sordna · Jan 14, 2015

segv11 said:
Weird. So we can unlock, but not lock?

Why not keep things simple and only offer the unlock option in BootUnlocker for the N6.
Users can always lock using fastboot. The main benefit of BootUnlocker which is to unlock preserving your data, will still be there.

Cheater912 · Jan 14, 2015

osm0sis said:
Hmm thinking some more, does flashing it again allow you to relock? It should leave the tokens intact, so might be possible. That would mean as long as a rooted user started with a locked bootloader BootUnlocker could do its thing. BootUnlocker could check for the existence of the tokens and if they don't exist request the user oem lock before using it.

Can that be a security risk? Everybody would be using the same keys if that's what's in there.

osm0sis · Jan 14, 2015

Cheater912 said:
Can that be a security risk? Everybody would be using the same keys if that's what's in there.

You misunderstand. The tokens are the unique data. I'm proposing we don't touch them at all, so each device remains with its own "key".

segv11 · Jan 14, 2015

osm0sis said:
You misunderstand. The tokens are the unique data. I'm proposing we don't touch them at all, so each device remains with its own "key".

Wait, so does flashing ONLY the common changes to a locked device unlock it? So I don't need to wipe and restore the token, just leave it alone?

In that case, my next question would be do I have to flash ALL the common changes to unlock, or only some of them?

Sent from my Manta

osm0sis · Jan 14, 2015

segv11 said:
Wait, so does flashing ONLY the common changes to a locked device unlock it? So I don't need to wipe and restore the token, just leave it alone?

In that case, my next question would be do I have to flash ALL the common changes to unlock, or only some of them?

Yup, that's what I suggested and was tried here: http://xdaforums.com/showpost.php?p=58153849&postcount=503

Whether only some suffice is the next big question.

osm0sis · Jan 14, 2015

osm0sis said:
I'm just saying we could leave the tokens alone. As long as there's root and the tokens exist we can write the common changes around them and control the lock state as long as the initial state was locked.

osm0sis said:
You misunderstand. The tokens are the unique data. I'm proposing we don't touch them at all, so each device remains with its own "key".

Proof of concept. Won't flash on an unlocked N6 bootloader (to relock) by checking for the existence of the first token, and will advise in this case the user fastboot oem lock before flashing again.

RushTea · Jan 14, 2015

osm0sis said:
Proof of concept. Won't flash on an unlocked bootloader to relock by checking for the existence of the first token, and will advise in this case the user fastboot oem lock before flashing again.

Can test this if you want. How safe is it? Ie, if it "breaks", will it brick, force flashing, or just me to factory reset?

osm0sis · Jan 14, 2015

RushTea said:
Can test this if you want. How safe is it? Ie, if it "breaks", will it brick, force flashing, or just me to factory reset?

I'm fairly confident in the script, but you're best practice would still be backing up one state or the other of your sp partition first. You would need to flash this partition dump back to sp if something went wrong, though honestly locking and unlocking again might fix it too. Factory Reset doesn't act on any partitions BootUnlocker will ever come in contact with.

RushTea · Jan 14, 2015

Bit nooby on the backing up specifics part. Could you provide the full path to the files I should back up?

Edit: did a backup of boot, firmware and efs. Is this sufficient?

Big fat edit: That's a brick. Flashed it once before relocking, locked, then wouldn't boot into anything but the bootloader. Totally should have done a full backup, good thing the device is only a day old!

Even more editing:

So, according to what I saw, this following bit did NOT happen, and the script claimed to have unlocked my bootloader:

Code:

      ui_print "Security token not present.";
      ui_print "Please fastboot oem lock before flashing.";

chef_christoph · Jan 16, 2015

Hello all,

I've been tinkering with my Nexus 6 today and flashing the unlock script supplied by @osm0sis upthread and something occurred to me.

It appears as though there are (at least) two different unlocked states of the bootloader in the Nexus 6.

One unlocked state allows relocking of the bootloader through the use of the script and the other doesn't seem to.

I was able to get dumps of the sp partition in both unlocked states and generated an MD5 of each .img and they are different.

At first glance it seems that booting into the bootloader, rebooting the system or a combination of both after unlocking the bootloader is what is changing the unlocked state. I haven't had time yet to try and figure out the cause.

My thought is that if we can figure out what the difference is between the two unlocked states, maybe there's a way to retain the ability to relock the bootloader using the script even after booting into the bootloader/rebooting the system.

Please let me know if this is old news and not worth looking into further or if additional examination could prove helpful.

RushTea · Jan 16, 2015

This seems consistent with why my phone died after the script believed my boot loader was locked. Currently unable to retest as I'm travelling, but can brick my phone many times over once I have some proper backups.

chef_christoph · Jan 17, 2015

I've had some more time to test.

As mentioned in my previous post, it looks to me like we've got two different and distinct unlock states. I've taken to referring to them as "OEM unlocked" and "script unlocked".

Starting from OEM locked the script will continue to toggle back and forth between script unlocked and locked repeatedly with no problems - until any form of reboot into bootloader or system.

After any reboot into the bootloader or system the unlock state changes from script unlocked to OEM unlocked.

From OEM unlocked, the script will not switch back to locked. This appears to mean that after every reboot, if the bootloader is unlocked, the script wouldn't be able to lock the bootloader again without an OEM lock being done.

I noticed some discussion earlier in the thread about having users manually go back to OEM locked after installing BootUnlocker.

I wonder now if we might have an additional avenue to try? Instead of having users manually go back to OEM locked, what about trying to have the script attempt to reflash the data to unlock again before attempting to lock?

What I have in mind is having the script change the bootloader unlock state from OEM unlocked to script unlocked and therefore be able to use the script to relock and avoid the need for the user manually doing an OEM lock.

I haven't had time to really look at the script that @osm0sis posted upthread but I could try to modify it to test this concept. I may need assistance with this if I get stuck but I'm not afraid to at least try it before asking for help from you all.

I am by no means proficient with this so if anyone thinks I'm on the wrong track, or you've already been down this avenue with other devices without success, let me know.

chef_christoph · Jan 18, 2015

osm0sis said:
Proof of concept. Won't flash on an unlocked N6 bootloader (to relock) by checking for the existence of the first token, and will advise in this case the user fastboot oem lock before flashing again.

I've flashed this a few times with OEM unlock but don't get any notification to do OEM lock before flashing again.

[APP][2015-01-12][root][GNex/Dev] BootUnlocker for Nexus Devices -- version 1.6.1

Senior Member

Senior Recognized Developer / Contributor

Senior Recognized Developer / Contributor

Senior Member

Senior Member

Senior Member

Senior Recognized Developer / Contributor

Senior Member

Senior Member

Senior Recognized Developer / Contributor

Senior Member

Senior Recognized Developer / Contributor

Senior Recognized Developer / Contributor

New member

Senior Recognized Developer / Contributor

New member

Senior Member

New member

Senior Member

Senior Member

Similar threads

Top Liked Posts