Related
Does latest Twrp & root together work well with latest 7.1.1. just got my real blue pixel, read some posts and found the new device differs from the old ones.
But I have to root to use the TitaniumBackup and to enable location report and brevent.
and how to tell whether the device is from google store or it is a verizon based device. As I found Verizon login APP under app settings
Yes to first post and as for second check the purchase receipt.
Not kidding. Factory Verizon >is flashed with a Verizon firmware or euro or other, but it is possible to flash any factory image to any Pixel so unclear ultimately without receipt. Check Build Number in settings and compare to factory image list on Google
Latest firmware is for all carriers, so no way to tell without just knowing.. Maybe!
(BTW I do NOT have a Verizon Pixel, but i do have those apps. They install more stuff and enable features if your carrier is Verizon)
Sent from my sailfish using XDA Labs
I manually updated to 26Q with the Google image so I'm not sure how to tell anymore (have VZW Pixel). The way it works is Google will issue the security patches and Verizon will handle the firmware updates. I believe the VZW build will have a different code than the Google updates. That's why the Verizon branded units will get locked down with 7.1.1 and the Play editions won't.
As for TWRP/SU I have the latest and so far I see no issues.
FernBch said:
I manually updated to 26Q with the Google image so I'm not sure how to tell anymore (have VZW Pixel). The way it works is Google will issue the security patches and Verizon will handle the firmware updates. I believe the VZW build will have a different code than the Google updates. That's why the Verizon branded units will get locked down with 7.1.1 and the Play editions won't.
As for TWRP/SU I have the latest and so far I see no issues.
Click to expand...
Click to collapse
Here is my theory.
Google will post the code and it will be the same as Google's, there won't be any separate builds. The locking is some trickery in the code. Based on CID or IMEI.
Sent from my Pixel XL using XDA Labs
TonikJDK said:
Here is my theory.
Google will post the code and it will be the same as Google's, there won't be any separate builds. The locking is some trickery in the code. Based on CID or IMEI.
Sent from my Pixel XL using XDA Labs
Click to expand...
Click to collapse
The locking isn't trickery in the code. Verizon will do as they always have. The update they push will have a locked, AKA different, bootloader. Since that component is different the build will be different. Same old story......
If they were the same builds there would be no way to differentiate between the Verizon and Google versions.
---------- Post added at 01:10 PM ---------- Previous post was at 12:54 PM ----------
You may want to read more here. Pay particular attention to items 5&6. There is no guarantee that the updates for the Pixel/Pixel XL sold by Verizon will get an OS update at the same rime or on the same schedule as the Google sold devices. This will like lead to different build numbers so the two devices can be distinguished. Google will push security updates to all devices but Verizon has control over OS updates to the devices they sell.
https://www.google.com/url?sa=t&sou...SEx8oJKWAQNk7lueQ&sig2=AWtYaP2LMe9rsKQeDjdviQ
FernBch said:
The locking isn't trickery in the code. Verizon will do as they always have. The update they push will have a locked, AKA different, bootloader. Since that component is different the build will be different. Same old story......
If they were the same builds there would be no way to differentiate between the Verizon and Google versions.
---------- Post added at 01:10 PM ---------- Previous post was at 12:54 PM ----------
You may want to read more here. Pay particular attention to items 5&6. There is no guarantee that the updates for the Pixel/Pixel XL sold by Verizon will get an OS update at the same rime or on the same schedule as the Google sold devices. This will like lead to different build numbers so the two devices can be distinguished. Google will push security updates to all devices but Verizon has control over OS updates to the devices they sell.
https://www.google.com/url?sa=t&sou...SEx8oJKWAQNk7lueQ&sig2=AWtYaP2LMe9rsKQeDjdviQ
Click to expand...
Click to collapse
The bootloaders are the same. It's more likely verizon phones are recognized by the IMEI and or CID. If the difference was in the bootloader, you could unlock, flash a Google bootloader (if there was a difference between the Google and Verizon bootloaders) and then relock, update to 7.1.1 and then unlock again. Something you can't do. If you tried it, you'd wish you hadn't.
A simple way to know if your phone is a Verizon or Google phone is to look in developer options and see if OEM unlocking is available to you. If it's grayed out and you can't select it, it's a Verizon device. If not grayed out and you are able to select it, it's a Google device.
Thank you all, the phone is from Google store as the bootloader can easily be unlocked.
FernBch said:
I manually updated to 26Q with the Google image so I'm not sure how to tell anymore (have VZW Pixel). The way it works is Google will issue the security patches and Verizon will handle the firmware updates. I believe the VZW build will have a different code than the Google updates. That's why the Verizon branded units will get locked down with 7.1.1 and the Play editions won't.
As for TWRP/SU I have the latest and so far I see no issues.
Click to expand...
Click to collapse
Hi there. Verizon builds were different than Google's pre 7.1.1 but now they're the same. Reference my post here (applicable part quoted below) and the Google Nexus/Pixel firmware page https://developers.google.com/android/images.
roirraW "edor" ehT said:
One question I've been wondering about and haven't noticed if it's been addressed anywhere, the 7.1.1 builds are all the same for Verizon and non-Verizon. They're all NMF26O for the first release of 7.1.1 and NMF26Q for the second OTA of it.
So I'm wondering if putting a Verizon SIM in does anything anymore if you're on a stock 7.1.1 image. I could relatively easily find out, but it's not a huge priority.
Also, as long as you already unlocked the bootloader, nothing will re-lock it, even Verizon OTAs, unless you manually do so.
No idea if there'll be Verizon-specific builds again later.
Click to expand...
Click to collapse
Might soon find out, reportedly there's a new update for Verizon soon: NMF26U. It's not on Google's page, at least yet. http://forum.xda-developers.com/pixel/how-to/verizon-update-nmf26u-t3527199/post70281819#post70281819
roirraW "edor" ehT said:
Hi there. Verizon builds were different than Google's pre 7.1.1 but now they're the same. Reference my post here (applicable part quoted below) and the Google Nexus/Pixel firmware page https://developers.google.com/android/images.
Might soon find out, reportedly there's a new update for Verizon soon: NMF26U. It's not on Google's page, at least yet. http://forum.xda-developers.com/pix...ate-nmf26u-t3527199/post70281819#post70281819
Click to expand...
Click to collapse
This would fit the pattern for Verizon. In the past, irregardless of device/manufacturer, Verizon would issue a new build. The new build would have a different bootloader that had whatever exploit patched to prevent the new bootloader from being unlocked. The build number would also be different so the different variants could be distinguished from each other. Been on Big Red for a number of years and have watched this game play out time after time.
The details are not exactly clear but the original story from Google/VZW was Google will update all Google sold devices and issue security patches to all devices no matter where bought from. Any OS updates to Verizon devices would come from Verizon. They get the next build from the OEM and make sure it is up to their requirements (and patch if needed) then push it to their devices. Somewhere in the process I am guessing that there is a way to tell what Google sold from what Verizon sold. This would prove or disprove that only Verizon sold devices can actually get locked down if still locked.
Google may have tried to say no to VZW control like that but when it all settles out money is the key. And Google is going to make a bunch......
---------- Post added at 12:07 AM ---------- Previous post was at 12:00 AM ----------
Reading the article and the linked article inside it seems to point out that NMF26U is targeted towards the UK carrier and is supposed to address MMS issues.
FernBch said:
This would fit the pattern for Verizon. In the past, irregardless of device/manufacturer, Verizon would issue a new build. The new build would have a different bootloader that had whatever exploit patched to prevent the new bootloader from being unlocked.
Reading the article and the linked article inside it seems to point out that NMF26U is targeted towards the UK carrier and is supposed to address MMS issues.
Click to expand...
Click to collapse
Regarding the bootloader, it's not handled the same way as on some other devices. The bootloader is the same on both Google Store and Verizon Pixels.
Also from my understanding, the vulnerability wasn't in the bootloader itself.
Take good care of installing TWRP
According to the guide from the developer, I install TWRP step by step,
after fastboot boot path/to/twrp.img, the lockscreen pin/pattern/password did not get prompted.
So I have to reboot, then lost all my data.
Therefore, it is necessary to clear all your locksreen pin/pattern/password before using TWRP
roirraW "edor" ehT said:
Regarding the bootloader, it's not handled the same way as on some other devices. The bootloader is the same on both Google Store and Verizon Pixels.
Also from my understanding, the vulnerability wasn't in the bootloader itself.
Click to expand...
Click to collapse
Ah. That I did not understand.
So, I guess there is something else I need to learn.
bush911 said:
According to the guide from the developer, I install TWRP step by step,
after fastboot boot path/to/twrp.img, the lockscreen pin/pattern/password did not get prompted.
So I have to reboot, then lost all my data.
Therefore, it is necessary to clear all your locksreen pin/pattern/password before using TWRP
Click to expand...
Click to collapse
I don't believe it matters whether or not there was a password. I've tested this with security on one Pixel, and without on a XL. I flashed stock to both phones prior to testing. I used a PIN password on the Pixel, and never ever installed any type of security on the XL. The key is whether or not the phone is encrypted. I don't have a Google store phone as both of mine came from Verizon. On mine, they were encrypted out of the box. You can see this status under Security, Encryption. Both phones have troubles, but only one out of 6 entrances into TWRP RC1, that they were not successfully decrypted. I then used the Reboot to Recovery from within TWRP, still couldn't decrypt after several reboots. However, in my experiments, if I powered off the devices completely, my very next execution of TWRP decrypted successfully. I don't recall a case in which I had problems after a power off. Just does not make sense. When TWRP doesn't decrypt, you'd see that warning right at the first screen, unless you had previously checked the "Do not warn me again" box. Then you'll see your folders and files all understandably garbled.
I then attempted a couple methods to decrypt the phones from the get-go to see if TWRP would behave if there was no encryption. However, both methods require Magisk which no longer works with 7.1.1. So my attempt to decrypt went nowhere.
All that said, you should never lose your data though. If TWRP doesn't decrypt the phone, and you don't do any file management, the data is still there untouched.
Maybe you are right, I did not catch you very well.
My Pixel was from Google store I tried twice to install TWRP RC1 strictly following the guidelines by the developer.
For the first time, the phone with pattern set up, TWRP did not get me prompted to enter the pin and ended up losing all my personal data.
After rebooted several times, I cleared the pattern and succeeded.
My point is whether TWRP prompts you to enter pin or not, as I never saw this.
quangtran1 said:
I don't believe it matters whether or not there was a password. I've tested this with security on one Pixel, and without on a XL. I flashed stock to both phones prior to testing. I used a PIN password on the Pixel, and never ever installed any type of security on the XL. The key is whether or not the phone is encrypted. I don't have a Google store phone as both of mine came from Verizon. On mine, they were encrypted out of the box. You can see this status under Security, Encryption. Both phones have troubles, but only one out of 6 entrances into TWRP RC1, that they were not successfully decrypted. I then used the Reboot to Recovery from within TWRP, still couldn't decrypt after several reboots. However, in my experiments, if I powered off the devices completely, my very next execution of TWRP decrypted successfully. I don't recall a case in which I had problems after a power off. Just does not make sense. When TWRP doesn't decrypt, you'd see that warning right at the first screen, unless you had previously checked the "Do not warn me again" box. Then you'll see your folders and files all understandably garbled.
I then attempted a couple methods to decrypt the phones from the get-go to see if TWRP would behave if there was no encryption. However, both methods require Magisk which no longer works with 7.1.1. So my attempt to decrypt went nowhere.
All that said, you should never lose your data though. If TWRP doesn't decrypt the phone, and you don't do any file management, the data is still there untouched.
Click to expand...
Click to collapse
bush911 said:
Maybe you are right, I did not catch you very well.
My Pixel was from Google store I tried twice to install TWRP RC1 strictly following the guidelines by the developer.
For the first time, the phone with pattern set up, TWRP did not get me prompted to enter the pin and ended up losing all my personal data.
After rebooted several times, I cleared the pattern and succeeded.
My point is whether TWRP prompts you to enter pin or not, as I never saw this.
Click to expand...
Click to collapse
No big deal. I'm saying there are two different components at play here. One is the built-in encryption structure on the phone. The other is the user-assigned password (PIN, pattern, fingerprint). The PIN, pattern, fingerprint are used to access your phone -- we all recognize that. However, whether or not that password is set, the phone's encryption setting is set elsewhere. Namely, it's under Settings - Encryption. My phone can be passworded, but its data is not encrypted. Or vice versa, it can be encrypted but does not require an unlock to access it.
I'm also making the observation that TWRP sometimes, for whatever reason, does not decrypt the Pixel successfully. Many times I've entered the correct PIN on the TWRP screen, it advanced to the menu screen, but folders and docs were still garbled by encryption. Same thing would also happen on my XL without any password. After I powered off both phones, TWRP magically decrypted both phones, with and without PIN code, successfully by the fact that they now show folders and files properly. So, in my logic, once TWRP irons out its decrypting glitches, this issue goes away. Either that or whenever I figure out how to disable encryption permanently.
There is some sort of weird magic where unlocking the bootloader instantly breaks Widevine but locking it again fixes it.
How does that even work? How is it possible that NOBODY has figured out how to fix Widevine with an unlocked bootloader? You can emulate anything in software, right? Surely the information must be retained on the device somewhere if relocking the bootloader brings it back?
Is there still no solution to this? (please provide a more detailed answer than "it's not possible")
There is no way to hide a unlocked bootloader and because of that, it's not possible to have widevine l1 with an unlocked bootloader.
matze19999 said:
There is no way to hide a unlocked bootloader and because of that, it's not possible to have widevine l1 with an unlocked bootloader.
Click to expand...
Click to collapse
What do you mean there's no way to hide it? I don't think OnePlus uses like hardware secure environment stuff, especially because the 7 Pro doesn't have hardware backed SafetyNet...
@LoganDark Only OnePlus can fix it, at first 8 series didn't had Widevine L1 while having unlocked bootloader, OnePlus patched it in 10.5.11 (8) & 10.5.13 (8Pro) specifically, so ya the answer is Only OnePlus fix/patch it & they should do it for 7 Series as well IMO!
aaryan45 said:
@LoganDark Only OnePlus can fix it, at first 8 series didn't had Widevine L1 while having unlocked bootloader, OnePlus patched it in 10.5.11 (8) & 10.5.13 (8Pro) specifically, so ya the answer is Only OnePlus fix/patch it & they should do it for 7 Series as well IMO!
Click to expand...
Click to collapse
I mean, OnePlus can do it but that doesn't necessarily mean that nobody else can, right? I'm curious to know where these claims came from, that it's completely impossible to fake a locked bootloader...
My best guess is that the unlocked state of the bootloader prevents it from sharing the widevine keys with Android (something like that), but it should be possible to extract those keys if they are stored in such a way that relocking the bootloader restores L1 functionality. That is, of course, only possible if they aren't locked away with TrustZone or similar.
I hope the 7 series continues to receive updates and attention because it's the only good phone on the market right now with no notch or screen cutout. Nothing else compares... But since OnePlus is already starting to leave it out of OxygenOS beta tests, I feel EOL is not too far away. :/
I doubt they will add any new features or fix any functionality like Widevine support... They will just backport code they write for newer devices, until the update window is over.
LoganDark said:
I mean, OnePlus can do it but that doesn't necessarily mean that nobody else can, right? I'm curious to know where these claims came from, that it's completely impossible to fake a locked bootloader...
My best guess is that the unlocked state of the bootloader prevents it from sharing the widevine keys with Android (something like that), but it should be possible to extract those keys if they are stored in such a way that relocking the bootloader restores L1 functionality. That is, of course, only possible if they aren't locked away with TrustZone or similar.
I hope the 7 series continues to receive updates and attention because it's the only good phone on the market right now with no notch or screen cutout. Nothing else compares... But since OnePlus is already starting to leave it out of OxygenOS beta tests, I feel EOL is not too far away. :/
I doubt they will add any new features or fix any functionality like Widevine support... They will just backport code they write for newer devices, until the update window is over.
Click to expand...
Click to collapse
I did some research on widevine L1 on unlocked bootloader and if I'm not wrong,
liboemcrypto.so is the file which needs to be patched!
aaryan45 said:
I did some research on widevine L1 on unlocked bootloader and if I'm not wrong,
liboemcrypto.so is the file which needs to be patched!
Click to expand...
Click to collapse
Yeah, that might be the case, but the hard part is figuring out what patch to apply.
Possible sure, but this isn't really something you can just spoof or emulate through software.
This is very complicated things, both of a software and hardware level. Really the only people who discovers exploits of this are responsible security researchers who disclose this to Qualcomm and Google. Which I don't blame them for, they get a pretty juicy bounty.
I guess you can hope OnePlus messes up like they did for OP8/Pro and accidentally(?) enable L1 for unlocked bootloaders, but I am pretty sure they just implemented TEE differently to actually do that.
If you're curious, here;
https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html?m=1
https://research.checkpoint.com/2019/the-road-to-qualcomm-trustzone-apps-fuzzing/
Lossyx said:
Possible sure, but this isn't really something you can just spoof or emulate through software.
This is very complicated things, both of a software and hardware level. Really the only people who discovers exploits of this are responsible security researchers who disclose this to Qualcomm and Google. Which I don't blame them for, they get a pretty juicy bounty.
I guess you can hope OnePlus messes up like they did for OP8/Pro and accidentally(?) enable L1 for unlocked bootloaders, but I am pretty sure they just implemented TEE differently to actually do that.
If you're curious, here;
https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html?m=1
https://research.checkpoint.com/2019/the-road-to-qualcomm-trustzone-apps-fuzzing/
Click to expand...
Click to collapse
So it is implemented with complicated hardware stuff?
Okay, well, the only way to get L1 back is to lock the bootloader again. I know that now. All L1 stuff is handled in hardware. I'm working on a solution for custom ROMs and rooted OOS though, stay tuned
LoganDark said:
Okay, well, the only way to get L1 back is to lock the bootloader again. I know that now. All L1 stuff is handled in hardware. I'm working on a solution for custom ROMs and rooted OOS though, stay tuned
Click to expand...
Click to collapse
That sounds interesting. Can I help you with that?
sToRm1nG said:
That sounds interesting. Any way I could help you with that?
Click to expand...
Click to collapse
Yes, you can definitely help - the main blocker for me is that this is my daily driver so I haven't done anything in months, but if you're willing to be my "guinea pig" for a while, that would be a huge help.
LoganDark said:
Yes, you can definitely help - the main blocker for me is that this is my daily driver so I haven't done anything in months, but if you're willing to be my "guinea pig" for a while, that would be a huge help.
Click to expand...
Click to collapse
I'll be switching from my OP7Pro to my new OP8Pro shortly. So I'll be able to test what ever you need.
Do you think this research will also be applicable to the OP8Pro?
sToRm1nG said:
I'll be switching from my OP7Pro to my new OP8Pro shortly. So I'll be able to test what ever you need.
Click to expand...
Click to collapse
Niiiice~ Contact me on Discord: LoganDark#4357
sToRm1nG said:
Do you think this research will also be applicable to the OP8Pro?
Click to expand...
Click to collapse
Honestly I'm not sure. I haven't even confirmed if L1 will come back on the OP7Pro. It's just a rumor, after all, and I think OnePlus spent literally all of their benevolence on the 7.
Edit: It looks like OP might have made it so that the OP8 still has L1 even with an unlocked bootloader. Major oof
LoganDark said:
Niiiice~ Contact me on Discord: LoganDark#4357
Honestly I'm not sure. I haven't even confirmed if L1 will come back on the OP7Pro. It's just a rumor, after all, and I think OnePlus spent literally all of their benevolence on the 7.
Edit: It looks like OP might have made it so that the OP8 still has L1 even with an unlocked bootloader. Major oof
Click to expand...
Click to collapse
Yeah there is still a chance to get L1 with an unlocked bootloader on the OP8Pro though I'm not part of the lucky ones.
I'll contact you ASAP.
This is big for me, I was just watching Prime and saw 1080p HD on the overlay.
I checked DRM info to find I am on L1.
I am rooted obviously with an unlocked bootloader.
7T 256gB
OP7T_O2_BETA_3.
Amazing.
Tagtag123 said:
This is big for me, I was just watching Prime and saw 1080p HD on the overlay.
I checked DRM info to find I am on L1.
I am rooted obviously with an unlocked bootloader.
7T 256gB
OP7T_O2_BETA_3.
Amazing.
Click to expand...
Click to collapse
Did you unlock boot loader freshly after you updated to beta 3 or u were unlocked before that?
antonyben006 said:
Did you unlock boot loader freshly after you updated to beta 3 or u were unlocked before that?
Click to expand...
Click to collapse
Was unlocked from day 1 of using the device. Installed OB3 and noticed prime play 1080p. Checked DRM Info to see I have got L1, checked Netflix(it still showed L3, so I cleared cache and then it showed L1).
I've seen people managed to have l1 certification with unlocked bootloader with the oos 11 ob 3 or newer than that even with custom rom. It seemed so simple that I've tried it myself
but then when I was in oos 11 with bootloader unlocked, the widevine was still l3.
I even went as far as installing fresh oos 10 with msm tool, unlock the bootloader and then immediately install twrp, flash oos 11 ob4/stable 11.0.0.0/stable 11.0.0.2 + dfe + magisk, turned on magisk hide but unfortunately it was still in l3, and whenever I locked the bootloader it always successfully went back to l1..
Can someone please tell me the step by step instruction to gain l1 on unlocked bootloader ?
I got the oneplus 7 pro 1910 chinese version 128/6
Griffiths_Anna said:
I've seen people managed to have l1 certification with unlocked bootloader with the oos 11 ob 3 or newer than that even with custom rom. It seemed so simple that I've tried it myself
but then when I was in oos 11 with bootloader unlocked, the widevine was still l3.
I even went as far as installing fresh oos 10 with msm tool, unlock the bootloader and then immediately install twrp, flash oos 11 ob4/stable 11.0.0.0/stable 11.0.0.2 + dfe + magisk, turned on magisk hide but unfortunately it was still in l3, and whenever I locked the bootloader it always successfully went back to l1..
Can someone please tell me the step by step instruction to gain l1 on unlocked bootloader ?
I got the oneplus 7 pro 1910 chinese version 128/6
Click to expand...
Click to collapse
Got L1 on OOS 11 rooted
Introduction:
This is an exploit chain intended to allow one to run a custom OS/unsigned code on the Chromecast with Google TV (CCwGTV).
This uses a bootROM bug in the SoC by security researcher Frederic Basse (frederic).
Frederic also did a great amount of work to temporarily boot a custom OS from USB here.
Security researchers Jan Altensen (Stricted) and Nolen Johnson (npjohnson) took the vulnerability and provided tools and customized a u-boot image to take advantage of the provided secure-execution environment to fully bootloader unlock the device.
Disclaimer:
You are solely responsible for any potential damage(s) caused to your device by this exploit.
FAQ:
- Does unlocking the bootloader void my warranty on this device?
Probably, assume so. Or just flash stock and lock your bootloader before RMA. The exploit itself leaves no traces.
- Does unlocking the bootloader break DRM in any way?
Nope, just like unlocking a Pixel device officially.
- Can I OTA afterwards?
NO - It will re-lock your bootloader, and if you've made any modifications, brick you pretty hard. If you manage to do this, re-running the exploit won't be possible either, as a BootROM password is set on any update newer than
- Can I use stock?
Yes, but only if you flashed the newer patched factory image offered up in the script.
- Can I go back to stock after installing custom OS's?
Yeah, totally, here's a "Factory Image" I made in the style of Pixel Factory Images. The patch level of this build is 2021-08-05. The tool offers to put you on a newer firmware, it's highly recommended to do so.
- Can I re-lock the bootloader?
If you flashed the factory image above, sure, but you run the risk of not being able to unlock again.
- I've run the exploit 10 times and it isn't working yet!
Swap USB ports/cables, and keep trying, for some people it takes one attempt, for some it takes a lot of attempts.
Requirements:
Chromecast With Google TV (sabrina) without USB password mitigation¹
Either a USB A to C, or a C to C cable
A PC running some flavor of 64-bit GNU Linux
`libusb-dev` installed
`fastboot` & `mke2fs` installed from the SDK Platform tools
¹: The USB password mitigation has been enabled on units manufactured in December 2020 and after. For units manufactured before, the mitigation was enabled by software update in February 2021. To discern this, look at the MFP date on the bar-code sticker on the bottom of your device's box. If you've powered it on and OTA'd, your firmware version needs to be below the February 2021 patch level. It's not possible to disable/change the password since it's burnt into the chip (efuses).
Instructions:
Follow the detailed and up-to-date instructions over at our Github repo, and maybe give the writeup a read/share on social media!
Post-unlock:
The script asks if you want to flash LineageOS Recovery, or a Magisk patched boot image, so enjoy those!
At the moment, there are no ROMs for the device, but Android builds in the form of LineageOS are coming soon™. Builds of that will be posted in this forum once ready, and I'll link them here.
Credits:
Nolen Johnson (npjohnson): The writeup, helping debug/develop/theorize the unlock method
Jan Altensen (Stricted): The initial concept, u-boot side unlock implementation, debugging/developing the unlock method, and being a wealth of information when it comes to Amlogic devices
Frederic Basse (frederic): The initial exploit and the AES key tip
Special Thanks:
Ryan Grachek (oscardagrach): Being an awesome mentor, teaching me a fair chunk of what I know about hardware security, and being a massive wealth of knowledge about most random things.
Chris Dibona: Being an awesome advocate of OSS software and helping ensure that we got all the source-code pertinent to the device.
Pierre-Hugues Husson (phh): For pointing me down the Amlogic road to begin with by letting me know Google had decided to make the ADT-3 bootloader unlockable.
XDA users @p0werpl & @JJ2017, who both helped experiment and find a combination of images that allowed us to skip the forced OTA in SUW.
sweet! I know what im doing tonight lol.. of course I need to check mine once I get home to see if it can be unlocked but pretty sure it can.
wow im glad i left mine unplugged
unfortunately mines not able to be unlocked :-(.. its got feb security update.. exploit says its password protected
elliwigy said:
unfortunately mines not able to be unlocked :-(.. its got feb security update.. exploit says its password protected
Click to expand...
Click to collapse
rip, there is no way around it unfortunately (for now atleast)
Stricted said:
rip, there is no way around it unfortunately (for now atleast)
Click to expand...
Click to collapse
Yea, figured as much. I was looking for a way to unlock the bootloader but didnt spend much time on it as i use my nstv pro 2019 model mainly for all my streaming needs lol.
i just left best buy by my house and all the cc they had were mfg 5/2021 lol.. i mustve looked all over.. looked behind stuff tried to find a dusty one but nope lol
probably got a better chance at an old one from walmart
im curious what causes it to not boot with patched boot.img.. on the nstv it was odd for a while since patching boot.img would cause bootloop.. had noticed in the logs it was failing to boot because the verifiedbootstate was orange so made a script for magisk to resetprop ro.boot.verifiedbootstate green and it would boot right up wonder if its something similar.. either way, can only toss up ideas until i get my hands on a unlockable model lol
elliwigy said:
Yea, figured as much. I was looking for a way to unlock the bootloader but didnt spend much time on it as i use my nstv pro 2019 model mainly for all my streaming needs lol.
i just left best buy by my house and all the cc they had were mfg 5/2021 lol.. i mustve looked all over.. looked behind stuff tried to find a dusty one but nope lol
probably got a better chance at an old one from walmart
im curious what causes it to not boot with patched boot.img.. on the nstv it was odd for a while since patching boot.img would cause bootloop.. had noticed in the logs it was failing to boot because the verifiedbootstate was orange so made a script for magisk to resetprop ro.boot.verifiedbootstate green and it would boot right up wonder if its something similar.. either way, can only toss up ideas until i get my hands on a unlockable model lol
Click to expand...
Click to collapse
Nah, it isn't.
Think it's just Amlogic boot image format not linking the repack method.
I'll look into it at some point.
Could this method work on mi box 3?Just asking !!!!
Verhuel15 said:
Could this method work on mi box 3?Just asking !!!!
Click to expand...
Click to collapse
You'd need u-boot source from your OEM - start by requesting that, then you can progress further if they give it to you (they legally have to, but a lot of them don't)
Tell me more about this "usb password mitigation", since it appears that this exploit is not going to be all that useful until this issue is addressed.
96carboard said:
Tell me more about this "usb password mitigation", since it appears that this exploit is not going to be all that useful until this issue is addressed.
Click to expand...
Click to collapse
It's not an "issue" we can overcome.
The BootROM mode we interact with the send the data for this exploit had a password slapped in the interface (to even be able to interact with it). It's a complex password based on a hash of something and a salt.
It's not something we could feasibly brute force, it's not something we can undo, it's not something we can work around.
The exploit was effectively patched in models manufactured after December 2020, and older units updated to February 2021.
If the February 2021 update added the password, wouldn't it be theoretically possible to reverse engineer that update to determine how the password is generated? Or do they encrypt these updates in a way that makes them impossible to disassemble or step through during execution before it burns the eFuses?
bydo said:
If the February 2021 update added the password, wouldn't it be theoretically possible to reverse engineer that update to determine how the password is generated? Or do they encrypt these updates in a way that makes them impossible to disassemble or step through during execution before it burns the eFuses?
Click to expand...
Click to collapse
We can totally (and have) dumped newer updates. You can look at the bootloader.img all you want, but it's AES encrypted, and the only way to get it decrypted is to dump the AES key from memory using the exploit those updates mitigate, so, no, not easy to analyze them.
But lets say we could, there's no way to extract the password that's even semi-feasible.
Brute force is more feasible, and that would take years.
I assume similar to Samsung bootloader revs Google has some form of rollback prevention so not possible to downgrade to an older firmware? do you know if theres anywhere that the ota.zip can be downloaded?
Is there anything else we know about this password? Is it the same password for all units (i.e. pre-generated) or is it unique (in which case it would have to be generated on-device)?
elliwigy said:
I assume similar to Samsung bootloader revs Google has some form of rollback prevention so not possible to downgrade to an older firmware? do you know if theres anywhere that the ota.zip can be downloaded?
Click to expand...
Click to collapse
Yeah, dumped on dumps.tadiphone.dev. Rollback is enabled. There's no going back. U-boot enforces it on OS, and BL2 enforces it on BL33 (u-boot).
96carboard said:
Is there anything else we know about this password? Is it the same password for all units (i.e. pre-generated) or is it unique (in which case it would have to be generated on-device)?
Click to expand...
Click to collapse
It is (as far as we currently understand) a global password.
npjohnson said:
Yeah, dumped on dumps.tadiphone.dev. Rollback is enabled. There's no going back. U-boot enforces it on OS, and BL2 enforces it on BL33 (u-boot).
It is (as far as we currently understand) a global password.
Click to expand...
Click to collapse
Is that site a private gitlab? i went there but my normal gitlab acct didnt work so i regustered with same email and it said it registered but my acct is blocked waiting for admin approval?
96carboard said:
Is there anything else we know about this password? Is it the same password for all units (i.e. pre-generated) or is it unique (in which case it would have to be generated on-device)?
Click to expand...
Click to collapse
pretty sure its not generated on the device.. its likely a key that was already there just wasnt being used until recent update or it was implenented in the update.. this is of course assuming its a global key i.e. same password for all the devices.. sort of similar to how samsung does their firmware maybe, key burned into the device at the factory well hidden behind layers of security to never be seen again even when its used to verify stuff lol
elliwigy said:
Is that site a private gitlab? i went there but my normal gitlab acct didnt work so i regustered with same email and it said it registered but my acct is blocked waiting for admin approval?
Click to expand...
Click to collapse
dumps.tadiphone.dev/dumps
elliwigy said:
pretty sure its not generated on the device.. its likely a key that was already there just wasnt being used until recent update or it was implenented in the update.. this is of course assuming its a global key i.e. same password for all the devices.. sort of similar to how samsung does their firmware maybe, key burned into the device at the factory well hidden behind layers of security to never be seen again even when its used to verify stuff lol
Click to expand...
Click to collapse
It is burned into the device, yeah, no disabling it or intercepting it.
npjohnson said:
dumps.tadiphone.dev/dumps
It is burned into the device, yeah, no disabling it or intercepting it.
Click to expand...
Click to collapse
right after i posted i went to explore and saw the dumps. i noticed there was some userdebug builds early on.. pretty cool.. are these all official firmwares?
and yes makes sense.. its easier to fibd a zero day exploit these days then to waste time trying to get the hardware infused private keys :-/
Hi,
After almost 2 years of owning this awesome device, not even once i stumbled upon any rom or root solution for it. Now after all that time being desperate for any development on this device, I come here for an opinion, answer or any idea how to get anything written above on this device.
So, I read some things about GSI roms being able to work on any device without porting and all that. I immediately downloaded the app called Treble Check and it said P30 is supported. So it got me thinking, in THEORY if somehow i got mine P30s bootloader unlocked, or if someone unlocked it before Huawei stopped unlocking bootloader, IS IT POSSIBLE TO GET GSI ROM WORKING, AND HOW?
If it is, is there any, even shady source to get the bootloader unlocked?
Bonus question if all this isn't possible: How to get EMUI 12 Beta Project in Serbia thru Beta app? Carrier locked model. ELE-L29.
Thanks.
I actually tried it, but stopped using it due to problems such as FOD coordinates and Volte.
Also, if you install GSI, your PC will not be able to recognize your device.
The boot loader was unlocked using DC Phoenix and hcu-client.
Hi folks,
I've managed to stumble my way through using pixel flasher to update my P7Pro to the latest fw with root. Only need root so I can record calls, should I lock the bootloader now I'm done?
Also how do I update in future please without having to wipe, use pixel flasher and patch as I've just done?
I like to think I'm quite tech savvy but the guides for the P7Pro have gone over my head :/
Connorsdad said:
Hi folks,
I've managed to stumble my way through using pixel flasher to update my P7Pro to the latest fw with root. Only need root so I can record calls, should I lock the bootloader now I'm done?
Click to expand...
Click to collapse
Not unless you want to brick your device. You need to be completely stock before relocking your bootloader (unless using avbroot, but you should have a deep understanding about how it works beforehand).
Connorsdad said:
Also how do I update in future please without having to wipe, use pixel flasher and patch as I've just done?
Click to expand...
Click to collapse
Pixel Flasher will work fine for updating.
Lughnasadh said:
Not unless you want to brick your device.
Click to expand...
Click to collapse
Huh, learn something new every day I guess...
Lughnasadh said:
Not unless you want to brick your device. You need to be completely stock before relocking your bootloader (unless using avbroot, but you should have a deep understanding about how it works beforehand).
Pixel Flasher will work fine for updating.
Click to expand...
Click to collapse
Awesome, thanks a lot for your reply, much appreciated.
never ever* lock bootloader on google devices. fastboot only works on unlocked bootloader and there is no alternative to fastboot.
* exception
alecxs said:
never ever lock bootloader on google devices. fastboot only works on unlocked bootloader and there is no alternative to fastboot.
Click to expand...
Click to collapse
And you can't flash a factory image to fix a phone on your own when it's soft bricked. It might have to go to a shop for repairs.
Connorsdad said:
Hi folks,
I've managed to stumble my way through using pixel flasher to update my P7Pro to the latest fw with root. Only need root so I can record calls, should I lock the bootloader now I'm done?
Also how do I update in future please without having to wipe, use pixel flasher and patch as I've just done?
I like to think I'm quite tech savvy but the guides for the P7Pro have gone over my head :/
Click to expand...
Click to collapse
AFAIK, relocking the bootloader requires wiping the device -- much like unlocking does -- and if you're unwilling to set everything (including anything on your /sdcard internal storage, not to mention all apps and their settings & system settings) back up from scratch (as any good complete backups require root access), this might not be what you wish to do.
And, if you had managed to successfully relock the bootloader, you could simply run the in-system update (OTA) that would update without wiping -- or even manually applying OTA from the recovery.
But there are hardly any benefits in re-locking the bootloader (after unlocking it) -- even if one was to a paranoid degree of security; which is the only major reason to (I can point you to the discussions that had taken place on it here, if you wish). If you don't want to run into any issues, you could simply run the stock ROM without root and be hardly impacted by it; with the added benefit of having the option to advanced recovery options and/or rooting options open to you in the future if need be...
alecxs said:
never ever lock bootloader on google devices. fastboot only works on unlocked bootloader and there is no alternative to fastboot.
Click to expand...
Click to collapse
*it just occurs to me you meant to never lock bootloader because it limits options; not the risk of hard-bricking the device -- in which I wrote the following with that assumption. I'll leave the following comment as it is still sound advice, but I apologize in advanced that it doesn't quite relate to what you meant...
I mean, I feel doing Google's official Android Flash Tool is a safe enough method; it wouldn't do well if Google's own tool bricked their devices using their tool...at the very least the tool ensures that the stock factory firmware flashed matches the bootloader version and automates the fastboot commands so when re-locking the bootloader, it has the least potential to brick the device...
Exactly. there is no official flash tool from google, that's why I personally won't recommend to keep bootloader locked. If it's bricked with no working recovery mode, not even repair shop can fix it. all you can do is RMA to google get new device. no edl mode or anything else will help, fastboot is the official flashing method.
If you're referring to the "Android Flash Tool" that's no flash tool at all. I haven't tested it, but to me it looks like a WebUSB browser plugin. Reading the requirements it works with adb commands, usb-debugging and fully booted android is required. Therefore cannot unbrick devices.
Doesn't unlocking the bootloader break saftynet so then you have to root to use gpay?
iRhyiku said:
Doesn't unlocking the bootloader break saftynet so then you have to root to use gpay?
Click to expand...
Click to collapse
I'll just chime in here because I have recently unlocked my bootloader but I haven't been able to root it yet and I haven't had any issues with safety net.
Trippyy Doee said:
I'll just chime in here because I have recently unlocked my bootloader but I haven't been able to root it yet and I haven't had any issues with safety net.
Click to expand...
Click to collapse
Interesting, I thought unlocking would break it. I'll have to unlock then for the extra safty!
iRhyiku said:
Interesting, I thought unlocking would break it. I'll have to unlock then for the extra safty!
Click to expand...
Click to collapse
That's of course another aspect. Good point. If you rely on SafetyNet or it's successor Play integrity, do not unlock bootloader. AFAIR the latter one can't be cheated.
simplepinoi177 said:
But there are hardly any benefits in re-locking the bootloader (after unlocking it)
Click to expand...
Click to collapse
There are some benefits like some banking apps, streaming apps and games beginning to work. So it really depends on what is important for the user. I don't like flashing random mods to make apps work on rooted/ bootloader unlocked devices, primarily banking apps.