I see it mentioned a few times but what on the phone prevents say 4.4.2 from being installed after the upgrade to 4.4.3?
Because the partion table and bootloader are different and can't be downgraded at all.
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
No, the Dev edition is no different. All the same "rules" apply.
The Dev edition is the same as any other.... It just keeps is warranty if you unlock it.
aviwdoowks said:
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
Click to expand...
Click to collapse
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
KJ said:
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
Click to expand...
Click to collapse
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
AGISCI said:
Because the partion table and bootloader are different and can't be downgraded at all.
Click to expand...
Click to collapse
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
It is security. Specifically the SECURED BOOTLOADER. Don't confuse secured with locked. Yes, you can unlock your bootloader, but it is still secured.
Read up on "TrustZone" and see why it is important, and why the OEMs would not want you to be able to downgrade. You can "buy" or "not buy" whatever you want....
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
The early (4.2.2 & 4.4) bootloader (motoboot.img) was vulnerable to an exploit that allowed us to disable write protection. The updated bootloader (4.4.2+) is patched. You *CAN NOT* downgrade back to the vulnerable version.
^Does that not have *everything* to do with security??
scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
Can't just fake the version number?
No, it's not possible.
samwathegreat said:
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
Click to expand...
Click to collapse
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
samwathegreat said:
You can "buy" or "not buy" whatever you want....
Click to expand...
Click to collapse
I know, and that is why I want to understand what it is I would be buying.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
AGISCI said:
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
Click to expand...
Click to collapse
Well said :good:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
scryan said:
Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
Click to expand...
Click to collapse
Our recovery devs never restore such partitions or boot loader elements.
scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
Smh I normally don't chime into these threads but I had to, you can't downgrade the bootloader because of security/compatibility plan and simple. It's the same concept as why you can't downgrade most PC's bios, if there is a flaw found in the system as a whole, then they don't want you to downgrade to that version. A lot of the times when people brick their device trying to downgrade is because it will flash, but because an efuse was blown when it was upgraded the downgraded version will not boot. Yes the recovery can technically rewrite those partitions but again because the efuse was blown it will not boot. Also yes being able to downgrade on any system Windows, Linux, Unix, IOS, Xbox, PS, etc are causes to security issues. If you can downgrade a system to a vulnerable version, it is then by definition less secure, no matter how you try to spin it. Take the futex vulnerability which affected most linux kernels from the past 5 years, so why would any desktop linux user ever want to downgrade to a vulnerable kernel? They wouldn't but if the end user isn't knowledgeable of the vulnerability they wouldn't know that downgrading makes them vulnerable. So since phones are used by so many people who are not knowledgeable of vulnerabilities, why would you want to give them the opportunity to downgrade themselves to a vulnerable OS?
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
aviwdoowks said:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
Our recovery devs never restore such partitions or boot loader elements.
Click to expand...
Click to collapse
By "Our recovery devs" do you mean the ones doing the moto specific stuff? Do you know if this Is typical of the custom recoveries for other devices?
@scryan
I know far less then other posters, but yes android recoveries are all very similar in that regard.
scryan said:
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
Click to expand...
Click to collapse
The thing is you keep looking at it from a PC point of view, where you basically have full control over the software and hardware. Phones have much tighter restrictions on them from carriers, fcc, etc they're not personal computers. So the reason they make it where you can't downgrade the bootloader is because that's what controls the restriction on downgrading any other partition on the device.
So with the Moto X's 4.4.4 update they probably blew an efuse, so users with a locked device can't downgrade. This is done because with locked devices they can only flash signed kernels, so by blowing the efuse they can't downgrade to the vulnerable 4.4.2 and below kernel even though it is signed correctly. This is because lets say a malicious app was able to get on a device that had the ability to downgrade say back to 4.2.2. That app could flash the older vulnerable signed kernel to the recovery partition, to disable write protection gain more control over the phone etc, without the users knowledge. Now that is a stretch and probably will never happen but that doesn't mean the threat isn't there, and hackers are very creative at deploying malicious attacks. So by updating the bootloader and blowing an efuse the older vulnerable kernels can't be flashed. Now this is all negated if you're unlocked of course, but if you don't want to ever worry about this issue don't update your bootloader. This is not recommended but I've mentioned it several times on this forum I haven't updated my X's bootloader since I bought it, it's still running the factory 4.2.2 bootloader, running 4.4.4 with no problem.
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
iKrYpToNiTe said:
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
Click to expand...
Click to collapse
A bit selfish, and perhaps lazy of me but I am only really here talking about the developer version, I just haven't bothered to write the full "verizon developer edition " every time (most of this is research for next phone, which will be developer handset)... To me, obviously a locked phone is going to have weird restrictions and hacked together paths to getting things done, your not supposed to have admin rights...(yeah, maybe I do look at it too much as a computer. Mostly because I am annoyed the differences seem intentionally imposed). But when I pay outright for a device so that I can own it and have full administrative control... anyways, thats a different more philosophical discussion. The point is I have been talking about an unlocked device using third party software where possible.
Either way, appreciate the reply. I have a better understanding of the issue... Though coming from an S4 it still seems weird that MDK*/developer phones don't seem to have the same issues/warnings. It would seem however that the difference may be that MDK/dev owners only use kernels/roms prepared for their devices and do not update the bootloader. I suppose if more people in the Moto X community were worried about maintaining the ability to downgrade an unlocked device it would be technically possible to upgrade in a way that could be easily reversed, similar to the S4.
(*MDK was the first VZ S4 firmware, and the only one that has a released exploit to allow for a full custom recover. Later locked firmwares must rely on safestrap)
Related
I'm using Moto XT1060 and on 4.4.4. I want to flash custom ROM, is there any ways to do this? Because i saw that must be on 4.2.2 to use safestrap recovery, and downgrade would be brick ? So anyway for me to go on ?
Once you are on 4.4.4 downgrading will result in a brick! The bootloader can NOT be downgraded.
Travisdroidx2 said:
Once you are on 4.4.4 downgrading will result in a brick! The bootloader can NOT be downgraded.
Click to expand...
Click to collapse
Bad news !
Yup, anything after and including 4.4.2 will brick if downgraded. This even goes for my Dev edition
Have you looked into the China middleman? He seems to be becoming somewhat less reliable but you may be able to get an unlock code which would allow you to flash unlocked versions of ROMs rather than being limited to safestrap versions. Either that or wait to see if sunshine gets updated to work on 4.4.4.
To answer your question directly. Do NOT downgrade. While there is SOME conflicting info here, the overwhelming consensus is that downgrading will result in a brick either now or during a future upgrade.
cntryby429 said:
Have you looked into the China middleman? He seems to be becoming somewhat less reliable but you may be able to get an unlock code which would allow you to flash unlocked versions of ROMs rather than being limited to safestrap versions. Either that or wait to see if sunshine gets updated to work on 4.4.4.
To answer your question directly. Do NOT downgrade. While there is SOME conflicting info here, the overwhelming consensus is that downgrading will result in a brick either now or during a future upgrade.
Click to expand...
Click to collapse
Curious what the conflicting information is?
cntryby429 said:
To answer your question directly. Do NOT downgrade. While there is SOME conflicting info here, the overwhelming consensus is that downgrading will result in a brick either now or during a future upgrade.
Click to expand...
Click to collapse
Travisdroidx2 said:
Curious what the conflicting information is?
Click to expand...
Click to collapse
The conflicting information is due to a few things...
1. It usually revolve around not explaining that due to security and other issues, GPT.BIN and MOTOBOOT.IMG can't be downgraded properly. And this causes a wide variety of issues.
2. We've had some who downgrades, doesn't brick then declares it "SAFE" for all... without taking into consideration what happens when future OTA gets installed (which is brick).
3. We've seen some try to be "fancy" and use mfastboot to downgrade everything but GPT.BIN and MOTOBOOT.IMG, the phone reboots and may generally work, so its declared "safe"... but doesn't explain there have been issues (like when on 4.4.2 and flashing down to 4.4 this way, go to Settings -> Security kicks you out)... and also doesn't take into consideration what happens when parts of the phone are miss-matched when a future OTA is taken and gets installed (bricks or on occasion user gets lucky and it just fails to install instead)... and this also poses a challange returning to a 100% consistent state.
4. We've seen those who don't explain that trying to downgrade with RSDLite will likely fail or will immediately brick your phone (which has happened). Or at least convey some kind of warning.
and more..
In most/all of these cases, the person who "tested it" and says "Its safe" fails to explain the risks and fails to state there are MANY threads and Posts of users who HAVE BRICKED while trying to downgrading, or at some point after downgrading, etc.
So, rather than seeing a ton of caveats, conditions, etc you'll just see most of give the "DO NOT DOWNGRADE!!" warnings.
I have read all of those "safe" way to downgrade that eventually leads to a brick. That is why I tell people do not downgrade even though I know it is the gpt.bin and bootloader security that can not be downgraded. I was just curious if that was the conflicting information or if it was me telling him that you will brick if downgrading was the conflicting information.
Travisdroidx2 said:
I have read all of those "safe" way to downgrade that eventually leads to a brick. That is why I tell people do not downgrade even though I know it is the gpt.bin and bootloader security that can not be downgraded. I was just curious if that was the conflicting information or if it was me telling him that you will brick if downgrading was the conflicting information.
Click to expand...
Click to collapse
Sorry if that wasn't clear. By "here" I meant that conflicting info can be found here in the Moto X xda forum, not in your post. Now that these people have recklessly posted stuff trying to say that you can downgrade, I think it's worth acknowledging that the misinformation exists rather than just saying "you can't, period." That way the casual reader doesn't see one of those posts and think he's about to get away with something that other (read, capable & most knowledgeable) folks have said "just can't be done." That's all. No confrontation intended unless you count those yahoos trying to say it's safe.
cntryby429 said:
Sorry if that wasn't clear. By "here" I meant that conflicting info can be found here in the Moto X xda forum, not in your post. Now that these people have recklessly posted stuff trying to say that you can downgrade, I think it's worth acknowledging that the misinformation exists rather than just saying "you can't, period." That way the casual reader doesn't see one of those posts and think he's about to get away with something that other (read, capable & most knowledgeable) folks have said "just can't be done." Today's all. No confrontation intended unless you count those yahoos trying to say it's safe.
Click to expand...
Click to collapse
Thanks for the response! I see your point. It is a good one to point out because we still see people ending up with a brick because they followed what someone told them was safe. Or they just don't read the warnings first.
I'll try to sum this up...
No, you can't downgrade. Unless you have money sitting in your pocket for a new device... Which more times than not is what you'll need to do.
2 new downgrade brick threads today.
Still wanna try? ?
So I actually don't have the S5, or any Samsung device for that matter, but a friend of mine does, and really wants to root their phone. I had no idea the AT&T S5 was so secure, but it's pretty interesting too. I've been researching for over 15 hours. I may not have been able to root his phone, but I think I have learned a couple things and maybe some possible root methods.
1.) Since using ODIN to downgrade would soft brick the phone, would it be possible to download the stock Lollipop update onto a computer, give the update super user access, replace the recovery with a custom one, or unlock the bootloader from the computer, then flash it through ODIN?
2.) Intercept any sort of OTA update, then alter it to flash a custom recovery or unlock bootloader? I don't know how you would go around this though.
3.) If someone hasn't taken the OTA update that patched the Stagefright exploit, could someone purposely use the exploit to allow installation of a custom recovery or even to unlock the bootloader since the Stagefright bug has super user access (or so I've heard).
Also, I'm sorry if these are stupid ideas. I know close to nothing about Samsung so everything I'm basing this off of is what I've read in the past 15 hours.
jsmithfms said:
So I actually don't have the S5, or any Samsung device for that matter, but a friend of mine does, and really wants to root their phone. I had no idea the AT&T S5 was so secure, but it's pretty interesting too. I've been researching for over 15 hours. I may not have been able to root his phone, but I think I have learned a couple things and maybe some possible root methods.
1.) Since using ODIN to downgrade would soft brick the phone, would it be possible to download the stock Lollipop update onto a computer, give the update super user access, replace the recovery with a custom one, or unlock the bootloader from the computer, then flash it through ODIN?
2.) Intercept any sort of OTA update, then alter it to flash a custom recovery or unlock bootloader? I don't know how you would go around this though.
3.) If someone hasn't taken the OTA update that patched the Stagefright exploit, could someone purposely use the exploit to allow installation of a custom recovery or even to unlock the bootloader since the Stagefright bug has super user access (or so I've heard).
Also, I'm sorry if these are stupid ideas. I know close to nothing about Samsung so everything I'm basing this off of is what I've read in the past 15 hours.
Click to expand...
Click to collapse
The issue is that AT&T (and Verizon) use an encrypted signature key to verify they are the correct unaltered files as well as the means to unlock the bootloader to allow the OTA. Without that key, the tasks you mention are near impossible. They are not stupid ideas at all..just very difficult with all the security checks included.
KennyG123 said:
The issue is that AT&T (and Verizon) use an encrypted signature key to verify they are the correct unaltered files as well as the means to unlock the bootloader to allow the OTA. Without that key, the tasks you mention are near impossible. They are not stupid ideas at all..just very difficult with all the security checks included.
Click to expand...
Click to collapse
Crap... well does anyone know how that encyption key is generated? Like, could I theoretically get an algorithm from a ROM?
Honestly for the time being I wouldn't bother with ROMS for that Device and carrier at the moment. Especially being that its someone elses device. Towelroot should be a good start. If Im not mistaken I don't think its supposed to trip knox.
Sent from my HTCEVODesign4G using XDA Free mobile app
jsmithfms said:
Crap... well does anyone know how that encyption key is generated? Like, could I theoretically get an algorithm from a ROM?
Click to expand...
Click to collapse
This is the riddle of the Sphinx my friend. I am sure the super devs have tried their best so far to crack it. It has been an ongoing effort to make phones more and more secure, not against the amateur developers and rooters, but against the hackers. These smartphones are now our personal computers, diaries, personal assistants, financial operator, and more. They basically are a person's (and business's) life. AT&T and Verizon have taken the big steps to appeal to the Exchange clients, corporate, government and military contracts. Even the general public want to know their phone is secure. This is what keeps me stuck on the Sprint network.
Have you tried Kingroot?
I successfully rooted my wife's AT&T S4 on OC3 lollipop (supposedly unrootable) with the desktop version. Mobile version didn't work but desktop did without a hiccup. Maybe it'll work on the S5.
http://forum.xda-developers.com/android/apps-games/one-click-root-tool-android-2-x-5-0-t3107461
Rockin' a l337 with Goldeneye v49.1 + Wanam Xposed and loving life on AT&T's 4G LTE network
S5 on lollipop has a new nasty boot loader.... it was a miracle on its own that they ever came up with safestrap to duck the boot loader on earlier versions of android
Is it possible to unlock?
At this moment, no.
You will know as it'll be reported here very early. There are some third party companies that do it. Some are cheaper than others.
For the moment, there is nothing..
Sucks I know
I asked this before on another similar thread and didn't get a response. Is it possible to dump the bootloader from either an unlocked or locked phone to analyse it for potential vulnerabilities either in how it handles the unlock code, or more generally that would allow a user to soft-mod unlock the phone? I know for the 5th, 7th, and 9th gen Fire 7 tablets exploits were found in the LK part of the bootloader which eventually allowed for a customised version of TWRP to be flashed onto the devices, and later LineageOS. If we could dump the current Huawei bootloader surely we could try to find if there are any similar exploits?
I am found metod but it needs mrt dongle((
Tbh custom roms aren't really important anymore. Google is already ruining android everytime a new update comes around, like the overlay feature that was introduced in oreo but then removed for no reason.
Besides EMUI is already optimised for the chip so, again, no reason for custom roms and/or rooting (unless you want to remove bloatware but that can be solved via ADB)
The Restless Soul said:
Tbh custom roms aren't really important anymore. Google is already ruining android everytime a new update comes around, like the overlay feature that was introduced in oreo but then removed for no reason.
Besides EMUI is already optimised for the chip so, again, no reason for custom roms and/or rooting (unless you want to remove bloatware but that can be solved via ADB)
Click to expand...
Click to collapse
I am need it for root and lineage os
newbie warning: don't re-lock bootloader, and beware flashing any custom ROM. &OTA...
only modify a phone you are willing to throw away.......
##
pre-note: TWRP 3.3.1-0 -> fastboot boot twrp.img (this is temporary)
before doing anything, backup some little partitions: EFS, fsg, Vendor. Maybe others. You will need these to get back to a working stock.
##
$$
DO AT YOUR OWN RISK - I TAKE NO RESPONSIBILITY.
note added 2-27-2020: it may be that some problems with returning to stock are due to not (in TWRP) advanced wiping data, system, dalvik ART cache before flashing. You can do temp "fastboot boot twrp-3.3.1-0-payton.img" w/o quotes, and do it there. -changed/edited. don't use TWRP to flash a stock zip!
$$
NO FIX IS KNOWN FOR ANY OF THESE PROBLEMS. PHONE IS DESTROYED.
newbie warning: don't re-lock bootloader, and beware flashing ANY custom ROM.
On the X4, the bootloader changes drastically between 8 and 9 as it introduces a dual file system which is used by OTA updates to alternate the live system, and as a backup if failure. It is not a true Treble system, only partial. You must not depend on being able to flash back and forth between O and P. If you update to P, stay there. I expect this to be exacerbated by those phones which update to 10, if that in fact happens(probably One/fi only). There is also much confusion as to which file system/setup any custom ROM uses, and thus, how you would get back to stock, if that is even possible. Be very careful and assure yourself that you are fully willing to lose permanently your new phone before you do anything. Please read posts in these forums.
I've seen many posts of folks, mostly noobs, who have flashed ANY custom ROM Lineage and are unable to get back to a working stock. Sounds super simple but apparently it's not. Best to assume that if you try things, especially Lineage, that you will never be able to get back to a working stock. Read a bunch of posts here and you will realize that.
I've also seen a bunch of folks on this phone, and other phones who have run a bat file to flash their phone which contains the line
"fastboot oem lock" or similar.
Don't do it!!! - This will lock your phone and you will never be able to do anything with it again. It is totally unnecessary to lock your phone. Folks who should know better are leaving bat files lying around with this command. If you use one of those bat files to flash your phone, just check and remove that command line. Else you will have destroyed your phone. That's one of those things that "sounds good" until you do it.
EDIT: You can run stock on a bootloader unlocked phone - I do it all the time - plays PoGo just fine. I don't know about banking apps - I don't use them as I assume any 10-year-old can and will hack my phone.
EDIT: 6Feb2020: folks are reporting taking a security OTA onto a modified phone and rendering their phone(s) unusable. Only take OTA to a pure unmodified (no Majisk ever on it)(etc)(no mods ever on it)(stock recovery)(etc) stock ROM. Heed this warning. All of these "temporary" mods leave traces that screw up the update process.
EDIT: this was successfully fixed. see: https://forum.xda-developers.com/moto-x4/help/ota-update-endless-fail-loop-ppws29-69-t4045771 my guess is only works if you haven't changed bootloader or file system - NO custom ROM.
NO FIX IS KNOWN FOR ANY OF THESE PROBLEMS. PHONE IS DESTROYED.
Please do a lot of reading here before you try to modify your phone, unless you are totally willing to render it useless. A word to the wise.
Ahah ))) I bought today X4 with relocked BL and I it seems it was relocked after flashing LOS or similar )) )
Now I trying to recover it ))
Сan we boot phone to QC9008 (EDL) mode without testpoiint?
St.Noigel said:
Ahah ))) I bought today X4 with relocked BL and I it seems it was relocked after flashing LOS or similar )) )
Now I trying to recover it ))
Сan we boot phone to QC9008 (EDL) mode without testpoiint?
Click to expand...
Click to collapse
afaik, you can't. Return the phone and get your money back. There will probably be a bunch of these worthless phones put up for sale. If you can't return it you could try the suggestions of sd_shadow in other threads here, but I don't believe they were successful on the X4.
KrisM22 said:
afaik, you can't. Return the phone and get your money back. There will probably be a bunch of these worthless phones put up for sale. If you can't return it you could try the suggestions of sd_shadow in other threads here, but I don't believe they were successful on the X4.
Click to expand...
Click to collapse
OK. But I unbrick it. Now I have fully loaded system, but without WiFi ot mobile network.. It`s problem - I can`t turn on OEM unlocking.. (
Goшng to try to find solution
UPD. Everything work well now. But it my device I have custom stock flashed. Not sure it`ll work with LOS onboard
its to late for me
llue45 said:
its to late for me
Click to expand...
Click to collapse
Yeah, I know. You're one reason I posted this.
modified OP
change: from "Lineage" to "any custom ROM"
hi im thinking about buy this phone for 100 bucks used how i can verify this relocked bootloader problem ? in Developer Options ? if i cant switch to Oem Unlocking its broken ? to make sure this dont happen to me the one who its selling it to me says that already its updated to PIE , i want stock and root it just that after unlock the bootloader but if cant be unlocked i better move on . so my question is what really im looking for , when i get my hands on the phone before drop my money to the thin air because is not a store . and maybe never see this guy again in my life , i Live In The Caribbean Dominican Republic
People here are not so trusty . so i will appreciate if i can have some tips to know if im going to do a good Buy. Thanks In Advance .
JavaShin said:
hi im thinking about buy this phone for 100 bucks used how i can verify this relocked bootloader problem ? in Developer Options ? if i cant switch to Oem Unlocking its broken ? to make sure this dont happen to me the one who its selling it to me says that already its updated to PIE , i want stock and root it just that after unlock the bootloader but if cant be unlocked i better move on . so my question is what really im looking for , when i get my hands on the phone before drop my money to the thin air because is not a store . and maybe never see this guy again in my life , i Live In The Caribbean Dominican Republic
People here are not so trusty . so i will appreciate if i can have some tips to know if im going to do a good Buy. Thanks In Advance .
Click to expand...
Click to collapse
Good to not be trusting!!!! With this (or any) phone, I recommend you get only from a place (like ebay) where you can easily return it and get your money back. ebay can force a reluctant seller to refund your money. Assure that the seller has a 99% + rating and says they will accept returns and pay for return shipment, usually for 30 days. I don't think you can easily tell if it has been unlocked and re-locked - only that it works perfectly, or doesn't. You can check the ID of the ROM in your phone against the latest for your area by checking lolinet.
When you get it, check all functions and assure IMEI is present. check wifi, BT, etc etc. Make calls. Check that the phone works with the towers in your area and with a local SIM. etc etc. read here and find the things that folks having problems where it won't do things and assure your phone will do it. Install Pokemon Go on it and play it briefly to assure your phone hasn't been modified. I have no idea if any of these phone will work with any banking or payment apps, and each app will have it's own specific checks that it performs against the phone. Test what you will use. Fully. ASSUME NOTHING!!!
As far as rooting it and/or unlocking it, I would strongly advise against it. For this particular phone X4 I would determine that it works perfectly and then NOT modify it. Unless, of course, you are willing to throw your phone away and buy a new one without a second thought(most of us don't have that kind of money!). Mine happened to have been unlocked when I got it from ebay but it was on a stock 8.1 and it was able to, and did OTA update to the latest Pie stock ROM. Thus I was easily able to assure if was okay. It being unlocked seems to have affected nothing. I have never tried to root it or do anything to it (recovery or otherwise) as I read far too many posts of folks here who had rendered their phones incapable of returning to a working stock, and only on a limited custom. Not what I wanted. I have not heard of anyone successfully getting one of these phones back to a FULLY WORKING stock state.
The days of getting a phone and easily modifying it and then returning it to stock may be gone. Get a phone you will enjoy, and use it! Unmodified!!! Welcome to pre-Treble part1a . Expect a few years of growing pains.
I like my phone and enjoy not having to worry about whether a custom ROM will work and constantly be chasing updates and fixes. I use a case - I believe it is this one
https://www.ebay.com/itm/For-Motoro...hash=item33d89fee5a:m:mU5XV7jSj1TfD_kr-L4VT9g
which, so far, has protected it from several minor falls. I would never use any phone w/o a case!!!
But i think if the phone gets unlocked the bootloader and flash twrp making a backup of the stock recovery before just booting the twrp custom recovery then flash magisk on twrp on top of Stock PIE , After Of Course Make A Full Backup Of all partitions reboot and then on Stock PIE have ROOT. and never flash custom roms and never lock the bootloader and stock can be reflashed without problems with a script on linux with fastboot on bootloader-fastboot mode this plan can work , NO ? i had a E4 sprint and never had problems doing that
I need root for A Lot Of Things like Xposed Drivedroid Youtube vanced Adway ETC.
Can Anyone who is reading this have done this just root pie on this phone with unlocked bootloader ? and able to restore stock flashing it back with the retail firmware just to remove root and clean the stock and recovery ? or try to put android one ? the phone which im going to buy its the XT1900-6 retail brazil i already have the retail stock official pie rom ready to flash and with the script on linux with no fastboot oem lock anywhere .
added to OP: EDIT: 2-6-2020 folks are reporting taking a security OTA onto a modified phone and rendering their phone(s) unusable. Only take OTA to a pure unmodified (no Majisk ever on it)(etc)(no mods ever on it)(stock recovery)(etc) stock ROM. Heed this warning. All of these "temporary" mods leave traces that screw up the update process.
OTA issues
KrisM22 said:
added to OP: EDIT: 2-6-2020 folks are reporting taking a security OTA onto a modified phone and rendering their phone(s) unusable. Only take OTA to a pure unmodified (no Majisk ever on it)(etc)(no mods ever on it)(stock recovery)(etc) stock ROM. Heed this warning. All of these "temporary" mods leave traces that screw up the update process.
Click to expand...
Click to collapse
I posted a new thread on these OTA issues with the X4 at https://forum.xda-developers.com/moto-x4/help/ota-update-endless-fail-loop-ppws29-69-t4045771. I was never presented with an "option" to install the latest OTA, it just automatically attempted to install (apparently a FORCED update) and is continuing to do so and failing ad infinitum. That phone works, just getting constant failure notifications. Question is, how to stop the attempted updates?
The second identical phone (updated per Magisk OTA tutorial instructions) is borked, with no phone connectivity. Can these be recovered by wiping/flashing stock rom PPWS29.60-39-6-2 and get them operating again as stock? I can forego the OTAs if there's a way to stop them from screwing up the device.
I never had other than stock recovery on either of these phones, I always boot TWRP via fastboot to do mods.
EDIT: XDA system is stalling and caused double post. Sorry. Mod please delete.
-deleted by me -
@redwoodie , please don't post to this thread. I read all your threads/posts but have no information.
NO FIX IS KNOWN FOR ANY OF THESE PROBLEMS. PHONE IS DESTROYED.
As to whether "x" strategy will work, you are certainly free to explore that on your own, in your own thread.
No one here knows. I am certainly not going to experiment on my own phone and run the likelihood of having to buy a new one. Folks like yourself keep showing up and doing just that because they are SURE it will work. But it hasn't.
Read all the posts.
There are very few folks left here on this forum. Once they have destroyed their phone, and tried a bunch of things, they move on.
THERE IS NO SOLUTION.
This thread is only to warn newbies.
I personally know nothing about the phone other than what has been posted by others.
Read it.
If you discover a true solution that allows a phone to work perfectly ON STOCK, please post it and you will make lots of folks happy, assuming it is repeatable.
However, no known solution.
But, again, you are free to explore solutions - just not in this thread, please. Thanks.
added paragraph at top:
$$
DO AT YOUR OWN RISK - I TAKE NO RESPONSIBILITY.
note added 2-27-2020: it may be that some problems with returning to stock are due to not (in TWRP) advanced wiping data, system, dalvik-ART-cache before flashing. You can do temp "fastboot boot twrp-3.3.1-0-payton.img" w/o quotes, and do it there. -changed/edited. don't use TWRP to flash a stock zip!
This guy is full of crap
KrisM22 said:
only modify a phone you are willing to throw away.......
NO FIX IS KNOWN FOR ANY OF THESE PROBLEMS. PHONE IS DESTROYED.
Please do a lot of reading here before you try to modify your phone, unless you are totally willing to render it useless. A word to the wise.
Click to expand...
Click to collapse
I've literally put so many different custom ROMs on this phone. I've bricked it, unbricked, hard bricked it and soft bricked it. Stop misinforming people bro. The Moto G6 I would say to be careful with but still I wouldn't make a post like this guy. The Moto x4 just requires a little prep to make it a full treble, GSI accepting, custom Rom beast. Plus there are a few official ROMs out there even Android 10 for the Moto x4 specifically. Don't be scared. Just research a lot and follow instructions
---------- Post added at 03:28 PM ---------- Previous post was at 03:24 PM ----------
JavaShin said:
But i think if the phone gets unlocked the bootloader and flash twrp making a backup of the stock recovery before just booting the twrp custom recovery then flash magisk on twrp on top of Stock PIE , After Of Course Make A Full Backup Of all partitions reboot and then on Stock PIE have ROOT. and never flash custom roms and never lock the bootloader and stock can be reflashed without problems with a script on linux with fastboot on bootloader-fastboot mode this plan can work , NO ? i had a E4 sprint and never had problems doing that
I need root for A Lot Of Things like Xposed Drivedroid Youtube vanced Adway ETC.
Can Anyone who is reading this have done this just root pie on this phone with unlocked bootloader ? and able to restore stock flashing it back with the retail firmware just to remove root and clean the stock and recovery ? or try to put android one ? the phone which im going to buy its the XT1900-6 retail brazil i already have the retail stock official pie rom ready to flash and with the script on linux with no fastboot oem lock anywhere .
Click to expand...
Click to collapse
The op is a cracker Jack
Ims status not registered
Guys i flashed custom rom without taking backups of efs and all,so i ended up with ims status not registered because of that my volte is broken mine is retin.I tried to flash stock firmware but the imei is broken.Any way to fix this?
bumpsi since apparently folks are not reading this. mod a phone, likely lose it. relock a phone and def lose it.
Totally stock pixel 5. Tried to sideload 12, and due to crappy instructions on XDA, that failed to mention the need to do the OEM unlock step, I ended up with a ADB sideload flash that failed at 94% and resulted in a empty A partition and a phone that failed to boot, so it switched to the backup system partition.
I'm now booted on the B partition (Android 11).
How can I fix my phone, so it's got 2 good system partitions?
Enable OEM unlocking, unlock bootloader, then use the Android Flash Tool to flash 12 Beta 5. Wiping /data shouldn't be necessary; however, if this fails and you have to force flash all partitions, a /data wipe will be required.
I highly recommend you keep the bootloader unlocked while using beta firmware, because it makes it a LOT easier to downgrade back to production firmware.
If you intend to root, don't forget to disable dm-verity and vbmeta-verification.
Detailed instructions on using the Android Flash Tool
Tip: When you get to the step of selecting which build to flash to your device, click the pencil icon to change options. Make sure you leave Relock Bootloader unchecked,
V0latyle said:
Wiping /data shouldn't be necessary
Click to expand...
Click to collapse
But unlocking the bootloader will wipe the phone.....
EDIT: I'm assuming there is a wipe data option with Android Flash Tool?
I don't know. I've never used it
xunholyx said:
But unlocking the bootloader will wipe the phone.....
Click to expand...
Click to collapse
Correct, but it's still necessary to install the beta (and downgrade)
xunholyx said:
EDIT: I'm assuming there is a wipe data option with Android Flash Tool?
I don't know. I've never used it
Click to expand...
Click to collapse
There is indeed. It's actually quite comprehensive.
I don't want to unlock the bootloader. I just want to get a system partition back, I do t want root or any modifications,
Chr1stOnABike said:
I don't want to unlock the bootloader. I just want to get a system partition back, I do t want root or any modifications,
Click to expand...
Click to collapse
In that case, I believe the only option for you is to attempt to sideload the OTA via recovery.
Download the beta OTA here
Follow the instructions to apply the OTA here
If this does not work, you can try using the Android Flash Tool after enabling Developer Options and USB Debugging. You can choose not to wipe your device in the tool options. No guarantee this will work. Requires unlocked bootloader
I will say this: Running beta software on a locked bootloader is not only highly inadvisable, it's foolhardy. Beta software is EXPERIMENTAL, you use it AT YOUR OWN RISK, meaning it is YOUR responsibility to fix it if something goes wrong. Keeping your bootloader unlocked means your ability to fix it is limited, if not impossible.
V0latyle said:
In that case, I believe the only option for you is to attempt to sideload the OTA via recovery.
Download the beta OTA here
Follow the instructions to apply the OTA here
If this does not work, you can try using the Android Flash Tool after enabling Developer Options and USB Debugging. You can choose not to wipe your device in the tool options. No guarantee this will work.
I will say this: Running beta software on a locked bootloader is not only highly inadvisable, it's foolhardy. Beta software is EXPERIMENTAL, you use it AT YOUR OWN RISK, meaning it is YOUR responsibility to fix it if something goes wrong. Keeping your bootloader unlocked means your ability to fix it is limited, if not impossible.
Click to expand...
Click to collapse
Flash tool doesn't work, as it expects to go i to recovery, and it doesn't it comes up with the no system error.
So when android 12 releases in a couple of weeks, will it just flash it to the other partition, to retain 11? In other words,will this fix itself in the fullness of time.
Also, who is going to fix the crappy XDA blog post that was poorly checked that caused this mess. I can't be the only one (I know the flawed instructions have been copied by the usual churnalists 9to5google Android authority, Android police)
Chr1stOnABike said:
Flash tool doesn't work, as it expects to go i to recovery, and it doesn't it comes up with the no system error.
Click to expand...
Click to collapse
Ah. Well, you can fix this, but it will require unlocking the bootloader.
You can always relock it after you're done.
Chr1stOnABike said:
So when android 12 releases in a couple of weeks, will it just flash it to the other partition, to retain 11? In other words,will this fix itself in the fullness of time.
Click to expand...
Click to collapse
Don't know. Given that you can't boot into recovery, you can't sideload the OTA to test this theory. I personally doubt it. You can either wait and see, or you can just bite the bullet and fix the issue.
Chr1stOnABike said:
Also, who is going to fix the crappy XDA blog post that was poorly checked that caused this mess. I can't be the only one (I know the flawed instructions have been copied by the usual churnalists 9to5google Android authority, Android police)
Click to expand...
Click to collapse
Link to the post? You may not be the only one, but the majority of folks (including myself, I was in the Marine Corps for 9 years so you can guess my mental acuity) have been able to use the instructions to our success.
Isn't unlocking and relocking bootloader detectable in soft fuses and an instant warranty void?
How to install Android 12 and 12L on Google Pixel and other Android devices
Google has just released Android 12L beta for the Pixel lineup. Here is how you can install Android 12 (or 12L) on your smartphone!
www.xda-developers.com
Someone in the comments also broke their phone by following the untested Instructions.
Chr1stOnABike said:
Isn't unlocking and relocking bootloader detectable in soft fuses and an instant warranty void?
Click to expand...
Click to collapse
I'm not sure. But that raises a question for you: Why are you running beta firmware if you're worried about the warranty?
Chr1stOnABike said:
How to install Android 12 and 12L on Google Pixel and other Android devices
Google has just released Android 12L beta for the Pixel lineup. Here is how you can install Android 12 (or 12L) on your smartphone!
www.xda-developers.com
Someone in the comments also broke their phone by following the untested Instructions.
Click to expand...
Click to collapse
I have updated my phone using both of these methods and can personally confirm the instructions are correct. The only difference I would point out is that I'm comfortable enough using adb and fastboot commands that I manually type them and don't use the batch file.
It is your responsibility to understand the instructions and follow them. You flash and modify your device at your own risk. If you do not fully understand the instructions, it is also your responsibility to either find the details you need, or ask for help.
This may seem rather condescending or apathetic, but the situation is this:
- You tried to run experimental beta firmware on your device despite your concerns for the warranty
- You did not ask questions before doing so, and if you did read any of the multiple threads on this issue, you would have been acutely aware of the recommendation to unlock your bootloader before you proceed
- You are now left with few options to fix your device because you decided to ignore experienced advice and do things your own way
As I stated previously, the responsibility for fixing things is yours and yours alone. If you were that concerned with your warranty, you should have kept your phone completely stock and avoided installing the beta.
I have one last recommendation for you:
Disenroll from the beta program and wait for the OTA to take you back to A11 public release. A data wipe will be required.
You have been told in detail what you can do to fix your device. What you do now is completely up to you.
V0latyle said:
I'm not sure. But that raises a question for you: Why are you running beta firmware if you're worried about the warranty?
I have updated my phone using both of these methods and can personally confirm the instructions are correct. .
Click to expand...
Click to collapse
The instructions only work if you have previously done the unmentioned OEM unlock step, which you must have done.
The fact you don't understand this, it limits your credibility. Just because something worked for you, doesn't make it correct.
It also sounds like you don't understand the difference between OEM unlock and a bootloader unlock.
Chr1stOnABike said:
The instructions only work if you have previously done the unmentioned OEM unlock step, which you must have done.
Click to expand...
Click to collapse
Yes - I unlocked and rooted my phone the day I got it, and I bought it full price direct from Google. Your point?
Chr1stOnABike said:
The fact you don't understand this, it limits your credibility. Just because something worked for you, doesn't make it correct.
Click to expand...
Click to collapse
Yes, it's always worked for me. I've been trying to work with you here and give you options that do not require OEM Unlock or unlocking the bootloader. The reason I thought the Android Flash Tool might work is because it's literally a tool provided by Google, and though it uses ADB, I figured they might have some sort of security to allow recovery of locked phones.
What exactly is it you don't think I understand? As I've pointed out, you decided to install beta software on your device despite your concerns for warranty. As I ALSO pointed out, if warranty was that much of a concern for you, you should have stayed on stock public release firmware and not messed with anything at all.
I will admit that the guide you linked does not mention needing an unlocked bootloader. I think it's generally been assumed among us in the community that modifying your device requires an unlocked bootloader. I will talk to the mods and see if we can get a note added to the post. However, you seemed to miss the big warning that advises against using the beta on your daily driver.
Chr1stOnABike said:
It also sounds like you don't understand the difference between OEM unlock and a bootloader unlock.
Click to expand...
Click to collapse
Again, how so? If you're going to call me ignorant, you had better explain how.
OEM Unlock simply sets a flag: "unlock-ability" to 1. It's an on/off switch that corresponds to the 1 or 0 set for the "unlock-ability" flag. It has no other function.
When someone attempts to unlock the bootloader, the device checks that flag. If it's 0, the bootloader cannot be unlocked. If it's 1, it can.
Unlocking the bootloader disables security features that prevent you from flashing partitions on your phone, or booting images sent via ADB. The reason why this is important when running custom or experimental firmware is because it allows the user to reflash corrupted partitions (like in your case). It allows a lot more freedom over what you can do with your phone.
I've been doing this for years - more than 10 years in fact. I would be careful about making accusations like "you don't understand the difference" or "you don't know what you're talking about'" to someone who is trying to help you. I understand you're frustrated, but you're going to have to swallow your pride here and admit, at least to yourself, that you screwed up. It seems pretty clear to me that you either did not fully understand the risk of trying to modify your device with a locked bootloader (yes, installing the beta counts as a modification), or you ignored the risk and tried to do it anyway. Yet you come here and impugn my credibility? As they say, "check yourself before you wreck yourself". You screwed up and got yourself into this mess. You alone are to blame. No one has to help you, and believe me, I've been quite tempted to tell you to pound sand. The least you can do is show a little gratitude for someone who's trying to help, and respect for experience and knowledge far beyond your own.
I have one more option for you: Rescue mode.
Reboot your phone into bootloader (hold power + volume down, release power but keep holding volume down when screen turns off)
Use volume buttons to select rescue mode on the right side, then press power to select
Google Pixel Repair Tool
This probably won't work because the repair tool only works if the firmware on your phone is older or equivalent to the firmware the repair tool has.
Chr1stOnABike said:
The instructions only work if you have previously done the unmentioned OEM unlock step, which you must have done.
The fact you don't understand this, it limits your credibility. Just because something worked for you, doesn't make it correct.
It also sounds like you don't understand the difference between OEM unlock and a bootloader unlock.
Click to expand...
Click to collapse
I haven't had time to read much of this thread yet, but why insult the one person I see who's trying to help you?
I've seen this before and other users who may know what to do, usually just walk away as they don't want to help someone who may just insult them or are clearly unappreciative of the help given.
Everyone let's all keep it civilized.
If you have issue with a post, please hit report button and walk away.
Positive vibes, all.
--andybones
@Chr1stOnABike I am indeed trying to help you, as I understand your situation is frustrating. I also understand that it may be frustrating to be told to do what you didn't want to do in the first place, but the reason why I'm telling you to do it is because it'll be of the most help to you.
Losing your data sucks. I get it. But fortunately the Pixel 5 is great about backing everything up to your Google account. Just make sure your photos are backed up and you'll be fine. Setting it back up after a wipe is a pain in the ass, but again, I'm recommending the bootloader unlock because I believe it's your best chance at recovery.
As far as that goes, I'm still trying to be flexible and provide you with different options. Be aware that if these other options don't work, you have no other choice. I'm not saying that to be rude, that's just the reality of it.
And lastly, I would very much appreciate you making the distinction between thinking I'm wrong because you have evidence to the contrary, vs thinking I'm wrong simply because you don't like my recommendations. If you sincerely believe I'm incorrect and can demonstrate how, please feel free to do so.
My only objective here is to help people the best I can with the knowledge and experience I have.
For those who ever get stuck like I did. When I got stuck in a bootloop, I realized I could 'fastboot boot twrp.img' and was able to save my internal storage from being lost by backing up to PC with TWRP, then move it back onto internal after the factory reset. Did I lost app data in these cases, yes. But that's my own fault for not regularly backup app data up with something like Swift or AppDash.
@Chr1stOnABike just checking in to see if you were able to get your problem resolved?