[Q] Phones that have no 'Secure Boot' NOT Locked Bootloader

[Q] Phones that have no 'Secure Boot' NOT Locked Bootloader - Android Q&A, Help & Troubleshooting

Hey Guys,
I've been using the OnePlus One (Bacon) for the past year and I'd like to switch however the OnePlus One has no 'Secure Boot' not to be confused with 'Locked Bootloader'
I can modify partitions like the SBL (Secondary Bootloader), ABOOT (Android Bootloader) and the Modem without the phone not booting.
Can anyone recommend a phone that either ships without any boot verification chain or has the option to disable 'Secure Boot'

(dylanger) said:
Hey Guys,
I've been using the OnePlus One (Bacon) for the past year and I'd like to switch however the OnePlus One has no 'Secure Boot' not to be confused with 'Locked Bootloader'
I can modify partitions like the SBL (Secondary Bootloader), ABOOT (Android Bootloader) and the Modem without the phone not booting.
Can anyone recommend a phone that either ships without any boot verification chain or has the option to disable 'Secure Boot'
Click to expand...
Click to collapse
I would assume the OPX and OP2 and possibly the OPPO [Find] devices would be similar in this regard, given their relationship. I have access to the OPX/OP2 but haven't had the time to dig into them yet. The new Intels might also be an option with the `fastboot flash keystore` function, so that you can use your own key for boot verification. I haven't had a chance to dig into it yet to see how much you can modify, but from what I gather, they will try to verify boot using the user keystore, followed by the OEM keystore.

binsol said:
I would assume the OPX and OP2 and possibly the OPPO [Find] devices would be similar in this regard, given their relationship. I have access to the OPX/OP2 but haven't had the time to dig into them yet. The new Intels might also be an option with the `fastboot flash keystore` function, so that you can use your own key for boot verification. I haven't had a chance to dig into it yet to see how much you can modify, but from what I gather, they will try to verify boot using the user keystore, followed by the OEM keystore.
Click to expand...
Click to collapse
Cheers for your response. Yeah I haven't even looked at the new Intel CPUs yet, oooo damn a 'fastboot flash keystore' would be very nice. This feature should be on all devices? I wonder why vendors don't just give consumers full access to the hardware.
A quick question. Is the OEM Keystore stored on the Flash or CPU? I guess it would be protected once the OS has booted but that wouldn't protect it against JTAG if its stored on Flash.

(dylanger) said:
Cheers for your response. Yeah I haven't even looked at the new Intel CPUs yet, oooo damn a 'fastboot flash keystore' would be very nice. This feature should be on all devices? I wonder why vendors don't just give consumers full access to the hardware.
A quick question. Is the OEM Keystore stored on the Flash or CPU? I guess it would be protected once the OS has booted but that wouldn't protect it against JTAG if its stored on Flash.
Click to expand...
Click to collapse
I originally thought the OEM keys were burnt-in on a ROM chip, but the more I read about it, it sounds like they're stored in a protected partition on eMMC. The eMMC 4.x+ spec suggests this is the case with the "Replay Protected Memory Block," little kernel source has references to similar protected memory. I'm just starting to dig into into it, but I'm pretty interested to know if it can be DMA'd.
I'm expecting the fastboot flash keystore to become common with late M or N devices with how Google is pushing the verified boot stuff (alerting the user about tampered boot). This would give their warnings a lot more value, since then you could sign your own modifications and only be alerted if something else then made changes to the boot.
The flash keystore seems to have a bunch in common with the (Windows) UEFI secureboot. I would assume that's a reason Intel has a jump on it.

binsol said:
I originally thought the OEM keys were burnt-in on a ROM chip, but the more I read about it, it sounds like they're stored in a protected partition on eMMC. The eMMC 4.x+ spec suggests this is the case with the "Replay Protected Memory Block," little kernel source has references to similar protected memory. I'm just starting to dig into into it, but I'm pretty interested to know if it can be DMA'd.
I'm expecting the fastboot flash keystore to become common with late M or N devices with how Google is pushing the verified boot stuff (alerting the user about tampered boot). This would give their warnings a lot more value, since then you could sign your own modifications and only be alerted if something else then made changes to the boot.
The flash keystore seems to have a bunch in common with the (Windows) UEFI secureboot. I would assume that's a reason Intel has a jump on it.
Click to expand...
Click to collapse
Interesting... I'm guessing Google will use qFuses to track weather or not the boot process has been tampered with. I wonder where the splash screens are located as I guess one could just replace the Tampered Boot screen with the normal boot one.
Surely all areas of the eMMC would be accessible via something like JTAG?
Hmm, yeah it would make sense for Little Kernel to check the OS'es Kernel integrity, something like Get Key from Keystore into a variable, then check against the actual Kernel image?
Little Kernel pretty interesting actually, from what I've gathered it controls stuff like entering modes (Holding Power + VolUp will enter Recovery or Fastboot etc) and Fastboot, have you ever tried to load LK into IDA? Integrating something like the Cerberus App into ABOOT would be awesome, Anti-Theft at the bootloader!

(dylanger) said:
Interesting... I'm guessing Google will use qFuses to track weather or not the boot process has been tampered with. I wonder where the splash screens are located as I guess one could just replace the Tampered Boot screen with the normal boot one.
Surely all areas of the eMMC would be accessible via something like JTAG?
Hmm, yeah it would make sense for Little Kernel to check the OS'es Kernel integrity, something like Get Key from Keystore into a variable, then check against the actual Kernel image?
Little Kernel pretty interesting actually, from what I've gathered it controls stuff like entering modes (Holding Power + VolUp will enter Recovery or Fastboot etc) and Fastboot, have you ever tried to load LK into IDA? Integrating something like the Cerberus App into ABOOT would be awesome, Anti-Theft at the bootloader!
Click to expand...
Click to collapse
I would guess the splash screen is in aboot, since it's the first thing with graphics output, and its alerting you that boot.img onward has been tampered with. If you can replace the splash screens, I'd assume you could break the whole chain since you'd already be altering aboot.
I think if you had raw access to the eMMC, you could replace the keystore. Do you know if JTAG is accessible on the OPO or similar devices? I read somewhere that JTAG is generally disabled/removed from non-engineering devices with 800+ series snapdragons. I've had no luck tracking down the JTAG so far on the board. All I've been able to get is UART.

binsol said:
I would guess the splash screen is in aboot, since it's the first thing with graphics output, and its alerting you that boot.img onward has been tampered with. If you can replace the splash screens, I'd assume you could break the whole chain since you'd already be altering aboot.
I think if you had raw access to the eMMC, you could replace the keystore. Do you know if JTAG is accessible on the OPO or similar devices? I read somewhere that JTAG is generally disabled/removed from non-engineering devices with 800+ series snapdragons. I've had no luck tracking down the JTAG so far on the board. All I've been able to get is UART.
Click to expand...
Click to collapse
Ah true, I didn't know ABOOT was the first process with Graphics Output, cheers for that
Really!? I'd assume that JTAG access is enabled for support purposes? The whole "My phones doesn't work" so you send it in? And they'd just re-partition everything?
I bought a RiffBox along time ago (Never actually used it -_-), that allowed direct access to eMMC, read and write you could dump and write whole bin images.
Another quick question, it was my understanding that some of the boot process used ARM's TrustZone or TZ to store keys.

(dylanger) said:
Ah true, I didn't know ABOOT was the first process with Graphics Output, cheers for that
Really!? I'd assume that JTAG access is enabled for support purposes? The whole "My phones doesn't work" so you send it in? And they'd just re-partition everything?
I bought a RiffBox along time ago (Never actually used it -_-), that allowed direct access to eMMC, read and write you could dump and write whole bin images.
Another quick question, it was my understanding that some of the boot process used ARM's TrustZone or TZ to store keys.
Click to expand...
Click to collapse
The source on the JTAG is evading me at the moment, but iirc the reasoning is that its a huge security hole (shocker...), and not really necessary as the new QC chips are generally regarded as unbrickable, though I have one here that would disagree. You can put the OPO into Qcom download mode and push stock images to the (logical) disk. Will get you out of most bricks, like if you delete boot/recovery and lock the bootloader. I haven't spent enough time digging into it yet to know if you can get raw emmc access that way.
TrustZone is used for secure execution and protected memory. From the LK source it looks like the eMMC keystore is dropped into TZ early in the boot. https://www.codeaurora.org/cgit/qui...rget/msm8974/init.c?h=LA.BR.1.3.2_rb3.16#n362

binsol said:
The source on the JTAG is evading me at the moment, but iirc the reasoning is that its a huge security hole (shocker...), and not really necessary as the new QC chips are generally regarded as unbrickable, though I have one here that would disagree. You can put the OPO into Qcom download mode and push stock images to the (logical) disk. Will get you out of most bricks, like if you delete boot/recovery and lock the bootloader. I haven't spent enough time digging into it yet to know if you can get raw emmc access that way.
TrustZone is used for secure execution and protected memory. From the LK source it looks like the eMMC keystore is dropped into TZ early in the boot. https://www.codeaurora.org/cgit/qui...rget/msm8974/init.c?h=LA.BR.1.3.2_rb3.16#n362
Click to expand...
Click to collapse
Oh the "Download" mode (The sort of last defence, I think its Power in + Volup + Power Button or something), would that be controlled by ABOOT or is it a SoC function? If it is controlled by ABOOT then it could be corrupted pretty easily.
If its controlled by the SoC then where would the code be stored?

(dylanger) said:
Oh the "Download" mode (The sort of last defence, I think its Power in + Volup + Power Button or something), would that be controlled by ABOOT or is it a SoC function? If it is controlled by ABOOT then it could be corrupted pretty easily.
If its controlled by the SoC then where would the code be stored?
Click to expand...
Click to collapse
The key combo trigger is in ABOOT: https://www.codeaurora.org/cgit/quic/la/kernel/lk/tree/app/aboot/aboot.c?h=LA.BR.1.3.2_rb3.16#n3280
However, I wouldn't be surprised if its stored in a different partition (ie dbi), then sbl could auto-boot it in the event of corrupt ABOOT. That would make sense to me, but I haven't purposefully erased or flashed a bad ABOOT yet to find out. The one I bricked here can still get into download mode, yet I cant get any other response from ABOOT if I boot it normally, pretty anecdotal, but leads me to believe the download mode is affected by corrupted ABOOT.

