Develop Bugs

[DEV][WIP]Bootloader unlock development[no unlock yet]

***This is not a bootloader unlock. This is only a discussion about a possible bootloader unlock***
So I've been following this blog for the past couple of weeks. The owner of the blog describes an exploit to run arbitrary code in trustzone kernel in msm8974 chipsets (post1, post2, post3).
Trustzone is responsible for stuff like android keystore, decoding audio and video with DRM and has absolute control over every bit of hardware inside the chipset.
Most importantly the Qfuses checked by the bootloader to determine if it's unlocked or not.
Now, I've been looking at the deassemblies of trustzone images extracted from firmware versions 4.3.6, 3.5 AT&T, 3.6.2T-MobileDE.
The bug caused this exploit is in fact fixed in firmware 4.6.3. I didn't test 4.6.1 because probably it is fixed.
Anyway, In firmware versions 3.5 and 3.6.2 the bug is still present. Meaning that we would probably be able to run arbitrary code on the devices with old firmware, or if we can downgrade our phones to 3.6.2 firmware.
The first problem we have is, the exploit needs a slight kernel driver modification to run. (that is if we are not going to use his "zero write primitive" to blow a Qfuse).
But in our devices we can't even boot a custom kernel! (fastboot kernel hotbooting complain even if you pass a signed boot image, saying "boot not allowed in locked HW").
So we might need to find a way to use "kexec" to hotswap a kernel at runtime. Which in turn might need a modified kernel module to be loaded.
We still don't know if we can load unsigned kernel modules to the stock kernel.
The next problem is to find the correct Qfuse to blow, If we blow a wrong one, We can say our device goodbye.
This would need an analysis of aboot partition image (emmc_appsboot.mbn) to find which Qfuse aboot check for bootloader unlocked. (take a look here to know more about this)
So a very simple outline of what we have to do is,
1)Find a way to downgrade to firmware/trustzone 3.6.2
2)Get kexec to run a custom kernel
3)Run the trustzone exploit to blow the correct Qfuse
Now, I'm not very good at reverse engineering stuff since I'm still a newbie, I need help from everyone.
Reply if you have any ideas and contributions. any kind of feedback is appreciated.

Hello @madushan1000,
Here seemed an appropriate place to reply to your PM
Some points to consider:
- Safestrap doesn't use kexec, it uses 2nd init which hijacks the boot process to load a different ramdisk
- Therefore you won't be able to use anything from Safestrap including 2nd init to enable loading a new kernel
- Also note kexec is not enabled on stock kernel builds so at least the exec part is out the window.
- I checked the aboot of 3.5.x and 4.6.1 and noted that the exploit used on the Kindle HDX tabs to bypass/unlock the bootloader have been patched up.
- Other than that: It seems the bootloader is going to remain locked on our devices - Though I hope I am wrong.

More info on the trustzoon exploit can be found in the posts I linked above.
Anyway, I don't think we can use HDX bugs even if the aboot bug was present because there is no unlock partition found on the device and flashing to any kind of partition is absolutely prohibited.
We are going to do what described in this post (http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html) using the trustzoon exploit.
As per kexec, there is a kexec kernel module developed at Xperia forums, I can try to port it to fire phone. Probably wouldn't be too hard because it was built for msms8974 kernel too.
Anyway, Does anyone had gone back to 3.6.2 from 4.6.1 without bricking the device?
Wow, I just found out you can't load unsigned kernel modules too.

madushan1000 said:
***This is not a bootloader unlock. This is only a discussion about a possible bootloader unlock***
So I've been following this blog for the past couple of weeks. The owner of the blog describes an exploit to run arbitrary code in trustzone kernel in msm8974 chipsets (post1, post2, post3).
Trustzone is responsible for stuff like android keystore, decoding audio and video with DRM and has absolute control over every bit of hardware inside the chipset.
Most importantly the Qfuses checked by the bootloader to determine if it's unlocked or not.
Now, I've been looking at the deassemblies of trustzone images extracted from firmware versions 4.3.6, 3.5 AT&T, 3.6.2T-MobileDE.
The bug caused this exploit is in fact fixed in firmware 4.6.3. I didn't test 4.6.1 because probably it is fixed.
Anyway, In firmware versions 3.5 and 3.6.2 the bug is still present. Meaning that we would probably be able to run arbitrary code on the devices with old firmware, or if we can downgrade our phones to 3.6.2 firmware.
The first problem we have is, the exploit needs a slight kernel driver modification to run. (that is if we are not going to use his "zero write primitive" to blow a Qfuse).
But in our devices we can't even boot a custom kernel! (fastboot kernel hotbooting complain even if you pass a signed boot image, saying "boot not allowed in locked HW").
So we might need to find a way to use "kexec" to hotswap a kernel at runtime. Which in turn might need a modified kernel module to be loaded.
We still don't know if we can load unsigned kernel modules to the stock kernel.
The next problem is to find the correct Qfuse to blow, If we blow a wrong one, We can say our device goodbye.
This would need an analysis of aboot partition image (emmc_appsboot.mbn) to find which Qfuse aboot check for bootloader unlocked. (take a look here to know more about this)
So a very simple outline of what we have to do is,
1)Find a way to downgrade to firmware/trustzone 3.6.2
2)Get kexec to run a custom kernel
3)Run the trustzone exploit to blow the correct Qfuse
Now, I'm not very good at reverse engineering stuff since I'm still a newbie, I need help from everyone.
Reply if you have any ideas and contributions. any kind of feedback is appreciated.
Click to expand...
Click to collapse
How do you know there's a bit in the QFPROM dedicated to unlocking the bootloader? Doesn't that seem kind of like an oversight since there's one you blow to lock it in the first place? Blowing a random fuse will just brick your phone and I'll tell you right now there's no bit to unlock it. The bug has been patched for quite a while and even if it did work, I'm doubtful you'd find what you're looking for.

