Develop Bugs

[Q] Explain to me why devs are unable to unlock the MJB bootloader

I've been curious about how the Bootloader is locked down and why it's so difficult/impossible to unlock. How does the mfg get the initial load onto the device when it's manufactured?
I read that this bootloader has some 2048 encryption and that it's impossible to crack. However, I feel like there should be a way to alter the systems firmware from a PC or some kind of connection to the device.

Buchez said:
I've been curious about how the Bootloader is locked down and why it's so difficult/impossible to unlock. How does the mfg get the initial load onto the device when it's manufactured?
I read that this bootloader has some 2048 encryption and that it's impossible to crack. However, I feel like there should be a way to alter the systems firmware from a PC or some kind of connection to the device.
Click to expand...
Click to collapse
The way I read it somewhere is this,
There are efuses built into the processor/motherboard/memory/whatever that the new bootloader "blows" when it is installed. These efuses are necessary pathways for the older bootloaders, hence why they won't install. I don't believe the new bootloader is "locked" per say, it just prevents earlier versions from being installed. There is also a guide somewhere on these forums to recover your device from a brick if you tried to downgrade the bootloader. The new bootloader also doesn't prevent you from installing earlier roms, as long as they are flashable from recovery. Just do not try to use Odin to revert to an earlier rom. That's what causes the bricks, and although there is a procedure to recover, it doesn't sound easy and you end up back on MJB when you're done anyway. Hope that helped.
To whoever wrote the original post I referred to above, my apologies for not giving credit.

Thanks for the reply.
I'm pretty solid with flashing ROM's and such. I have been wondering if it would be possible to use a regular PC and some cool software to reset or reformat the firmware on the system.
Here is a link to the article I was reading:
http://rootzwiki.com/news/att-locks-down-its-galaxy-s-iv-bootloader/
Say I have brand new S3 hardware right off the factory floor. How does that system get injected with the software? When the factories get damaged or "Bricked" units back and refurb them, how do they do that. I know that you can use the SD card trick to jump your phone back to life, but there has to be some master way to do this

Buchez said:
Thanks for the reply.
I'm pretty solid with flashing ROM's and such. I have been wondering if it would be possible to use a regular PC and some cool software to reset or reformat the firmware on the system.
Here is a link to the article I was reading:
http://rootzwiki.com/news/att-locks-down-its-galaxy-s-iv-bootloader/
Say I have brand new S3 hardware right off the factory floor. How does that system get injected with the software? When the factories get damaged or "Bricked" units back and refurb them, how do they do that. I know that you can use the SD card trick to jump your phone back to life, but there has to be some master way to do this
Click to expand...
Click to collapse
I don't have an S3, I'm on the S3 section because my mom broke her phone, so this is speculation based on when I owned an Optimus G:
There are qualcomm tools that can fix a lot more than Odin and Fastboot can, apparently, and manufacturers have access to those. When I had an Atrix 4G someone told me they replace the entire board when eFuses are burned incorrectly, but that sounds really expensive. Anyway, just my 2 cents, i'm out~

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.

how to connect htc one m8 to PC, without having acces to Recovery?

some help pls?

That depends on what you are trying to do. You can use fastboot commands in bootloader-fastboot mode; which will still work even if OS and recovery are not accessible. But anything more (such as adb, storage access) you will need at least recovery.
What is the current condition of the phone, what were you trying to do, or want to do, etc.?

redpoint73 said:
That depends on what you are trying to do. You can use fastboot commands in bootloader-fastboot mode; which will still work even if OS and recovery are not accessible. But anything more (such as adb, storage access) you will need at least recovery.
What is the current condition of the phone, what were you trying to do, or want to do, etc.?
Click to expand...
Click to collapse
Thanks for willingness to help,i was already solving the problem.I went to a specialized server,and they repair it.

morrientes99 said:
Thanks for willingness to help,i was already solving the problem.I went to a specialized server,and they repair it.
Click to expand...
Click to collapse
That's too bad. You probably spent money to fix something we could have helped you with, for free.

redpoint73 said:
That's too bad. You probably spent money to fix something we could have helped you with, for free.
Click to expand...
Click to collapse
was not so bad..i was also replacing the battery and usb connector,so now looks like new..unfortunately they didnt install Android 7.0,but im afraid to try to do it

morrientes99 said:
unfortunately they didnt install Android 7.0,but im afraid to try to do it
Click to expand...
Click to collapse
Sounds like you haven't modded the phone before? No need to be afraid in my opinion. You won't brick (or otherwise damage) the device by unlocking the bootloader, installing custom recovery, and flashing a custom ROM. And the process is almost entirely reversible, with the slight exception of the fact that the bootloader will only ever say UNLOCKED or RELOCKED; versus LOCKED (stock condition). But this is almost entirely irrelevant, as RELOCKED is functionally the same as LOCKED, aside from the possibility that RELOCKED voids the warranty (indicates the phone was bootloader unlocked) but the huge majority of M8 devices don't have warranty at this point, as the phone is going on 3 years old.
Just be sure to properly read and understand the process before you start, don't use outdated methods, backup any personal data before bootloader unlock, and be sure to make a backup of your current stock ROM before flashing the new ROM. Also understand how to recover from problems, such as restoring a TWRP backup, etc.
Do the necessary due diligence before you start, and modding the phone will go just fine.

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.

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.