binsol said:
The key combo trigger is in ABOOT: https://www.codeaurora.org/cgit/quic/la/kernel/lk/tree/app/aboot/aboot.c?h=LA.BR.1.3.2_rb3.16#n3280
However, I wouldn't be surprised if its stored in a different partition (ie dbi), then sbl could auto-boot it in the event of corrupt ABOOT. That would make sense to me, but I haven't purposefully erased or flashed a bad ABOOT yet to find out. The one I bricked here can still get into download mode, yet I cant get any other response from ABOOT if I boot it normally, pretty anecdotal, but leads me to believe the download mode is affected by corrupted ABOOT.
Click to expand...
Click to collapse
I've successfully nulled out some fastboot commands before for Anti-Theft, but I'm pretty sure if you have access to Qualcomm's download mode you should be able to re-flash the ABOOT partition and get out of that brick?
Do you think that OnePlus would ever make LK/ABOOT open source? I'd love to be able to create my own bootloader, I wonder if any vendors do this because I'd buy one of their phones immediately!
Going off topic a little bit:
Have you ever looked into Qualcomm's DIAG mode with QPST? A lot of interesting stuff, I know they lock the modem's NV data down with an SPC (Special Programming Code) its a 6 digit PIN. I wonder if anyone has tried to brute-force this PIN? Because the data would allow you to do lots of interesting stuff like have the phone run on completely unsupported frequencies.

(dylanger) said:
I've successfully nulled out some fastboot commands before for Anti-Theft, but I'm pretty sure if you have access to Qualcomm's download mode you should be able to re-flash the ABOOT partition and get out of that brick?
Do you think that OnePlus would ever make LK/ABOOT open source? I'd love to be able to create my own bootloader, I wonder if any vendors do this because I'd buy one of their phones immediately!
Going off topic a little bit:
Have you ever looked into Qualcomm's DIAG mode with QPST? A lot of interesting stuff, I know they lock the modem's NV data down with an SPC (Special Programming Code) its a 6 digit PIN. I wonder if anyone has tried to brute-force this PIN? Because the data would allow you to do lots of interesting stuff like have the phone run on completely unsupported frequencies.
Click to expand...
Click to collapse
I doubt they will, I think support is a pretty big reason they dont release it. That and the number of people who would actually roll their own would be pretty small. Though I would love if they did.
Were you able to make changes to the OPO ABOOT? I saw your IDA post the other day.
It's bee a while since I was digging around in QPST, there was quite a bit of research done for unlocking additional bands on the OPO, generally being inconclusive. http://forum.xda-developers.com/one...ock-aditional-bands-qualcomm-t2877031/page100
https://nathanpfry.com/wip-band-4-band-17-on-chinamobile-oneplus-one/