Well, I don't know. That's why this is still work in progress. But still, As pointed out in the original post, the is one qfuse which is blown after first factory flash to mark the device as bootloader locked. Then there is another one (which is not blown in almost all the msm chipsets in case vendor change their mind and offer a unlock in the future) which mark the device as permanently unlockable. Even if this fuse is blown, by gaining arbitrary code execution in trustzoon we might be able to trick the bootloader in to thinking device is unlocked.
Don't worry, I'm not going to start blowing qfuses up blindly. First I'm going to identify if there is such a qfuse at all by looking at the aboot drassembly. Then try reading their values first to verify it is in fact not blown. Then I'm going to blow stuff up when I can afford a new phone
Even before that, I have to find a way to downgrade trustzoon and find a way to load unsigned kernel modules. I have no illusions, I'm very very far away from unlocking this thing.
And which bug you are referring to? The new trustzoon bug I mentioned or the previous trustzoon bug?

kaboom away
madushan1000 said:
Don't worry, I'm not going to start blowing qfuses up blindly. First I'm going to identify if there is such a qfuse at all by looking at the aboot drassembly. Then try reading their values first to verify it is in fact not blown. Then I'm going to blow stuff up when I can afford a new phone
Click to expand...
Click to collapse
With the current fire sale on these phones, you can probably afford to blow up as many as you want. I cannot believe the prices on these babies right now, that is, if you are into Prime, or don't mind reselling the Prime. I am almost ready to buy a third one.

LNRrgB said:
With the current fire sale on these phones, you can probably afford to blow up as many as you want. I cannot believe the prices on these babies right now, that is, if you are into Prime, or don't mind reselling the Prime. I am almost ready to buy a third one.
Click to expand...
Click to collapse
The sad thing is, Amazon prime is not available, let alone fire sales I would definitely love to get my hands on few more.

madushan1000 said:
The sad thing is, Amazon prime is not available, let alone fire sales I would definitely love to get my hands on few more.
Click to expand...
Click to collapse
it's $124.99 in ebay, brand new, prime and warranty.

Yup, ebay has the 32GB and the 64GB for sale right now, with Prime ! Seller is qualitycellz .

litan1106 said:
it's $124.99 in ebay, brand new, prime and warranty.
Click to expand...
Click to collapse
Now $119
Perhaps, after all stock containing Prime is depleted, we will get a bootloader unlock...

Wow, If I only had the money. Wish the stock will hold untill I graduate next month and get a job.

Help - Bricked HTC m9 - Not rooted - Advice needed -

Hi,
My wife HTC m9(UK, Vodaphone, latest stock ROM, No root) was turned off last night to charge.
When booted up it does the below. It does not load into the OS. Every boot loops into the below.
https://drive.google.com/file/d/0B8n21CQX7535cjF4MnZqV2E1dGM/view?usp=sharing
It says the software has been modified?
My wife was very insistent that I never root or change ROMS on her phone.
Does anyone have a fix or is this send off for replacement?
Any advice would be greatly appreciated.
Thanks
Ca1v

ca1v said:
Hi,
My wife HTC m9(UK, Vodaphone, latest stock ROM, No root) was turned off last night to charge.
When booted up it does the below. It does not load into the OS. Every boot loops into the below.
https://drive.google.com/file/d/0B8n21CQX7535cjF4MnZqV2E1dGM/view?usp=sharing
It says the software has been modified?
My wife was very insistent that I never root or change ROMS on her phone.
Does anyone have a fix or is this send off for replacement?
Any advice would be greatly appreciated.
Thanks
Ca1v
Click to expand...
Click to collapse
What happens if you try to boot to Download Mode? I guess you see the black screen that is mentioned in Q7, right? If that's the case there isn't much you can do...

