Related
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
I'm getting a 6p for Christmas and I have a question.
Say the 6p is on Marshmallow, and I decide to unlock the bootloader (just that, no root or anything) on MM. Will I be able to update to 7.1.1 via ota (no I don't want to sideload or flash) without issues? Or is there a process to it like updating bootloader, vendor, radio or whatever else. Or does the Ota file contain the updated boot.img and vendor etc.
ricbaez said:
I'm getting a 6p for Christmas and I have a question.
Say the 6p is on Marshmallow, and I decide to unlock the bootloader (just that, no root or anything) on MM. Will I be able to update to 7.1.1 via ota (no I don't want to sideload or flash) without issues? Or is there a process to it like updating bootloader, vendor, radio or whatever else. Or does the Ota file contain the updated boot.img and vendor etc.
Click to expand...
Click to collapse
Yes, you can unlock then update via OTA. OTAs patch every partition permitted there are no modifications done to system and boot.
Sent from my Nexus 5X using Tapatalk
ricbaez said:
I'm getting a 6p for Christmas and I have a question.
Say the 6p is on Marshmallow, and I decide to unlock the bootloader (just that, no root or anything) on MM. Will I be able to update to 7.1.1 via ota (no I don't want to sideload or flash) without issues? Or is there a process to it like updating bootloader, vendor, radio or whatever else. Or does the Ota file contain the updated boot.img and vendor etc.
Click to expand...
Click to collapse
Why would you want to unlock the bootloader if you don't intend to root or install a custom recovery? I don't understand what the benefit is.
jhs39 said:
Why would you want to unlock the bootloader if you don't intend to root or install a custom recovery? I don't understand what the benefit is.
Click to expand...
Click to collapse
I actually intend to install megapixel rom
jhs39 said:
Why would you want to unlock the bootloader if you don't intend to root or install a custom recovery? I don't understand what the benefit is.
Click to expand...
Click to collapse
@ricbaez
No disrespect, but I would say why would you NOT unlock the bootloader on a Nexus? Especially when you first get the phone because unlocking wipes it. Unlocking the bootloader allows you to use MANY more tools in the event your phone boot loops or becomes unresponsive. There are dozens of threads where people are completely screwed because they did NOT unlock the bootloader and so cannot salvage their device with ADB/Fastboot. If you bought a Nexus, one of the selling points is that Google ALLOWS the owner to unlock the bootloader right in the Dev Options! Even if the OP is not going to root or install a custom recovery, if he/she does not unlock the bootloader, they are going to be S.O.L. if the phone won't boot. There are many examples of this since Google has gone to the monthly security OTA's and updates. Or... simply put, if you are unlocked you can flash full Google images and use ADB/Fastboot. If you are locked, you can only sideload an OTA with the stock recovery and that hasn't been working out well for so many people here on XDA.
To the OP. Recommend you unlock your bootloader first thing which will wipe the phone and start you out fresh. Unlocking the bootloader will not prevent you from receiving OTA's. Make sure your Google login works properly. Login. Logout. Login. Then do whatever the F you want with your phone, knowing you will have serious options to recover in the event things go south for any reason. Next would be installing TWRP. Good luck!
v12xke said:
@ricbaez
No disrespect, but I would say why would you NOT unlock the bootloader on a Nexus? Especially when you first get the phone because unlocking wipes it. Unlocking the bootloader allows you to use MANY more tools in the event your phone boot loops or becomes unresponsive. There are dozens of threads where people are completely screwed because they did NOT unlock the bootloader and so cannot salvage their device with ADB/Fastboot. If you bought a Nexus, one of the selling points is that Google ALLOWS the owner to unlock the bootloader right in the Dev Options! Even if the OP is not going to root or install a custom recovery, if he/she does not unlock the bootloader, they are going to be S.O.L. if the phone won't boot. There are many examples of this since Google has gone to the monthly security OTA's and updates. Or... simply put, if you are unlocked you can flash full Google images and use ADB/Fastboot. If you are locked, you can only sideload an OTA with the stock recovery and that hasn't been working out well for so many people here on XDA.
To the OP. Recommend you unlock your bootloader first thing which will wipe the phone and start you out fresh. Unlocking the bootloader will not prevent you from receiving OTA's. Make sure your Google login works properly. Login. Logout. Login. Then do whatever the F you want with your phone, knowing you will have serious options to recover in the event things go south for any reason. Next would be installing TWRP. Good luck!
Click to expand...
Click to collapse
You are right. I wasn't aware that people were having boot loop issues on phones running stock Android but that apparently is the case. But as long as USB Debugging and Allow OEM Unlock are ticked in the developer options you should be able to unlock the bootloader later through ADB if you need to. I assumed the warning about my phone being insecure since my bootloader is unlocked that pops up every time I boot was there for a reason. There is no security issue created by unlocking your bootloader?
jhs39 said:
You are right. I wasn't aware that people were having boot loop issues on phones running stock Android but that apparently is the case. But as long as USB Debugging and Allow OEM Unlock are ticked in the developer options you should be able to unlock the bootloader later through ADB if you need to. I assumed the warning about my phone being insecure since my bootloader is unlocked that pops up every time I boot was there for a reason. There is no security issue created by unlocking your bootloader?
Click to expand...
Click to collapse
It's cool, and I respect your decision to stay locked if you decide that is best for you. I suppose you could set Allow OEM unlock in Dev settings AND USB debugging in USB just in case, but if for some reason you could not boot, unlocking bootloader would then wipe userdata and your backups would be gone before you could transfer them off. In the end it's up to the individual to choose security vs, recoverability. Many ppl are getting locked out of their phones in the interest of security (or just the default settings). As it turns out, they were just trying to perform a monthly security update and hosed their phone. Stock rom, stock recovery, unrooted. Every Nexus phone I've owned (Galaxy?) has been unlocked so that I could use all the tools available to get myself out of a bind if needed. I don't give a sh!t about the boot up warning, because I know that my nandroid and FF backups can get me back home in the event of a lockup. Unlocking will not stop you from receiving OTA's if you are stock. Even if you are not, unlocking will allow you to use ADB, custom recoveries, toolkits, etc. If you end up in a bootloop and your bootloader is locked you are S.O.L. plain and simple. Each to their own though... if you need encryption and value high security of your data over recoverability then you may want to stay bootloader locked. As owners of a Nexus phone we have that option. Many others do not. Cheers my friend!
Thank you guys everything was successful, unlocked it in no time, downloaded 7.1.1 and it's perfect. NOw time to flash twrp and MegaPixel Rom
Hey all.
So I've installed LineageOS just fine - the unlocking guides around here are mostly clear enough. Certainly not as easy as I've been used to for Nexus and OnePlus devices though! I've been using the 'official' TWRP 3.0.4.1 and not any of the other (now often links removed) unofficial versions.
I've also got my hands dirty with EDL mode and have totally reflashed a couple of times while playing around.
So on to my question. Basically I have an email client for work (Good for Enterprise) that detects unlocked bootloaders as 'root' (even though I'm not rooted), so I would like to relock my bootloader.
However, as soon as I use 'fastboot oem lock' it instantly bricks my phone. It goes straight into EDL mode, from which it cannot return. No bootloader, no recovery mode, no booting of system. Completely dead. All button combos attempted etc.. The only way back that I've found is to flash a whole new system image in EDL, and start over.
So, have I missed something (a signed recovery?) that makes this happen? Are there some verifications that the bootloader does while locked that fails because there's a custom system and recovery in place?
Is there anything I can do about this? Am I doomed to use stock for as long as I need to use this darned app?
Thanks very much!
Yes you need to be completely stock to lock BL.
Also if you want to stay unlocked, you can use MAGISK to hide root for your mailing app.
Thanks for the replies. I actually don't have, and never have had, root. So the only thing it can possibly be detecting is either the custom ROM itself (or rather, not a factory one from some list they maintain) or the unlocked bootloader. So I doubt MAGISK will work, because there's no root there to hide in the first place
(In case it wasn't obvious, we're talking about Good for Enterprise here).
The blackberry mobile device management system (earlier called GFE) doesnt care if bootloader is unlocked, it just checks whether you have a custom recovery (twrp) and that is enough to flag your system as rooted.
I wish to root my phone(XT1686) but intend to keep the stock ROM(no bootloader unlock).
Is there any advantage in doing so? And will OTA updates be affected?
yourSAS said:
I wish to root my phone(XT1686) but intend to keep the stock ROM(no bootloader unlock).
Is there any advantage in doing so? And will OTA updates be affected?
Click to expand...
Click to collapse
It is not possible to root without unlocking the bootloader on this device...
If you don't have a specific reason to root, don't do it.
And once rooted, you cannot accept any OTA... most likely case if you do it will just fail, worst possible case it bricks (which can happen but is extremely rare).
To answer the question in your title, about the advantages of rooting...
Rooting gives you near full access to your device, and thus the ability to customize it beyond the options provided to you via the default interface. Also, some apps provide additional features on rooted phones. For example, some security programs recommend rooting your device so that it can more forcefully integrate itself with the device to protect against malware, hacking, etc. I tend to install a security package that works better on a rooted device, as well as make use of features that tend to only work on a rooted device, such as folder mounting from the internal SD card to the external one. Also, allows me to access system files that are unavailable otherwise, allowing me to customize certain sounds (or copy them at least).
If you decide you want to root your device, make sure you understand the steps to take BEFORE trying it. That means when you come across a guide on how to do it, make sure you get all the files that will be required and reading through the instructions step by step. If any of the steps sound like it will leave you lost on what to do, then DO NOT do any of it. Also, make sure you read the comments for the guide as well, looking for any mention of issues encountered and consider if you might encounter those issues as well. For example, if it causes issues for devices that use a particular carrier and you use that same carrier, you might want to leave well enough alone. Compare your phone version numbers with what others report having issues with (kernel, baseband, build, etc). Anything that someone has an issue with where their phone somehow matches up with yours in some way, take that as a sign to investigate deeper, so as to avoid having any issues yourself.
For the most part, unless you have a need or desire for a feature/function that requires rooting your device, don't mess with it. I'm not kidding, as one mistake can leave you without a working phone and without any options for returning/replacing it.
Thanks for the replies & warnings.
I'm not a noob so I know the risks of rooting. So maybe I should have rephrased it-
What are the advantages of rooting Moto G5 plus specifically?
Say like in terms of mods and other stuff? Also, is it possible to unroot once rooted- I mean to ask if it's possible to revert the state to factory mode with bootloader locked and stock ROM so that device will be eligible for OTA updates again?
yourSAS said:
Thanks for the replies & warnings.
I'm not a noob so I know the risks of rooting. So maybe I should have rephrased it-
What are the advantages of rooting Moto G5 plus specifically?
Say like in terms of mods and other stuff? Also, is it possible to unroot once rooted- I mean to ask if it's possible to revert the state to factory mode with bootloader locked and stock ROM so that device will be eligible for OTA updates again?
Click to expand...
Click to collapse
Bootloader lock is not relevant to OTA's. You might be able to relock, but the fact it was once unlocked cannot be hidden, it will always be very clear that it was unlocked.
Unrooting is easy, the issue arises undoing what you did with root, undoing them all depends what you changed.
I don't know of any reasons specific to this device to root.
acejavelin said:
Bootloader lock is not relevant to OTA's. You might be able to relock, but the fact it was once unlocked cannot be hidden, it will always be very clear that it was unlocked.
Click to expand...
Click to collapse
If the OEM knows I've unlocked bootloader, why will it push OTAs to my phone even though I've locked bootloader on my end? So isn't bootloader lock status relevant for OTA?
yourSAS said:
If the OEM knows I've unlocked bootloader, why will it push OTAs to my phone even though I've locked bootloader on my end? So isn't bootloader lock status relevant for OTA?
Click to expand...
Click to collapse
No, the status of your bootloader is not relevant... Moto will notify you of an available update and happily attempt to apply it regardless if your bootloader is locked or not.
What matters is if the boot or system partitions is changed, if there is ANY change to those, among other things like if the radio version or recovery versions don't match or the partition table is changed, the update will fail. If you flash any custom recovery it will fail as well.
On this subject I mention a slight con which is that some banking or financial apps might complain to you if they detect root. I have maybe 10 different bank and credit apps installed and all work flawlessly except 1. The Huntington Bank app wont allow me to use fingerprint login but otherwise the app is fully functional like mobile deposits. Just wanted to mention to be aware.
Hey guys, I found this quick and tidy way to get a fastboot console inside the bootloader. You can use it to do stuff like "fastboot format (partition)", etc.
GUIDE:
Go to fastboot mode on your Pixel XL
Open a CMD on the computer in fastboot directory and write in "fastboot flash bootloader pixelcustombootloader.img" (make sure the bootloader is in the directory or else it will not flash!)
Download: s000.tinyupload.com/index.php?file_id=44700284262726497364
Note: I am NOT responsible if this screws up anything.
Also I do NOT know if theres and copyright trouble with this, if there is, Mods go take this down.
I wonder if this is the bootloader that was seen in screenshots that was used to downgrade a Verizon pixel to unlock it?
DR3W5K1 said:
I wonder if this is the bootloader that was seen in screenshots that was used to downgrade a Verizon pixel to unlock it?
Click to expand...
Click to collapse
If the bootloader is locked you can't flash anything or boot anything that isn't signed by Verizon/Google/whoever.
As far as I know there's never been a downgrade workaround available where pixel8 wasn't patched, but could be wrong.
bobbarker2 said:
If the bootloader is locked you can't flash anything or boot anything that isn't signed by Verizon/Google/whoever.
As far as I know there's never been a downgrade workaround available where pixel8 wasn't patched, but could be wrong.
Click to expand...
Click to collapse
There was a guy positing pictures of someone from a cell phone shop where he was recording the procedure that they did to his phone it was a signed bootloader that allowed him to downgrade for an unlock. It was labeled HTC which people thought was weird.
DR3W5K1 said:
There was a guy positing pictures of someone from a cell phone shop where he was recording the procedure that they did to his phone it was a signed bootloader that allowed him to downgrade for an unlock. It was labeled HTC which people thought was weird.
Click to expand...
Click to collapse
Eh.. 3rd party pictures that don't come with a detailed "how to" are 99% BS or marketing.
Like I said I'm not all knowing but I'm pretty in touch with the goings-ons of the pixel and have never heard of a downgrade method for a locked bootloader.
If this shop has a private method of doing so then they sure as hell wouldn't let someone take pictures of the process.
Yea like u said the guy said they were spy shots that he snuck in. Probably bs like you said. I could careless for myself my Verizon pixel is unlocked. Feel bad for those stuck locked though. Wishful thinking I suppose.
Yeah, don't flash your bootloader with anything other than stock google imgs. If your bootloader is messed up, how do you get into fastboot to fix it? Can't change slots either afaik.
Thanks for sharing, this has loads of potential - could be used on-the-go to temporarily recover from the freeze/reboot glitch (flashing stock images tends to lower the probability of the glitch for a day or two), plus we could actually have tetherless TWRP support for Oreo with this as you could use it to fastboot boot the TWRP boot img.
That being said, I'm reluctant to flash a random bootloader on my phone with no info on where it came from. Did you make this? If so is it a patched version of the most recent bootloader? If not, where'd you find it? We need more info.