binsol said:
I doubt they will, I think support is a pretty big reason they dont release it. That and the number of people who would actually roll their own would be pretty small. Though I would love if they did.
Were you able to make changes to the OPO ABOOT? I saw your IDA post the other day.
It's bee a while since I was digging around in QPST, there was quite a bit of research done for unlocking additional bands on the OPO, generally being inconclusive. http://forum.xda-developers.com/one...ock-aditional-bands-qualcomm-t2877031/page100
https://nathanpfry.com/wip-band-4-band-17-on-chinamobile-oneplus-one/
Click to expand...
Click to collapse
Indeed I was, I used a Hex Editor to null out (\x00) commands like "fastboot flash", "fastboot erase" and "fastboot oem"
Its very irritating, IDA can read everything up until the apps_init function.
Here's a snippet of the apps_init boot process from Reverse Engineering Android's Aboot book (http://newandroidbook.com/Articles/aboot.html)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
When IDA got to loading any app, I.E fastboot it would get obfuscated and just render as hex. Have you tried to play around with ABOOT before? So close to actually seeing ARM Assembly.

(dylanger) said:
Indeed I was, I used a Hex Editor to null out (\x00) commands like "fastboot flash", "fastboot erase" and "fastboot oem"
Its very irritating, IDA can read everything up until the apps_init function.
Here's a snippet of the apps_init boot process from Reverse Engineering Android's Aboot book (http://newandroidbook.com/Articles/aboot.html)
When IDA got to loading any app, I.E fastboot it would get obfuscated and just render as hex. Have you tried to play around with ABOOT before? So close to actually seeing ARM Assembly.
Click to expand...
Click to collapse
That's cool, I'll start probing around. I haven't messed with aboot in IDA at all, but I've used IDA a lot in a past.
Do you think the obfuscation is deliberate? Also have you tried some of the mbn scripts around? http://forum.xda-developers.com/showthread.php?t=2641245
I've seen a few references to them when people are reversing bootloaders.

binsol said:
That's cool, I'll start probing around. I haven't messed with aboot in IDA at all, but I've used IDA a lot in a past.
Do you think the obfuscation is deliberate? Also have you tried some of the mbn scripts around? http://forum.xda-developers.com/showthread.php?t=2641245
I've seen a few references to them when people are reversing bootloaders.
Click to expand...
Click to collapse
Really? Reverse Engineering is pretty fun, really getting into the mind of the developer.
Yeah use that plugin,
Oooo I have have found the code that loads fastboot.c
The obfuscation may have been my fault, I've loaded in ABOOT from Color OS and it looks like everything is okay now.
Woohoo! Check that out!

After poking around a little bit more, ColorOS is a KitKat ROM that uses an older ABOOT, that's why it successfully opened in IDA.
If I open ABOOT from OnePlus One's latest firmware (cm-12.1-YOG4PAS1N0-bacon-signed) I get this
Now I think its doing this because the plugin provided by MemoryController is outdated, I have no idea how to create these scripts/plugins for IDA, if anyone does know please let me know, I think this could also unlock the ability to change the boot splash screens on newer firmware as the images in the LOGO partition are encrypted, the code inside of this newer ABOOT could contain the decryption process.
Back to the older KitKat ABOOT here is the boot.img (Kernel) loading code just FYI:

We should probably move this thread over to your OPO topic, It'll probably get move views over there:
http://forum.xda-developers.com/oneplus-one/general/oneplus-one-lk-little-kernel-bootloader-t3269111

binsol said:
I read somewhere that JTAG is generally disabled/removed from non-engineering devices with 800+ series snapdragons.
Click to expand...
Click to collapse
This isn't specifically the source I was thinking of when I wrote that, but it also suggests that JTAG is generally disabled:
http://recon.cx/2013/slides/Recon20...uditing Android's Proprietary Bits-public.pdf
Slides 31,48

binsol said:
This isn't specifically the source I was thinking of when I wrote that, but it also suggests that JTAG is generally disabled:
http://recon.cx/2013/slides/Recon20...uditing Android's Proprietary Bits-public.pdf
Slides 31,48
Click to expand...
Click to collapse
Ah yeah I've seen this, I'm actually digging into the vendor-ril driver (libril-qc-qmi-1.so) as I'd like to share the baseband of one device to another.
Interesting I've found come code referencing "QCRIL_EVT_HOOK_UNSOL_ENGINEER_MODE", UNSOL means Unsolicited Command, meaning its an incoming command from the base band to the upper layers of the RIL, looks kind of backdoor-ey to me, perhaps remote enabling of Engineer Mode?
I've also just seen (I guess) is the SIM PIN and PUK verification code?
Should I create another thread? Would you be interested in discussing further?

There were a lot of interesting strings in the modem last time I looked, like stuff relating to http and hdmi (video drm?). Is this the OnePlus One modem? It would probably make sense to make a thread in that forum. I'm not sure how much interest it would generate here.

Related

[REF] Education on Device Fundamentals (Bootloader QFuses Hacks O My!)

So I know everyone wants to get a boot loader hack, and as I read I notice a lack of guides on what is a boot loader, how it works, and a lot of references on learning.
Why am I posting this?
That’s a very good question. There are two main reasons for me posting this. The first reason is that the developers are often times too busy to work on trying to explain and educate the public on the ins an outs of boot loaders. The second reason for this is that I am a firm believer in open transparency. When bounties and other incentives are offered to the community we loose site of what the goal is: To unlock the boot loader. People become so secretive and ideas are not shared, this makes it so people perceive a competition between devs, instead of a competition between the devs and the company’s. This is why I love providing this information, because in the end the money doesn’t matter, it’s the boot loader unlock. So for those two reasons I have created this thread.
So let us begin:
What is a boot loader?It is a common misconception that a boot loader boots up the OS. Yes this is a type of boot loader, but it is not necessarily what a boot loader is. A boot loader is a set of machine instructions that push a device from an off state to an on state. By looking at this definition we lean there are so many more boot loaders.
Low-Level boot loaders
These are the boot loader that we usually don’t look at, or hear about. Most of the time these are what are referred to as chip firmware. An example of this is when we look at something like NVFLASH, or other programs that can fix a device regardless of how bricked the device is. With in these boot loaders often times contains the operations on how to start the device i.e. start up the power supply, and other very low level functions.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
omappedia.org
When we say a boot loader is locked this is usually where the security chain starts. Once this has issued the next stage boot loader, it checks to make sure the signature is correct. We will discuss how they do this in later sections.
omappedia.org
High-Level boot loadersThese are the boot loaders we are used to things such as Uboot, Aboot, rrboot, Hboot. These binaries are often located in an on chip memory bank. These are the boot loaders that check for buttons pressed, whether to boot into recovery or normal, and what we usually focus on hacking, as we have access to this subsystem through the USB.
omappedia.org
Many of the on chip boot loaders such as the Low-Level boot loaders are not accessible unless directly connected to the chips leads, however these High-Level boot loaders can be accessed via SPI, I2C, or other inter chip communication.
omappedia.org
Well that’s all fine and dandy but how the heck do they lock them, can’t we just disable it?
Well unfortunately they have already thought of this. This is where we get QFuses, Write Protect, and other “security” measures that prevent us from reading or writing new code on top. With these “On Chip” security measures, a company is able to start the chain of trust from the initial stage boot loader always making sure that the next stage has a valid signature.
Lets go over a couple of different types of Countermeasures:
eFuses
eFuses are the death of all hackers as these truly are one time write. The idea of an efuse is effectively to blow up a connection to change the value of a bit.
xda-developers.com
When we look at the image above we can clearly see that one of them seems to be damaged. This one has been written too, and has actually destroyed the connection, making it impossible to reconnect it, unless you want to FIB it and deposit the metal.
Supervisory Code
Supervisory Code is actually more common then most people think. The idea of this is to have an SROM, which contains supervisory commands that are hardcoded commands. These commands are the only commands that can operate on SRAM that is on chip. Once these SROM codes can only be used from the chip level, and cannot be executed if the MMAP table in SRAM has write protection on it, if it does the entire boot loader is erased.
EEPROM
This is an older tech and really isn’t used that much. The basic principle of this is utilizing the idea the semiconductors can behave like ROM under given conditions, and erased given other conditions.
hitequest.com
This is used in tech like NVRAM and such. It relies on being able to supply multiple voltages as seen above. Another old way of erasing was to flash with UV light as it allowed for all of them to reach the erase condition. The problem is that once programed, they cannot be changed because it requires higher voltages to change. These types are often programed off board and then placed on board, or have usage of something like JTAG to reprogram.
There are many more security measures and this list will continue to expand.
Okay well this all sucks how have we unlocked boot loaders in the past?
Wow now that one is a tough one as there are so many different ways. But lets try and get a list started
Buffer Overload
This method is probably one of the coolest methods out there. I utilizes the basic structure of how subroutines work and then exploits them. When subroutine or for that case a variable enters that stack it gets put there, and then the return address gets put on the end so that it will return to the designated location. The problem comes in when we don’t have sanity checking of variables, or we don’t catch overflowing them. The explanation of this is highly complicated so I’m going to sight some text from Wiki.
Code:
#include <string.h>
void foo (char *bar)
{
char c[12];
strcpy(c, bar); // no bounds checking...
}
int main (int argc, char **argv)
{
foo(argv[1]);
}
For some one whom sees this they can see that we can specify an array of char with a length longer then 10 and cause a collision into the return address of the stack read. This type of buffer overflow is often referred to as stack smashing. We utilized a technique like this when we built the stack smash for the nook tablet boot loader unlock. We relied on them not checking the header size before loading it into memory. By extending the header by 4 bytes we could smash our own custom return address onto the stack.
Overwriting Existing Code Calls
This is actually how loki worked. It relied on an idea of loading a ramdisk, over existing memory. In this case we utilized shell code that jumped us out of the signature check. By doing this we told the boot loaders to load a ramdisk into a location in memory where we know it will be called. There are three major things done here that we rely on.
The security check for the boot loader occurs when the boot loader is loaded from the ram, any code, which modifies it within the boot loader, will not return as a tampered device.
The boot loader loads the kernel and the ramdisk from memory. Once loaded, then functions are preformed on this. The locations of the ramdisk load are given in the boot header meaning that you can specify any where in code you want to load the ramdisk too.
The function that is being overwritten must be called.
When we look at loki we see that they are overwriting the check_sig function, and putting the custom written shell code there. Once loaded when that function is called it calls the custom code instead of the functional code for check_sig.
I've generated a very rudimentary animation showing how loki works.
This method is extremely tedious as there is no source for a lot of the boot loaders meaning that hole have to be discovered in assembly or a reference to other source codes.
Making a device S-Off or disabling boot loader checking.
This is the one thing that I’m least familiar with. It involves utilizing the boot loader parameters themselves to disable the boot security of primary boot loaders. I’m hopping that someone will be able to point me to more information on how we do this. I do know that doing this is the only true way to unlock a boot loader. Otherwise we rely on the boot loaders not being patched.
Bootstraping and 2nd init
This is actually the “easiest” (use that term lightly) way to overwrite the boot loader. This relies on the system booting up either partially or fully. Theres a really great article here cvpcs.org . The premises of this is that there is an order in which things get booted up. In motorola’s example they boot up the data in the init. They use a ptrace to attach it to the head of the stack, and then when the stack is fully loaded it loads another init, and ramdisk on top of it. This shuts down the entire previous system and allows a second system to be run on top of the current system. In this case the loads take longer as they wait for the complete boot and then boot again on top.
Security leaks and holes.
When we look at the history of hacking we can see that it has always been around and will always be around. For as long as there are new security measures there will be hackers trying. One of the greatest tools that we can get is when leaks occur or when we get holes discovered. One of the greatest examples I can think of was that of the SGNII.
One of the first boot loader hacks discovered with a hole in the boot chain. The Low-level boot loader called the high-level boot loader. The high level boot loader would then check the signature of the boot.img. However they did not check the recovery signature and as such we were able to load another boot loader into the recovery.
Another one of these came in the form of a leak was the SGS3 boot loader. Remember how I said earlier we develop a secure boot chain that goes starts at a Low-Level boot loader. Well in this case we were provided a new boot loader that broke the chain. This boot loader had a valid signature so that the first Low-Level boot loader could verify, and then from there on out there were no verifications.
This thread will continue to grow and evolve.
I WELCOME ALL CONTENT AND CRITICISM. PLEASE LET ME KNOW IF I'M MISSING SOMETHING.

Very informative; nice write up!! Subscribed
Edit: For those trying to learn or get a better understanding can we post our questions here? I ask only because I don't know if you want that obligation.
Sent from my SCH-I545 using xda app-developers app

Good info. Subbed!
Sent from my SCH-I545 using xda app-developers app

Very nice write up
Sent from my SCH-I545 using xda app-developers app

I found this very interesting, thanks for sharing.

Thanks for sharing
Sent from my SCH-I545 using xda app-developers app

Wow. Despite there still being a lot of jargon I didn't understand it was still very informative. I wonder if anyone has considered offering the current bounty for the ME7 bootloader unlock to one of the guys on the LK project as a bribe for the source code of the LK project. Correct me if I'm wrong but that is the project that the new bootloader is based on.
Sent from my ADR6400L using xda app-developers app

DraconicSeed said:
Wow. Despite there still being a lot of jargon I didn't understand it was still very informative. I wonder if anyone has considered offering the current bounty for the ME7 bootloader unlock to one of the guys on the LK project as a bribe for the source code of the LK project. Correct me if I'm wrong but that is the project that the new bootloader I'd baser on.
Sent from my ADR6400L using xda app-developers app
Click to expand...
Click to collapse
Thanks glad you like it. I think we need to clarify two things. A. Bribing of any type is illegal. B. LK is not actually the problem. While LK produces the aboot code, they are not the ones whom would have anyway of unlocking the device because that is all done by Qualcomm. If you look at the partition map there is theres a partition called TZ. This is actually the partition that takes care of the locking, and unlocking theres some some cool stuff that ill have to post about fuses on qualcomm and such.

Loglud said:
Thanks glad you like it. I think we need to clarify two things. A. Bribing of any type is illegal. B. LK is not actually the problem. While LK produces the aboot code, they are not the ones whom would have anyway of unlocking the device because that is all done by Qualcomm. If you look at the partition map there is theres a partition called TZ. This is actually the partition that takes care of the locking, and unlocking theres some some cool stuff that ill have to post about fuses on qualcomm and such.
Click to expand...
Click to collapse
I guess it wouldn't be so much a bribe as a just letting him know that the bounty is there he would still have to come up with the process :angel: I kid of course. But the reason I mentioned LK is because from what I can remember reading, Don (djrbliss) was able to come up with the previous unlock because he noticed that the bootloader was simliar to the open source code for aboot which is what allowed him to work it out. Just thought if we could get our hands on the code for LK it might help. Then again there seems to be progress being made in another thread in regards to using a Dev verision. It sounds like somebody was able to get a temp unlock using a Dev version and is not working with others to try to figure out a way to translate to the consumer editions. You can find it here.
So what your telling me is we need to get an in with someone at Qalcomm
Anyway good info, I obviously still have a lot to learn as I am a flaher but not a dev. I don't know nearly enough about adb, C++, java and the source codes used in android OS to even fake a claim as a Dev lol. Thanks for the info!!

nice
nice ınfos

Not bad, but it confuses several things. S-ON/S-OFF is specific to HTC's smartphone designs and they may not even use it anymore. Also, 2nd init is not a replacement of the bootloader.

The TWRP Password Protection Thread

The TWRP Password Protection Thread
Yes, it has been discussed to no end. People say it makes no sense. More importantly, the TWRP team says it makes no sense:
Password protecting TWRP (lockscreen)
http://teamw.in/securetwrp
I've had people ask enough for a protected TWRP that I'm creating this page as a response so I don't have to retype. If you're seeing this page, you're probably asking, "Why doesn't TWRP offer password protection?" You want to lock down your device so that a would-be theif won't be able to wipe your device to get past your lockscreen and/or so they can't wipe away that cool app you bought from the Play Store that will let you track your stolen device via GPS. Well, here's the short answer:
Nothing trumps physical access to your device. If you've lost it, there's no way that TWRP can secure it.
For a longer answer, it's very easy for anyone with just a little bit of knowledge to get around any kind of security that TWRP might have. All they have to do is flash one of the other recoveries that's available that doesn't have password protection to get around it. Most, if not all devices have ways to flash recovery without needing to boot to either Android or recovery (usually via fastboot or download mode / Odin). Quite literally the only way to truly secure your device would be to render the USB port completely unusable which isn't an option for most newer devices that don't have removable batteries. Even then most devices could still be worked with via jtag though it's unlikely that a thief will go to the trouble of paying for a jtag service on a device that has a broken USB port. (Note: I am not recommending that you purposely damage your USB port as it will also likely make it very difficult to recover your device if anything ever goes wrong!)
I also don't want to offer a lockscreen / password protection because it offers such a superficial level of protection. Users rarely read and would skip over any disclaimers that we have that indicate that any protection that we displayed indicating that their device really isn't secure. If your device has fallen into someone else's hands, your best case scenario should be that you hope that they don't get your personal data. If you don't want someone getting your personal data, use Android's device encryption and a good lockscreen.
But it does makes sense in many cases. My objectives with this thread are: to change the minds of the TeamWin team members on this matter, and to discuss the best way to implement TWRP security. I will start by answering TeamWin's post.
1) Most people just want their data safe, not their phones unusable to burglars.
It is true that nothing beats encryption. But encryption with a trivially short PIN, pattern or password is useless. Raw access to the encrypted media allows brute forcing which in almost all realistic cases will recover the key in no time. Making it hard to reach the encrypted media would in these cases provide more security than encryption itself. And in any case, this would be added security, not replacement security, and can only strengthen the system (and in common cases, by a great deal).
The security of some phones is fundamentally broken, and there is nothing TWRP can do to fix that. The only fix could come from updated bootloaders. But bootloaders need to be signed by the phone manufacturer to work (so aftermarket bootloaders are not an option), and many companies are just not serious enough to care.
Case in point: dirty Samsung. All Samsung cares about is ending your warranty if you dare install software of your choice on your own phone. It has made it impossible for developers to overcome this by actually blowing physical fuses within the phone in their bootloaders if you exercise your freedom. Their "upgrade" bootloaders also blow fuses to prevent you from ever downgrading to the more permissive bootloader that might have been in the phone when you first bought it.
They care about invalidating your warranty a lot, but not at all about your data. I can grab a stock S3, flash whatever I want (voiding warranty, or so they say because in many countries it is rightly not so) and get to your data. So it better be encrypted because Sammy is not giving a damn to defend it.
But other phones actually make an effort to defend your data. This is the case of, for instance, all Google Nexus devices, and the OnePlus One. I name these phones because these are the only mass-market phones I know that do not try to take away your tinkering freedom with threats of voided warranties, and so are the only phones I consider when buying. (No feature is worth loosing your freedom IMO.)
These phones actually fully wipe your data when you unlock their bootloaders, a required step before any flashing is allowed. This means that if I grab a bootloader-locked nexus, I can wipe it but not get to the data without the lockscreen code. Well, unless TWRP is flashed. TWRP breaks the security that Google (and others) baked into their phones.
There used to be a good reason to avoid security in the old CWM days: CWM was not touch, and much less was capable of popping up a keyboard. TWRP has gone such a long way forward that now security can be easily implemented. There is no reason to break the security of good phones just because some phones are broken.
One could disallow access to the storage media on their phone (encrypted or not) by installing TWRP with a password and then relocking the bootloader. In this way, the modded phone would be as secure as its stock counterpart. Modding your phone would not longer mean zero security.
2) It turns out that those who want to disable the burglar's ability to reset the phone and sell it can actually do it in many cases!
It so happens that bootloaders usually do not wipe the phone themselves as it is "too complex" an operation. Many times during bootloader unlocking, the bootloader boots stock recovery instructing it to 1) do the wipe, then 2) reset the bootloader lock. If the bootloader is locked and TWRP is installed in place of the stock recovery and TWRP ignores these commands (as current versions do), then there is no way to wipe the data or unlock the bootloader (and thus no way to flash a door to the system) from fastboot.
So if you:
1) setup a TWRP lockscreen,
2) keep a flashable zip that unlocks your bootloader in your phone (see boot unlock scripts),
3) setup an android lockscreen,
4) download a root app that unlocks your bootloader (see BootUnlocker),
5) and lock the bootloader,
...then you are secure. You can recover bootloader access without wiping as long as either one of rooted android and/or recovery works. But you cannot use either without going through their respective lockscreens.
This prevents access to your data, but in the case mentioned here (recovery does the actual bootloader unlock) it also prevents wipes. In this situation, it is not difficult to imagine a burglar attempting to sell you back your own phone on the cheap. Of course suitable contact info would be displayed in your lockscreen. This is even more security than was planned by Google, and not less as is the current situation with TWRP.
I know for a fact that the OnePlus One works in this recovery-invoked-to-unlock-bootloader manner, and I suspect all Nexuses work in the same way. For these phones, anti-theft can be a reality, and getting them back after a robbery, a not so improbable scenario.
NOTE: It should now be obvious why it is very dangerous to lock your bootloader unless a working stock recovery is in place. If you cannot obtain root access in either android or recovery, your recovery is custom (and thus it does not unlock the bootloader), and your bootloader is locked, then you are stuck: you will not be able to unlock your bootloader without a JTAG rig. Under some circumstances this can render your phone unrootable or effectively bricked. This is in part our objective anyway: that burglars are not able to gain control of the phone, not even by full wipe. But it can seriously backfire if you make a configuration mistake or simply forget your passwords. Keep in mind that you can make these mistakes today, without security in TWRP. Bootloader re-locking in a scenario other thank return-to-stock is an intrinsically dangerous operation that only advanced users should attempt.
3) Encryption is insecure unless the boot chain can be trusted.
An adversary that gains physical access to your phone can dump and save a copy of the encrypted partition(s) and plant a password sniffer that later forwards the password to them. You cannot trust your password to a non-tamper-evident device that can be trivially modified. The only way to protect the boot chain from tampering in today's phones is locking the bootloader and restricting access to the recovery.
Countermeasures
Some SoCs are compromised. For example, a signed USB-fed bootloader for the Galaxy Nexus has leaked into the public domain, and with it the SoC of a Galaxy Nexus can be booted entirely via the USB port. A monitor software can be loaded that can read (or write) the complete eMMC (the storage). This is possible because either TI or Samsung leaked a properly signed debugging bootloader. This is an extremely rare case because this bootloader makes you God. I think some Kindle Fires also have a similar thing. Few phones had their security broken so drastically; compromised SoCs are the exception and are very few.
Finally, the attacker could open up the phone and use JTAG to directly access the eMMC. It requires equipment and know-how and work and time, and significantly adds to the full cost of robbing a phone, eating up their profit. Probably almost all phones could be recovered by JTAG.
But of course, there are countermeasures to countermeasures. Many people have discussed damaging JTAG traces, bond wires, or even the IC itself, and some JTAG ports can be irreversibly disabled by design.
Conclusions
1) TWRP is doing nothing in fundamentally insecure phones.
2) TWRP is disabling the security of secure phones.
3) Secure phones with TWRP could be as secure as they are with stock recovery.
4) In some cases phones with TWRP can be even more secure, preventing their unauthorized wiping and reselling.
5) A barrier blocking access to encrypted media can effectively protect more than encryption itself if short keys are used.
6) Encryption is insecure with an unlocked bootloader or an open-access recovery.
We have the rationale, we have the UI, we have the keyboard, and we have the great team of programmers behind TWRP: let's get this old rat hole plugged for good.

