flashing unlock_critical - what's the deal? - Nexus 6P Q&A, Help & Troubleshooting

flashing unlock_critical - what's the deal? - Nexus 6P Q&A, Help & Troubleshooting

One problem is no one really seems to know what it does/allows in practice. The Android developer pages say it prevents/allows modification to the bootloader. But to flash a factory image, you flash a bootloader. So I'm not quite understanding it.
I understand there are layers of the bootloader so perhaps, on Nexus devices at least, flashing a factory image does not require writing certain *critical* layers of the bootloader. But beyond that, I don't yet understand what it allows/prevents. It's certainly not needed for "regular" root.
Any ideas (or corrections)?

Bump. Dealing with an apparent soft brick here (running stock from the factory on Project Fi), and have the same question.

Related

Is it possible to root 4.3 locked bootloader without wiping all data

I know it was possible previously to root without unlocking the bootloader.
Is it still possible? something people are working on? or not possible and backup everything first.
Thanks in advance
Mark

mark1holland1 said:
I know it was possible previously to root without unlocking the bootloader.
Is it still possible? something people are working on? or not possible and backup everything first.
Thanks in advance
Mark
Click to expand...
Click to collapse
I didn't know that was ever possible on the Nexus 7. I bought one of the first available, and from the moment I got it I had to unlock the BL to root. Thought it was always like that. Nothing's changed as far as I can tell. On other devices, sure you can root with a locked BL, but for the N7, you've always had to unlock first, and with it being so easy, I don't think anyone's motivated enough to cook up a workaround.