Download mode seems to be working (https://drive.google.com/file/d/0B8n21CQX7535cEFhTlpnajF5anM/view?usp=sharing)
If this is the case, can you point me in the right direction to get resolved?
Many thanks for the help

Flippy498 said:
What happens if you try to boot to Download Mode? I guess you see the black screen that is mentioned in Q7, right? If that's the case there isn't much you can do...
Click to expand...
Click to collapse
Download mode seems to be working (https://drive.google.com/file/d/0B8n...ew?usp=sharing)
If this is the case, can you point me in the right direction to get resolved?
Many thanks for the help

Interesting. Your video in post 1 shows a security warning. That means that the OS got deleted. This is only possible if you unlock the bootloader and delete it manually via TWRP or if the EMMC gets broken. Since the phone's S-ON and its bootloader is locked and not unlocked or relocked I assumed that the latter happened*.
As long as the download mode is working you can restore the system with the help of a RUU. Instructions can be found in the thread I linked in my last post. Be aware that all data on the phone is going to get erased.
* Well, it is possible to get the phone's status back to S-ON and locked with S-OFF but you said you never tinkered with that phone...

Flippy498 said:
Interesting. Your video in post 1 shows a security warning. That means that the OS got deleted. This is only possible if you unlock the bootloader and delete it manually via TWRP or if the EMMC gets broken. Since the phone's S-ON and its bootloader is locked and not unlocked or relocked I assumed that the latter happened*.
As long as the download mode is working you can restore the system with the help of a RUU. Instructions can be found in the thread I linked in my last post. Be aware that all data on the phone is going to get erased.
* Well, it is possible to get the phone's status back to S-ON and locked with S-OFF but you said you never tinkered with that phone...
Click to expand...
Click to collapse
Just thought I'd bring to your attention that apps are now being written that will try to obtain root without you knowing. The reason is that they can steal any information they want and sell it to corporations for as little as 4 pence/6c a record.
It is possible that it is a failed root by an app.
"I'm safe, I only download my apps from google playstore" - nope, you're not.
"I only use signed apps and the checksum is always correct" - nope, checksum can be matched with padding.
"I only use external sources to update genuine apps" - nope, see the Google playstore comment above.
"I have all my security and privacy set to super strict, I have my apps verified by google" - nope, still not secure because alerts are only written when the malicious/bad code is found.
Be warned, my fellow xda'ers. There is a whole new breed of security breach and it is terminal to root as a whole. Apps like kingoroot etc are issuing the wrong type of people with the wrong type of information and they are using it for the wrong purposes.
Google will stuggle to put a lid on these types of apps because they attack the hardware for access to software (a simple memory buffer overflow attack), inject a few lines of code and you're in, permanently. It will eventually result in a total lockdown at the manufacturer and bye bye root access, roms, mods etc, you'll get what you're given.
How do we prevent this?. We don't and we can't. We just have to sit back and watch as the world takes our privacy while bricking our devices one by one just to "try" to earn a poxy 4p.
Beamed in by telepathy.

@shivadow: I'm actually not sure what you're trying to achieve with your post. Malicious apps that can root your device without letting the user know about that exist since several years now. (Click here for a random example from 2011) Smartphones aren't completely safe and they never were. Everyone who's claiming the opposite either doesn't know what he/she is talking about or is simply lying.
To name just a few more android security flaws/exploits that emerged in the past: rageagainstthecage, gingerbreak, heartbleed, stagefright, the master key vulnerability, the futex bug, rootnik...
All of these have more or less been used for manipulating android phones. There is no absolute security. Android is still as secure/insecure as it's always been.
In addition, several OEMs are already trying to prevent their customers from rooting their phones since several years. Samsung's KNOX is a perfect example. (I don't want to discuss whether they're successful. That's a whole different topic.)
But let's get back to the deleted OS of the OP's phone: I've never heard about failed root attempts that erase a complete system partition. Therefore, I highly doubt that a malicious app caused all the trouble. Failed root attempts may cause a bootloop but they don't wipe your phone. Just think about the following: How should the dev of such app gain money if the app deletes OSes? Without OS there is no information you can steel and if you have no information you could sell/abuse/whatsoever you don't gain any money. Oh and not to forget that most apps on the play store already collect more than enough data from your phone they can sell afterwards without having to root it.

I meant failed root could be the cause, if the op didn't then who did?. If no-one modded it then dead nand is the only player..
I agree with every thing else but I don't trust those apps that try to gain root in the background to steal data and I think it's too easy for them to bugger your phone just for the sake of making a few coins. Face it, if I was doing it, once I had what I wanted I wouldn't care about the device. Sod the gracious exit and all that jazz.. No evidence, no conviction.
Maybe I'm being ott but my questions and points are still valid.
This is a proper "who dunnit" because I doubt it died of its own accord.
Knox is for businesses btw. If knox is triggered, which is very easy to do, the business is advised not to buy the device as it "may" have been compromised. But if no company secrets are being held on the device then it's still good to use. Knox protection was counteracted by supersu. In a nutshell, unless you run a company knox is of no concern to the everyday user.
Just thought I'd chuck that in there, I'm versed in the arts of the s3 i9300. I moved from that phone to this m9.
Beamed in by telepathy.

Bootloaders (aboot/sdi/rpm/hyp/pmic/cmnlib/etc) Interchangeability

Hi, I understand that the G-2PW2100s all share identical hardwares, but are the bootloader partitions interchangeable between the Verizon ones & non-Verizon ones? (<- This is question #1) i.e. Can I for example use NJH47F factory image instead of NHG47Q (Verizon) from https://developers.google.com/android/images#marlin on a Verizon marlin assuming the bootloader is unlocked? Or if the stock rom is already rooted and I can overwrite the bootloader partitions via dd? Or perhaps fastboot boot twrp and then dd the bootloader partitions?
If so, can one say there are then no differences between these G-2PW2100 variants? (<- This is question #2)
Update 1: Since everyone focuses on the unlockability and ignores what's asked above, let me state that I know there's currently no way to unlock the bootloader or root the Verizon Pixel, and the purpose of this thread is to collect information in order to help those stuck with a locked bootloader on Verizon Pixels. If you have such information, feel free to share; repeating "you can't unlock/root" is not helpful. I do not own a Verizon Pixel, and I have absolutely nothing to gain from this; I merely want to give back to the community.
Rooting gives one access to read/write the partitions on the eMMC, therefore gives the ability to overwrite the bootloader partitions, which allows unlocking the bootloader.
Unlocking the bootloader also grants read/write access to the partitions on the eMMC, therefore allowing one to overwrite the partitions on the eMMC.
Sneaking an OTA pre-rooted image may or may not be possible, so is finding another way to gain access such as disabling signature check.
The point is, it comes down to the ability to write the partitions on eMMC; once it's writable, you own everything that's on the eMMC. Most people tend to think it's only about the ability to root/unlock, which isn't exactly false, but it's not exactly true either.
Update 2: According to aboot.c, the last byte of the eMMC controls whether a device can be unlocked or not (assuming the compiled aboot in your device uses this logic) For future reference, code is attached.

I don't think you can fastboot boot twrp img with lock bootloader.
Sent from my SM-G950U using Tapatalk

Nochis said:
I don't think you can fastboot boot twrp img with lock bootloader.
Sent from my SM-G950U using Tapatalk
Click to expand...
Click to collapse
Right, but if there's a way to flash or write to the partitions, it should be able to convert a Verizon Pixel to a non-Verizon Pixel. That's what I'm trying to confirm.

AncientDeveloper said:
Right, but if there's a way to flash or write to the partitions, it should be able to convert a Verizon Pixel to a non-Verizon Pixel. That's what I'm trying to confirm.
Click to expand...
Click to collapse
You can't overwrite a locked bootloader...that is the very definition of a locked bootloader. Yes, you need root. Root either temporary or permanent is what is needed to unlock the VZ phones. This has been covered a million times here.

TonikJDK said:
You can't overwrite a locked bootloader...that is the very definition of a locked bootloader. Yes, you need root. Root either temporary or permanent is what is needed to unlock the VZ phones. This has been covered a million times here.
Click to expand...
Click to collapse
The question asked in the post was that if this was doable, then there should be no differences between the 2 variants? I have not asked if unlocking the bootloader is possible at the moment.

Go ahead, brick it. You can't. Same hardware doesn't mean same software, there's still a difference.

martinez5241 said:
Go ahead, brick it. You can't. Same hardware doesn't mean same software, there's still a difference.
Click to expand...
Click to collapse
The Verizon image is obviously different than the non-Verizon one. That's a proven as the checksums are different. The question asked was that by loading the non-Verizon image into a Verizon Pixel, does it effectively make the phone non-Verizon since the hardware is the same?

Lets clear up some misconceptions here.
The phones ship with exactly the same image. It is not until you put in a VZ SIM do you get the different image. And it is only changes to radio and some network settings. Don't matter where you bought it, and it has nothing to do with locking.
Verizon does not lock the phone. They all ship locked including Googles. When you start it up it phones home to Google and Google decides if the phone qualifies to be unlocked. If so it unlocks. Verified with packet captures.
You will not unlock this phone without root. You will not flash anything other than OTA's without root.

If Rooted
yes on the first
NO on the second

TonikJDK said:
Lets clear up some misconceptions here.
The phones ship with exactly the same image. It is not until you put in a VZ SIM do you get the different image. And it is only changes to radio and some network settings. Don't matter where you bought it, and it has nothing to do with locking.
Verizon does not lock the phone. They all ship locked including Googles. When you start it up it phones home to Google and Google decides if the phone qualifies to be unlocked. If so it unlocks. Verified with packet captures.
You will not unlock this phone without root. You will not flash anything other than OTA's without root.
Click to expand...
Click to collapse
chazall1 said:
If Rooted
yes on the first
NO on the second
Click to expand...
Click to collapse
Since we're on the "unlockability" subject, we know that once it normal boots with a Verizon SIM, it becomes not unlockable; but does anyone know if it's because the phone contacts Verizon/Google & received "you can't unlock" command, or the baked-in factory image is pre-programmed to do this once the phone boots with a Verizon SIM?
Technically, one would just need to gain access to write to the eMMC; rooting is one way to gain such access.

AncientDeveloper said:
Since we're on the "unlockability" subject, we know that once it normal boots with a Verizon SIM, it becomes not unlockable; but does anyone know if it's because the phone contacts Verizon/Google & received "you can't unlock" command, or the baked-in factory image is pre-programmed to do this once the phone boots with a Verizon SIM?
Technically, one would just need to gain access to write to the eMMC; rooting is one way to gain such access.
Click to expand...
Click to collapse
It has nothing to do with the sim. This has been covered a million times. Some think it's the cid. Others think it's the IMEI. Either way it's nothing you can get around without temp root.

toknitup420 said:
It has nothing to do with the sim. This has been covered a million times. Some think it's the cid. Others think it's the IMEI. Either way it's nothing you can get around without temp root.
Click to expand...
Click to collapse
I don't have a Verizon Pixel to verify what you're saying, but according to this post, what you said is not true. Either way, I'm just trying to study the specifics and help the community, and I have nothing to gain or lose by either helping or not helping the community.
As mentioned, "rooting" is one way to gain access to write the system onto eMMC, unlocking bootloader is another; there may or may not be other methods. Saying one cannot get around without temp root is quite an absolute statement. And yes, I have also read most of the "million" threads.

AncientDeveloper said:
I don't have a Verizon Pixel to verify what you're saying, but according to this post, what you said is not true. Either way, I'm just trying to study the specifics and help the community, and I have nothing to gain or lose by either helping or not helping the community.
As mentioned, "rooting" is one way to gain access to write the system onto eMMC, unlocking bootloader is another; there may or may not be other methods. Saying one cannot get around without temp root is quite an absolute statement. And yes, I have also read most of the "million" threads.
Click to expand...
Click to collapse
Okay let me definitively explain this.
VZW Pixel's run the EXACT same software Google Store Pixel's that insert a VZW SIM get. The factory image you run doesn't affect your unlock ability at all.
A Google Store Pixel will update to the VZW build if a VZW SIM is inserted.
DISCLAIMER: From here down is conjecture based on my findings, reverse engineering, and things said/found around the forums.
/** begin my thoughts **/
A few things affect unlock ability (this isn't a catch all list, just from my findings):
1. Is the device SIM locked? - if yes, return grey out "Allow OEM Unlock" switch, if no, continue.
2. Is the device IMEI/MEID on approved by Google to be unlocked? - if this is met, allow "Allow OEM Unlock" to be checked, if not, continue checks.
3. Is the CID a non-unlockable CID (CID = Carried ID ex. VZW___001 on VZW sold Pixels) - if this is met (meaning that the CID is on a specific list of CID's like VZW's for example), grey out "Allow OEM Unlock", if not, allow "Allow OEM Unlock" to be checked.
If when the device connects to Google's servers it passes the above checks, the switch can be toggled.
If the switch can be toggled, you can unlock your device.
Hence why random VZW Pixels are unlockable for no apparent reason, their IMEI isn't VZW's or it doesn't have the VZW MEID (which comically is "vzwmeid"), then the CID being one of a locked device doesn't matter, because that check is never reached.
/** end my thoughts, back to cold hard facts **/
Though I may not be certain of the exact order/magnitude of the checks, the same basic principle applies, its a list of if/then statements. "Flashing an unlocked bootloader" doesn't even make sense in the context of 99% of devices. If you were on a VZW Pixel, and magically were able to flash a non-VZW generic factory image, bootloader set and all, you'd still be unable to unlock all the same.
Now, what else do we know? The device's switch can be toggled if /data/system/users/ 0.xml reports <restrictions> as "false".
This file cannot be edited without root, which many will say "...requires an unlocked bootloader...", but that isn't right.
Currently there are 3 main methods to root access:
- /system/ root - in which the SU binary is put in /system/, as /system/ already has the set-suid capability (which allows SU to actually work), this used to be the go to way, but as of DM-Verity's unveiling in Android 6.0 Marshmallow, we can't remount the system partition read/write, as the verity contexts would be changed, and the device would refuse to boot (and I haven't seen any public DM-Verity bypasses/vulnerabilities). An example of this is SuperSU installed in "System Mode". This can't be used on Locked Bootloader devices (running higher than Android 6.0 Marshmallow), because DM-Verity is enforced in the kernel (which is signature checked).
- Boot Image Root - in which the SU binary is put in the ramdisk, which has the set-suid capability (which allows SU to actually work), this was ChainFire (and later everyone else's) method to root Android 6.0 Marshmallow and beyond while respecting DM-Verity, with this method, we still can't remount the system partition read/write, as the verity contexts would be changed, and the device would refuse to boot (and I haven't seen any public DM-Verity bypasses/vulnerabilities). An example of this is SuperSU installed in "System-less Mode", or any Magisk installation. This can't be used on Locked Bootloader devices because the ramdisk is signature checked.
- Temporary Root - in which the SU binary is either put in /system/ in memory (like we saw with the DirtyCow vulnerability/exploits), or in the /data/ partition (this won't work unless we use some method to give /data/ the set-suid capability). To explain a little more, you've likely seen devices with Locked Bootloaders and /system/ write protection making use of these temp-root setups, like carrier editions of the Samsung Galaxy Note 4/5 with locked bootloaders, and of HTC phones that are S-ON/Bootloader locked. On these devices the exploit needs to be re-run after each boot (hence the "temp" part of temp-root).
The Pixel's can't be rooted with the top two methods due to the combination of DM-Verity and the bootloader being Locked. Though, temp-root can work.
All dePixel8 did was temp-root the Pixel's, remove the restrictions in that file (no proof of this one, though I believe it did), and manually set the "unlockable" bit that the "Allow OEM Unlock" sets when flipped on.
Hence why JCase (one of its creators) said "If anyone hands us a temp-root, we will release another unlock for the Pixel's.". It is literally as simple as plugging in the new temp-root exploit.
Now, the problem with finding a temp-root solution for the Pixel's is that they are one of the most secure and updated devices on the market, often getting Android's monthly security patches before any other device. What I would do it I were serious about it (and let me tell you, I am not), is surf the Android security bulletins and CVE boards for "Privilege Escalation" vulnerabilities that have public PoC's or exploits, and then either further reverse dePixel8 to figure out what bit they set, or just ask JCase, because if you can prove you have temp-root working, I'd bet he'd be friendly enough to talk it through with you. Now granted, that train of thought will only result in an unlock for a previous month's security patch level, but it is better than nothing.
As I noted above, I am not putting this here to express interest in me working on this (for those that might recognize me from my S4 research, or other security ventures), but have seen so much misinformation on these forums, and so much general misunderstanding that I felt it would be helpful to throw this out publically.
Tl;DR: Please link the confused to this post.

npjohnson said:
Tl;DR: Please link the confused to this post.
Click to expand...
Click to collapse
Thank you for your time and effort. I did not want to explain all that. I was attempting to collect information, but instead ended up explaining myself and replying replies that weren't related to the questions I asked.
Anyway, here's a minor update: According to the aboot.c code (and assuming the logic is not modified), the last byte of the eMMC controls whether the device is unlockable. Having root would be nice as it allows the user to write anything onto the eMMC, which makes this rather easy if it's a matter of overwriting one byte.

AncientDeveloper said:
Thank you for your time and effort. I did not want to explain all that. I was attempting to collect information, but instead ended up explaining myself and replying replies that weren't related to the questions I asked.
Anyway, here's a minor update: According to the aboot.c code (and assuming the logic is not modified), the last byte of the eMMC controls whether the device is unlockable. Having root would be nice as it allows the user to write anything onto the eMMC, which makes this rather easy if it's a matter of overwriting one byte.
Click to expand...
Click to collapse
Which aboot.c are you analyzing?
1. Google uses its own lock/unlock mechanism, much alike many other OEM's.
2. msm8996 uses non-standard LK, so it the public LK logic isn't necessarily what we use.

npjohnson said:
Which aboot.c are you analyzing?
1. Google uses its own lock/unlock mechanism, much alike many other OEM's.
2. msm8996 uses non-standard LK, so it the public LK logic isn't necessarily what we use.
Click to expand...
Click to collapse
Yes, in fact, the public aboot.c requires OEM implementation in order for it to work as some functions are merely defined as interfaces where OEM has to implement the actual code.
Perhaps I should've been more clear on "assuming the logic is not modified". What I meant was, if the OEM did not change the specific position of the unlock byte, this is where it'd be. Of course, there's no way to verify this without (1) obtaining the OEM aboot.c or (2) experimenting it on a device. One of the OnePlus for example, stores it at position 0x000FFE10.
This particular aboot.c is listed under quic/la from codeaurora under a late enough branch, where marlin is under.
Hope this clears things up a bit.

AncientDeveloper said:
Yes, in fact, the public aboot.c requires OEM implementation in order for it to work as some functions are merely defined as interfaces where OEM has to implement the actual code.
Perhaps I should've been more clear on "assuming the logic is not modified". What I meant was, if the OEM did not change the specific position of the unlock byte, this is where it'd be. Of course, there's no way to verify this without (1) obtaining the OEM aboot.c or (2) experimenting it on a device. One of the OnePlus for example, stores it at position 0x000FFE10.
This particular aboot.c is listed under quic/la from codeaurora under a late enough branch, where marlin is under.
Hope this clears things up a bit.
Click to expand...
Click to collapse
If you need some one to test this theory out for ya, I've got a VZW Pixel xl. I've also got a Nexus 6p I can fall back on if we "F UP" my Pixel. Plus I've brought back a lot of phones from brick. Even the Bootloader locked LG Flex. And those Flex owners thought it couldn't be done.

mattwheat said:
If you need some one to test this theory out for ya, I've got a VZW Pixel xl. I've also got a Nexus 6p I can fall back on if we "F UP" my Pixel. Plus I've brought back a lot of phones from brick. Even the Bootloader locked LG Flex. And those Flex owners thought it couldn't be done.
Click to expand...
Click to collapse
That's very brave of you. I've been exploring the possibility of using EDL (QDLoader 9008) mode to overwrite the whole eMMC with an already-unlocked image. Pixel is in an unique position to try this as all US versions share the same hardware (except marlin vs sailfish), so there shouldn't be a reason why they can't run the same image.

Shameless bump.

Recover from hard brick with locked bootloader - Fairy tale?

Hello guys!
After much research on the internet about unbrick for Moto Z2 Force, after many forums, tutorials, tools, blankflash, etc., I've came to the conclusion: I've not found anyone who has managed to recover a Moto Z2 Force from a hardbrick with a locked bootloader.
Many are hopeful that it is possible to do so, but I believe it is no more than a fairy tale.
If you succeeded, please help others to get it too.

andrecesarvieira said:
Hello guys!
After much research on the internet about unbrick for Moto Z2 Force, after many forums, tutorials, tools, blankflash, etc., I've came to the conclusion: I've not found anyone who has managed to recover a Moto Z2 Force from a hardbrick with a locked bootloader.
Many are hopeful that it is possible to do so, but I believe it is no more than a fairy tale.
If you succeeded, please help others to get it too.
Click to expand...
Click to collapse
My second Z2 kept bricking and locking itself. My only saving Grace was I was able to unlock it since I had the unlock code still and since it wouldn't boot, it would accept the unlock code. It is a slot ab issue where if your phone never took an OTA (I flash all to Oreo and tried flashing DU and AOSP before taking an OTA to open slot B). This caused the phone to lock itself and go a little nuts. But it was unlocked then locked due to slot issues, so it shouldn't count. Maybe my story is a fairy tale ... No... I remember spending the hour trying to figure out why this thing wouldn't install an AOSP rom but my other would just fine, then facepalm when I figured I just needed to take an OTA.

This person had a locked bootloader and we were able to sort through and get it back to good. Maybe yours is a little worse off, idk, but the gist should be the same. I'm not sure what you've tried. whether you can load os, etc. Here is a link to the thread where we finally got it sorted, it's a little hit and miss, but maybe it'll get you going in the right direction.
https://forum.xda-developers.com/z2-force/help/help-help-help-deep-cable-flash-cable-t3925742

41rw4lk said:
This person had a locked bootloader and we were able to sort through and get it back to good. Maybe yours is a little worse off, idk, but the gist should be the same. I'm not sure what you've tried. whether you can load os, etc. Here is a link to the thread where we finally got it sorted, it's a little hit and miss, but maybe it'll get you going in the right direction.
https://forum.xda-developers.com/z2-force/help/help-help-help-deep-cable-flash-cable-t3925742
Click to expand...
Click to collapse
Alas this person had a different problem from me. It sounds like they had something of a pseudo-lock that just needed a nudge to get the kernel to recognize the OEM unlock had been authorized.
The above thread may prove useful to people who have had issues with locked bootloader but who have access to the system.
I do not have access to the system. fastboot oem blankflash command is "restricted" for me. Yet it still classifies both slots as bootable, it just refuses to boot them, which is not enough to trigger any emergency download apparently. It seems this person never succeeded in doing that, because they found an easier way.
I'm really trying to figure out if buying a cable would be worth it, but I have doubts. I was able to access my usb hub and manually short the pin using a voltmeter and some wire to find which traces were connected -- exactly mimicking the action of most "deepflash" cables.
No dice.
That, and I read that the MSM8998 doesn't use the same programmer as other qualcomm androids, possibly uses an older one, and I haven't found any reference to which one. I think blankflash should be possible on these phones, but triggering edl seems impossible from my position, since I have no adb but I do have a basically useless bootloader, which aggressively overrides edl. :angel:
Basically the way I see this, my bootloader thinks its serving a purpose: fending off modified system files, which I unwittingly made its only function when I locked it. It is forbidden from handing over the power of my z force to a patched OS. Since the bootloader exists, and is technically able to boot, it's just not allowed, edl will never be activated because it utterly defeats android security. edl is the backdoor that opens when everything else is completely gone or unintelligible. Is that accurate? :cyclops:
I am beginning to accept that my phone was not meant to be rooted really in the sense that, yes, its Linux and you can, but it's basically been booby trapped by Lenovo and if you fall for the logic I did at first, and try relocking it at the first sign of strange behavior, you have to buy a new phone. Exactly what they want.

Sony bootloader exploits and/or bypass

Hi
I'm new to the forum but have been doing a fair amount of research. I am stuck now though and would like a bit of help.
My situation is that I have a Xperia XA1 ultra (I know I should post in that device specific forum but not much seems to be happening there) I have a very specific problem that I have treated like a forensics problem.
The phone is locked by a pattern which has been guessed by another person so many times that the gatekeeper only allows one entry per day provided the phone is charged otherwise the timer resets.
It has not been rooted and ADB is disabled.
I have connected to it through fastboot and what I can gather is that it is running Android Oreo.
The system details are as follows:
Product: XA1 Ultra G3221
Build Number: 48.1.A.0.129
Chipset: Mediatek MT6757 Helio P20
Bootloader: Locked
My research has led me to the possibility of loading a recovery image into the RAM of the phone and accessing ADB that way. I tried this with a TWRP image but obviously it didn't work. There is a company called Cellebrite that claims to be able to load it's own boot/recovery image into the bootloader and gain entry that way, however the license is something like £10,000. I'm definitely not a commercial customer.
The final option for me would be to dump the memory via JTAG or chipoff, the contents would be encrypted but I found a blog where somebody had managed to find the location of the gesture.key file while the system was encrypted. I can't remember what the site was called though, it took me ages to find last time.
My main questions are does Sony sign the boot image with it's own keys or does it use the standard Android Verified Boot?
Does Sony reuse the same keys for signing across devices? Likely not but maybe
Is there a way to send specific instructions to the RAM via fastboot?
Does anybody know of an exploit that could be used?
Is there a way to extract the boot.img and recover the Sony keys?
If there any other docs, resources or ways to get the data that could help, I will gladly read and/or try them. I think this forum is probably the biggest resource one though but after a while the specific information needed gets harder to find.
The main thing is that I don't unlock the bootloader and flash anything. It's all got to be live and non data damaging.
I tried MTPwn on the off chance that it would work but nope, it was a no go.
If there was a way to utilise the mediatek exploit to gain entry from fastboot that would be excellent, or to use fastboot to dump the memory.
Thanks for reading, I hope someone can help.

Your thread was quite confusing at first as I wasn't sure what to look for exactly :/
That being said, you have your phone locked and you want to unlock it. However you don't want to flash or reset your device, you don't have root permission, you don't have debugger mode on and you don't want to unlock the bootloader, correct?
Basically you're asking for the impossible...
All I can think of is FROST attack. See article for details and source code.
You can also send your device to your nearest Sony service center and they can probably fix it with no memory loss.
Other than that, you MUST hard reset your phone if you want it back.
However should you come to your mind and realize the reality of the situation where you shouldn't be picky about it then you can start with flashing custom recovery. Or using third-party programs like dr.fone.

XDHx86 said:
Your thread was quite confusing at first as I wasn't sure what to look for exactly :/
That being said, you have your phone locked and you want to unlock it. However you don't want to flash or reset your device, you don't have root permission, you don't have debugger mode on and you don't want to unlock the bootloader, correct?
Basically you're asking for the impossible...
All I can think of is FROST attack. See article for details and source code.
You can also send your device to your nearest Sony service center and they can probably fix it with no memory loss.
Other than that, you MUST hard reset your phone if you want it back.
However should you come to your mind and realize the reality of the situation where you shouldn't be picky about it then you can start with flashing custom recovery. Or using third-party programs like dr.fone.
Click to expand...
Click to collapse
Thanks for getting back to me, yes I realise it is asking for the impossible. I'll have a research around that article and see if I can find some information on how to write the program to dump the contents over USB. I tried Dr Fone but that only gave me the option of a hard reset.
My current line of attack is an exploit over USB called OATmeal, whereby a Raspberry Pi is used over OTG with a filesystem label of "../../data", it allows the filesystem of the phone to be mounted and data written off. It is a little complex and so I am struggling a bit with getting it to work. The team over at Project Zero have a good write-up of it so I'm following that and the POC at exploit-db to guide me through it.
I think I will be able to get the USB part to work but I'm not sure if I have to write a Java file to automatically run when /data is mounted, or if that's even possible.

Forenzo said:
My current line of attack is an exploit over USB called OATmeal
Click to expand...
Click to collapse
Not to make you frustrated, but this is an old exploit and I highly doubt it'd work on your device, unless your device security patch is older than 9-2018.
And you can't rollback on your security patch.
You should really consider flashing TWRP or other custom recovery. You have no other option.

XDHx86 said:
Not to make you frustrated, but this is an old exploit and I highly doubt it'd work on your device, unless your device security patch is older than 9-2018.
And you can't rollback on your security patch.
You should really consider flashing TWRP or other custom recovery. You have no other option.
Click to expand...
Click to collapse
Fortunately the device hasn't been updated since around 2-2018 or 3-2018 so any exploit I can find from then onwards that I can use will be great. I really do get that the only realistic option is to unlock the bootloader and flash the recovery but the data needs to be recovered and I absolutely don't want to wipe it.
If I can't do it then it will gather dust until the end of time...

It seems that no matter what I say you won't realize the situation you are in.
I can only suggest to NEVER mess with the phone circuits or the motherboard. No matter which stupid yoututbe tutorial you saw. Those guys are douchebags who only know how to get views and don't care for whatever you/they do to your device.
Needless to say messing with the circuits or the motherboard require dexterity and experience which I'm positive you don't have.
As I said before if you send it to an authorized service center, then they can help you with it without memory loss.
Sending you device to a service center isn't an insult or an act of low self esteem. Service centers exist for a reason, and they're basically geeks who are too passionate about electronics and decided to make a living out of it.
Or maybe you can somehow use the EDL mode on the phone.
In Qualcomm devices the EDL mode is locked and can only be accessed by an authorized person who have the security code of your device. I don't know if it even exist in MTK devices.
Should you actually manage to boot into EDL mode - Assuming it exists and is unlocked - then BEWARE: EDL mode is very low level and any command can directly affect the kernel or compromise the system. Don't use commands you're not sure what do they do.
You can use EDL mode to recover the data from the phone then wipe it clean, then restore the data.
You cannot access memory with EDL mode, but you can access the current image on your device. And from which you can get the key file.
EDL mode is a very very powerful tool (Much more powerful than debugging, fastboot, or anything you may know of) as it doesn't need unlocked bootloader to use it and through which you can do anything to your device including flashing other ROMs.
Good luck on your impossible quest. Make sure to post updates should you find yourself stuck.