Implementation Ideas
Security is never trivial to implement, so I will accumulate some points here to guide the design of a solution. Fell free to contribute.
The passwords must be stored in an irreversible manner, using proven, properly salted cryptographic methods.
The password store (PS) should not be accessible to apps, or else they might attack it by brute-force. In /data/media devices, if the PS is stored in /data/media/0, it should be stored with restrictive permissions such that the fuse daemon will not reflect it into world readable /sdcard. Under kitkar (and even using a permission-less real fat32 /sdcard) files could be made inaccessible under folders in /Android i think. Otherwise the /data partition could work (ugly due interactions with nandroid backups). Also, bytes reserved in the /recovery partition itself could do the trick. NOTE: nandroid backups suffer the same problem: they are world readable copies of your passwords and auth tokens. It is imperative that general solution to this problem be found for TWRP. CM's recovery places the backup files outside of '0' in /data/media which is a good solution for /data/media devices. And going forward, this type of devices should be the norm.
adbd and mtpd should not start before the password is entered.
It is enough to ask for password once per boot.
adb on recovery is the data recovery method of choice when a screen is broken. it should be possible to enter the password via USB to enable adb and mtp with a broken screen. NOTE: by the same token, it should be possible to enter the phone encryption password via USB if any.
Both the recovery lockscreen/password and android lockscreen/password could be the same, since access to android's lockscreen data is needed for encryption support anyway and thus that code is already in place. But then, forget this one password and your phone is a brick!!!
If they are not the same, a way (an app) to change the password (or at least reset it) from root android should be provided.
There could be an official TWRP password manager app that stores the TWRP password in its private data in /data and TWRP could read it from there. (But the interaction with nandroid backups would kinda suck.)
To enter the password over USB, ideally a restricted adbd mode would ask for the password, then restart itself a la "adb root" switcheroo. So that standard adb can be used to enable adbd and another host tool is not needed.
There should be some throttling down of passwords tries both via the recovery popup keyboard and via adb. If the same password is used for android and recovery, then the throttling should not be less aggressive than android's.
Ideally the password hash in the PS should be stored in a way compatible with some proven challenge response authentication so that the data in the PS can support future unlock protocols that do not send the password in the clear.

kind invitation to read this thread:
@Dees_Troy
 @bigbiff
thanks!

Lanchon said:
Some SoCs are compromised. For example, a signed USB-fed bootloader for the Galaxy Nexus has leaked into the public domain, and with it the SoC of a Galaxy Nexus can be booted entirely via the USB port. A monitor software can be loaded that can read (or write) the complete eMMC (the storage). This is possible because either TI or Samsung leaked a properly signed debugging bootloader. This is an extremely rare case because this bootloader makes you God. I think some Kindle Fires also have a similar thing. Few phones had their security broken so drastically; compromised SoCs are the exception and are very few.
Click to expand...
Click to collapse
All MediaTek SoCs can be considered compromised, for every single one of them allows the entire ROM to be read back and reflashed using spFlashTool, even with a "locked" 2nd stage bootloader. Furthermore, their source code quality can be considered as "rotten to the core", I would bet my behind on the Mediatek kernel customization containing more than one exploitable hole.

harddisk_wp said:
All MediaTek SoCs can be considered compromised, for every single one of them allows the entire ROM to be read back and reflashed using spFlashTool, even with a "locked" 2nd stage bootloader. Furthermore, their source code quality can be considered as "rotten to the core", I would bet my behind on the Mediatek kernel customization containing more than one exploitable hole.
Click to expand...
Click to collapse
thank you for the contribution. it is good to know that all mediatek devices can be rooted and are effectively unbrickable.
it also seems that the opo is unbrickable: there seems to be a ColorOS leak that flashes the system by debug-booting the qualcomm soc.

This is really important stuff… pitty how most people are more interested in skins than serious security issues. Hope it gets the attention it deserves.

i forgot to mention in the first post that Philz Touch Recovery does have password support. (i think they are actually PINs.) i haven't checked how the security is implemented in Philz though. regrettably that recovery has been discontinued so further investigation seemed useless.
TWRP is such a great piece of software that i simply can't imagine any competition will dare take on it again. that's exactly why it's important to get security merged in TWRP.

Lanchon said:
i forgot to mention in the first post that Philz Touch Recovery does have password support. (i think they are actually PINs.) i haven't checked how the security is implemented in Philz though. regrettably that recovery has been discontinued so further investigation seemed useless.
TWRP is such a great piece of software that i simply can't imagine any competition will dare take on it again. that's exactly why it's important to get security merged in TWRP.
Click to expand...
Click to collapse
3 people in the entire world do a majority of the work for TWRP. We are welcome for contributions to the TWRP projcect at OMNI's gerrit for people who want to get this done.

bigbiff said:
3 people in the entire world do a majority of the work for TWRP. We are welcome for contributions to the TWRP projcect at OMNI's gerrit for people who want to get this done.
Click to expand...
Click to collapse
i thought of that, but adding a feature like this to TWRP probably requires too much effort for somebody who doesnt know the codebase. i imagine that TWRP is sort of an app framework in itself. i chose to advocate for it instead of implementing, i just can't justify the effort it would take *me*. i also tried to help by centralizing ideas on how it should be implemented, if somebody chooses to.
anyway, it's great to know you are not opposing the idea and you would consider merging if somebody implements, that is a good start.
btw, there is a tangentially related issue i'd love to hear your opinion on:
i hear TWRP can mount encrypted partitions and there is a UI for entering PINs, passwords, patterns etc. but i dont have my phone encrypted because if i break my display with the phone encrypted then im toast: i cant extract my files from the device anymore.
would you consider implementing a way to enter the encryption password via usb? maybe some sort of adb shell command?

UPDATE: Added a third item to the OP...
3) Encryption is insecure unless the boot chain can be trusted.
An adversary that gains physical access to your phone can dump and save a copy of the encrypted partition(s) and plant a password sniffer that later forwards the password to them. You cannot trust your password to a non-tamper-evident device that can be trivially modified. The only way to protect the boot chain from tampering in today's phones is locking the bootloader and restricting access to the recovery.