absinthesummer said:
I didn't know that was ever possible on the Nexus 7. I bought one of the first available, and from the moment I got it I had to unlock the BL to root. Thought it was always like that. Nothing's changed as far as I can tell. On other devices, sure you can root with a locked BL, but for the N7, you've always had to unlock first, and with it being so easy, I don't think anyone's motivated enough to cook up a workaround.
Click to expand...
Click to collapse
Hi, absinthesummer...
Yes, there was (and still is, if you're still on JB 4.2.2) a method available of rooting without unlocking the bootloader. And it was ridiculously easy to do. Avoiding unlocking the bootloader also avoids the factory reset, and consequential wipe.
Sadly however, under Jellybean 4.3, this exploit no longer works, and it seems unlikely a similar root-without-unlocking-the-bootloader type exploit, will become available anytime soon. Which, from a security point of view, is actually (probably) a good thing.
mark1holland1 said:
I know it was possible previously to root without unlocking the bootloader.
Is it still possible? something people are working on? or not possible and backup everything first.
Thanks in advance
Mark
Click to expand...
Click to collapse
Hi, mark1holland1...
As, I've mentioned, the old 'motochopper exploit' no longer works under JB4.3, so if you want root, you're going to have to do it the old fashioned way...
------------------------------------------
Backup the stuff on your Nexus 7...
Unlock the bootloader...
Fastboot flash a Custom Recovery (CWM or TWRP)...
Using that Recovery, flash Chainfires SuperSU root updater zip...
Copy all your stuff back to the Nexus 7...
Not difficult to do... just tedious and time consuming.
------------------------------------------
...it's either the above, or wait around indefinitely for a genius developer to find another exploit, which, given the security enhancements of JB4.3 does seem hugely unlikely.
Rgrds,
Ged.

GedBlake said:
Hi, absinthesummer...
Yes, there was (and still is, if you're still on JB 4.2.2) a method available of rooting without unlocking the bootloader. And it was ridiculously easy to do. Avoiding unlocking the bootloader also avoids the factory reset, and consequential wipe.
Sadly however, under Jellybean 4.3, this exploit no longer works, and it seems unlikely a similar root-without-unlocking-the-bootloader type exploit, will become available anytime soon. Which, from a security point of view, is actually (probably) a good thing.
Hi, mark1holland1...
As, I've mentioned, the old 'motochopper exploit' no longer works under JB4.3, so if you want root, you're going to have to do it the old fashioned way...
------------------------------------------
Backup the stuff on your Nexus 7...
Unlock the bootloader...
Fastboot flash a Custom Recovery (CWM or TWRP)...
Using that Recovery, flash Chainfires SuperSU root updater zip...
Copy all your stuff back to the Nexus 7...
Not difficult to do... just tedious and time consuming.
------------------------------------------
...it's either the above, or wait around indefinitely for a genius developer to find another exploit, which, given the security enhancements of JB4.3 does seem hugely unlikely.
Rgrds,
Ged.
Click to expand...
Click to collapse
Hmm, wow thanks for the info. I never knew that! I just remember my first N7 every post said Step 1:Unlock your bootloader... lol had I known there was a way around it I might have tried it! But my first 16gb and my later 32gb were both unlocked and rooted within hours of buying them, so perhaps I just wasn't motivated enough to look for it.
I could see how or why that would be desirable though I guess... before I bought my S3, I had an LG L9 that the only way you could unlock the BL was to root then flash/update (LG Update tool hack) the firmware meant for the international version of the phone, which mirrored(!!!) the entire display both horizontally and vertically. Then fastboot the oem unlock and unlock the best way you could with that kind of touch screen lol, THEN re-flash standard rooted firmware for the US back over it... Seriously NOT worth it! Because even if the mirroring went away with the right firmware, the boot logo would still be mirrored and it was possible your screen would not return to normal. So forget about any warranty at that point. But, I gotta hand it to the devs on that device- now they were some motivated folks. They went to a lot of trouble to unlock that BL. You could root and install CWM without unlocking, but if you flashed CM and it was buggy or something, there was no turning back to stock. We were left with mods only unless we wanted to do alll that work.
That just reminds me how thankful I am for my S3 and N7s.

Would it be plausible to use JTAG to rewrite an unlocked firmware?

I know that the Verizon bootloader is almost impenetrable as is, but would it be plausible to completely go over the head of the firmware and directly write an image with JTAG that would allow for custom software? If so, would it be possible to use the firmware from another carrier like USC or would it have to be a custom image?
EDIT: summary of the method and everything I have thusfar discovered
So, this method after a bit of evolution, got to the point it basically entailed the following: Using the SD Card debrick method (popularized by the galaxy s3 LTE variants) a modified firmware image would be written to an SD Card, and the phone would boot from that image. The main problem I ran into: it would not let me flash anything that could brick the phone, nor was I able to pull the usb cord at the right moment and try and manually brick it. I was able to flash firmware and stock tars from other variants of the phone (such as the one that runs on T-mobile), but what I found out through that is a couple things:
1. The stock tars seem mostly carrier independent, and I was without any modification able to flash a T-mobile bootloader, system image, and pit file, but within recovery and download mode it would show that because of integrated CSC, it would still change back to the original variant. This could have implications for a very simple method of removing bloat from the phone, but I'm not so sure
2. It must have a very low level method of injecting information and file verification that is not located anywhere on eMMC
The latter led me to research a TON, eventually finding that the most likely culprit is the use of Qualcomm Qfuses, non-volatile pre-set memory located directly on the SoC, to check how the bootloader is signed. They consist of a couple blocks of registers, and definitely aren't readily writable. The trusted base of the entire secure system, the same system that KNOX invokes on other systems, is within a series of Qfuses. From what I have deduced, however, they must be at some software level writable, as although the Knox counter is an e-fuse, the others (such as the warrantee bit) have been both changed upon their void and reverted when brought back to a service center. This must mean that the entire block is possible to modify in both directions, unlike a fuse or breaker; It seems to act more like flash memory than a "fuse." This is very good, mainly because if the service center can change it it means that jtag has not been disabled by those flags, and is enabled in at least some form. What this also means is that without another MAJOR exploit within unfortunately simple, clean code or a leak of several RSA keys from verizon, either current workarounds such as safestrap are the answer for the foreseeable future, or a method of manually changing a simgle Qfuse (the one that controls the "Qualcomm Secureboot" flag) could be used.
What I'm hopefully going to start at some point here is research into finding a way of accessing and changing that Qfuse via JTAG. I have no money for a JTAG box at the moment, so it'll have to wait, but if anyone who already has one wants to use it, hopefully this info helps
P.S. I figured out exactly what T-flash does in odin: it flashes the files that you input into odin to the currently inserted SD Card (or so it seems, I could be wrong but that's what it did for me)
P.P.S. Verizon, I respectfully request that...oh never mind, profanity is definitely frowned upon here
Also, I'm in ongoing discussion with the FCC as to block C violations by Verizon of aspects of the regulations that upon research have not really been argued to any substantial extent, so if that comes to fruition hopefully there'll be simple ODIN flashable patches for this stuff :fingers-crossed:
UPON REFLECTION: if the phone could be bricked, either by very subtly corrupted file or by interrupting a flash at the right moment, then could the debrick image from a tmobile galaxy s5 with an unlocked bootloader be used as not a method of flashing the on-board bootloader but as a kind of external boot, so a permenantly installed SD Card that would be permissive of modified kernels and such but still accepted as a boot device by the phone?

I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.

tr4nqui1i7y said:
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
Click to expand...
Click to collapse
what was done with the droix x? Did they use a direct JTAG patch?

I just realized something. From reading here: http://forum.gsmhosting.com/vbb/f200/how-fix-samsung-galaxy-s5-sm-g900f-dead-boot-1813266/
It seems to show that the S5 has a "alternative boot upon init fault" method similar to that that allows the galaxy s3 debrick to work (I have a guide I made with details) so would it be possible to somehow corrupt a very important part of the bootloader in an official update (would one or two bits still mess with the signature?), apply that, and have an insecure bootloader on a microsd card in the phone allowing it to boot into that, then use that with odin to flash an insecure bootloader to the s5 itself?

Now I have to ask an interesting question somewhere (since he: http://forum.xda-developers.com/verizon-galaxy-s5/help/g900v-hard-brick-t2914847 seems to have done it): "guys how do I brick my sm-g900v?"

They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.

tr4nqui1i7y said:
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
Click to expand...
Click to collapse
I think it might actually be easier
So long as a couple conditions are met for it:
1. The bootloader alone determines if an image is "signed" or not (like when flashed in odin)
2. The same UnBrick exploit from the S3 LTE variants works in some form (secondary storage, fault-triggered boot)
3. It is possible to get it to load a modified bootloader from that secondary boot (this is why number 1 is important)
4. KNOX is completely firmware based, and doesn't have any chip based verification
5. I or someone else actually knows how to modify the bootloader such that it will allow unsigned images (even if not removing it all together, then changing the key to one they publicize so people can sign their rom with it)
If all of these are met, then we might actually have free root! Basically all it would involve would be bricking the device badly enough it boots from secondary storage, have that secondary boot have a "back door" that allows a custom image to be flashed, that allows a bootloader image to be flashed that allows for a signed recovery (signed with that publicly available code) to be flashed without having to deal with safestrap or anything like that. Just full root like on any other phone. Anyone want to offer an opinion? Will this work? I would love to try this out, though I'm a bit unwilling to offer my s5 as a sacrifice just yet as I don't have a JTAG unit on site. I know the bounty is probs gone but I'm ok just getting my bootloader unlocked an' $#*+

The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.

Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting

tr4nqui1i7y said:
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Click to expand...
Click to collapse
Have you found anything yet?

dreamwave said:
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
Click to expand...
Click to collapse
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.

tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom

dreamwave said:
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
Click to expand...
Click to collapse
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.

tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
that's why I'm hoping the debrick image method will work

tr4nqui1i7y said:
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
Click to expand...
Click to collapse
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom. Also, safestrap didn't do a thing with the bootloader, it was done during kernel init, right after firmware finishes. If a phone is hard bricked then adb won't work, and what I'm getting at is hard bricking it then using the debrick image thing

dreamwave said:
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom
Click to expand...
Click to collapse
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?

tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Click to expand...
Click to collapse
I don't know, I got it to go back to when root was still possible to get via an app. I don't see why there's a need to downgrade the bootloader if the debrick image thing works

tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
Click to expand...
Click to collapse
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.

dreamwave said:
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
Click to expand...
Click to collapse
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.

tr4nqui1i7y said:
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
Click to expand...
Click to collapse
but that has already been done I think, root on a system with any bootloader so long as a root exploit exists for the OS
That's safestrap. It doesn't allow custom kernels or a full custom recovery though, that's why I'm trying to modify the bootloader

How can I unbrick nexus 6p if I didn't unlock bootloader or OEM?

I'm new to Android. Recently I got a new nexus 6p. I was so confused that whether I have to unlock bootloader or not. Currently I just want to experience the pure Android simply without rooting or changing anything. But I heard a lot about bricked nexus 6 that the device would not be manually fixed if it was not bootloader unlocked before. As I am in China where I have no warranty for my nexus 6p, I have to keep my device safe as possible as I can.
So my question is under the circumstance that I haven't unlocked bootloader or OEM:
How much probability could it be I do nothing but unexpectedly brick the device?
If it is bricked, is it possible to recover it?
Do common nexus 6p users have to unlock bootloader?
Another important thing should be mentioned. Generally I can't access to any service by google in China, so I utilize a proxy tool to get over the great firewall to use google. Is there any experience about the situation like me? I also heard a saying that upgrading nexus 6 firmware by OTA through a proxy tool in China may brick the device, because google can not save the upgrading information of the device for the reason that the proxy IP is not static, then google will push update again, and once you click it, brick.
Puzzled enough...Thanks in advance.

I am not 100% certain what you are asking... If you do not unlock the bootloader, you should not be able to brick your device. The only reason to unlock it is to flash a custom ROM (not official from Google) or to flash Google factory images, which it sounds like might be necessary for you being that you are in China and may not receive OTAs properly. This is a process of downloading a file from Google and flashing to your device after unlocking the bootloader.
Your post was not exactly clear partially, but is your phone already bricked and you are trying to recover, or simply asking for your own reference?

fury683 said:
I am not 100% certain what you are asking... If you do not unlock the bootloader, you should not be able to brick your device. The only reason to unlock it is to flash a custom ROM (not official from Google) or to flash Google factory images, which it sounds like might be necessary for you being that you are in China and may not receive OTAs properly. This is a process of downloading a file from Google and flashing to your device after unlocking the bootloader.
Your post was not exactly clear partially, but is your phone already bricked and you are trying to recover, or simply asking for your own reference?
Click to expand...
Click to collapse
Thanks for replying. Could you please point out the unclear expressions? And I could edit them.
I have only unlocked nexus 6p bootloader, and the device is running well. I do not understand exactly why I have to do this, I just do it in case the situation described by other nexus 6 users happen to my nexus 6p. So I want to figure out the logic.

If you have no reason to unlock it, then you can relock it. Unlocking will always cause a full wipe (factory reset) of the device. Some users have stated that relocking the bootloader will also induce a wipe. If you want to leave it unlocked, this will allow you to flash factory images (such as updates from Google) as often as you'd like. It is possible to flash a factory image without losing any data by modifying the batch file used to flash the firmware.
Simply having the bootloader unlocked should not pose any threat to your device. You have to try very intentionally to flash firmware and risk bricking the device, it's not really something you can do by accident. The one thing I will mention is that with the bootloader unlocked, someone with the correct knowledge could flash a new image on your phone without needing your password or other security information. They would only need to power off the device, enter bootloader mode and plug into a PC to begin flashing. This would remove every trace of you and your data from the device and make it like it was brand new from the factory.
By keeping the bootloader locked and the "Allow OEM unlocking" option turned OFF, a person would need to have your password (or fingerprint) to gain access to this option in the settings, thus not allowing them to flash over the device as it is today.
Hope this helps.

fury683 said:
If you have no reason to unlock it, then you can relock it. Unlocking will always cause a full wipe (factory reset) of the device. Some users have stated that relocking the bootloader will also induce a wipe. If you want to leave it unlocked, this will allow you to flash factory images (such as updates from Google) as often as you'd like. It is possible to flash a factory image without losing any data by modifying the batch file used to flash the firmware.
Simply having the bootloader unlocked should not pose any threat to your device. You have to try very intentionally to flash firmware and risk bricking the device, it's not really something you can do by accident. The one thing I will mention is that with the bootloader unlocked, someone with the correct knowledge could flash a new image on your phone without needing your password or other security information. They would only need to power off the device, enter bootloader mode and plug into a PC to begin flashing. This would remove every trace of you and your data from the device and make it like it was brand new from the factory.
By keeping the bootloader locked and the "Allow OEM unlocking" option turned OFF, a person would need to have your password (or fingerprint) to gain access to this option in the settings, thus not allowing them to flash over the device as it is today.
Hope this helps.
Click to expand...
Click to collapse
According to you, I should not be able to brick my device if I did not unlock the device. I can understand this. But the problem is I am in China...By using proxy, I could receive OTAs correctly. But some nexus 6 users in China still encountered with device bricked after upgrading firmware by OTAs even they didn't unlock bootloader. One possible reason is like what I mentioned in last paragraph #1.
I don't like the prompt each time when I reboot the device after unlocking bootloader. Let's make the problem simpler. Can I unbrick the device if it is bricked and bootloader locked?

I can't really speak to your concern regarding bricking from OTA. This should nearly never happen, but I would suspect that the proxy is the issue. If you are concerned about that particular instance being an issue, I would simply not accept the OTA and don't install it. The file will download to your device and you will see a notification very similar to this: http://images.tapatalk-cdn.com/15/08/12/1c244e92c6a0cd69ca6e1a3037a05d62.jpg If you do not click Install, it will not install itself. You can click Later but usually cannot dismiss the notification. I have had the update pending on my Nexus 7 tablet that I don't often for months, but simply have not upgraded because I don't use it often enough to justify it.
If you want to be on the latest firmware for security reasons (Android 6/M will have monthly security patch releases from Google), you can download the factory images and flash yourself. However, if you believe there may be an issue because of the proxy you are using, the factory image could face the same issue as the OTA as you described. As I said, because I am not in China and do not use a proxy as you do, I cannot comment on how or why other users may have faced a hard brick scenario.
Ultimately, having the bootloader unlocked will allow you to flash the factory image over a bricked firmware caused by a corrupt (or otherwise unusable) OTA. If the phone can enter bootloader mode, you can flash the firmware and restore it to like new state. The warning message you see when booting is not able to be disabled without locking the bootloader again, but it only appears for a few moments. It was previously hidden on the Nexus 6 (not the 6p) so it might be possible in the future, but that is just a guess.

fury683 said:
I can't really speak to your concern regarding bricking from OTA. This should nearly never happen, but I would suspect that the proxy is the issue. If you are concerned about that particular instance being an issue, I would simply not accept the OTA and don't install it. The file will download to your device and you will see a notification very similar to this: If you do not click Install, it will not install itself. You can click Later but usually cannot dismiss the notification. I have had the update pending on my Nexus 7 tablet that I don't often for months, but simply have not upgraded because I don't use it often enough to justify it.
If you want to be on the latest firmware for security reasons (Android 6/M will have monthly security patch releases from Google), you can download the factory images and flash yourself. However, if you believe there may be an issue because of the proxy you are using, the factory image could face the same issue as the OTA as you described. As I said, because I am not in China and do not use a proxy as you do, I cannot comment on how or why other users may have faced a hard brick scenario.
Ultimately, having the bootloader unlocked will allow you to flash the factory image over a bricked firmware caused by a corrupt (or otherwise unusable) OTA. If the phone can enter bootloader mode, you can flash the firmware and restore it to like new state. The warning message you see when booting is not able to be disabled without locking the bootloader again, but it only appears for a few moments. It was previously hidden on the Nexus 6 (not the 6p) so it might be possible in the future, but that is just a guess.
Click to expand...
Click to collapse
OK I choose to give in...leave it unlocked there.
Thank you very much!

gnange said:
OK I choose to give in...leave it unlocked there.
Thank you very much!
Click to expand...
Click to collapse
The decision to leave it unlocked is the right decision. The other person replying in this thread is completely wrong when he says you can't brick a phone if you don't unlock it, that's completely and utterly incorrect. Sometimes things happen, unforeseen spontaneous problems happen all the time with smartphones. If this happens to you and your bootloader is locked there's absolutely nothing you can do to fix it. So yes, leave your bootloader unlocked as an insurance policy against the unforeseen.
@fury683, I'd think twice before telling someone that nothing bad can happen to their phone as long as it's locked, this is false information, and could potentially lead to someone being unable to repair a soft-bricked device due to following your advice.

Heisenberg said:
The decision to leave it unlocked is the right decision. The other person replying in this thread is completely wrong when he says you can't brick a phone if you don't unlock it, that's completely and utterly incorrect. Sometimes things happen, unforeseen spontaneous problems happen all the time with smartphones. If this happens to you and your bootloader is locked there's absolutely nothing you can do to fix it. So yes, leave your bootloader unlocked as an insurance policy against the unforeseen.
@fury683, I'd think twice before telling someone that nothing bad can happen to their phone as long as it's locked, this is false information, and could potentially lead to someone being unable to repair a soft-bricked device due to following your advice.
Click to expand...
Click to collapse
To be fair, I said should not. I've never bricked a device from normal use.
I offered my opinion, and the reasons why. I've been burned by comments and advice from people plenty of times and try my best to help out where I can. I don't think my post was misleading, and I appreciate your comments on the matter as well.

Heisenberg said:
The decision to leave it unlocked is the right decision. The other person replying in this thread is completely wrong when he says you can't brick a phone if you don't unlock it, that's completely and utterly incorrect. Sometimes things happen, unforeseen spontaneous problems happen all the time with smartphones. If this happens to you and your bootloader is locked there's absolutely nothing you can do to fix it. So yes, leave your bootloader unlocked as an insurance policy against the unforeseen.
@fury683, I'd think twice before telling someone that nothing bad can happen to their phone as long as it's locked, this is false information, and could potentially lead to someone being unable to repair a soft-bricked device due to following your advice.
Click to expand...
Click to collapse
Thanks for your advice. So, I can make the conclusion that we should unlock nexus bootloader no matter where we are, when it is and whether we will root or not, right ?

gnange said:
Thanks for your advice. So, I can make the conclusion that we should unlock nexus bootloader no matter where we are, when it is and whether we will root or not, right ?
Click to expand...
Click to collapse
The choice is ultimately yours, but my advice is always to have it unlocked, that way you're able to access and use fastboot in the event that something goes wrong.

fury683 said:
To be fair, I said should not. I've never bricked a device from normal use.
I offered my opinion, and the reasons why. I've been burned by comments and advice from people plenty of times and try my best to help out where I can. I don't think my post was misleading, and I appreciate your comments on the matter as well.
Click to expand...
Click to collapse
As I am new to android, your reply benefits me a lot. I notice you replied me before dawn while it was afternoon in China, thanks for your kindness but you should pay more attention to getting enough sleep, don't burn yourself out. : )

Heisenberg said:
The choice is ultimately yours, but my advice is always to have it unlocked, that way you're able to access and use fastboot in the event that something goes wrong.
Click to expand...
Click to collapse
Actually I used to suppose one has to unlock bootloader only if in China. Now I get it. Thank you !

Heisenberg said:
The choice is ultimately yours, but my advice is always to have it unlocked, that way you're able to access and use fastboot in the event that something goes wrong.
Click to expand...
Click to collapse
Yep what Heisenberg said is 100% true. My phone got bricked after the OTA update resulted in an error. I hadn't enabled the OEM Unlock setting, so couldn't unlock the phone. Have to wait for a replacement now

[DISCUSSION] Re-locking Bootloader w/ Custom OS

While I am an advocate for device customization and modifications, I also believe there is an inherent need for locked bootloaders. When we unlock a BL and leave it that way so we can run custom ROMs, root etc, we sacrafice the security it provides allowing our devices to be tampered with or redistributed after a theft. I've seen the PSA advising people not relock their bootloaders on anything except stock. That is entirely true for Verizon and EE pixels that were never intended to be unlocked in first place. However I believe its entirely possible to boot properly self signed images on unlockable devices after re-locking.
Now, I'm not saying we should go around re-locking bootloaders with custom firmware installed there's a process. I've done a bit of reading on verified boot. I am interested in utilizing the "YELLOW STATE" so we can run self signed boot images using an "embedded certificate" along with dm-verity disabled. The problem is how can we self sign our boot images allowing boot to continue without compiling from source?
https://source.android.com/security/verifiedboot/verified-boot.html
https://mjg59.dreamwidth.org/31765.html
I found some information & maybe a more experienced DEV can shed some light on if its possible with our Pixel devices. That's really the goal of this thread, to start a discussion which I think is extremely important & hopefully turn into a guide or tool. We shouldn't completely sacrafice security to utilize root or custom ROMs. On my N5X I have a locked bootloader and modified boot/system with Allow OEM unlock disabled. Difference with our Pixels and Nougat BLs is verified boot is strictly enforced.
Please excuse me if this thread seems jumbled or all over the place. I really do want help with this idea tho to help inform and keep us secure. Any input is appreciated.

Well if anybody is interested in re-locking their boot loader with a custom ROM and kernel in place I basically figured out how
Refer to this post
If anybody plans to attempt this and has ANY questions or concerns regarding re-locking their bootloaders in a custom state please don't hesitate to post here. I successfully re-locked my bootloader with custom ROM and Kernel. I also modified TWRP in my kernel to only start via locked down adb with key access. This allows my pixel to be highly secure and still recoverable. Might start a new post highlighting my proceedures and research on this subject.

I still wouldn't do this. What's the point? You will still pass safety net with custom kernel.
As for security you, your device still needs to be decrypted to use TWRP. It should still be as secure. I guess someone can wipe your device if they get ahold of it but that's not really a security risk.
Risk is still huge locking your device with a custom OS.
Sent from my Pixel using Tapatalk

milan187 said:
I still wouldn't do this. What's the point? You will still pass safety net with custom kernel.
As for security you, your device still needs to be decrypted to use TWRP. It should still be as secure. I guess someone can wipe your device if they get ahold of it but that's not really a security risk.
Risk is still huge locking your device with a custom OS.
Sent from my Pixel using Tapatalk
Click to expand...
Click to collapse
It has nothing to do with passing safety net. TWRP can only access the data after the pin is input, true, but leaving a device with an unlocked boot loader leaves the ability to flash modified boot images (a huge attack vector). This is to keep your device yours if it falls into a theives hands. You can not have device protection features on a unlocked Allow OEM unlock device. You're right there is risk but being careful can alleviate the risk. I do this because I want my phone to be a trackable paper weight if somebody takes it. I have established my own chain of trust outside of googles. I have even modified my TWRP side of boot.img to only start with my PC using adb-keys.

Which risk is greater. The risk of losing an unlocked device and it falling into the hands of someone that knows what to do or bricking it relocking it.
I vote the latter.

Its not re-locking that bricks... Its disabling the allow OEM unlock in dev options & screwing with stuff afterwards that may cause a bootloop. As long as you have a signed boot image in place with TWRP or stock recovery that uses your own keys the risk is minimal.
Simple rule... With a locked boot loader on a device where verification is strictly enforced always leave that option ticked if modifying anything.
I'm sorry but people are misinformed. Locking the boot loader doesn't brick if you have a custom ROM in place any more than a stock ROM. Its screwing with things or using a poorly dev'd ROM. If you are like me and can set something up the way you like once and not screw with it you'll be fine. If you do wanna screw with something remember to check allow OEM unlock in dev opts. Don't uncheck until you're 100% sure. It really is that simple.

If you are leaving the toggle open what have you accomplished when it gets stolen? They just issue the fastboot command to unlock it. Yea, it wipes data at that point. But I honestly can't think of anything on my phone that is confidential.

When I'm out n about and using my phone normally (i.e. not modding, flashing etc) I put the toggle to off. If I'm planning on changing anything I toggle it back on & if something causes a bootloop (most probably user error) I can recover. I don't think most people who steal phones care about data either but I keep a lot of keys, passwords etc to networks in my devices storage. I admit its not for everybody, just a way to be more secure and protect a $700+ investment. My phones bootloader isn't just locked, its locked with a persistent root ssh backdoor integrated into system so I can maintain control in the event.

want to re-lock my boot loader ?
Geofferey said:
Well if anybody is interested in re-locking their boot loader with a custom ROM and kernel in place I basically figured out how
Refer to this post
If anybody plans to attempt this and has ANY questions or concerns regarding re-locking their bootloaders in a custom state please don't hesitate to post here. I successfully re-locked my bootloader with custom ROM and Kernel. I also modified TWRP in my kernel to only start via locked down adb with key access. This allows my pixel to be highly secure and still recoverable. Might start a new post highlighting my proceedures and research on this subject.
Click to expand...
Click to collapse
hey,
I as well as plenty of others thought I was clever unlocking it as I mainly wanted to unlock it from EE UK network , its not been touched since ,no custom rooms or root but after reading people are trying to Re-lock it and getting bricked im too scared too try lol its only phone ive got ? Appreciate any help please x
---------- Post added at 10:57 AM ---------- Previous post was at 10:21 AM ----------
sally76 said:
hey,
I as well as plenty of others thought I was clever unlocking it as I mainly wanted to unlock it from EE UK network , its not been touched since ,no custom rooms or root but after reading people are trying to Re-lock it and getting bricked im too scared too try lol its only phone ive got ? Appreciate any help please x
Click to expand...
Click to collapse
Sorry Duhhhh !! Custom u said lol

Geofferey said:
Well if anybody is interested in re-locking their boot loader with a custom ROM and kernel in place I basically figured out how
Refer to this post
If anybody plans to attempt this and has ANY questions or concerns regarding re-locking their bootloaders in a custom state please don't hesitate to post here. I successfully re-locked my bootloader with custom ROM and Kernel. I also modified TWRP in my kernel to only start via locked down adb with key access. This allows my pixel to be highly secure and still recoverable. Might start a new post highlighting my proceedures and research on this subject.
Click to expand...
Click to collapse
Geofferey, Do you happen to know if these commands are still right with LOS 17.1 / Android 10?
(Or does anyone else know?)
PS: Sorry everyone for pumping such an old thread

nullstring2 said:
Geofferey, Do you happen to know if these commands are still right with LOS 17.1 / Android 10
Click to expand...
Click to collapse
Unfortunately no. Now there is avbtool and the process is actually a bit more complicated. Somebody wrote a guide on how to use it externally for another device but I couldn't even follow. I actually find it easier to get the sources for whatever ROM it is I'm trying to sign and set the signing params in config before build.
Here is the guy who did it usually avbtool externally
https://forum.hovatek.com/thread-32664.html
Many instructions here
https://android.googlesource.com/platform/external/avb/+/master/README.md

Geofferey said:
...but I couldn't even follow. /QUOTE]
Well, thats an intimidating introduction, but I'll take look.
That guide appears to be talking about mediatek CPUs which makes it a little confusing.
Any hint on how to get the vbmeta signing key for the google pixel?
Click to expand...
Click to collapse

nullstring2 said:
Any hint on how to get the vbmeta signing key for the google pixel?
Click to expand...
Click to collapse
If you mean how to make your own key to perform signing then
Code:
openssl genrsa -des3 -out avb.pem 2048
If you're asking how to get the same key that Google used to sign vbmeta, it ain't ever gonna happen.

Geofferey said:
Well if anybody is interested in re-locking their boot loader with a custom ROM and kernel in place I basically figured out how
Refer to this post
If anybody plans to attempt this and has ANY questions or concerns regarding re-locking their bootloaders in a custom state please don't hesitate to post here. I successfully re-locked my bootloader with custom ROM and Kernel. I also modified TWRP in my kernel to only start via locked down adb with key access. This allows my pixel to be highly secure and still recoverable. Might start a new post highlighting my proceedures and research on this subject.
Click to expand...
Click to collapse
Is there ANY way to do this on Xperias or LGs?

Geofferey said:
It has nothing to do with passing safety net. TWRP can only access the data after the pin is input, true, but leaving a device with an unlocked boot loader leaves the ability to flash modified boot images (a huge attack vector). This is to keep your device yours if it falls into a theives hands. You can not have device protection features on a unlocked Allow OEM unlock device. You're right there is risk but being careful can alleviate the risk. I do this because I want my phone to be a trackable paper weight if somebody takes it. I have established my own chain of trust outside of googles. I have even modified my TWRP side of boot.img to only start with my PC using adb-keys.
Click to expand...
Click to collapse
It has ALL to do with safetynet/play integrity.
I wouldn't care to leave my bootloader unlocked otherwise.
But I want a rom that passes all security standards without "tricks".

RE-LOCK the bootloader possible?

Hi!
I've recently unlocked my bootloader as I wanted to root the phone.
However, I'm planning to sell it and want to revert it.
I've tried "fastboot oem lock", but this soft bricked my phone so I had to unlock it again.
Is it possible to relock the bootloader or at least get rid of the booting message "the bootloader is unlocked and software integrity cannot be guaranteed, etc..."...

vessk0 said:
Hi!
I've recently unlocked my bootloader as I wanted to root the phone.
However, I'm planning to sell it and want to revert it.
I've tried "fastboot oem lock", but this soft bricked my phone so I had to unlock it again.
Is it possible to relock the bootloader or at least get rid of the booting message "the bootloader is unlocked and software integrity cannot be guaranteed, etc..."...
Click to expand...
Click to collapse
Ensure that unroot first before locking the bootloader.
The command you used worked for legacy devices. New devices including the OP8 series use the 'fastboot flashing lock' command.
P.S. If you have questions, please post them under the OnePlus 8 Pro Q&A section.

Use MSM tool. This will ensure that the software is 100% clean and in a new state.

Lossyx said:
Use MSM tool. This will ensure that the software is 100% clean and in a new state.
Click to expand...
Click to collapse
+1

Lossyx said:
Use MSM tool. This will ensure that the software is 100% clean and in a new state.
Click to expand...
Click to collapse
It will, but MSM is a low-level flashing utility and thus only recommended for unbricking.
For some very odd reason, I was able to break my phone's proximity sensors after using it the second time.
I wouldn't personally advise it to be a go-to solution for something that could be easily done via a bunch of commands. Just me two cents. ✌

DJBhardwaj said:
It will, but MSM is a low-level flashing utility and thus only recommended for unbricking.
For some very odd reason, I was able to break my phone's proximity sensors after using it the second time.
I wouldn't personally advise it to be a go-to solution for something that could be easily done via a bunch of commands. Just me two cents. ✌
Click to expand...
Click to collapse
I understand what you mean. But if that's the case then you would want to advise somebody to un-root, then run the adb command to remove any and all left over magisk modules, then factory wipe, then lock the bootloader.
Personally have ran the MSM tool 3 times due to poor flashes and it's been perfect.
I think the risk is much much higher if you plan to downgrade your OS. If not then you'll be absolutely fine.
Plus it's quicker

dladz said:
I understand what you mean. But if that's the case then you would want to advise somebody to un-root, then run the adb command to remove any and all left over magisk modules, then factory wipe, then lock the bootloader.
Personally have ran the MSM tool 3 times due to poor flashes and it's been perfect.
I think the risk is much much higher if you plan to downgrade your OS. If not then you'll be absolutely fine.
Plus it's quicker
Click to expand...
Click to collapse
I did mention unrooting first. Magisk will automatically take care of the modules when that's done. But yes, if someone did forcibly mount the system (not sure if it's possible anymore with dynamic partitions) and altered it, then that requires extra care.
As for a factory wipe, that'll be done at the same time when the bootloader is locked. So, that's why I suggested just unrooting and locking the bootloader straightaway.
Anyways, the suggestions you provided are equally valid as well.

DJBhardwaj said:
I did mention unrooting first. Magisk will automatically take care of the modules when that's done. But yes, if someone did forcibly mount the system (not sure if it's possible anymore with dynamic partitions) and altered it, then that requires extra care.
As for a factory wipe, that'll be done at the same time when the bootloader is locked. So, that's why I suggested just unrooting and locking the bootloader straightaway.
Anyways, the suggestions you provided are equally valid as well.
Click to expand...
Click to collapse
No mate you're wrong there im afraid. That is not always the case
Hence the actual requirement for a magisk removal command.
Magisk does not always clear up left overs, that's a well known problem.
But hey that's my advice.
Plus the wipe before hand is to eliminate anything that may have stuck similar to magisk modules.
It can happen.
Tbhi think he'll be fine either way.

dladz said:
No mate you're wrong there im afraid. That is not always the case
Hence the actual requirement for a magisk removal command.
Magisk does not always clear up left overs, that's a well known problem.
But hey that's my advice.
Plus the wipe before hand is to eliminate anything that may have stuck similar to magisk modules.
It can happen.
Tbhi think he'll be fine either way.
Click to expand...
Click to collapse
But sometimes, it is also the module developers to blame. That's why merging the modules into the official repository is difficult.
John has strained on this often. He recently removed EdXposed from the official repo:
https://twitter.com/i/web/status/1350590699113115648
As for wiping, it's all the same if you do it just before the relock command or let the command do it for you. The same thing is gonna happen either way, so it feels redundant to perform a factory reset right before locking the bootloader. This is what I was trying to convey earlier.
And yes, agreed. He'd probably be fine, given that we have provided various points to look out for before locking the bootloader.

DJBhardwaj said:
But sometimes, it is also the module developers to blame. That's why merging the modules into the official repository is difficult.
John has strained on this often. He recently removed EdXposed from the official repo:
https://twitter.com/i/web/status/1350590699113115648
As for wiping, it's all the same if you do it just before the relock command or let the command do it for you. The same thing is gonna happen either way, so it feels redundant to perform a factory reset right before locking the bootloader. This is what I was trying to convey earlier.
And yes, agreed. He'd probably be fine, given that we have provided various points to look out for before locking the bootloader.
Click to expand...
Click to collapse
I think he'll be fine.
An yea R-ice doesn't remove properly especially if you don't remove the theme first

Database Users

welcome