Thank you very much for this call, I highly appreciate it! Me, I consider securing Recovery also very essential, but instead of coding a patch I would like to contribute the overall discussion:
having a locked bootloader normally restricts you to booting a stock kernel without a bootloader-valid signature, right? Otherwise you could simply fastboot any kernel without flashing. But this can be an issue in case your kernel is outdated and has other security flaws which e.g. make it vulnerable from remote. In this case, you secure your device from offline attacks but stay vulnerable to online attacks. The hard questions is: which attacks are more realistic?
in "good old cm7 times", maniac103 implemented a password-protected CWM for the Motorola Defy which was based on entering a password sequence using the sensor keys (back, home, search etc.). See this commit.
many people argue against Android encryption because it is based on the "same password as for the screen unlock". This is essentially not true: It's just the front-end in almost all Stock ROMs which does not support it - the back-end does. You can set a much stronger passphrase for protecting your encryption key using comand line or a tool like this or this (both require root, stupid!). You still suffer from the hardcoded limitations in crypt.c (like only 2000 rounds, just 128bit AES, maximum 16 char limitation etc.) but much better than having just a numeric PIN! Please note that Android 5.0 also tries to store the encryption key in a more secure location than the footer of the disk partition as outlined here.
Even if you could overcome a TWRP password on a bootloader-unlocked device easily by fastbooting a different boot image, it still raises obstacles for a "stupid" attacker (e.g. you need a device with USB and not just a microSD card or USB drive+OTG cable). Although I would still consider it "security by obscurity", in essence, it's going in the same direction as JTAG also being hard(er) to exploit.
The same argument accounts for "dumping your encrypted partition and installing a sniffer" - it raises the barrier and the victim will likely notice that something is wrong (unless it's using a device that's unstable...) because the device will be off or rebooted. A counter-measure would be: if you find your device in such a state, boot into recovery and compare checksums of your boot and system partitions - probably many even more advanced attackers will probably forget to install rogue versions of md5sum/sha256 etc, and of course you could also carry a write-protected USB drive+OTG cable with a clean boot image, provided TWRP would allow you to boot from that (which afaik it currently does not).
Considering the huge security breach of an unprotected recovery, I would consider the option to recover stuff via adb from recovery a secondary objective. A more effective approach which could help against the problem of non-recoverable data from a hardware failure would be having the data already external - like in the approach I posted in this thread where I argue against keeping private data in internal phone memory. Unfortunately, on many devices this will not work with a locked bootloader unless you manage to modify the rootfs elsewise (but I assume recoveries like Philz seem to manage it already somehow with locked bootloaders).
There are many other attack vectors like a memory freeze which a locked bootloader can certainly make more difficult.

For instance, if we had a tool like https://play.google.com/store/apps/details?id=net.segv11.bootunlocker compatible with the OPO, it would be easy to have a pretty secure custom rom.
Scenario (encrypted of course) : unlocked bootloader, TWRP to flash some stuff, back to stock recovery then lock bootloader.
Each time you need back a custom recovery, you unlock the bootloader and to your stuff.
I always did that for the Nexus 4.

Defier525 said:
having a locked bootloader normally restricts you to booting a stock kernel without a bootloader-valid signature, right? Otherwise you could simply fastboot any kernel without flashing. But this can be an issue in case your kernel is outdated and has other security flaws which e.g. make it vulnerable from remote. In this case, you secure your device from offline attacks but stay vulnerable to online attacks. The hard questions is: which attacks are more realistic?
Click to expand...
Click to collapse
thanks!
no, it does not. android reference bootloaders (nexus, opo, etc) do not check kernel signatures when locked. they just disallow flash and boot commands. your point here is void.

Defier525 said:
Even if you could overcome a TWRP password on a bootloader-unlocked device easily by fastbooting a different boot image, it still raises obstacles for a "stupid" attacker (e.g. you need a device with USB and not just a microSD card or USB drive+OTG cable). Although I would still consider it "security by obscurity", in essence, it's going in the same direction as JTAG also being hard(er) to exploit.
Click to expand...
Click to collapse
personally i do not consider connecting the device to a host being any kind of bar raising at all. it is the realm of script kiddies and the standard way stolen phones are reset and/or returned to stock when they have a screen lock.
JTAG, on the other hand, is. it requires physically disassembling the phone and maybe modifying the board. it requires hardware and software tools that are not in the arsenal of the usual adversary. (i am not talking about the NSA!) i have JTAG hardware and use OpenOCD for hardware development but i have never attempted to JTAG a phone and probably never will. it is just too much trouble; not worth it.
modded phones will always be a minority. as long as mainstream phones do not need JTAG after being stolen, i predict modded phones that require JTAG to be recycled will not be recycled and will be sold for parts or maybe resold to the owner at a reduced price. (the "hey, i found this phone..." scenario.)

Defier525 said:
Considering the huge security breach of an unprotected recovery, I would consider the option to recover stuff via adb from recovery a secondary objective. A more effective approach which could help against the problem of non-recoverable data from a hardware failure would be having the data already external - like in the approach I posted in this thread where I argue against keeping private data in internal phone memory. Unfortunately, on many devices this will not work with a locked bootloader unless you manage to modify the rootfs elsewise (but I assume recoveries like Philz seem to manage it already somehow with locked bootloaders).
Click to expand...
Click to collapse
i do not. i do not encrypt my phone because i would not be able to access it with a broken screen. that proposition is unthinkable for me. i use software fallbacks such as keepass. this is a matter of priorities.
also, i dont consider the sdcard hack to be a valid alternative. i will answer to your thread here (but keep in mind that even if it were a valid alternative, this thread is about securing the recovery, not about other options):
-using an external encrypted sdcard with an untrusted boot chain leaves you vulnerable to all caveats of internal encryption, plus more. eg: wiping the phone to get control of its bootloader to plant an attack does not wipe the sdcard.
-the sdcard can be trivially dumped even with a trusted boot chain in place.
-many phones today, including my last 4 phones, do not even have sdcard slots (eg, most of the "free" phones: nexuses and the opo; some GPE phones do have slots) and you can expect the number keep falling down.
-sdcards are extremely slow compared to internal flash.
-sdcards tend to use much more power than internal flash.
-sdcards tend to be unreliable.
-the FTL in sdcards is not designed to handle the constant writing android will subject /data to. most FTLs do not provide good wear leveling, specially if cards are mostly full, and as a result the cards would probably fail soon.
-ASOP encryption of /data is all that is needed since the emulated "internal sdcard" is backed by storage in /data/media since reference android 4.0
-eMMCs in phones *do* provide secure erase commands! it has been a required part of the eMMC standard for years. commands are: SECURE ERASE and SECURE TRIM, and maybe later they added a SECURE DISCARD command, not sure. furthermore, reference android recovery does use these commands while wiping a phone.

Xoib said:
For instance, if we had a tool like https://play.google.com/store/apps/details?id=net.segv11.bootunlocker compatible with the OPO, it would be easy to have a pretty secure custom rom.
Scenario (encrypted of course) : unlocked bootloader, TWRP to flash some stuff, back to stock recovery then lock bootloader.
Each time you need back a custom recovery, you unlock the bootloader and to your stuff.
I always did that for the Nexus 4.
Click to expand...
Click to collapse
this is not solution. you can do this with the opo. it is trivial to use adb shell or the terminal to unlock the bootloader.
but what if android does not boot for any reason? you loose access to your phone? this is not a valid alternative for me.

Lanchon said:
this is not solution. you can do this with the opo. it is trivial to use adb shell or the terminal to unlock the bootloader.
but what if android does not boot for any reason? you loose access to your phone? this is not a valid alternative for me.
Click to expand...
Click to collapse
How do you do that with adb/fastboot without wipe ? (I mean I know oem lock / unlock but unlock implied wiping right)
For your second point, even if I lost access to the android boot, I always get fastboot screen so for me it's a pretty good alternative.

Xoib said:
How do you do that with adb/fastboot without wipe ? (I mean I know oem lock / unlock but unlock implied wiping right)
For your second point, even if I lost access to the android boot, I always get fastboot screen so for me it's a pretty good alternative.
Click to expand...
Click to collapse
you have to change one bit. you need to be root. there are threads that discuss how to, google them.

Lanchon said:
you have to change one bit. you need to be root. there are threads that discuss how to, google them.
Click to expand...
Click to collapse
Right, but adb don't use this trick.
That's why I said it will be cool when the bootunlocker app upgrade to handle OPO address bit.

Thank you for these comments! But could you (re-)post the arguments concerning the fitness of sdcards for /data in the other thread, please? This way we could keep the discussion more focused.
JTAG vs. fastboot: I agree with you, JTAG is a much higher obstacle for a thief and probably most will not go this way while I guess most "bring back to stock" tools work over fastboot anyways. I was just considering a different scenario, e.g. you leave your phone unattended for some minutes on a party.
Data recovery in case of hardware failure: Well this is in conflict with getting more security, unless you additionally secure adb in Recovery like you proposed...
Internal sdcard in /data/media since AOSP 4.0: This was new to me, but it seems to be implemented this way in my Nexus S. I just wonder why my Xperia V does not handle it this way then?
eMMC and secure erase: Okay this was new to me as well. But afaik, TWRP does not use these commands for wiping, does it?
locked bootloader and password protected TWRP: What if an attacker would try to fastboot erase the data or recovery partition? Will a locked, properly implemented bootloader prevent that?
My sd hack in general: I agree, that if this hack only works with a unlocked bootloader (like probably on my Sony) it is less secure than having a locked bootloader even without encryption. Therefore, I was already considering re-locking the bootloader and disabling the hack, but using at least a non-stock userland. Yet, the stock kernel will probably not see any updates anymore and thus will be vulnerable to any upcoming threats.
Yet I think that we both agree in the point, that having password protected TWRP would enhance security. Since TWRP already has all means of a password-unlocker screen in place (for dealing with encrypted /data), it should be trivial to provide a patch which asks for a password before it lets you do anything in TWRP. Maybe if I find some time I can try to see what it would take to implement it, but I am quite busy these days.
Nevertheless, I am quite interested in discussing the security of locked bootloaders and any attack vectors over fastboot in general here.

Flash H901 kdz to get bootloader unlocked, will it works?

As far as i know, someone in a china forum said that he had unlocked the F600S' bootloader successfully.
He first flashed a pre-rooted 5.0 TOT and change the build.prop to h901. Then, he flashed h901 6.0 kdz to his phone and the bootloader became h901 version.
Therefore, he could unlock the bootloader simply by entering "fastboot oem unlock", flashing H901's recovery and rooted the phone.
Some users said this method works but some said didn't and even bricked their phones into "Qualcomm HS-USB QDLoader 9008" mode.
I open this thread for raising attention and investigate whether this method really works or not, but please, DO NOT intend to perform this method unless it was proved to be safe.
If you can read Chinese, here is the source (please remove this link if it violates xda's rules):
http://bbs.gfan.com/android-8325666-1-1.html

i recommend, don't... unless u needed to do that then go

I was attempting something like this awhile back. But I wasn't using the normal build.prop. There is one hiding in /cust/open_com_ds/cust_open_hk.prop that I assumed was what the LGUP program used to check vs the one in /system but apparently I was mistaken. Theoretically there isn't anything hardware wise different between the H901 and the H961N besides the dual sim. Those that don't use dual sim might try this. Otherwise I would wait. If there are any people out there that can make kdz's then all it takes is one person to do it right then everyone else can benefit. I might go ahead and try for shizas and googles.

If memory serves correctly, Yes with an unlocked bootloader you could adb flash modem *BLAHBLAHBLAH* but idk how that works with dual sim phones.
I honestly get aggravated when I see certain users that say they make TOT or KDZ files when really they took it from other sites that aren't English and say they made it. If that was the case they would make a KDZ with stock everything for the device its for but replace the bootloader to the version from H901 and every LG v10 would be bootloader unlockable but somehow they are too busy or working on other TOTs and kdzs... Assinine lies. Sorry had to throw my two cents out there.
I'm so glad I didn't do this attempt yet. Just remembered I gave my backup phone away so I have nothing to fall back on if this fails. If no one tries this before I get it back I will try.

DarkestSpawn said:
I was attempting something like this awhile back. But I wasn't using the normal build.prop. There is one hiding in /cust/open_com_ds/cust_open_hk.prop that I assumed was what the LGUP program used to check vs the one in /system but apparently I was mistaken. Theoretically there isn't anything hardware wise different between the H901 and the H961N besides the dual sim. Those that don't use dual sim might try this. Otherwise I would wait. If there are any people out there that can make kdz's then all it takes is one person to do it right then everyone else can benefit. I might go ahead and try for shizas and googles.
Click to expand...
Click to collapse
Even though many of the pieces are the same, there could well be some fairly significant differences hardware-wise between the H901 and H961N. The two that I know are really close are the H961N (Hong Kong) and H962, if the kernel sources are identical then there isn't much difference between the two.
On the flip side though, there could be enough similarity to flash the H901's bootloader onto another device. The bootloader wouldn't need to worry about how any of the radio bits work, just avoid touching them.
DarkestSpawn said:
I'm so glad I didn't do this attempt yet. Just remembered I gave my backup phone away so I have nothing to fall back on if this fails. If no one tries this before I get it back I will try.
Click to expand...
Click to collapse
Please do report if you do this. Anyone else out there who is reading, we'd love to hear from you if you try this. While I hope you succeed, failure could well occur. Could you report what device you're thinking of trying this on?
There is a tool from Qualcomm which can allow you to write to the flash before the device boots. If your try fails, that tool could be used to write back what is "supposed" to be there and hopefully you won't have a complete brick. A simpler solution might be to use that tool to simply overwrite your device's bootloader with the H901 bootloader. Note there are 2 copies of the bootloader on the H962 and likely other devices and you'd need to get both. I imagine there are several, but here is one tool for extracting the KDZ files (my goal is to be able to construct modified KDZ files, but I haven't analyzed things enough yet, will likely take some time).
EDIT: What look to be the bootloader areas in the H901, H961N and H962 KDZ files appear to be at the same offsets and the same sizes. I cannot be certain, but this might very well be a workable strategy.
EDIT2: If someone does this, it may be helpful to know which H901BK firmware version you use. The known KDZ file is for 20c, so it may be handy to keep links to that. Once you've done the process, it would be helpful for you to dump copies of all the block devices on the phone. Knowing which one(s) have changed could lead us to how LG's bootloader marks a device as unlocked, leading to easier methods of unlocking (hmm, really need a binary diff utility).

emdroidle said:
Even though many of the pieces are the same, there could well be some fairly significant differences hardware-wise between the H901 and H961N. The two that I know are really close are the H961N (Hong Kong) and H962, if the kernel sources are identical then there isn't much difference between the two.
On the flip side though, there could be enough similarity to flash the H901's bootloader onto another device. The bootloader wouldn't need to worry about how any of the radio bits work, just avoid touching them.
Please do report if you do this. Anyone else out there who is reading, we'd love to hear from you if you try this. While I hope you succeed, failure could well occur. Could you report what device you're thinking of trying this on?
There is a tool from Qualcomm which can allow you to write to the flash before the device boots. If your try fails, that tool could be used to write back what is "supposed" to be there and hopefully you won't have a complete brick. A simpler solution might be to use that tool to simply overwrite your device's bootloader with the H901 bootloader. Note there are 2 copies of the bootloader on the H962 and likely other devices and you'd need to get both. I imagine there are several, but here is one tool for extracting the KDZ files (my goal is to be able to construct modified KDZ files, but I haven't analyzed things enough yet, will likely take some time).
EDIT: What look to be the bootloader areas in the H901, H961N and H962 KDZ files appear to be at the same offsets and the same sizes. I cannot be certain, but this might very well be a workable strategy.
EDIT2: If someone does this, it may be helpful to know which H901BK firmware version you use. The known KDZ file is for 20c, so it may be handy to keep links to that. Once you've done the process, it would be helpful for you to dump copies of all the block devices on the phone. Knowing which one(s) have changed could lead us to how LG's bootloader marks a device as unlocked, leading to easier methods of unlocking (hmm, really need a binary diff utility).
Click to expand...
Click to collapse
I think the only worry of trying this method is a complete hard brick. As you have mentioned, any qualcomm phone has a recovery mode and i guess it should be the "Qualcomm HS-USB QDLoader 9008" mode.
I have searched some information and turn out there are two 9008 mode. It depends on whether the phone messed with Qualcomm’s stuffs, if not, then the phone will enter the "new 9008 mode" and it can let you recover the phone easily by a backup emmc image. If it is, then the phone will enter the "old 9008 mode" and it required specific files and "programmer", however, file suitable for msm8992 hasn't been discovered. Therefore, if this method brick the phone into old 9008 mode, no solution at all.
The information i have refered to, don't know if it is correct:
http://www.droidsavvy.com/unbrick-qualcomm-mobiles/
EDIT: The ro.expect.recovery_id should be "0x9260d50f08bef4a761309001fe20e5ab59508e78000000000000000000000000" (if you try it, double check by yourself)
some people said that they bricked the phone because of typing it incorrectly, but i don't know whether it is true or not

I have asked the people who bricked their phones from trying this method. It seems that they really made a typo on ro.expect.recovery_id and cause brick.
Also, i am pretty sure that those phones have gotten into the "old 9008 mode", therefore, "rawprogram0.xml, patch0.xml and prog_emmc_firehose_8992.mbn" are required for using QPST the fix the hard brick.
However, no suitable prog_emmc_firehose_8992.mbn for V10 has been discovered on the internet (even for the G4).

Personally, I injected the H901 aboot into an H962 DZ and flashed it onto my device a few months ago.
Long story made short, it was completely bricked, even without 9008 mode. I recommend you guys to be cautious with this method.
Edit: As I can understand Chinese, I'm currently looking into the tutorial.

ivangundampc said:
I think the only worry of trying this method is a complete hard brick. As you have mentioned, any qualcomm phone has a recovery mode and i guess it should be the "Qualcomm HS-USB QDLoader 9008" mode.
I have searched some information and turn out there are two 9008 mode. It depends on whether the phone messed with Qualcomm’s stuffs, if not, then the phone will enter the "new 9008 mode" and it can let you recover the phone easily by a backup emmc image. If it is, then the phone will enter the "old 9008 mode" and it required specific files and "programmer", however, file suitable for msm8992 hasn't been discovered. Therefore, if this method brick the phone into old 9008 mode, no solution at all.
The information i have refered to, don't know if it is correct:
http://www.droidsavvy.com/unbrick-qualcomm-mobiles/
Click to expand...
Click to collapse
Useful, though I cannot speak to the reliability of that information. A different source has a tool they say comes from Qualcomm, which may be more reliable with newer devices. Please note, this is a source of claims, I don't know how reliable they are (they also don't provide much detail on the limits of the tool).
WillyPillow said:
Personally, I injected the H901 aboot into an H962 DZ and flashed it onto my device a few months ago.
Long story made short, it was completely bricked, even without 9008 mode. I recommend you guys to be cautious with this method.
Edit: As I can understand Chinese, I'm currently looking into the tutorial.
Click to expand...
Click to collapse
I look forward to more detail/reports from that tutorial. Exact details would be invaluable.
I hoped that would work, but I feared the above possibility. The problem is which portions of the flash image sign which other portions of the image, and how many different keys does LG use? Your observation seems to suggest either the key used for signing the H901 aboot was not honored by the rest of the H962 firmware, or the key used for signing the H962 kernel wasn't honored by the non-unlocked H901 aboot (or both).
If the former case, then which are the pieces prior to aboot and can only those pieces be transplanted from a H901 while still preserving the dual-SIM functionality of the H962 (and H961N)? If the latter case, then I suspect you merely need to run a H901 kernel long enough to unlock the bootloader, then you can put back the H962 kernel and run that with the unlocked bootloader.
The other question is, which portions of the data unlock the bootloader? Is it a small change to the aboot portion? Is it changes elsewhere? Can those changes be isolated from the rest of the H901 firmware?
Just in case you didn't notice, I've got lots of questions. I hope I can figure out answers to some, but others I may not be able to answer. I'm currently targeting the kdztools portion.

@emdroidle
TBH I don't see anything not mentioned already. Basically the process is just
Flash 5.1 rooted -> modify build.prop -> flash H901 KDZ
Personally, I'm not going to do more risky experiments since I already RMA'd my last hard brick
Also, you might want to use IDA to take a look at aboot, which is basically an ELF binary. I had been doing that, but stopped after the brick.

WillyPillow said:
@emdroidle
TBH I don't see anything not mentioned already. Basically the process is just
Flash 5.1 rooted -> modify build.prop -> flash H901 KDZ
Personally, I'm not going to do more risky experiments since I already RMA'd my last hard brick
Also, you might want to use IDA to take a look at aboot, which is basically an ELF binary. I had been doing that, but stopped after the brick.
Click to expand...
Click to collapse
I understand. You're in a better position since LG will honor the warranty on your H962. They're a bit tougher if you get one outside Taiwan.
I was fearing we would have to take that approach. Worse, it looks like the firmware updates change aboot, which suggests settling on one version and trying to crack that is best. I wanted to try Plasma, but IDA is likely far enough ahead to beat Plasma. I'm just glad IDA has a Linux version.

WillyPillow said:
Personally, I injected the H901 aboot into an H962 DZ and flashed it onto my device a few months ago.
Long story made short, it was completely bricked, even without 9008 mode. I recommend you guys to be cautious with this method.
Click to expand...
Click to collapse
After some thought, I realized I should ask for some detail about the failed process you used for this. Did you flash both the aboot and abootbak slices? (/dev/mmcblock0p9 and /dev/mmcblock0p15 if I recall correctly)
If you flashed only aboot and ended up bricked, this seems to suggest it did in fact successfully execute the H901BK aboot, but the aboot decided the signature on boot was incorrect and halted. In this scenario if the portion before aboot had decided aboot had a bad signature, then it should have restored abootbak, which likely would have successfully booted the H962 kernel.
If you flashed both aboot and abootbak, this suggests the portion before aboot decided aboot's signature was wrong and it halted there. This doesn't rule out it successfully executing aboot and aboot deciding boot had the wrong signature, but it makes that less likely.
Hate to say it, but flashing only aboot doesn't really give us much information on the likelihood of flashing a full H901BK image onto a H962 being successful or not. The problem is there could be signatures in many places and any one of those could fail yet reproducing the original scenario would work perfectly.

emdroidle said:
After some thought, I realized I should ask for some detail about the failed process you used for this. Did you flash both the aboot and abootbak slices? (/dev/mmcblock0p9 and /dev/mmcblock0p15 if I recall correctly)
If you flashed only aboot and ended up bricked, this seems to suggest it did in fact successfully execute the H901BK aboot, but the aboot decided the signature on boot was incorrect and halted. In this scenario if the portion before aboot had decided aboot had a bad signature, then it should have restored abootbak, which likely would have successfully booted the H962 kernel.
If you flashed both aboot and abootbak, this suggests the portion before aboot decided aboot's signature was wrong and it halted there. This doesn't rule out it successfully executing aboot and aboot deciding boot had the wrong signature, but it makes that less likely.
Hate to say it, but flashing only aboot doesn't really give us much information on the likelihood of flashing a full H901BK image onto a H962 being successful or not. The problem is there could be signatures in many places and any one of those could fail yet reproducing the original scenario would work perfectly.
Click to expand...
Click to collapse
Hmm, I've never thought this deep. I was just like "Sxxt, my phone bricked! Must be a bad signature somwhere..." and stopped messing around with it
To answer your question, I only flashed aboot, without anything else. And for the details of the brick, you can't even see the "powered by Android" bootloader screen. The device just viberates if you want to turn it on. The only way to make the screen display something is remove the battery and connect it to a computer, for which a "no battery" icon is showed. So my guess then was the aboot signature was invalidated. But now you reminded me the existance of abootbak...
I'll do some research and thinking right now

WillyPillow said:
Hmm, I've never thought this deep. I was just like "Sxxt, my phone bricked! Must be a bad signature somwhere..." and stopped messing around with it
To answer your question, I only flashed aboot, without anything else. And for the details of the brick, you can't even see the "powered by Android" bootloader screen. The device just viberates if you want to turn it on. The only way to make the screen display something is remove the battery and connect it to a computer, for which a "no battery" icon is showed. So my guess then was the aboot signature was invalidated. But now you reminded me the existance of abootbak...
I'll do some research and thinking right now
Click to expand...
Click to collapse
Well, i think that you have bricked your phone into the "Qualcomm HS-USB QDLoader 9008" mode
The phone should be able to fix if you can see "Qualcomm MMC Storage USB Device" in "Devices Manager" when the phone is connecting to the computer.

WillyPillow said:
Hmm, I've never thought this deep. I was just like "Sxxt, my phone bricked! Must be a bad signature somwhere..." and stopped messing around with it
Click to expand...
Click to collapse
I was thinking about it, since I would very much like to somehow unlock the bootloader. While this way may or may not be tweaked to work, it does sound plausible. Analyzing failures can be very valuable.
WillyPillow said:
To answer your question, I only flashed aboot, without anything else. And for the details of the brick, you can't even see the "powered by Android" bootloader screen. The device just viberates if you want to turn it on. The only way to make the screen display something is remove the battery and connect it to a computer, for which a "no battery" icon is showed. So my guess then was the aboot signature was invalidated. But now you reminded me the existance of abootbak...
Click to expand...
Click to collapse
So this may suggest aboot successfully executed, but found a mismatched signature and halted. At which point, flashing the H901BK aboot and boot may be enough to make this work. This may though also require the H901BK recovery image. I do not know where the unlock process actually does its magic, so part of it could be in recovery.
I'd love to hear if you can get it to be successful.

Two threads relevant to this topic have shown up.
First, apparently someone somehow managed to accidentally flash a H901 firmware onto a H960A. That person was looking for help with restoring their device, but it leaves me hopeful this method could in fact work on other devices. Most likely you'd end up with a mix of some portions of the flash being copied from a H901 and some from whatever your phone is normally supposed to run, but this does confirm it is possible to run H901 firmware on other devices.
Second, a method has been found to recover devices from Qualcomm 9008 mode. This is big news since it greatly lessens the danger of a bad flash. Problem is it requires root on the phone to generate the initial image, though I suspect the images produced by my kdztools may well work for the job too.

I very much want to unlock the bootloader of my device, so I'm still doing research trying to estimate how plausible this method is. At this point there are enough reports of wrong V10 device images not being fatal to other V10-type devices for me to consider this method "likely".
Examining KDZ files for several devices, there is quite a bit of overlap between device images. There are 9 slices though which seem to warrant special attention based upon them having backup copies. These are named "sbl1", "pmic", "hyp", "tz", "rpm", "aboot", "sdi", and "raw_resources".
My guess is install a H901 image, do `fastboot oem unlock` and then you can copy everything aside these slices from your original device. My concern is these may need to remain the H901 versions in order to remain unlocked (unless all V10 devices share the unlock method, which may or may not be the case).
It may also work to use my KDZ Tools to copy the PrimaryGPT and BackupGPT areas from the target device onto a H901 image, at which point the process could be done without even needing a factory reset!
I'm pretty sure "sbl1"/"sbl1bak" are the first-stage bootloader. All the others aside from "raw_resources" look to be ELF executables.
Open request to Qualcomm here, could you please make your chips either alternate between trying to boot off of "sbl1" and "sbl1bak" (a single MRAM or PCRAM cell should take too much space, should it?), or else make them randomly choose between booting off them upon power-on? Too often one or the other gets corrupted in such a way that booting fails, but either isn't so corrupt to trigger them to try the backup, or else the primary is so badly damaged it is unable to try the backup. Alternating (and passing to the Linux kernel which one it successfully booted off of!) would greatly increase the chances of successful recovery without specialized tools.

Wiki + Likelyhood evaluation
Having examined the situation enough, I'm pretty sure this method should work. Experimentation though is risky.
I'm now working on creating 2 software tools for this project. One is a simple tool to remark the device a KDZ is for. This is pretty simple and the reports are, once this is done LGUP will happily flash a KDZ onto other devices. The second goal is a tool for modifying the GPT afterwords. While the H901 has a GPT similar to other V10s, it isn't quite identical. Of major note, many other devices have a /cust partition which has some extra software.
These two tools may actually be unnecessary. My KDZ Tools expose all of the data in an inconvenient, but workable format. The KDZ Tools can also be used to replace the GPT for the H901 with a GPT from another device, and they also expose the areas which mark which device a KDZ is for. Problem with using the KDZ Tools for this is there is what looks to be an extra checksum, and I've got no idea whether it covers the GPT (I hope not, but...).
I'm now looking to create the above two tools on GitHub, the LGE Tools. Alas, what may be more valuable is the Wiki on GitHub. I've got speculative instructions a little ways from the top. Towards the bottom I've got a list of which areas you'd need to restore from your original device. I guess I'm a bit unsure of "persist", the content is identical for my device, but the differing timestamps might trigger a flag that something has happened.
Hopefully we can get some testers who can risk needing to RMA their devices (I hope they don't need to, but this IS risky).

emdroidle said:
Having examined the situation enough, I'm pretty sure this method should work. Experimentation though is risky.
I'm now working on creating 2 software tools for this project. One is a simple tool to remark the device a KDZ is for. This is pretty simple and the reports are, once this is done LGUP will happily flash a KDZ onto other devices. The second goal is a tool for modifying the GPT afterwords. While the H901 has a GPT similar to other V10s, it isn't quite identical. Of major note, many other devices have a /cust partition which has some extra software.
These two tools may actually be unnecessary. My KDZ Tools expose all of the data in an inconvenient, but workable format. The KDZ Tools can also be used to replace the GPT for the H901 with a GPT from another device, and they also expose the areas which mark which device a KDZ is for. Problem with using the KDZ Tools for this is there is what looks to be an extra checksum, and I've got no idea whether it covers the GPT (I hope not, but...).
I'm now looking to create the above two tools on GitHub, the LGE Tools. Alas, what may be more valuable is the Wiki on GitHub. I've got speculative instructions a little ways from the top. Towards the bottom I've got a list of which areas you'd need to restore from your original device. I guess I'm a bit unsure of "persist", the content is identical for my device, but the differing timestamps might trigger a flag that something has happened.
Hopefully we can get some testers who can risk needing to RMA their devices (I hope they don't need to, but this IS risky).
Click to expand...
Click to collapse
Wow, i am very surprised that you are still working on this method! You have really paid a lot of effort on it!
After taking a look on your works, i really think that this method may really works to help us to unlock the bootloader.
In fact, the T-Mobile variant of both G5 and V20 have bootloader unlocked and so other version of G5 and V20 may also be able to unlock their booloader through a method like this, therefore, I think we should be able to draw more attention (more devs?) on studying this method.

General Bootloader unlock token for T-Mobile variant now available

Just a quick heads-up.
unlock token - OnePlus (United States)
www.oneplus.com
By the way, to root without readily available stock firmware, first unlock bootloader, then boot a pre-rooted GSI with DSU Sideloader, pull stock boot partition from there, and finally patch/flash it. This applies to the Open variant as well.

AndyYan said:
Just a quick heads-up.
unlock token - OnePlus (United States)
www.oneplus.com
By the way, to root without readily available stock firmware, first unlock bootloader, then boot a pre-rooted GSI with DSU Sideloader, pull stock boot partition from there, and finally patch/flash it. This applies to the Open variant as well.
Click to expand...
Click to collapse
Tried to unlock but apparentpy my device only has 7 digits in the serial number which keeps me from being able to use the website to request the unlock code.
I used the debloat script I found on n200 threads to get oem unlock on option. T-Mobile variant

PsYk0n4uT said:
Tried to unlock but apparentpy my device only has 7 digits in the serial number which keeps me from being able to use the website to request the unlock code.
I used the debloat script I found on n200 threads to get oem unlock on option. T-Mobile variant
Click to expand...
Click to collapse
Try prepending 0s?

Well. I was thinking that doing that would make the unlock token they give me different from what the phone would be expecting

PsYk0n4uT said:
Well. I was thinking that doing that would make the unlock token they give me different from what the phone would be expecting
Click to expand...
Click to collapse
Tried adding zero on front and back of serial it just tells me invalid serial

PsYk0n4uT said:
Tried adding zero on front and back of serial it just tells me invalid serial
Click to expand...
Click to collapse
Chatting with OnePlus hasn't yielded anything so far

Just a tip, because in my infinite forgetfulness I wasted an hour last night trying to figure out why I was getting the error, fastboot could not open target HAL.
Remember that you must request the unlock code from fastboot, not fastbootd. Which is what you will boot into if you issue adb reboot fastboot.
So here's a quick step by step.
1.Enable usb debugging. 2. Connect your device and allow access for the computer. My device asks if I want it to charge or transfer files. Select transfer files/Android auto and then use adb start-server. May have to unplug the USB cable and reconnect. Select "always allow this device/PC".
3. Issue "adb devices" to make sure your connected.it should list your device by it's serial number. If not then try unplugging the device and revoke adb authorizations in dev options and toggle USB debugging off and back on, may even need to reboot the device to get it to connect after doing this.
4. If your device is listed under devices go ahead and issue "adb reboot fastboot"
5. Once rebooted issue "fastboot devices" and make sure the device is listed again.(If not listed make sure you have your driver's installed correctly and fastboot is installed correctly, may need to install Android SDK into same folder as fastboot)
6.You can select English or whatever language if you want but it doesn't seem necessary.You are in fastbootd mode you will see if you DO select a language.
So from here issue"fastboot reboot bootloader" device will reboot and you will have scrollable option at the top beginning with a big green START at the top. This is regular fastboot And where you wanna be to get your unlock code for submitting to Oppo for your unlock token.
7. Issue "fastboot oem get_unlock_code"
8. It should return the info you need, you will also need your IMEI number when submitting so be sure to copy that down.
you can copy and paste the unlock code into notepad or Word and delete out the extra stuff so your left with just the two lines of your unlock code as one single contiguous string of numbers.
8. Go to the link listed by OP and submit the required info. And wait for what seems like forever.
ADB/Fastboot commands-quick recap.
1. adb reboot fastboot
2. fastboot reboot bootloader
3. fastboot oem get_unlock_code

PsYk0n4uT said:
ADB/Fastboot commands-quick recap.
1. adb reboot fastboot
2. fastboot reboot bootloader
3. fastboot oem get_unlock_code
Click to expand...
Click to collapse
Simply "adb reboot bootloader". You won't need fastbootd until GSIs (which I already did ofc).

Thanks, definitely a quicker way to get to fastboot. I guess I wasn't sure if you could reboot directly. Seems maybe I was confusing an older device where you had to reboot to fastboot then "fastboot reboot fastboot" to get to fastbootd for a whole different reason.
This one goes directly to fastbootd when you "adb reboot fastboot"
Nice catch.

with this particular model in scope, what do either of you guys suggest I do if I have gottne the age old bricked message "destroyed boot/recovery image"".. I've tried the MSMTool route and cna't get it to register under Device Manager with the Qualcomm drivers.. It's highly upsetting..

I'm not really sure to be honest, this is my first OnePlus device and just trying to contribute anything I can to get the N20 section up and going as I make progress with the device.
Just a quick search though turns up this and maybe it could be of use if you can still access the bootloader.
the current image(boot/recovery) have been destroyed
I updated my oneplus 8t to KB2005_11.C.11 (OOS 12 ) by first booting to twrp-3.6.1_11-0-kebab.img and then flashed the KB2005_11_C_OTA_1100_all_362b9b_10100001.zip. After the upgrade I had no mobile data on t-mobile and had Volte instead of 5g...
forum.xda-developers.com
Someone mentions extracting the boot.img from stock image and flashing it. I would imagine it should work for you if the stock firmware can be found and circumstances are similar. Maybe at least a start. Wish I could be of more help, maybe someone else can chime in that knows more.
Try Linux, maybe a live dist. if your on a windows machine that won't recognize it just to get it into a state that you can work with it again.
Just an idea, I don't want to steer you wrong as i still have a lot to learn

DrScrad said:
with this particular model in scope, what do either of you guys suggest I do if I have gottne the age old bricked message "destroyed boot/recovery image"".. I've tried the MSMTool route and cna't get it to register under Device Manager with the Qualcomm drivers.. It's highly upsettinghav
Click to expand...
Click to collapse
DrScrad said:
with this particular model in scope, what do either of you guys suggest I do if I have gottne the age old bricked message "destroyed boot/recovery image"".. I've tried the MSMTool route and cna't get it to register under Device Manager with the Qualcomm drivers.. It's highly upsetting..
Click to expand...
Click to collapse
I want to try and help but I'm so new it's sketchy I don't want to say something and get bashed

Please feel free to comment. Don't worry about the trolls. We would love to have you to be part of this conversation. If you have suggestions just post them, and if your unsure about anything just mention that you are. It's a great way to learn. Don't worry about negative feedback, take it as constructive criticism. You may find that the feedback can clear up many questions and/or misconceptions. You never know how your dialogue with other members could help someone else in the future. These forums are here to document all of it just for that purpose. We are all here to learn or help others who want to learn. Though this account is only a year old I have been around these forums on and off for many years and I learn something each and every time I come in search of wisdom. I'm by no means an expert but I find that others benefit from my questions and answer just as much as I have over the years.

Fyi according to a recently made friend who also had the 7 digit serial issue, they were told by OnePlus their dev team is working on an OTA update that will resolve the serial number issues. I'm not sure how that's going to work but I saw the email between them and Oppo support

I guess this must be a widespread issue that they feel is cheaper to invest the amount of money it takes for r&d to come up with a fix than it was to replace a few devices or attempt to do remote repairs.
But this also makes me wonder what avenue they will take to correct the issue.
Also I wonder if someone with the right skillset could gather enough bootloader unlock codes along with the unlock tokens, serial, IMEI, pcba etc.. maybe the algorithm their using to generate the codes could be broken. I'm no crypto expert or math genius either, but if we have the variables to the equation minus one but have the answer, isn't this pretty simple almost pre-algebra?
I mean I guess their not worried about enough people being brave enough to give out sensitive info like that. But maybe Im just ignorant of the complexity of these algorithms.
64 digit key on one end

T-Mobile bought sprint and they have T-Mobile sims no. But I understand that sprint is still a somewhat seperate company (tried to buy a T-Mobile phone and it would not activate on my sprint account. So I bought this from the sprint side of the T-Mobile site so I knew it would work but I assume this is a sprint phone and not a T-Mobile phone so this method would not work.
Can anyone confirm this?

PsYk0n4uT said:
Please feel free to comment. Don't worry about the trolls. We would love to have you to be part of this conversation. If you have suggestions just post them, and if your unsure about anything just mention that you are. It's a great way to learn. Don't worry about negative feedback, take it as constructive criticism. You may find that the feedback can clear up many questions and/or misconceptions. You never know how your dialogue with other members could help someone else in the future. These forums are here to document all of it just for that purpose. We are all here to learn or help others who want to learn. Though this account is only a year old I have been around these forums on and off for many years and I learn something each and every time I come in search of wisdom. I'm by no means an expert but I find that others benefit from my questions and answer just as much as I have over the years.
Click to expand...
Click to collapse
okay peep theres a way i put my oneplus into efu mode, hold both vol up and down then put usb c in continue to hold u should hear PC recognize it

So, before i do it, would deleting the modemst1/modemst2 partitions still let me bypass the t-mobile sim lock and let me unlock the phone like it did on the old oneplus phones?

Flashed a patched boot.img and lost modems. Anyone willing to post the modems? Are they device specific like a device partition?

Sim locked and trying to recover. No radios are working

Question This is just a theory but...

How possible would it be to change a slot from A to B using an edl tool like https://github.com/bkerler/edl ? How would this be used? or, for example, what command should be used? Are there any other methods of application? just including an EDL method? Because simply stating android has two slots one may be bricked and deleted of info and another may have a working slot and yes (I am ware fastboot can do this) but this is for those who cannot access it on a certain slot.

oneplushypergaming said:
How possible would it be to change a slot from A to B using an edl tool like https://github.com/bkerler/edl ? How would this be used? or, for example, what command should be used? Are there any other methods of application? just including an EDL method? Because simply stating android has two slots one may be bricked and deleted of info and another may have a working slot and yes (I am ware fastboot can do this) but this is for those who cannot access it on a certain slot.
Click to expand...
Click to collapse
If you're asking specifically about the 10T the answer is no. Authentication is required to use EDL on this device and bkerler's implementation doesn't support this kind of authentication. However, if you had a device with unprotected EDL mode you could theoretically alter the current slot if it's saved on a disk partition.

TheNewHEROBRINE said:
If you're asking specifically about the 10T the answer is no. Authentication is required to use EDL on this device and bkerler's implementation doesn't support this kind of authentication. However, if you had a device with unprotected EDL mode you could theoretically alter the current slot if it's saved on a disk partition.
Click to expand...
Click to collapse
I see. So, in other words, it is simply impossible for any user to obtain it without authentication, which sucks a lot. It's unfortunate to see such a dependable company resort to this, even though they claim to be very user-friendly. can't argue with their pricing though, it was never about pricing for me. It was always about "if you break it, you can fix it in a single click, but all that has changed. thank you for your support.

oneplushypergaming said:
How possible would it be to change a slot from A to B using an edl tool like https://github.com/bkerler/edl ? How would this be used? or, for example, what command should be used? Are there any other methods of application? just including an EDL method? Because simply stating android has two slots one may be bricked and deleted of info and another may have a working slot and yes (I am ware fastboot can do this) but this is for those who cannot access it on a certain slot.
Click to expand...
Click to collapse
You don't know how to use that guy's tool there's many people who have made videos about it I suggest you go watch your video on it and tools not that complicated but it is complex if you don't have prior tech skill

AkayamiShurui said:
You don't know how to use that guy's tool there's many people who have made videos about it I suggest you go watch your video on it and tools not that complicated but it is complex if you don't have prior tech skill
Click to expand...
Click to collapse
I've used this tool on phones like the Oneplus 7t, motorola g8 power, LG velvet and 7Pro, as well as other msm tools, and I'm very intimately acquainted with 9008 I understand how to utilize it. I was only inquiring if it could be used on the 10t.

Which slot is active is saved in the misc partition, beyond the usual reboot command.
I've not yet had an A/B device, so I can't say more.
With non-A/B you can erase the misc partition without a problem.
I don't know how bad it would be if you erased misc on an A/B.
I presume that it would default to A?

Renate said:
Which slot is active is saved in the misc partition, beyond the usual reboot command.
I've not yet had an A/B device, so I can't say more.
With non-A/B you can erase the misc partition without a problem.
I don't know how bad it would be if you erased misc on an A/B.
I presume that it would default to A?
Click to expand...
Click to collapse
well.. you'd think that would happen because it's the most logical way to put it, but in my experience, whenever the partition is erased, it always stays on the slot, leaving the overall device bricked sadly, or depending on what in the misc is erased, you may just be lucky to get boot loops or booted into a constant bootloader, which can fortunately be solved by fastboot enhanced. at least for oneplus devices and by fast boot you can just simply switch to the desired working slot.

Better Mobile App

welcome