Step-by-step instructions for reproducing this work will be in the second post.
Regardless of anyone's opinion about it being a good idea, some people prefer to run their device with a locked bootloader, whether for security, to avoid the 5-second wait on boot, or for some other reason. Unfortunately, it seems to be common knowledge around these forums that you cannot re-lock your bootloader on this device after installing a custom firmware or recovery, or at least you will "brick" your device by trying. After being re-locked, the bootloader appears to load your custom boot.img/recovery.img, fail to verify it (or crash in the process), and immediately reboot. So consensus is that everyone is stuck with the 5-second warning screen.
However, the blog post releasing the bootloader vulnerabilities shows proof (see the image halfway down the page) that at least one person was able to flash a modified boot image and still be able to boot with a locked bootloader. Taking advantage of the vulnerabilities in the OOS 4.0.1 bootloader described on that page, I did some research into why he was able to boot (albeit still with a warning) while everyone else gets stuck in a loop. I'll skip the process of experimentation, and go straight to the results.
The bootloader for this device is provided by Qualcomm/CAF (see https://github.com/OnePlusOSS/android/blob/bd6a70d6218dbc0e72f70740422e3dac2fdc82fb/default.xml#L32). Source is at https://source.codeaurora.org/quic/la/kernel/lk/tree/?h=LA.HB.1.3.1.c1.
The bootloader has two states, locked and unlocked. (If you read the slides linked below, you'll see that some Android bootloaders, such as Intel's, have a third "verified" state; ours does not). In the unlocked state, no verification of the boot image is performed at all, so the presence of a signature is not important. In the locked state, the bootloader expects a signature to be present just past the end of the boot image (calculated based on the lengths in the header), following the scheme described in this LWN article. Additional documentation from Qualcomm is here.
If the signature is valid, the device boots the kernel without warning.
If the signature is invalid (does not match the kernel or is not signed by the appropriate key), the device boots with a verification warning like the one seen here.
If the signature is missing (currently the case on all custom kernels and recoveries), the device immediately reboots.
When built from source, the signature is added by the boot_signer utility in system/extras/verity. This utility gets called from build/core/Makefile when PRODUCT_SUPPORTS_BOOT_SIGNER is set for the device. Normally this is enabled from build/target/product/verity.mk when dm-verity is enabled for the device, like it is on the stock firmware. However, since custom ROMs disable dm-verity, they end up disabling boot.img signing as well.
Thus, the purpose of this thread is to encourage custom ROM, kernel, and recovery developers to enable boot.img signing in their device tree, or to manually run boot_signer on their generated boot.img files, or even simply concatenate a valid (that is, parseable by the bootloader, while not cryptographically correct) signature to the end of the file. Note that for AnyKernel-like packages that run mkbootimg on the device, this will have to be done afterward. Even if developers do not start adding signatures to kernels they release, it should be possible to create a flashable zip that fake-signs any installed custom kernel, that way you can keep your bootloader locked without waiting for an update.
While this step will prevent bricking devices by locking the bootloader, a worthy goal in itself, it does not remove all boot delays/warnings. This should be possible by generating and flashing your own signing key to the keystore partition with fastboot, as described in the linked slides. I have not had a chance yet to try this. However, the current bootloader (as of OOS 4.0.3) is vulnerable to the bug fixed here. This means that if the size of the boot.img does not match the size reported in the signature, the bootloader does not attempt to verify it cryptographically and simply returns success. This allows custom kernels/recoveries to boot without any warning or prompt at all. This is how I have my device working right now.
Unfortunately, this is likely a very bad idea going forward. The device appears to use a different flash storage encryption key based on what security state the bootloader is in. This explains problems where people "without encryption" get prompted for a password after first installing TWRP, and threads such as this one. Once the bug is fixed, the bootloader will be in a red state (invalid signature) or at least a yellow state (non-OEM key) and will likely use the "untrusted" key, forcing everyone who uses this trick to wipe their data after updating the bootloader.
Documentation:
Android Verified Boot: https://source.android.com/security/verifiedboot/verified-boot.html
Android Keystore: https://developer.android.com/studio/publish/app-signing.html
Android Verified Boot: https://lwn.net/Articles/638627/
Qualcomm Bootloader: https://developer.qualcomm.com/download/db410c/little-kernel-boot-loader-overview.pdf
WARNING: Before playing around with any of this, enable OEM unlocking in Developer options and downgrade to the OOS 4.0.1 bootloader, or you may lock yourself out permanently!
How to extract the signature from a stock boot.img:
Find the end of the Android boot image data in the file. Use unpackbootimg (e.g. from LineageOS) and add up the size of the extracted "zImage" and "ramdisk.gz" files, or read the sizes of the kernel and initramfs directly from the boot image header. Round up each of these sizes to a multiple of 4096, since each section of the boot image data is always a multiple of the page size.
Add one page (4096 bytes) for the header at the beginning of the file.
The next bytes immediately following that will be the signature. From the documentation/bootloader source, it can vary in length, but OnePlus's signatures are around 1320 bytes long. The size of the signature is a variable-length integer starting with the second byte of the signature. In short, take 256*sig[2]+sig[3]+4 as full length of the signature data.
How to fool the current bootloader and bypass all warnings:
Concatenate any valid-format signature to the end of your boot image.
Flash your boot image with fastboot or in TWRP.
Profit.
Note that this method works for any modified kernel: TWRP, stock with Super-SU, LineageOS, franco.kernel, etc. (Well, almost any. The signature records the size of the boot image in it, and if that happens to match, you will get a warning, but it will still boot.)
The attached zip file will perform this operation on the currently-installed boot image.
I have added a zipfile (sha256sum c4a15c0d3d6f8efa4c4e14196b48790cdb86f6110bcb51e92dbfce32c959db11) to the second post that will "sign" the currently-installed boot image using the certificate from the OP3T beta 3 stock kernel (though any one will work). It is intended to be flashed last after installing your ROM or kernel. Unfortunately, you will have to do this after every update. It will be obvious if you forget, but the reboot cycle won't hurt anything (just use the button combo to get back to recovery).
I can't attach a fixed recovery because it's too large, but you can modify the zip to sign the recovery partition (the path at the top of the script). Of course, you would have to do this before locking your bootloader.
smaeul said:
How to extract the signature ....
... add up the size of ...
.. add one page (4096 bytes) ... then round up ...
.. The next bytes immediately following that will be the signature.
... OnePlus's signatures are 1320 bytes long. ...
... note that this method works for any modified kernel:
Click to expand...
Click to collapse
The above maths is fine for the boot.img of OP3 but the recovery.img leaves 5420 bytes (both are attached). When I compared these trailing 1320 and 5420 bytes, they seemed similar but the 5420 bytes extracted from recovery.img have a lot of trailing zeros. What explains this? (PS: I used the tail command on ubuntu to extract these bytes from 4.0.3 stock boot and recovery images).
rk2612 said:
The above maths is fine for the boot.img of OP3 but the recovery.img leaves 5420 bytes (both are attached). When I compared these trailing 1320 and 5420 bytes, they seemed similar but the 5420 bytes extracted from recovery.img have a lot of trailing zeros. What explains this? (PS: I used the tail command on ubuntu to extract these bytes from 4.0.3 stock boot and recovery images).
Click to expand...
Click to collapse
The math I provided earlier is also only right when the kernel or ramdisk happens to be a multiple of 4096 bytes. The correct algorithm for the offset (and I'll update the second post) is round_to_4096(kernel)+round_to_4096(ramdisk)+4096.
The size of the signature is actually encoded at the beginning of the DER data, as a variable-length integer (see the source). Pasted below is the first 64 bytes of the signature from the stock recovery. You can see that the first byte matches what the bootloader expects (line 106 of the code). The second byte tells us the signature length is two bytes long. The next two bytes are 0x0528 (hexadecimal), which is 1320 when converted to decimal. So those 4 bytes + the next 1320 are the signature. So the remaining 4096 bytes (exactly one flash page) is something else. It could be junk or some other (OnePlus-specific?) metadata.
Code:
00000000 30 82 05 28 02 01 01 30 82 03 fd 30 82 02 e5 a0 |0..(...0...0....|
00000010 03 02 01 02 02 09 00 97 0f 98 39 09 aa 89 49 30 |..........9...I0|
00000020 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 81 |...*.H........0.|
00000030 94 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 13 |.1.0...U....US1.|
This matches what we expect from the boot.img, which has a signature that is 4+0x0524 = 1320 bytes long, and that is exactly the length of the extra data after the ramdisk. When we have the whole signature, we can use openssl to decode it:
Code:
openssl asn1parse -i -in signature.der -inform der
Oh, and I'll add this to the OP, I found the official Android description about how this all works: https://source.android.com/security/verifiedboot/verified-boot.html
smaeul said:
...
This matches what we expect from the boot.img, which has a signature that is 4+0x0524 = 1320 bytes long, and that is exactly the length of the extra data after the ramdisk. ...
Click to expand...
Click to collapse
But then comparing these 1320 bytes from recovery and boot images, aren't they different?
rk2612 said:
But then comparing these 1320 bytes from recovery and boot images, aren't they different?
Click to expand...
Click to collapse
Yes, of course. The last 256 bytes of the signature are an encrypted hash of the boot image. The bootloader is supposed to 1) calculate a hash of the boot image and 2) decrypt the hash in the signature using the public key from the certificate (also in the signature), and then verify that the two hashes match. The reason that we can just throw these existing signatures around is that, when the boot image is the wrong size, the bootloader doesn't even look at the hash in the signature.
The point of what you quoted was to say that the math that tells us how many bytes there should be, matched the actual number of bytes remaining in the file, so therefore the math was reasonable. The signatures from the two files do not match. They are not even the same size (though I haven't investigated why yet). But it doesn't matter what they contain, as long as they cause the bootloader to 1) not crash and 2) trigger the bug.
smaeul said:
Yes, of course. The last 256 bytes of the signature are an encrypted hash of the boot image. The bootloader is supposed to 1) calculate a hash of the boot image and 2) decrypt the hash in the signature using the public key from the certificate (also in the signature), and then verify that the two hashes match. The reason that we can just throw these existing signatures around is that, when the boot image is the wrong size, the bootloader doesn't even look at the hash in the signature.
The point of what you quoted was to say that the math that tells us how many bytes there should be, matched the actual number of bytes remaining in the file, so therefore the math was reasonable. The signatures from the two files do not match. They are not even the same size (though I haven't investigated why yet). But it doesn't matter what they contain, as long as they cause the bootloader to 1) not crash and 2) trigger the bug.
Click to expand...
Click to collapse
Thanks. Try concatenating the 5420 bytes from the stock recovery to TWRP and see the magic!!! I was brave enough to try with a locked bootloader. .....Of course with OOS 4.0.1 bootloader. Reminds me of Bump! on LG G3. Not sure if this will work with OOS 4.0.3 bootloader.
A few other things I tried which seem weird and quite likely to be a security loophole:
1. When you unlock a bootloader, it boots back into the security warning screen. At that time, the data partition is still not wiped!
2. The data partition is wiped when it starts to boot and goes into recovery. I think the code --wipe-data is used with a recovery script (openrecoveryscript or recovery.command) stored in cache.
3. Therefore, if a modified recovery is flashed immediately after unlocking and before it boots into recovery, then it possible to defeat the script (...can be done by either not mounting cache or by not mounting data partitions ... deleting mount points in fstab).
4. Even if an official TWRP is flashed immediately after unlocking, the data wipe does not wipe data/media as TWRP treats these wipes differently than stock recovery.
From a tigher security point of view, I would have expected fastboot to wipe the data partition rather than rely on recovery to do it. Therefore, this sounds like a security loophole but I do not have enough technical knowledge to say with full certainty as I consider myself a "cut-and-paste" developer.
And I also wonder whether this behaviour is specific to OnePlus 3 or if it is similar across all devices where bootloader can be unlocked.
rk2612 said:
Thanks. Try concatenating the 5420 bytes from the stock recovery to TWRP and see the magic!!! I was brave enough to try with a locked bootloader. .....Of course with OOS 4.0.1 bootloader. Reminds me of Bump! on LG G3. Not sure if this will work with OOS 4.0.3 bootloader.
A few other things I tried which seem weird and quite likely to be a security loophole:
1. When you unlock a bootloader, it boots back into the security warning screen. At that time, the data partition is still not wiped!
2. The data partition is wiped when it starts to boot and goes into recovery. I think the code --wipe-data is used with a recovery script (openrecoveryscript or recovery.command) stored in cache.
3. Therefore, if a modified recovery is flashed immediately after unlocking and before it boots into recovery, then it possible to defeat the script (...can be done by either not mounting cache or by not mounting data partitions ... deleting mount points in fstab).
4. Even if an official TWRP is flashed immediately after unlocking, the data wipe does not wipe data/media as TWRP treats these wipes differently than stock recovery.
From a tigher security point of view, I would have expected fastboot to wipe the data partition rather than rely on recovery to do it. Therefore, this sounds like a security loophole but I do not have enough technical knowledge to say with full certainty as I consider myself a "cut-and-paste" developer.
And I also wonder whether this behaviour is specific to OnePlus 3 or if it is similar across all devices where bootloader can be unlocked.
Click to expand...
Click to collapse
You wouldn't have to use a modified recovery. "fastboot erase cache" before booting into recovery mode should do the trick.
I'm on the latest open beta bootloader for the 3T (I haven't bothered to update since OOS 4.1.0 came out), and nothing has changed. Even if OnePlus does pull changes from Qualcomm and fix the bug, it will still boot, albeit with the warning shown here:
{
"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"
}
Ironically, according to Google's documentation, the "red boot state" shown there should force the device to turn off after the delay (prevent booting).
Further explanation of the wiping comes from Google's verified boot documentation. Search for "Binding TEE root of trust". Basically, the disk encryption key is derived from the kernel signing key and the boot verification state, in addition to your password. So when you boot an unsigned (or signed-by-somebody-else) recovery/kernel, the encryption key will be different, even for the same password. That's what causes the impossible password prompt in TWRP, and how they can implement "wiping without actually wiping" once you break dm-verity or install a custom ROM.
Of course, since the bug lets you still be in the green bootstate, that means you can keep your data from stock, locked, unrooted OOS, since the keys stay the same. So, yes, this is a huge security vulnerability, because it allows somebody to install a malicious OS without triggering a wipe. For this and other reasons, security on this phone is a joke, and there's nothing we can do about it.
smaeul said:
You wouldn't have to use a modified recovery. "fastboot erase cache" before booting into recovery mode should do the trick.
Click to expand...
Click to collapse
Somehow that didn't work me. Maybe the wipe instruction are placed into cache again after the device starts booting.
---------- Post added at 07:10 AM ---------- Previous post was at 06:35 AM ----------
smaeul said:
....So when you boot an unsigned (or signed-by-somebody-else) recovery/kernel, the encryption key will be different, even for the same password. That's what causes the impossible password prompt in TWRP, and how they can implement "wiping without actually wiping" once you break dm-verity or install a custom ROM.
...For this and other reasons, security on this phone is a joke, and there's nothing we can do about it.
Click to expand...
Click to collapse
I used the following way to get around this impossible password:
1. After unlocking, immediately flashed a modified TWRP recovery which did not mount cache.
2. Backed up system and data with TWRP on usb-otg.
3. Flashed stock recovery, which did a factory reset at next boot (...because the script to wipe data was still there).
4. Flashed TWRP at the next startup (...device is without any data).
5. Used TWRP to flash a modified boot image (...with encryptable data partition and system verify deleted in boot fstab).
6. Restored backed up system from TWRP and set up the device as a fresh device (... data is unencrypted).
7. Booted back into TWRP and restored backed up data from TWRP and wiped cache.
8. Delected the 5 lock settings files in /data/system/.
9. Booted back into device with original data unencrypted and without any impossible password!
10. Booted into fastboot and flashed stock recovery (...to enable full data wipe if the device falls into not so experienced hands).
11. Locked bootloader and used fastboot oem disable_dm_verity using OOS4.0.1 bootloader (...because I am using a modified hosts file in my system).
12. Set up passwords again after booting into device.
(...I think this works because I had file encryption rather than full device encryption).
The security warning that you refer to is still showing but the device is locked and has original data. I think the data can be encrypted back again (...because boot fstab has a flag of encryptable). And then stock boot and system images can also be flashed back again (...unless system has modifications like a modified hosts file like mine). Perhaps without system modification and with original boot, this warning will also go away but I do not want to give up on my modified hosts file as yet.
Two things that are still bugging me:
1. Is there any way to get rid of security warning (...using a properly self signed boot image rather than an invalid signature)? I'm aware that with all the security loopholes in this device / bootloader / android, that does not grant full security but all I am trying to achieve is for the device to look unmodified so that not so experienced persons who find my device believes that confidential information cannot be extracted from it.
2. If I flash either of systemless or system SuperSu before locking, the device does not boot fully and gets stuck at the rotating dots animation. BTW, I do not miss root so much on nougat as hosts file can be replaced through TWRP and data control in nougat serves as an effective firewall. But I'm still looking for flexibility in case it is needed.
Any suggestions?
smaeul said:
.....though I haven't investigated why yet...
Click to expand...
Click to collapse
The signature on an Android verifiable boot image is an ASN.1 DER-encoded message (https://source.android.com/security/verifiedboot/verified-boot.html). This can be parsed using online tools (https://lapo.it/asn1js/#30820524020...B24FF93E4ADF5F5D7D4153F794D2EE9D87422AB8A2258) to show that 1320 bytes of the boot signature comprise of a 1316 byte length sequence.
Decoding the signature of the recovery block indicates that the differences are:
1. An extra page in the end (4096 bytes) in addition to the above (as you'd already pointed out)
2. Before that, recovery signature is 4 bytes longer because "/recovery" string takes 4 extra bytes to represent compared to "/boot" string.
3. Size of the recovery image (as mentioned within the 1324 bytes) is different from boot image as well.
rk2612 said:
Somehow that didn't work me. Maybe the wipe instruction are placed into cache again after the device starts booting.
Click to expand...
Click to collapse
It may be an kernel command-line argument or on the "persist" or "misc" partition instead of inside /cache. I haven't looked into it.
rk2612 said:
The security warning that you refer to is still showing but the device is locked and has original data. I think the data can be encrypted back again (...because boot fstab has a flag of encryptable). And then stock boot and system images can also be flashed back again (...unless system has modifications like a modified hosts file like mine). Perhaps without system modification and with original boot, this warning will also go away but I do not want to give up on my modified hosts file as yet.
Two things that are still bugging me:
1. Is there any way to get rid of security warning (...using a properly self signed boot image rather than an invalid signature)? I'm aware that with all the security loopholes in this device / bootloader / android, that does not grant full security but all I am trying to achieve is for the device to look unmodified so that not so experienced persons who find my device believes that confidential information cannot be extracted from it.
2. If I flash either of systemless or system SuperSu before locking, the device does not boot fully and gets stuck at the rotating dots animation. BTW, I do not miss root so much on nougat as hosts file can be replaced through TWRP and data control in nougat serves as an effective firewall. But I'm still looking for flexibility in case it is needed.
Any suggestions?
Click to expand...
Click to collapse
Is the security warning about dm-verity, or that it cannot verify the kernel/OS? (Post an image?) If it's dm-verity, see the verified boot documentation (search for "Recovering from dm-verity errors") for how that gets reset. I don't know which way device uses, since I haven't spent much time on a dm-verity enforcing ROM/kernel. If the warning is about something else, I don't know. My device never shows any warnings except with a modified stock kernel/recovery that matches the original size.
rk2612 said:
2. Before that, recovery signature is 4 bytes longer because "/recovery" string takes 4 extra bytes to represent compared to "/boot" string.
Click to expand...
Click to collapse
Well that makes perfect sense .
smaeul said:
It may be an kernel command-line argument or on the "persist" or "misc" partition instead of inside /cache. I haven't looked into it.
Click to expand...
Click to collapse
No, I think it is in the cache as the command does not execute if a modified recovery (which does not mount cache) is used. But the command may be getting pushed from devinfo partition (where I think fastboot related status is stored).
smaeul said:
Is the security warning about dm-verity, or that it cannot verify the kernel/OS? (Post an image?) If it's dm-verity, see the verified boot documentation (search for "Recovering from dm-verity errors") for how that gets reset. I don't know which way device uses, since I haven't spent much time on a dm-verity enforcing ROM/kernel. If the warning is about something else, I don't know. My device never shows any warnings except with a modified stock kernel/recovery that matches the original size.
Click to expand...
Click to collapse
The warning is the same one as in the image that you posted. And that's because I am using a modified kernel (no forced encryption and no verify for /system) for the time being. I doubt if there is a way to get rid of that warning and keep a modified kernel or system. Also, if I go back to stock kernel and have a modified system (...not yet ready to give up on hosts file ad-blocking after so many years), then I will have to rely on the fastboot oem disable_dm_verity and that may also trigger a warning I think. No?
rk2612 said:
The warning is the same one as in the image that you posted. And that's because I am using a modified kernel (no forced encryption and no verify for /system) for the time being. I doubt if there is a way to get rid of that warning and keep a modified kernel or system. Also, if I go back to stock kernel and have a modified system (...not yet ready to give up on hosts file ad-blocking after so many years), then I will have to rely on the fastboot oem disable_dm_verity and that may also trigger a warning I think. No?
Click to expand...
Click to collapse
Are you using the stock kernel that you unpacked and repacked? And are you using the signature from the stock kernel? That's the one case where you will get that warning. Since the repacked kernel is the exact same size as the original one, the bug in the bootloader isn't triggered, and the verification fails as it should. Try using the signature from the stock recovery with your kernel and see if the warning goes away.
smaeul said:
Are you using the stock kernel that you unpacked and repacked? And are you using the signature from the stock kernel? That's the one case where you will get that warning. Since the repacked kernel is the exact same size as the original one, the bug in the bootloader isn't triggered, and the verification fails as it should. Try using the signature from the stock recovery with your kernel and see if the warning goes away.
Click to expand...
Click to collapse
I'm currently using the stock kernel modified with a modified fstab (no verify for /system and encryptable instead of forced encryption for /data). When I repacked the kernel, it came to be a slightly different size even without the signature. The warning remains ....with or without a signature (from either boot or recovery).
What triggers the warning in your case?
rk2612 said:
I'm currently using the stock kernel modified with a modified fstab (no verify for /system and encryptable instead of forced encryption for /data). When I repacked the kernel, it came to be a slightly different size even without the signature. The warning remains ....with or without a signature (from either boot or recovery).
What triggers the warning in your case?
Click to expand...
Click to collapse
I was only able to trigger the warning by unpacking and repacking the stock kernel, and appending the original signature from the same stock kernel. Any custom kernel, SuperSU rooted stock kernel, recovery kernel, etc. signed with the stock kernel signature did not produce any warning/prompt at all. This is with the bootloader from OOS 4.0.1, 4.0.3, and 4.1.0 beta 3. I haven't updated to the 4.1.0 stable yet. What is your bootloader version.
Send me your modified boot.img and I'll create a signature for it that should avoid the warning.
SOLVED
smaeul said:
I was only able to trigger the warning by unpacking and repacking the stock kernel, and appending the original signature from the same stock kernel. Any custom kernel, SuperSU rooted stock kernel, recovery kernel, etc. signed with the stock kernel signature did not produce any warning/prompt at all. This is with the bootloader from OOS 4.0.1, 4.0.3, and 4.1.0 beta 3. I haven't updated to the 4.1.0 stable yet. What is your bootloader version.
Send me your modified boot.img and I'll create a signature for it that should avoid the warning.
Click to expand...
Click to collapse
Thanks. I'm using bootloader 4.0.1 but have modified boot and system from 4.0.3. Modified boot image attached.
EDIT: Reading your comment again, I realize what I missed. You mention that the warning comes after by unpacking and repacking the stock kernel (with modifications, I presume). That is the case with me as well. However, I have now locked the device and if I try to flash SuperSu 2.79SR3 (systemless) now, I get into a bootloop.
SOLVED: On a hunch, I hex edited the boot signature to reduce the size mentioned after the "/boot" and made it nearly half of the original boot.img size. And it worked without throwing up any warning!!! Thanks to you for pointing out that size variation triggers the bug which causes the warning not to be displayed. The size difference needs to be (perhaps) big enough for the warning not to be triggered (...maybe bigger than the 1,320 bytes being added / bigger than one page ).
rk2612 said:
Thanks. I'm using bootloader 4.0.1 but have modified boot and system from 4.0.3. Modified boot image attached.
EDIT: Reading your comment again, I realize what I missed. You mention that the warning comes after by unpacking and repacking the stock kernel (with modifications, I presume). That is the case with me as well. However, I have now locked the device and if I try to flash SuperSu 2.79SR3 (systemless) now, I get into a bootloop.
SOLVED: On a hunch, I hex edited the boot signature to reduce the size mentioned after the "/boot" and made it nearly half of the original boot.img size. And it worked without throwing up any warning!!! Thanks to you for pointing out that size variation triggers the bug which causes the warning not to be displayed. The size difference needs to be (perhaps) big enough for the warning not to be triggered (...maybe bigger than the 1,320 bytes being added / bigger than one page ).
Click to expand...
Click to collapse
If you flash a zip that modifies your boot image, like SuperSU, you should expect to get the boot loop. They work by running unpackbootimg and mkbootimg on your device, which will throw away any signature. If you flash the fakesign.zip from post 2 after flashing SuperSU (or adb pull the boot partition and manually add the signature yourself), it should work.
Try the boot image in the attached zip and see if it works or produces any warning.
Boot loops caused by SuperSu are not due to signature. If modified stock boot works without a signature and only a warning, why should be any different for further modifications to boot image by SuperSu?
rk2612 said:
Boot loops caused by SuperSu are not due to signature. If modified stock boot works without a signature and only a warning, why should be any different for further modifications to boot image by SuperSu?
Click to expand...
Click to collapse
Ah, this is the fun part, and something that had me confused for an hour or two as well. The modified stock boot image does not work without a signature. It only appears to, because the repacked image is the same size as the signed one, minus the signature at the end. I can guarantee this because you say you got the warning. This means that when you flash it, the original signature is still sitting there in flash!
The boot.img before the signature is a multiple of the page size long. Only the necessary flash pages are written by fastboot. So any part of the flash partition after that point will be untouched. Since the signature is on the next page, it doesn't get erased or changed.
Try a "fastboot erase boot" and then flashed the unsigned modified stock. It won't work, because the signature is erased. SuperSU doesn't work without re-signing because it adds several files to the ramdisk, thus increasing the size of the boot image and overwriting the residual in-flash signature. If the boot.img was modified to be smaller than the original, the signature would still be there, but not where the bootloader looks for it, so that case would fail as well.
Related
@MikeChannon removed OP. please close
what? lol
I'm away from PC for few days but if someone has luck with 1050l please update.
Sent from my YOGA Tablet 2-1050L using Tapatalk
This is awesome, to unlock the full potential of the tablet!
Works on my 1380F
Oh! I gave up on the unlock
Now, thank you for opening the possibilities!
Thank you! XD!
Worked on my already unlocked 1050F..... Bring on the fun people....
and the first tester prize goes to @workdowg ... as usual i might add
just when i was ready to write: come'on all of you dwarf 1050 owners
so we already have confirmation from 1050 (workdowg), i would say 99% it's the same on 830
again after you flash it you can leave it there (it's a good feeling to know that you have an unlocked bootloader)
and now the really important questions will follow:
- is this a permanent root?
- it already installs linux/windows or do i have to put my sdcard in?
- where's the link to the marshmallow cm rom ?
I succeeded. np (flashing, 1050F)
But how can I know that I had unlocked? (how to check?)
neverapple88 said:
I succeeded. np (flashing, 1050F)
But how can I know that I had unlocked? (how to check?)
Click to expand...
Click to collapse
if it boots up to Android AFTER you flashed the patched esp image then you are
it allows whatever boot image (in boot or fastboot or recovery partition) to be loaded without being checked for valid signature (ie you can modify your boot images from now on and flash them and you will no longer get the "verification failed" error message that a locked bootloader would give)
ionioni said:
if it boots up to Android AFTER you flashed the patched esp image then you are
it allows whatever boot image (in boot or fastboot or recovery partition) to be loaded without being checked for valid signature (ie you can modify your boot images from now on and flash them and you will no longer get the "verification failed" error message that a locked bootloader would give)
Click to expand...
Click to collapse
Thank you! :victory:
neverapple88 said:
Thank you! :victory:
Click to expand...
Click to collapse
if you really want to test with some more tangible result (the already tested) extract then flash the attached file, boot to fastboot and flash with
fastboot flash boot boot-selinux-permissive.img
it will make your selinux permissive ie log & ALLOW operations that are violating the selinux policy. the original stock has selinux in enforcing mode ie log & BLOCK
before you flash the modded boot image open an adb shell and check the selinux mode, input
getenforce (it should output enforcing)
now go to fastboot and flash the modded image as per above instructed, reboot and enter in the same command
getenforce (should output permissive now)
there you go... on a locked bootloader it would have hang on boot start after you flashed the modded image with some verification failed error message (and it's true, the modded image is by no way digitally signed )
ps. this is made from a stock 1050f boot image so it works/testing on 1050f only (the other 830 and 1380 models will most likely hang on boot or at least blank the screen due to different configurations in the original images, but it's the same concept, this is made at the special request of our korean guy)
ionioni said:
if you really want to test with some more tangible result (the already tested) extract then flash the attached file, boot to fastboot and flash with
fastboot flash boot boot-selinux-permissive.img
it will make your selinux permissive ie log & ALLOW operations that are violating the selinux policy. the original stock has selinux in enforcing mode ie log & BLOCK
before you flash the modded boot image open an adb shell and check the selinux mode, input
getenforce (it should output enforcing)
now go to fastboot and flash the modded image as per above instructed, reboot and enter in the same command
getenforce (should output permissive now)
there you go... on a locked bootloader it would have hang on boot start after you flashed the modded image with some verification failed error message (and it's true, the modded image is by no way digitally signed )
ps. this is made from a stock 1050f boot image so it works/testing on 1050f only (the other 830 and 1380 models will most likely hang on boot or at least blank the screen due to different configurations in the original images, but it's the same concept, this is made at the special request of our korean guy)
Click to expand...
Click to collapse
Thank you for your time.
Test and english search(?) success!
ps. (After the test, find) I've used this app for security : SELinuxModeChanger
Any chance this could be modified for yt3?
Worked on my 1050f. Thanks!
Patched image booting fine on my 1050f.
Thanks
What's droidboot.img?
The original disk contains no droidboot:
Number Start End Size File system Name Flags
1 20.5kB 8409kB 8389kB reserved msftdata
2 8409kB 43.0MB 34.6MB fat32 ESP boot, esp
3 43.0MB 59.8MB 16.8MB boot msftdata
4 59.8MB 80.8MB 21.0MB recovery msftdata
5 80.8MB 97.5MB 16.8MB fastboot msftdata
6 97.5MB 106MB 8389kB reserved_1 msftdata
7 106MB 139MB 33.6MB panic msftdata
8 139MB 676MB 537MB ext4 factory msftdata
9 676MB 685MB 8389kB misc msftdata
10 685MB 819MB 134MB ext4 config msftdata
11 819MB 953MB 134MB ext4 cache msftdata
12 953MB 1222MB 268MB ext4 logs msftdata
13 1222MB 3369MB 2147MB ext4 system msftdata
14 3369MB 31.3GB 27.9GB ext4 data msftdata
Click to expand...
Click to collapse
cocacola2015 said:
What's droidboot.img?
The original disk contains no droidboot:
Click to expand...
Click to collapse
Fastboot
From my LG-G4, Rooted running Stock 5.1
---------- Post added at 01:57 AM ---------- Previous post was at 01:54 AM ----------
workdowg said:
Fastboot
From my LG-G4, Rooted running Stock 5.1
Click to expand...
Click to collapse
And it changed significantly from kit Kat to lollipop.
From my LG-G4, Rooted running Stock 5.1
ionioni said:
if you really want to test with some more tangible result (the already tested) extract then flash the attached file, boot to fastboot and flash with
fastboot flash boot boot-selinux-permissive.img
it will make your selinux permissive ie log & ALLOW operations that are violating the selinux policy. the original stock has selinux in enforcing mode ie log & BLOCK
before you flash the modded boot image open an adb shell and check the selinux mode, input
getenforce (it should output enforcing)
now go to fastboot and flash the modded image as per above instructed, reboot and enter in the same command
getenforce (should output permissive now)
there you go... on a locked bootloader it would have hang on boot start after you flashed the modded image with some verification failed error message (and it's true, the modded image is by no way digitally signed )
ps. this is made from a stock 1050f boot image so it works/testing on 1050f only (the other 830 and 1380 models will most likely hang on boot or at least blank the screen due to different configurations in the original images, but it's the same concept, this is made at the special request of our korean guy)
Click to expand...
Click to collapse
Awesome! I flashed it on my 1050f and it is now finally unlocked and the SELINUX stuff has been successfully tested as well!
I really hope that finally some great custom rom's might get released sooner than later.
Your work was hidden for a while - but finally you decided to make it public.
I was so frustrated about the bootloader policy and the missing possibilities an Android device usually offers. But I see light at the end of the tunnel. Looking forward to see also your work on AoL and other great stuff.
You guys are really the Yoga 2 heroes!
So does this mean we can now get a permanent recovery?
Can you post video guide? Thank's.
pateken said:
Can you post video guide? Thank's.
Click to expand...
Click to collapse
Please don't take this wrong... His instructions are pretty straight forward (1,2,3)... If you don't understand them you may not want to start messing with your tablet like this. Rooting is more than enough for the average user (See HERE for Windows based rooting and HERE for Linux based rooting)...
{
"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"
}
This thread has the aim is to provide you with one single thread to find what you seek and where every user can participate by sharing files and/or links to.
Here's a list of all variants as thankfully provided by @Kisakuku:
htc_ocndtwl - China (Dual SIM)
htc_ocnuhl_jp - Japan (Single SIM)
htc_ocnuhl - Asia / EMEA (Single SIM for carriers and HTC direct sales)
htc_ocndugl - Asia / EMEA (Dual SIM for HTC direct sales)
htc_ocnwhl - North America (Single SIM US Unlocked, Sprint)
Helpful links:
[GUIDE | FIX] PIN/PATTERN/PASSWORD not recognised after TWRP restore
[GUIDE] HTC U11 How-To - Return to Full Stock ROM/Firmware
Downloads of fastboot mini platform tools from Google: Win64 | Linux
Downloads of htc_fastboot from HTCDev: Win64 | Linux | macOS
Instructions on fastboot flashing and Firmware by @Sneakyghost
Instructions on how to get an OTA link from HTC by @topjohnwu
Universal HTC RUU/ROM Decryption Tool by @nkk71 and @Captain_Throwback
SunShine Unlock/S-OFF thread by @jcase and @beaups
I cannot accept any liability and/or responsibility for these firmware packs. I am not able to go through the process of testing each pack, hence community members are called to test these on their own.
Regards 5m4r7ph0n36uru
Post #2: Google Spreadsheet with download links
Post #3: Firmware flashing methods by @Sneakyghost
Post #4: General Information by @Sneakyghost
Post #5: How-To Guidelines
1. How-To flash a RUU using the SD card method
2. How-To restore an untouched/pristine system image using a Nandroid Backup
3. How-To manually flash an OTA Update
Post #6: RUU Errors & Fixes
This thread wouldn't be as good as it already is without all those contributes named at the end of this thread. Thanks again to all of you sharing your files and knowledge that enables me to hold up this thread.
There are some special thanks I want to express to
@Sneakyghost by whom's firmware threads I gained the most, if not all, my knowledge about firmware reagarding HTC
@Captain_Throwback for creating and maintaining the HTC RUU decrypt tool, as well as maintaining all those TWRP Recoveries
@nkk71 for creating and maintaining the HTC RUU decrypt tool, as well as the MultiROM Mod on my past HTC devices
XDA:DevDB Information
[GUIDE][Collection] HTCU U11 – RUU/Firmware/Recovery/OTA/Backups
Contributors
@5m4r7ph0n36uru, @ziand_, @Kisakuku, @OMJ, @JEANRIVERA, @blueberry60, @Golv, @sergos1221, @topjohnwu, @andybg40, @Petert87, @sirioo
Created 2017-05-25
Last Updated 2017-06-24
[Collection] Spreadsheet with download links
GOOGLE SPREADSHEET
Recent Additions:
Please remember: you're writing to boot-critical parts of your phone. If anything goes wrong along the way, your phone might be bricked.
2019/02/09 - 2.42.709.86 RUU thanks to @ziand
2018/10/12 - 2.42.709.82 Nandroid thanks to @ziand / 2.33.91.7 Nandroid thanks to @korom42
2018/10/12 - 2.42.709.7 DUGL Nandroid, 2.42.709.7 > 2.42.709.82 DUGL OTA thanks to @ziand
2018/10/11 - 2.42.709.6 > 2.42.709.7 DUGL OTA, 2.33.401.19 DUGL Nandroid thanks to @ziand / 1.27.89.10 RUU thanks to @ziand and @migascalp / Updated all OTA links possible to AFH links thanks to @ziand, and removed those whhich are no longer working, due to HTC's server changes
2018/09/19 - 2.33.401.19 Nandroid thanks to @scotty2000 / 1.13.161.7, 1.27.161.5, 1.27.161.10, 2.33.161.11 Combined FullWipe Firmware thanks to @Petert87
2018/09/18 - 2.33.161.11 > 2.33.161.12 OTA, 2.33.161.12 Firmware, Nandroid & Stock Recovery thanks to @Petert87
2018/09/15 - 2.33.401.10 > 2.33.401.19 OTA thanks to @ziand
2018/09/06 - 2.42.400.3 DUGL RUU thanks to @ziand
2018/08/24 - 2.42.617.7 RUU ZIP thanks to @ziand / 2.42.400.6 > 2.42.400.7 DUGL OTA thanks to @desean
2018/08/12 - 2.33.91.6 Nandroid thanks to @korom42 / 2.42.617.7 Nandroid thanks to @8bitbang / 2.42.617.7 NoWipe Combined Firmware thanks to @darwinmach
2018/01/13 - EMEA DUGL: 1.27.401.11 > 2.33.401.10 OTA thanks to @jhil110/@sirioo, 2.33.401.10 Stock Recovery thanks to @ziand_ / EMEA UHL 1.27.401.12 > 2.33.401.10 OTA / 2.31.709.1 > 2.42.709.1 OTA, Stock Recovery & Nandroid thanks to @ziand_ / 2.31.617.2 > 2.42.617.1 OTA, Stock Recovery thanks to @JEANRIVERA / RUU (EXE & ZIP) thanks to @OMJ / Nandroid (AFH) thanks to @ziand_
2017/12/28 - 1.11.701.5 > 1.28.710.4, 1.28.710.4 > 1.29.710.5, 1.29.710.5 > 2.33.710.9 OTAs added thanks to @GraeFNZ
2017/12/17 - 1.27.400.8 > 1.27.400.21 OTA, 1.27.400.21 RUU & Nandroid thanks to @Kisakuku / 1.27.118.5 > 1.27.118.12 OTA, Nandroid & Stock Recovery thanks to @buttie / 1.27.1405.7, 1.35.1405.2 RUUs & 1.27.1405.6, 1.27.1405.7, 1.35.1405.2 Nandroids thanks to @liweichen6 / 1.28.617.30 > 2.31.617.2 OTA & Nandroid thanks to @OMJ / RUU (.EXE/.ZIP), Stock Recovery, Combined NoWipe & Full Wipe Firmwares thanks to @Kisakuku / 1.27.400.21 > 3.31.400.6 OTA thanks to @goodman_east / Stock Recovery, Combined FullWipe & No Wipe Finmares thanks to @Kisakuku
2017/11/03 - 1.28.651.40 > 1.28.651.50 thanks to @OMJ / 1.28.651.50 RUU (EXE & ZIP), Combine FullWipe & NoWipe Firmwares, Stock Recovery, Nandroid thanks to @Kisakuku / 1.27.401.11 (DUGL) OTA thanks to @Electronic Punk / 1.27.401.11 (DUGL) Combined FullWipe & NoWipe Firmware, Stock Recovery thanks to @Kisakuku / 1.27.401.11 (DUGL) Nandroid thanks to @ziand_ / 1.27.401.12 (UHL) OTA thanks to @axst_68 / 1.27.401.12 (UHL) Combined FullWipe & NoWipe Firmwares, Stock Recovery as well as 1.28.617.30 RUU (EXE & ZIP), Combine FullWipe & NoWipe Firmwares, Stock Recovery, Nandroid thanks to @Kisakuku
2017/10/15 - 1.27.401.5 UHL RUU, Combined FullWipe &NoWipe Firmware, Nandroid / 1.27.401.5 DUGL RUU, Combined FullWipe & NoWipe, Nandroid by @Kisakuku
2017/09/14 - 1.27.401.5 Stock Recovery by @Kisakuku
2017/09/12 - 1.27.401.5 OTA by @axst_68
2017/09/10 - 1.28.709.6 OTA by @topjohnwu, 1.28.709.6 Recovery, Combined FullWipe & NoWipe Firmware, Nandroid by @Kisakuku
2017/09/03 - 1.27.401.5 OTA & Nandroid by @ziand_, Recovery by @Kisakuku / 1.28.651.3 OTA by @OMJ, Nandroid, RUU, Recovery, Combined FullStock & Combined noWipe Firmware / 1.27.400.8 Nandroid, RUU, Recovery, Combined FullStock & Combined noWipe Firmware all by @Kisakuku / 1.27.1405.4 & 1.27.1405.6 RUU by @liweichen6 all added to the spreadsheet
[...]
2017/07/08 - Initial release of the newly created spreedsheets with all links provided as of today
Click to expand...
Click to collapse
Disclaimer
You are aware that writing to security protected, boot-critical partitions increases your risk to lose the device exponentially. You understand and agree that I cannot be held responsible for such or any other damages. The flash process is theoretically safe and well tested, however you are the brains behind the wheel and you are solely responsible for the execution of the process. I will not accept any liability. The method itself is developed by Google and HTC, I only provide access and information to it and I am trying my best to make it understandable and simple. Do not use this if you have difficulties understanding what this is!
You understand that you should not do it if you are not willing to accept this risk.
As some questions within this thread already showed that people don't read the OP, which includes all linked threads linked to in post #1, I'll leave the follwing here. With courtesy of our fellow contributer @Sneakyghost who allowed me to use his work in this thread, I'll quote his explanations on flashing methods, as well as the provided firmware.zip variants below.
If S-OFF will get available I'll double check all what's written below and alter it to reflect the the currrent situation on the HTC U11 if needed. For as long as we don't know what still holds true on the U11, I'll leave his fabulous work untouched as a quote.
The whole thanks and respect for this work belongs to @Sneakyghost. Thanks again to you mate!
Sneakyghost said:
Flashing methods:
The safest way is still HTCs RUU and OTA method. US RUUs can be accessed via HTC's US Support Site. Jump to your device, then click "View" and scroll down for the download-link. The page has Dev/Unlocked (617), Sprint (651), AT&T (502) and T-Mobile US (531) covered. RUU's are superior to other flashing methods because they carry lab tested combinations of partition images and the method itself is also known to work well (plus the psychological advantage).
Other than HTC's original OTA's which are "incremental", My packages are always FULL packages (applies to my NoWipe as well! It can also be considered a FULL update as opposed to incremental) - with these you can safely jump from a very old firmware right up to the newest. Following this original RUU / OTA method, come the methods most suitable for my packs:
My preferred method is the "Fastboot method", which needs a PC or Mac or Linux computer. I will be detailing how to fastboot flash firmware further down.
The "SDCard Method" can be considered the fastest and most suitable for people without a PC. I will be detailing how to SDCard flash firmware further down.
An explainer to the ZIP variants provided here:
Full Stock WIPE ZIPs:
NOTICE: FullStock zips currently permanently break the phones ability to receive HTC stock OTA's - to restore your OTA functionality, refer to post #5 for more information!
Only System removed (and encryption broken) - Everything else stock! This type of zip also re-flashes the /data partition with HTC's DZDATA files (meaning you loose everything on your internal SDCARD). Also replaces the Kernel, recovery and Splash1 with latest stock images! The /system partition will not be touched. (Else this would be a RUU.zip). It also includes the "apppreload.img" with all the carrier-bloatware (WWE has no bloat in there!).
Be sure to put a ROM onto your EXTERNAL SD before proceeding with a Full WIPE ZIP! If you forgot to put a zip on your sdcard: you can reflash TWRP with Fastboot (use my batch tool) and then choose between ADB file push, MTP transfer or even USB mass storage transfer mode. Last but not least you can take out the sdcard and use a card-reader with your computer. Phone will NOT boot without ROM reflash after using this!
NoWipe ZIPs:
These packages are modified. This type of ZIP updates basic Firmware partitions, does not touch the /data partition, leaves kernel, splash and ramdisk (in order to support custom ROM's modifying ramdisk) alone. The "apppreload.img" is removed, the bloatware partition will remain unchanged (to remove already existing bloat permanently flash apppreload.img from International/WWE/401, it is an empty image). Recovery will be replaced with the current TWRP. Phone should in most cases boot normally after using this.
And what you won't get here (fine print):
Since this is a Firmware Update Thread and not a ROM thread, you do NOT EVER get a ROM (a.k.a "System.img" or plain: "System" here. You understand and agree that you cannot have this from me. You also acknowledge that I cannot be blamed for your non-booting phone due to you not reading or not understanding this. You may find stock system backups here
How to flash firmware.zip's using fastboot
Prerequisites:
You need ADB and Fastboot on your PC. To get ADB and Fastboot up and running I strongly suggest you use my "Batch Tool" setup, because it contains an updated htc_fastboot, which is 100% working with the HTC 10 . This is important: the generic Google fastboot from SDK API Level 24 (latest at time of writing) is NOT FULLY COMPATIBLE.
The method outlined here does apply to my zips as well as HTC signed zips. The difference is, that for my zips, S-OFF is mandatory, while HTC signed zips can under certain conditions also be flashed to S-ON phones, however, different prerequisites and risks apply there. I will not cover HTC signed zips here as they are fundamentally different in some aspects while the flashing method remains the same.
Note: use "htc_fastboot" with my batch tool. If you use another ADB/Fastboot set, it will probably be Google Fastboot and then the commands should be starting with "fastboot".
Step-By-Step:1. If device is booted into Android, reboot into download mode by running:
Code:
adb reboot download
NOTICE: adb reboot download is new since the M9 for those who come from earlier HTC devices - zips can be flashed in download mode or RUUMode, both work. The on-screen status report is more detailed in download mode. This making it the preferred flashing mode for now.
1.a Or else, if your device is in a different state or you just prefer the button method:
In Android: Press and hold Power and VolDown at the same time for approx. 15 seconds, when the screen and charging LED go dark immediately let go of power, keep holding VolDown a little longer.
During Boot and sometimes when booted into Recovery: Press and hold Power, VolDown and VolUp at the same time for approx. 15 seconds, when the screen and charging LED go dark immediately let go of power and VolUp, keep holding VolDown a little longer.
When in download mode, use the VolUp and VolDown buttons to navigate up and down and use Power to confirm.
2. Now place the Firmware_xx.zip into your adb/fastboot folder (which will be "C:\Android\com" if you use my Batch Tool).
3. Followed by:
Code:
htc_fastboot flash zip Firmware_xx.zip
(replace "Firmware_xx.zip" with the name of your zip)
4. Now check the console output. It should approximately look like this log:
NOTICE: this flash log is taken from a NoWipe (not all images included) flash on an HTC 10. New is (compared to M7, M8) that the checking routine is way more sophisticated and Controller Firmware for e.g. the touch panel or the Infra Red Remote (One Series only, not available on the HTC10) and the like do NOT get flashed if the checks determine that they are already up-to-date. Images that do not get flashed show "BYPASSED", which is NOT an error.
Important: Should you decide to flash in RUUMode (instead of Download Mode like suggested further up), the flash process halts at around 90% on phone screen! This is normal and a safety precaution! The last few percent is the reboot, which is NOT happening automatically, so you get a chance to check the console output to make sure it is safe to reboot! The bar will only fill up to 100% once you type:
Code:
htc_fastboot reboot
Important: Download Mode flashes finish at 100% on phone screen and in console and ask you to hit Power to return to Download Mode screen.
IF you encounter any errors which are not "FAIL90", have a look into Post #3 or ask in the thread! DO NOT reboot the device until you have an idea what happened!
5a.
Code:
htc_fastboot reboot-bootloader
or press Power to return to Download Mode screen - depending on the mode you used to flash the zip. In Download Mode and Bootloader you can go to either regular reboot or shut-down the device via button navigation.
5b. Optional:
Code:
htc_fastboot reboot
to just reboot the phone to Android.
How to flash firmware using SDCard MethodPrerequisites:
Compatible SDCard, should be formatted with FT32 for older firmware, newer firmware can also handle ExtFS formatted cards.
A firmware.zip you would like to flash, taken from Post #2 (Downloads)
Phone charged up at least 30% (will fail with low power warning if lower than 30%)
Step-By-Step:1. Rename your firmware.zip to exactly "2PS6IMG.zip" - make sure you enable "show file extensions" in Windows Explorer, if you rename it on your PC. Else you might end up with a "2PS6IMG.zip.zip" which won't flash.
2. Copy your "2PS6IMG.zip" over to the root of your SDCard. Use a cardreader, or MTP protocol in Android or Recovery, or USB Mass Storage protocol in Recovery, or ADB push the file in Android or Recovery - many methods available.
3. Now, if device is booted into Android, reboot into download mode by running:
Code:
adb reboot download
3.a Or else, if your device is in a different state or you just prefer the button method:
In Android: Press and hold Power and VolDown at the same time for approx. 15 seconds, when the screen and charging LED go dark immediately let go of power, keep holding VolDown a little longer.
During Boot and sometimes when booted into Recovery: Press and hold Power, VolDown and VolUp at the same time for approx. 15 seconds, when the screen and charging LED go dark immediately let go of power and VolUp, keep holding VolDown a little longer.
4. Once Download Mode starts, it will "see" the 2PS6IMG.zip and ask you (yellow text at bottom of screen) if you want to flash the firmware. Press VolUp to confirm and proceed with the flash, or press VolDown to cancel and continue into Download Mode UI.
5. Now check the screen while it flashes. It should stop at "end UI updating. Press Power to continue" - the phone will now shut off! To turn it back on, press and briefly hold power again.
Click to expand...
Click to collapse
General Information
The whole thanks and respect for this work belongs to @Sneakyghost. Thanks again to you mate!
Sneakyghost said:
FullStockWipe and HTC OTA's a.k.a "Verity"
What's the problem?
The way the new security works, a FullStock zip will break your OTA capability in almost all scenarios. The only scenario where that would NOT happen is if you have, before you flash the zip, already the corresponding untouched, hash-sum matching stock system image flashed. Nobody using custom ROM's has that. So, what happens is this:
- FullStock.zip flashes stock kernel which has verity enabled and checks partition integrity upon boot.
- After flashing, you reboot. The kernel kicks in (around when bootanimation would start). The kernel checks the /system partition if it is the correct one.
- The kernel finds it is not the correct system and reports a fail-status, sets this as persistent information, and will force a reboot
- At reboot, (and every reboot after) the Bootloader picks up the fail status and pass it on to the kernel, which in turn will pass it on to the system.
- Now, Android thinks, System is messed up and will not allow you to download and apply an OTA.
From now on, every boot, even if you flash a clean stock system, the aboot will tell the rest of the guys working inside your phone: hey, this thing has been messed with, it cannot be updated anymore!
Fixing strategies:
1.) To restore OTA function fast and easy: run a RUU.
2.) If there is no RUU for your specific model, you could convert to another model which has a RUU.
3.) Then there is a third, theoretical way I have not yet tested: obtain an untouched system image that fits your FullStock (same version), flash that in fastboot (it can be a raw dump or a TWRP systemimage backup of the correct system) and then flash the corresponding FullStock again. That should, like a RUU, restore OTA functionality too.
4.) Also very simple: grab the HTC OTA file which you find in /data/data/com.htc.updater somewhere if you can download. If not, find it on XDA from someone else who got it. Then put it on your sdcard, have stock recovery flash it from SDCard (no detailed guide here but its the same since years, there are tons of guides on how to manually flash a HTC OTA out there. Use Google).
5.) Remove boot.img from my FullStock zip before you flash. Your custom ROM of choice will put a hacked kernel into your phone again anyway...
However, at time of writing this, I know @nkk71 is investigating other, simpler methods to restore the correct state.
So, if you absolutely depend on HTC's OTA's, best would be to just not flash/boot a stock kernel ever while a custom system is installed.
Flash Process Output (applies mostly to older phones, the newer HOSD driven output is much more detailed)
There are a few steps in the flash process which are not really straightforward but i can maybe explain some of them here:
sending 'zip' means: fastboot is sending zip over to client (here referred to as “remoteâ€)
OKAY [ 2.839s] means status of sending was good. Transfer succeeded.
writing 'zip'... means the zip is being written to some location on the phone from the /temp location.
(bootloader) zip header checking... means the zip header is being checked for validity, see if it’s a real zip file and check for HTC’s signature, which often resides in the header part.
(bootloader) zip info parsing... means most likely a check on the file hashes in the zip (integrity check - if the zip is borked, it will fail here)
(bootloader) checking model ID... The bootloader checks if the android-info.txt contains the right MID. If it fails here you gotta swap out your model ID in the android-info.txt file or write another MID to your phone.
(bootloader) checking custom ID... The bootloader checks if the android-info.txt contains the right CID. If it fails here you gotta swap out your Customer ID in the android-info.txt file or write another CID, possibly SuperCID, to your phone.
(bootloader) start image[hboot] unzipping for pre-update check... means the bootloader is now unzipping the [hboot] image. This line will be repeated before every image that is to be flashed.
(bootloader) start image[hboot] flushing... means the bootloader is now beginning to flash the [hboot] image.
(bootloader) [RUU]WP,hboot,0
(bootloader) [RUU]WP,hboot,99
(bootloader) [RUU]WP,hboot,100 these three lines read [RUU] for what mode fastboot is in, WP for “Write Partition†for what is currently being done in RUUmode, “hboot†is the name of the currently flashed partition, number xx is a percent stage of the write process.
(bootloader) ...... Successful means the final status is successful.
Now, before the [RUU]WP,hboot,xx line we often see another line reading [RUU]UZ,radio,50 for example. That reads RUUmode is currently unzipping the Radio.img and at stage 50 percent. UZ means UNZIP.
If you see something like this:
(bootloader) start image[sbl1-1] unzipping & flushing...
(bootloader) [RUU]UZ,sbl1-1,0
(bootloader) [RUU]UZ,sbl1-1,100
(bootloader) signature checking... means it is checking the signature of the partition if it matches the expexted signature stored in the hboot.
(bootloader) verified fail means the signature in the image did not meet expectations.
(bootloader) ..... Bypassed means the image got skipped because its got the wrong signature.
This has to be interpreted like this: there are multiple “SBL†images, to be exact: type 1 has 3 variants and type 2 has only one variant. Of type 1 (“SBL1-xâ€), two get skipped, one gets flashed (see my log above), of type two (“SBLxâ€) both get flashed. I believe, SBL 2 and 3 are device independent, but SBL1 has three variants, of which only one fits the current device. So, depending on the device you have, you will see either SBL1-1, SBL1-2 or SBL1-3 being flashed and the other two subtypes being skipped (bypassed).
The same goes for the "dzdata" images in the firmware package. They come in two or three size flavors (16, 32 and 64 GB) and resemble the file structure of the /data partition. Depending on your device and model, only the one with the right size gets flashed, the others skipped.
Important to understand: nearly all FAILED messages that do NOT occur while [RUU]WP (write partition) should be considered harmless. Only a FAIL during a write operation will most likely result in a damaged partition. All other fails will probably leave the original partition intact and thus the device can be rebooted. So far my understanding.
General hints for RUUmode / Download Mode zips
- Opening a zip is best done with 7zip as WinRAR and other zipping tools have lead to flash fails in the past.
- Choose low compression, higher compressions often fail. Pick "save" or "normal" to be safe, anything higher could cause the unzip in Bootloader to fail.
- Adding and Removing images is not a problem. The naming of the partition images seems flexible, yet if you encounter an “Error 23: parsing image fail†you need to rename the relevant image to something stock as not all names seem to be recognizable. The Hboot/Aboot determines the right partition from the header inside the image.
- Additional Dots in zip file names are known to have caused issues for a few people.
- Spaces in names are a no-go!
- Custom Recoveries can be added to those zips as well as custom kernels. In fact, if your phone is S-OFF, you can pretty much add anything and name it e.g. “recovery.img†and it will be flashed. You gotta be very very careful, as this is an easy way to break your phone. Make sure not to mess around with modified images!
- With S-ON, those zips only flash if everything is totally stock, from the android-info.txt being right up to all images being the correct versions for that update package and all having the right signatures. Reads: no custom messing with firmware zips for S-ON phones. In fact: apart from HTC OTA firmware.zip’s and RUU’s, nothing will flash with S-ON at all...
General hints for android-info.txt
- Use an Editor that doesn't mess up linebreaks like Windows Notepad does. Use Notepad++
- MID’s can be added one per line. Also supports wildcards i think e.g.: 71******, but i’m not sure.
- CID's can easily be added or removed- one per line, definitely supports wildcards (used by HTC in DevEd phone)
- Mainver line: should hold the version of the used set of firmware images. Example how to format the version: 2.24.401.1 (2= Base version always increases by 1 with each Android base version rise, 24= Build version from HTC, 401= Regional/Customer identifier, 1= Revision of the HTC Build). This line is being written to the /misc Partition and is meant to reflect the whole phones software version - it is not meant to only describe the “firmware†part or the “ROM†part alone. HTC has intended the Version to always represent the whole thing, firmware version matching the ROM version. therefore, it would be wise to always run matching firmware and ROM versions, except where explicitly recommended otherwise. Mismatches can cause anything from no issues over radio problems up to semi-bricks.
- hboot pre-update line: usually says "3" but i have seen different numbers. I think they determine if hboot-preflash is required (when you get “Error 90 - please flush image again immediately†this is when the hboot/aboot needs to be flashed separately first and then the rest. If you encounter this, you need to run the flash command you just did, again.
- btype:1 not clear. [Item subject to change]
- aareport:1 Since HTC hboots/aboots, boot and recovery images come as "hboot_signedbyaa†/ “aboot_signedbyaa†/ “boot_signedbyaa†and “recovery_signedbyaa†i would read this as "aa" representing htc ("hboot signed by aa"). It could possibly mean check on the signature in hboot/aboot/boot/recovery - all of those also come in unsigned flavors - in HTC OTA’s, those are usually without the “_signedbyaa†but in the RUU, they are carrying a signature). So, aareport: 1 can just mean check on signature yes or no.
- Delcache means erase cache when rebooting. Simple. Some firmwares seem to need it, some don't. Line is not present in every android-info.txt. If you mess with a zip that contains the line, leave it active. This is also not referring to the Android OS cache partition. It refers to the separate Kernel and Recovery Cache. Sometimes, not deleting Kernel or Recovery Cache after flashing those leads to malfunctions. If the Kernel is launching and there is an older conflicting copy cached, the phone won’t boot past Kernel stage (before the bootanimation starts), if Recovery is conflicting with a cached copy (usually after flashing a new/different recovery), it will lead to the recovery not booting or malfunction (like aborting an ongoing ROM flash or not being able to execute other functions).
RUUmode:
is the mode used for RUU flashes by HTC. It allows a few more things than the normal fastboot. You recognize it by looking at the phone’s screen. It will be black, showing only a silver HTC logo and if a command is being active, a green progress bar. New M9 RUUMode now shows a percentage counter below the bar.
Download Mode:
New flashing mode, introduced 2015 with the HTC One M9, due to changing to a different, aboot-based bootloader structure, HTC also introduced the use of an HOSD partition containing sort of a micro-linux with extended fastboot-capabilities. It provides much more logging output and can be considered the better flashing environment now. When flashing my firmware.zips, I recommend using Download Mode over RUUMode, as it gives you much more feedback. The ARUWizard (a.k.a RUU or FUU) might still expect RUUMode for flashing, but when manually flashing or also when using SDCard method, Download Mode will work best.
Bootloader Mode:
You can also directly flash most firmware partition images with the by-name method, and that works only when booted to Bootloader (the white screen with colored text lines). In this mode, you can for example flash stuff like this: “htc_fastboot flash recovery recovery.img†or “htc_fastboot flash adsp adsp.img†- almost all image files can be flashed separately without HOSD or RUUMode in bootloader.
On the HTC10 this has become a critical function when recovering from flashing frankenbuild-firmware. After the Android N transition for example, a combination of old keymaster.img with new Android N firmware would lead to broken Download Mode and broken RUUMode, hence disabling all flashing methods. Using this direct image flashing method, you can recover your phone in such a situation. Inside the firmware.zips will be a file called “partition_info†- you can open that with a text editor like NotePad++ and see all the flashing names for the partition and this way figure out how to reflash every single partition manually.
NOTICE: do not flash aboot_signed.img this way! The only image that should not be flashed directly over itself when booted into bootloader!
Recovery flash risk:
Some of you might have heard of, or are thinking about flashing firmware using recovery.
Although it is perfectly possible to write firmware images to the NAND chip using the DD method in recovery (either with a script or by using ADB shell dd) it is highly recommended that no developer employs this method (except if it's the only way to rescue a damaged device, e.g it only boots to recovery or something like that). This suggestion can be limited to boot critical files (SBL images, Aboot, HOSD, Keymaster for instance), but I prefer to see this as a general “good practice†thing. The reason behind this is, that DD has no inbuilt write verification. If there is just one single bit that does not get written correctly, DD won’t notice and won’t correct it. With some bad luck, you end up with a brick this way.
JTAG with a RIFF Box
Every device of these days has so-called jtag test-points. Basically, these are points on the mainboards, where a direct connection to the main chip can be established and then that chip can be read and written to with an external device. Sometimes, these testpoints are hidden (like they are normal contacts of the chip) and no direct visible gold points on the board. It always takes a while after a device is released until the jtag layout is fully discovered but once that is done, companies like multi-com.pl start manufacturing small boards with pins that can be pressed onto the mainboard, so no soldering to the device is required. Once such a board exists, the mainboard can be hooked to the RIFF box which can rewrite a dead chip from the outside.
As long as there is no such small board (called a "JIG") the phone can still be revived but it is necessary to solder hair-thin wires to the test-points. That is perfectly possible, Tecardo can do such a thing, but its not very good for the board and cannot be done very often. At some point the solder points will degrade so much that the board is garbage then.
In case you really brick your device, you can contact Tecardo here: http://forum.xda-developers.com/showthread.php?t=2116062
MID and CID
MID = Model Identification. It serves the purpose of identifying the Model of the phone. There usually are several different ones. The ModelID in android-info.txt is CaSeSenSiTivE!
Some limited Data is here: https://docs.google.com/spreadsheet...ShfYNFAfSe-imhhqtVfeMPVDA/edit#gid=1606643937
CID = Customer ID and describes, for which customer HTC made this phone. HTC has a few own CID's for its regional stores. Then certain carriers decide to have their own CID. Some carriers even have their own Model ID’s.
So, while the MID more like describes the hardware, the CID basically just describes the software set that comes delivered with it. Both get checked on when flashing in RUUmode. How to trick this system? Fairly easy. Just add your respective MID or CID to the android-info.txt file inside the ZIP or make your phone SuperCID (My Batch Tool can do that automatically - but remember: all this only works on S-OFF phones).
S-OFF:
S-OFF refers to the NAND’s security lock. S is for security and OFF means the security is switched off. The factory state HTC’s phones ship with is ON, except for the userdata partition, which of course is always unlocked.
The key for that lock is the most heavily guarded secret in HTC’s software vaults. It cannot be extracted, bought or otherwise obtained from them. There is no official way to unlock the NAND partitions (approximately similar to what Apple fans do when they “jailbreak†their products, although technically not quite as similar). While the HTC Dev Unlock (available through htcdev.com) just unlocks 3 partitions (Boot, Recovery, System), the “S-OFF†hack we use unlocks all partitions, thus enabling the flashing of custom, modified or other devices firmware. This is what you want for this thread and you can get it from the famous reverse engineers Jcase and Beaups over at: http://theroot.ninja/ or alternatively purchase a “Java Card†and learn how to work it, from chinese sellers on Alibaba, sometimes Ebay. Then there is a way to do it with an XTC Clip. But SunShine S-OFF is by far the safest and fairest method. You will only be charged if it works and the guys over at sunshine are really helpful.
A more detailed look at how S-OFF works
[Subject to change - not a definite explanation, just how I think it works]
In the phone's Firmware is a component that checks if certain partitions have a digital signature from HTC and deny write access if the signature is wrong or missing. The checking component is known to be the Security, which can be set to OFF. Then we say the phone is
S-OFF.
System, recovery and boot do not get signature checked at all once you “unlocked†your phone on htcdev.com. The other partitions however do get checked as long as Security flag is set to ON. Partition 3 is where the Security flag is located and maybe also the checking routine that checks the other partions digital signatures,
The S-ON state is resembled by a 3 in the fastboot command to switch security on. It is: fastboot oem writesecurflag 3. You do NOT want to do that while any custom firmware is running. Only after a full RUU that removes any modifications.
Why? For some partitions like the splash screen, it might not lead to a brick if you set security to ON while a custom splash is installed (then failing the signature check), as this partition is not vital for the boot process, it might just be skipped and give you an error message (I have never tried obviously). Other partitions however, boot critical partitions like Hboot/Aboot.... You guys have to understand that altering any of these partitions can be deadly to your phone if you happen to leave them altered when switching security back on.
Determining your “Firmware Versionâ€
I believe there is some wrong info circulating the HTC Fora. People keep saying when running fastboot getvar all it will report the Firmware Version in the line “Version-Mainâ€. This is not always true though. Fastboot getvar all or alternatively getvar mainver pulls a version it finds in the MISC partition and relies on that to be correctly updated. Source
So how does that version string get updated? It is being taken from the android-info.txt file in any firmware zip that you flashed. The last zip you flashed determines what will be reported by the getvar function. So if you mess around with Firmware.zips and RUU’s a lot, chances are, that the version reported there is not equivalent to what you are already running. Often the android-info.txt has version entries not appropriate for the actual zip contents, for compatibility reasons, because it wasn’t done properly or whatever. My zips usually have the correct MainVer though.
The "Firmware" as a concept like we use it on XDA does not exist in HTC's terms. HTC does NOT differentiate between the /System Partition (what we know as "the ROM") and the other 36 partitions. Hence, if you run getvar all or getvar mainver on a stock phone, it will report correctly. It does not go looking for a fictitious place where it would find a separate "Firmware" version. That place it is looking at is the Misc Partition and that’s correct as long as you haven’t messed with lots of different Firmware zips... So, if you happen to run a hybrid system with a ROM from one base and the other partition images from another base or multiple bases (like hboot from 1.27, radio from 4.06 and ROM from 3.62) the getvar function will report as "Version-Main" what it finds in /misc/, precisely the last zip you flashed determines the string put there.
Example: you flashed a radio with a RUUmode zip from Base X.YY but the android-info.txt is maybe still an old one because the dude who made the zip, just dropped the new radio into an old existing zip, the getvar function will later report that old version as your mainver.
To check your firmware: boot to bootloader and look at the combination of hboot version and radio version - if you didn't flash those separate, the combination will let you know what base you are on (each OTA and RUU has the radioversion in its name).
Finding out your firmware is a game of guesses and knowing what you did to your device and where you are coming from.
If totally lost, best thing is to reflash some clean stock package to be sure you are on the same level with all partitions.
Long story short: you better know what you do because finding out your firmware is going to be difficult if you don't.
Click to expand...
Click to collapse
How-To Guides
1. How-To flash a RUU using the SD card method
reboot to download mode
perform
Code:
htc_fastboot getvar all
and note down your original software version
download the latest Stock RUU for your device.
flash your RUU to revert to stock
rename RUU to 2PZCIMG.zip
copy 2PZCIMG.zip to root directory of SD card
reboot to download mode
press Volume Up button to confirm flash of RUU
As soon as your RUU has been flashed sucessfully, that's it. Your are now Full Stock again, or updated to lates software version respectively!
2. How-To restore an untouched/pristine system by using a Nandroid Backup
flash TWRP custom recovery
download custom recovery at https://twrp.me
reboot to download mode
Code:
adb reboot download
flash recovery image
Code:
htc_fastboot flash recovery nameoftwrp.zip
Restore your Nandroid. If you got none yourself, it might be possible that you’ll find one in the above linked Google spreedsheet.
unzip the according Nandroid
copy Nandroid to TWRP/Backup/SerialNo/Nameofbackup on your extSD
restore Nandroid by using TWRP > RESTORE and choosing above copied Nandroid
Flash incremental OTA firmware
reboot to download mode
perform
Code:
htc_fastboot getvar all
and note down your original software version
download all incremental OTA firmwares to your PC, starting with the one above your current firmware version, up to the software version number of your above choosen Nandroid Backup (ATTENTION: If you are S-OFF it will suffice to download the latest Incremental OTA as well as the latest Combined Full Wipe firmware according to the above choosen Nandroid Backup)
flash all incremental OTA firmwares – one after another – following the below named steps (ATTENTION: If you are S-OFF you start with the Combined FullWipe, and proceed with the Incremental OTA one, to ensure that you’ll be able to receive upcoming OTA updates)
Code:
htc_fastboot flash zip nameoffirmeware.zip
(ATTENTION: this has to be done twice to comlete, and it will flash full firmware, thus TWRP will be replaced by stock recovery)
As soon as you restored the Nandroid and flashed all incremental firmware file up to the current build number of your Nandroid, that's it. Your are now Full Stock again!
3. How-To manually flash an OTA Update
3.1 Pre-ota preparations:
Download needed OTA package, in my example we will use
Code:
OTA_OCEAN_UHL_N71_SENSE90GP_HTC_Europe_1.13.401.1-1.03.401.6_release_5054200ovndmjh5kcwjecc.zip
Check your ROM version in Settings > About > Software Information, it MUST match the second value. In this example case
Code:
1.13.401.1-1.03.401.6
, if you have version different from
Code:
1.03.401.6
, update will FAIL.
Make sure that your device running system without any app/files modifications, otherwise update will FAIL.
Check your recovery, official OTA should be applied only on Stock Recovery.
Now copy your OTA package to system storage, I recommend to copy file in root of the Internal Storage.
When preparation stage is done, we can proceed to installation.
3.2 OTA installation:
Turn off device.
Press Power button and Volume down button, keep them until you see download mode.
Use the Volume rocker to navigate to the menu entry Reboot to bootloader and press Power button to confirm this action.
Use the Volume rocker to navigate to the menu entry Reboot to Recovery and press Power button to confirm this action. Your device will now reboot to recovery mode.
When recovery starts, you will see a red triangle with an exclamation mark within. Don’t worry nothing bad happened, this is just the entry screen of your stock recovery.
Wait for a short while and press Volume-Up button with Power button. This combination allows you to enter the Recovery menu.
Use the Volume rocker to navigate to apply from phone storage option and press Power button to confirm.
Now you can choose your OTA package. In our example it will be stored in
Code:
data/media/0/OTA_OCEAN_UHL_N71_SENSE90GP_HTC_Europe_1.13.401.1-1.03.401.6_release_5054200ovndmjh5kcwjecc.zip
then press Power button.
After reboot you will get message that you successfully updated your device.
4. How-To to take an OTA using TWRP Recovery
The whole thanks and respect for this work belongs to @Captain_Throwback. Thanks to you mate!
Captain_Throwback said:
You can take the OTA directly with TWRP installed; it should work fine - in fact, that's how I took it today.
Prior to hitting the "Install Now" radio button in the System Update notification, though, I had to make a copy of the OTA zip and place it elsewhere on the device. Then, I extracted the firmware.zip from it. Then I extracted the zip itself, and zipped it back up without recovery.img (so that I wouldn't overwrite TWRP). Renamed the new zip 2PS6IMG.zip and placed on the root of my SD.
Then hit "Install Now". System reboots into recovery and OTA install begins. You'll see some red text in the console at the end of the install but it'll complete successfully.
Take a fresh "System Image" backup in case you decide to modify system later. Reboot to download mode, and install the firmware zip. It reboots once by itself to update aboot, and finishes updating after then. Then you have to press power to power off the device (for some reason). When powering back on, hold Volume Down to get back to download mode, this time cancelling the update and rebooting to bootloader, then back to recovery (TWRP). Re-root with SuperSU, flash systemless Xposed or whatever and when you're done, reboot. It'll reboot by itself once to process the SuperSU install, and then booting will proceed. It'll optimize apps, which will take a while, but once it's finally back up, you'll be all updated, without ever having flashed a stock recovery, and fully rooted once again
[...]
P.S. Obviously the OTA will only apply if your system is completely stock, without ever having been mounted rw.
P.P.S. You can only modify the firmware.zip and successfully flash it if you're S-OFF. Otherwise, you have to leave the firmware zip untouched and flash it that way. Then you'll have to re-flash TWRP.
P.P.P.S. You can obviously root using whatever method you'd like. I'm no longer using SuperSU - I'm currently using Magisk combined with phh's open-source root.
Click to expand...
Click to collapse
5. How-To Downgrade your device while S-ON
The whole thanks and respect for this work belongs to @ziand_. Thanks to you mate! But never do it if you do not have a clear vision how to do it. For inexperienced users it is a way to get a brick, I will not accept any liability!
ziand_ said:
There is a possibility to flash old RUU with with S-ON Unlocked. It is necessary to delete current ROM number in misc (example on my OCEN_DUGL 1.13.401.1):
Boot into TWRP recovery.
Check position of ROM version number in misc by command (0x2208 - the same as on HTC 10 and HTC One M9):
c:\adb>adb shell "dd if=/dev/block/platform/soc/1da4000.ufshc/by-name/misc bs=1 skip=2208 count=16"
(or c:\adb>adb shell "dd if=/dev/block/sde1 bs=1 skip=2208 count=16")
1.13.401.1 16+0 records in
16+0 records out
16 bytes (16B) copied, 0.007585 seconds, 2.1KB/s
Delete ROM version number (1.13.401.1):
c:\adb>adb shell "dd if=/dev/zero of=/dev/block/platform/soc/1da4000.ufshc/by-name/misc bs=1 seek=2208 count=16"
16+0 records in
16+0 records out
16 bytes (16B) copied, 0.007466 seconds, 2.1KB/s
Boot into download mode (you can see empty line "OS- ") and flash previous RUU by PC or SD card flashing method, I prefer last one.
It works, I checked it on my U11 (some users checked earlier on HTC 10 and HTC One M9). This can be helpful to flash RUU for removing troubles and fixing phone when there isn't a current running RUU.
Click to expand...
Click to collapse
07 RU_CID_FAIL: CID in android-info.txt does not match your phone’s CID
10 RU_MODELID_FAIL: MID in android-info.txt does not match your phone’s MID
12 SIGNATURE FAIL: phone expects an HTC signature and can't find one; or found a wrong one
22 RU_HEADER_ERROR: something wrong with your zip; check md5 of download
23 PARSING IMAGE FAIL: something wrong with the image within the zip
24 ANDROID-INFO FAIL: something wrong with android-info.txt within the zip
32 HEADER ERROR: the zip couldn't be read and unzipped properly; seems same as 22.
33 NOT KNOWN YET: might indicate hardware failure.
35 FAILED (remote: 35 RU_PARTITION_NOT_SUPPORT <PartitionName>): means you can’t flash an image in download mode, as it has to be done in bootloader mode.
41 WRONG MODEL ID: means the RUU is menat for a different device
42 WRONG CUSTOMER ID: means you got to swap CID first
90 PRE-UPDATE FAIL: means it only flashed aboot and you have to run the process again immediately to flash all other partitions. The htc_fastboot.exe now auto-reboots on Error 90!
99 UNKNOWN: usually indicates you are S-ON, but sometimes also recognizes other Security related issues.
130 WRONG MODEL ID: see 41
152 IIMAGE ERROR: phone ccreen shows a little triangle beside a full green bar
155 INDICATES DIFFERENT THINGS:
the need to relock bootloader; if S-ON
the RUU cannot be executed, because the software versions of ROM, Firmware and RUU aren't matching
170 CHECK USB: RUU won’t run because ADB isn't working properly
171 USB ERROR: happens all the time when the RUU reboots the phone to download mode. For some reason the device is losing its connection and making a RUU flash virtually impossible . There is an incompatibility between USB 3/3.1 and Fastboot/ADB, as well as an issue with Windows Device Detection on the newer Windows 10 builds.
ERROR FIXES by @Sneakyghost:
For Error “7 RU_CID_FAIL” do:
- Make your phone have SuperCID (htc_fastboot oem writecid 11111111)
- Or: edit android-info.txt inside the zip to have your phone’s CID in its list
For Error “10 RU_MODELID_FAIL” do:
- check that the Model ID in android-info.txt matches your phone’s Model ID.
Typically, making your phone “SuperCID” makes it ignore CID and MID mismatches alike. However, lately we have noticed HTC has changed that behavior. MID mismatches are not ignored by SuperCID anymore. You will need to unzip my firmware package, change the MID in there to your MID and rezip it. Or, alternatively, change your phone’s MID, which is a bit trickier.
To un- and re-zip, please refer to Post #5 of this thread for more information!)
For Error 12 “signature fail" do:
- might indicate that a signed firmware package is required. This would only happen with S-ON phones though.
For Error 22 "RU_HEADER_ERROR" do:
- verify that you followed my zipping instructions exactly. If a correct zip is given (e.g. you get this error with one of my zips as well), we will need further information to work out what happened. This means a complete log and step-by-step post of what you did. Best just copy and paste the full console window contents so we can take a look.
For Error 23 "parsing image fail" do:
- change image names in the zip to stock image names like “hboot.img" or “radio.img" or whatever failed there....
For Error 24 "android-info fail" do:
- check that your ZIP isn’t some HTC OTA or anything that’s got no android-info.txt - those cannot be flashed with “htc_fastboot flash zip nameof.zip” command.
- check that your zip has a good MD5 and is not broken, check android-info.txt etc...
For Error 32 "header error" do:
- Make sure there is only one . (dot) in the filename, before the extension. Fastboot reads anything after the first dot it sees as the extension. If that is not zip, it fails.
- See Error 22.
For Error 33 "Update fail" do:
- Try other flashing modes, such as "SDCard method" or direct bootloader-flashing (only available for images named in "partition-info" file inside the firmware zip) if Fastboot Method fails.
- If all modes keep failing, validate image integrity with someone else who was able to flash successfully (MD5 Hash Sum compare).
- [UPDATE] Re-try to flash the image again and again, even for days. Maybe power it down completely for a night, then try again. It might eventually flash again. If you notice stuff in your phone failing again after it was actually fixed (like Sensors again not working if it was Sensor_Hub.img that didn’t properly flash initially, like if the symptoms come back after you fixed the flash), you might have a hardware damage rather than a broken software.
- Send it in for warranty! Should we find a "soft" solution, I will update this piece of info.
For Error 42 "Wrong Customer ID" and: 41 "Wrong Model ID" do:
Code:
htc_fastboot getvar all
Read that output, take note of your CID and MID and then edit the "android-info.txt" in your firmware.zip accordingly (For Wrong MID change the MID in the text, for wrong CID add your CID to the text).
Alternative method for MID and CID errors:
go SuperCID. Do:
Code:
htc_fastboot oem writecid 11111111
You can change back to any desired CID after a successful firmware flash. Notice: this command only works on S-OFF phones (which you have already of course or else you wouldn't be here).
For “pre-update FAIL 90 ..." do:
- Let the phone reboot itself into Download Mode. If it doesn't boot to download mode, force it back there (From Android with adb reboot download or with the button method, see "step 1").
- If the flash does not auto-resume, run the same flash command again which you just ran (press arrow up on your keyboard to get to the previous command in console)
For “Error 99 UNKNOWN" do:
- Check with other zip’s if they work!
- Check if your S-OFF is correct
- You are S-ON? Then almost definetely this means the ZIP is not signed - get an unmodified zip!
For “Error 130 wrong model ID" do:
- Please refer to Error Code 41/42.
For “Error 155 relock bootloader" do:
- Since my thread works only with S-OFF phones anyway, this error can be read as: you need to S-OFF first!
- Error 155 can mean that you need SuperCID. On a few occasions this was shown when the RUU refused to run because of a wrong region lock.
- Error 155 also sometimes occurs when a RUU was launched from within Android. When encountering a RUU error 155 with the process stalling after the rebootRUU (stuck at black screen with silver HTC logo), please just restart the RUU and leave the phone in that mode, or reboot the phone, then reboot to bootloader, then do “htc_fastboot oem rebootRUU” and then launch the RUU again.
- run the fastboot command “htc_fastboot oem lock" - only applies to S-ON phones that want to update the firmware with a stock OTA package (not offered on this thread!!). Stock OTA files sometimes need a locked bootloader.
For “Error 170 Check USB" do:
- Sometimes shown when running a RUU. Indicates issues with drivers. One way to solve is to run the ARUWizard with the phone already in Fastboot mode. Else you will have to re-install HTC Sync manager. Also, avoid USB 3 ports (the blue ones) - they have a complete new driver stack and that still doesn't always as expected.
For “Error 171 USB" do:
How to fix RUU error 171 on Windows 10x64 easily. System: Win 10 Redstone (1607) x64 with Intel based USB3.0 and USB2.0 ports:
Sync Manager from HTC Website
Download the attached file Fastboot.reg.txt and change the extension to Fastboot.reg.
Right click on the Start button and choose Command Prompt (admin). Then type "regedit" and press enter.
Go to File > Import > choose Fastboot.reg.
Reboot
NOT safe to reboot / Flash (partly) happened Errors (if you encounter one of them, DON’T reboot):
For “Error 152 Image Error" do:
- Error 152 is quite rare, have seen it only once with a friend’s phone and it aborted the flash nearly at the end. The flash was started by the FUU. We could resolve the matter by NOT rebooting the phone and flashing the zip again through a manual fastboot flash as outlined further up.
Click to expand...
Click to collapse
Good times. I guess just for completeness sake, let's mark htc_ocnuhl as "Asia / EMEA (Single SIM for carriers and HTC direct sales)" since HTC is selling it in the UK and possibly in other markets.
Thanks for the heads-up. Will correct as soon as I'm back home in an hour or two.
Sent from my htc_pmeuhl using XDA Labs
H3G, OrangeEU, EE, VodafoneUK, CHS RUUs found
Mornin' folks,
just a little informational heads-up. I've been able to find H3G, OrangeEU, EE, VodafoneUK, and CHS RUUs. Already saved them on my harddrive. As I'm away all day today, will try to upload them on saturday, or sunday so stay tuned.
Greeting s
5m4r7ph0n36uru
Interesting, Vodafone UK basically said they weren't getting the handset...
Flinny said:
Interesting, Vodafone UK basically said they weren't getting the handset...
Click to expand...
Click to collapse
2PZCIMG_OCEAN_UHL_N71_SENSE90GP_Vodafone_UK_1.03.161.6_Radio_8998-001791AE-1705110032_release_503500_signed_2_4.zip does exist though.
I'm not denying it, just very strange that it exists!. I wonder if it was a late decision to not stock it, or maybe it's only available to business customers. I've been with them forever and am making the jump to EE because of them not stocking htc phones anymore. EE just better not lock the bootloader or it's going straight back
Flinny said:
I've been with them forever and am making the jump to EE because of them not stocking htc phones anymore. EE just better not lock the bootloader or it's going straight back
Click to expand...
Click to collapse
Then 2PZCIMG_OCEAN_UHL_N71_SENSE90GP_EE_UK_1.03.91.6_Radio_8998-001791AE-1705092019_release_503492_signed_2_4.zip should be more up your alley )
I'll help for now yes, and it'll still be useful to pull some system/build.prop settings out of.
As long as I can unlock the bootloader I'll likely switch to SlimRoms as soon as I get it working, that'll likely require some kernel source first though!
Kisakuku said:
Then 2PZCIMG_OCEAN_UHL_N71_SENSE90GP_EE_UK_1.03.91.6_Radio_8998-001791AE-1705092019_release_503492_signed_2_4.zip should be more up your alley )
Click to expand...
Click to collapse
Flinny said:
I'll help for now yes, and it'll still be useful to pull some system/build.prop settings out of.
As long as I can unlock the bootloader I'll likely switch to SlimRoms as soon as I get it working, that'll likely require some kernel source first though!
Click to expand...
Click to collapse
Will upload this RUU at the weekend.
Sent from my htc_pmeuhl using XDA Labs
No rush for me, I grabbed it already. Noticed there are others on easy firmware also.
Finally received my AFH developer status. Uploading promised RUUs right now. Will transfer one of the RUUs on my GDrive to AFH later this week. As soon as all RUUs are up I'll update the currently missing links.
Sent from my htc_pmeuhl using XDA Labs
OP updated
Uploaded the following RUUs to my AFH account and added links accordingly
H3G,
OrangeEU,
EE,
VodafoneUK,
and CHS
Uploaded the following recoveries to my AFH account and added links accordingly
EE,
VodafoneUK
Whats next:
upload recoveries for H3G, OrangeEU, and CHS
Noticed that U11 firmware does not contain the good old 900+Kb aboot_signed.img. Instead it has a much smaller abl_signed.img of around 140 Kb, which has no red text warning string or any plain text string for that matter. Gets unarchived during boot?
BTW, US Unlocked 1.11.617.1 has been posted (2PZCIMG_OCEAN_WHL_N71_SENSE90GP_NA_Gen_Unlock_1.11.617.1_Radio_8998-001791-1705231845_release_505052_signed_2_4.zip).
Kisakuku said:
Noticed that U11 firmware does not contain the good old 900+Kb aboot_signed.img. Instead it has a much smaller abl_signed.img of around 140 Kb, which has no red text warning string or any plain text string for that matter. Gets unarchived during boot?
BTW, US Unlocked 1.11.617.1 has been posted (2PZCIMG_OCEAN_WHL_N71_SENSE90GP_NA_Gen_Unlock_1.11.617.1_Radio_8998-001791-1705231845_release_505052_signed_2_4.zip).
Click to expand...
Click to collapse
Thanks for your information. Already got three more and will upload them at the weekend. If I got enough time I'll as well unpack and upload all recoveries.
Sent from my htc_pmeuhl using XDA Labs
I dont take responsibility for possible damages!'
1. When you unlock the bootloader, all your data will be erased!
2. When you try to lock the bootloader, your data will be erased and you will lose the API.
3. YOU CAN RECEIVE OTA UPDATES WITH THE BOOTLOADER UNLOCKED!
Download the tool: https://forum.xda-developers.com/mi-a2/how-to/mi-a2-toolkit-unlock-bootloader-root-t3834585
1. Unlock the bootloader (I will not go into detail, the tool is intuitive, follow the tool's instructions!.)
2. Start your phone and enable USB debugging.
3. Put your cellphone in Fastboot.
4. In the tool, use option 4 (This will not install TWRP, just start) (follow the tool's instructions!)
5. When entering TWRP, if prompted, check "Keep system read only".
6. Open in the tool folder "Open CMD here"
7. Run the command: adb shell
8. Now enter the following command: "setprop persist.camera.HAL3.enabled 1" without quotation marks, and enter. - This command enables the required core API for GCAM.
9. Now type "exit" to exit adb.
10. Go back to the phone, in TWRP -> Reboot -> System -> Do Not Install
Ready.
I did this tutorial quickly. Any questions, use the comments!
Just a note. That tool is working with August security patch, but a lot of us received already September Security patch. And how do you know that we will receive OTA. Did you test by yourself? And btw, looks very easy and clear explained. For now I will wait for stable patch from Xiaomi, and updated Tool from the link you recomended. Thank you.
kaiwanted said:
Just a note. That tool is working with August security patch, but a lot of us received already September Security patch. And how do you know that we will receive OTA. Did you test by yourself? And btw, looks very easy and clear explained. For now I will wait for stable patch from Xiaomi, and updated Tool from the link you recomended. Thank you.
Click to expand...
Click to collapse
The tool just has the August picture. But the functions used for the gcam works in the September patch.
Yes. I have.
when i want to launch the TWRP, my device already plugged in and in fastboot mode, but it says "could not detect the active partition used, please ensure your phone is plugged in and in fastbook mode". How to fix this? tks
asuturo said:
when i want to launch the TWRP, my device already plugged in and in fastboot mode, but it says "could not detect the active partition used, please ensure your phone is plugged in and in fastbook mode". How to fix this? tks
Click to expand...
Click to collapse
I'm stuck at this too, i got the september update, already unlocked the bootloader but still can't install the twrp
"could not detect the active partition used, please ensure your phone is plugged in and in fastbook mode"
Rafaelboxer said:
I'm stuck at this too, i got the september update, already unlocked the bootloader but still can't install the twrp
"could not detect the active partition used, please ensure your phone is plugged in and in fastbook mode"
Click to expand...
Click to collapse
I think the September update change the active partition from A to B ( the August is A). Thats why it doesn´t work.
I´m also with September Update, and camera2api is the only thing i want to enable on Mi a2 ( don´t want to root and lose OTA) until a relliable TWRP is relleased.
This command should tell you which slot is active:
fastboot getvar current-slot
ki69 said:
I think the September update change the active partition from A to B ( the August is A). Thats why it doesn´t work.
I´m also with September Update, and camera2api is the only thing i want to enable on Mi a2 ( don´t want to root and lose OTA) until a relliable TWRP is relleased.
Click to expand...
Click to collapse
I got the september boot.img from another topic and rooted
Still no working solution for the ones that have setember update, and don´t want to root or use magisk??? I think the problem is that TWRP does not work with september update. Any easy way to downgrade to August again??
I'm thinking of installing Camera2API/GCamera, but I wonder if it's worth it. What are the real benefits? Does this make the camera compatible with more applications (eg Snapchat), avoiding them from making a screen of the camera ?
Hey guys i have some doubts.
I saw many threads saying to flash twrp into a partition (A or B) but i don't get why we have to flash it... So can someone clarify for me some stuff?
1 - fastboot boot twrp.img
I don't recall where the persist properties are stored but i believe it's not a partition that the OEM or google will constantly modify, right? So why making changes to the persist props in TWRP doesn't make it persist when booting into system? Is it possible to make it store it not temp?
Why there are people saying that flashing TWRP into, eg. part A, and booting into it, and then changing to part B, is working to enable the camera2 API? This should be the same as fastboot boot TWRP and then reboot it.
2 - As far as i remember, su permissions might be allowed in boot.img (.props file), so i thought that magisk patched image would have some su privilegies, but after booting from a patched image, su doesn't return anything. Does anyone knows what is the patched image from magisk? I heard about an app showing up after booting, so the patch is just a runnable with root?
3 - I also saw many threads changing sys build.prop directly. Horrible choice, but, does anyone knows if it possible to have a build.prop in OEM partition? From what i know, the build.prop will be concat. from all the folders related to the booting process. Has anyone tried to throw a build.prop into OEM with the persist enable? I believe that, since the folder is related to OEM only, and since we have no OEM making apps or whatever in an Android One phone, i think it is more safe than other partitions
ricardohnn said:
Hey guys i have some doubts.
I saw many threads saying to flash twrp into a partition (A or B) but i don't get why we have to flash it... So can someone clarify for me some stuff?
1 - fastboot boot twrp.img
I don't recall where the persist properties are stored but i believe it's not a partition that the OEM or google will constantly modify, right? So why making changes to the persist props in TWRP doesn't make it persist when booting into system? Is it possible to make it store it not temp?
Why there are people saying that flashing TWRP into, eg. part A, and booting into it, and then changing to part B, is working to enable the camera2 API? This should be the same as fastboot boot TWRP and then reboot it.
Click to expand...
Click to collapse
If you did a search on that 'persist' command, you'd find that it does persist, to many of the tables that type of information is stored in. It does not change the info in the properties file in 'System'. It does change the 'Data' partition, but that's okay, as there's only 1 of those (used no matters which slot boots up). The reason for booting on the non-active partition is a twrp / dual slot phone type of thing. I know it works as I've done it, but the 'setprop persist' changes the one and only Data partition, which both slots use, that's why it works.
ricardohnn said:
2 - As far as i remember, su permissions might be allowed in boot.img (.props file), so i thought that magisk patched image would have some su privilegies, but after booting from a patched image, su doesn't return anything. Does anyone knows what is the patched image from magisk? I heard about an app showing up after booting, so the patch is just a runnable with root?
Click to expand...
Click to collapse
I thought the patched image would have some su capabilities also, but it doesn't. It only installs the Magisk stub, which you can further install magisk from. Magisk is a great and sophisticated app. Has numerous Magisk modules which do a wide variety of things. But if you don't need any of those things, and don't need root, it's pretty over the top for just setting the cam2api, imho.
ricardohnn said:
3 - I also saw many threads changing sys build.prop directly. Horrible choice, but, does anyone knows if it possible to have a build.prop in OEM partition? From what i know, the build.prop will be concat. from all the folders related to the booting process. Has anyone tried to throw a build.prop into OEM with the persist enable? I believe that, since the folder is related to OEM only, and since we have no OEM making apps or whatever in an Android One phone, i think it is more safe than other partitions
Click to expand...
Click to collapse
If you change 'System' directly you will not get any OTA updates, so yer right, don't change that. There's no need to consider changing it anywhere else, as the 'setprop persist etc' command populates all the tables for you. 'System' is not affected and OTA updates will continue. There's no removing Magisk, restoring boot image, reinstalling etc etc etc.
One thing I would warn others about, using the various 'Tools'. You don't know what commands they are running, so you can't be sure what they will do. I say that because one of the tools I recently downloaded and went through and found the commands in it. The first thing it did after booting TWRP was to mount 'System' as Read / Write!! Why does that matter? From what I've read, doing that stops OTA from happening. Just mounting it R/W will change the date stamp on it concerning modifications, and that's all the OTA needs to know to say 'it's been modified'.
good luck, cheers
Agree with the data persist, but why do you need to flash into the different partition and not only boot from it?
I don't disagree that it will work, i just want to know why not boot from fastboot directly instead of flashing into one of the backup partition. I know that fastboot boot command triggers different code than usual flow. But not that i remember that it would affect something.
Getprop | grep camera would return if enabled right? Or nope?
ricardohnn said:
Agree with the data persist, but why do you need to flash into the different partition and not only boot from it?
I don't disagree that it will work, i just want to know why not boot from fastboot directly instead of flashing into one of the backup partition. I know that fastboot boot command triggers different code than usual flow. But not that i remember that it would affect something.
Getprop | grep camera would return if enabled right? Or nope?
Click to expand...
Click to collapse
The dual partition thing is new to everyone, I only understand bits and pieces, like everyone. But we do know there's no more 'recovery' partition, like we use to know. And we also know the way the dual works is that when an update occurs, if the device then try's to boot it and fails, it will automagically switch to the previous partition and boot it. Pretty sure we also know that booting and flashing are different with dual slot devices, but I'm not 100% sure how different.
I've tried booting twrp and just ended in bootloops. And that may be because of diff versions of TWRP, or it may be because of basic code all TWRP's have, not sure. But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images.
I do know for sure I didn't want to brick my phone (duh). So when I found a Magisk install guide, mentioned in my Guide thread, they used TWRP to install it. It sounded like an authoritative guide to me, re the part of getting TWRP to work. So I used that just to be able to run the setprop commands. Worked perfectly. Having to use the other (non active) partition **may** have something to do with avoiding triggering any automatic code to switch partitions unnecessarily, not sure, but not going to experiment any further to find out
Again, do some research on that setprop command, one of the things you'll find is that it doesn't populate all the appropriate tables until 'after' the device has been rebooted. So doing a getprop directly after doing the setprop won't work, not until it's been rebooted.
cheers
AsItLies said:
I've tried booting twrp and just ended in bootloops. And that may be because of diff versions of TWRP, or it may be because of basic code all TWRP's have, not sure. But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images.
Click to expand...
Click to collapse
I did manage to boot the last version of TWRP only first time, every other time ended in bootloops.
And I can sorry say that ADB did not work in booted TWRP, adb did not recognized the phone, so no commands could be typed.
For me, it is easier to flash patched_boot.img and install root temporarily, and then when job is done with activating camera2, uninstall root.
But hey, there are two easy ways, and everyone can choose which one is best suitable for them to try.
It would be of course easiest to just boot TWRP and enable camera2, but it doesn't work for now.
minnuss said:
I did manage to boot the last version of TWRP only first time, every other time ended in bootloops.
And I can sorry say that ADB did not work in booted TWRP, adb did not recognized the phone, so no commands could be typed.
For me, it is easier to flash patched_boot.img and install root temporarily, and then when job is done with activating camera2, uninstall root.
But hey, there are two easy ways, and everyone can choose which one is best suitable for them to try.
It would be of course easiest to just boot TWRP and enable camera2, but it doesn't work for now.
Click to expand...
Click to collapse
Yes, just 'booting' twrp has been problems for everyone, "that" doesn't work (not just now, but probably never).
But, following the Guide I wrote, and 'flashing it' does work. Right Now.
AsItLies said:
The dual partition thing is new to everyone, I only understand bits and pieces, like everyone. But we do know there's no more 'recovery' partition, like we use to know. And we also know the way the dual works is that when an update occurs, if the device then try's to boot it and fails, it will automagically switch to the previous partition and boot it. Pretty sure we also know that booting and flashing are different with dual slot devices, but I'm not 100% sure how different.
I've tried booting twrp and just ended in bootloops. And that may be because of diff versions of TWRP, or it may be because of basic code all TWRP's have, not sure. But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images.
I do know for sure I didn't want to brick my phone (duh). So when I found a Magisk install guide, mentioned in my Guide thread, they used TWRP to install it. It sounded like an authoritative guide to me, re the part of getting TWRP to work. So I used that just to be able to run the setprop commands. Worked perfectly. Having to use the other (non active) partition **may** have something to do with avoiding triggering any automatic code to switch partitions unnecessarily, not sure, but not going to experiment any further to find out
Again, do some research on that setprop command, one of the things you'll find is that it doesn't populate all the appropriate tables until 'after' the device has been rebooted. So doing a getprop directly after doing the setprop won't work, not until it's been rebooted.
cheers
Click to expand...
Click to collapse
About the setprop, even after the reboot isn't returning the prop, so that's why i am not sure if it is actually keeping it after twrp boot.
About the AB partition... well...
it's more or less like this...
let's say some simple partition scheme....
Preloader
Boot
System
Vendor
ODM
Data
So the phone will probably have many boot images type... like the usual boot.img or recovery.img (before treble) etc.
The boot.img will have the kernel image bla bla bla... since this is a google update, i believe that the AB partition procedures starts here (meaning all the relevant code of checking whether is A or B)
Google wanted to make things faster for the OEM (Samsung, LG etc) so they wanted to separate their ****s from google's one.
So (if things didn't change) you will have the following partitions now (actually i am not sure if they kept the system AB, but i believe so, since it seems to be working in other phones like that )
BootA
BootB
SystemA
SystemB
VendorA
VendorB
OEMA
OEMB
Data
So let's say google wants to update some security patches, from kernel til android, it will have to update boot and system. So in a OTA (changes if it is a google phone or a branded phone) before treble, it would update like... download the image containing boot and system into cache partition or data partition (depending the OTA size), after the download the update manager apk would set as a update booting and reboot your phone. Once booted, the phone would copy the partitions to the correct place (not being detailed) and rereboot. After the rereboot, if everything went normal, it would delete the downloaded image from your data/cache partition.
Now it's different like... instead of sending the update to the data partition and copying. It has a flag to set whether you are in A or B partition.
If you are (for eg.) in A partition, it will download the OTA to the B partition. (consider that in an untouched phone, A and B would have identical copies). So after downloading it, the flag is set to the B partition and reboot the phone. When booting, this time, it will not follow the A booting flow, like...
Before the update booting process would be
BootA
SystemA
VendorA
ODMA
Data
After the update the boot process will be
BootB
SystemB
VendorB
ODMB
Data
But i didn't update the vendor or ODM... why not keep in A? Because it's too hard to manage it.
So if anything fails in this update, it can easily go back into A booting process (which means you have a backup of your old boot).
Since system is too big, i am not sure if the system AB exists (it would just take up too much space... but anyway...).
It is also not a way to prevent bootloop, it is related to update. If an update fails (say, the image is corrupted or has no signature etc) the boot will change back, but if the update is "correct" it will boot as it should, even if the image is bad.
So again... when we do the fastboot boot boot.img, we are copying this boot into some cache or data to boot up, instead of our original boot. When we reboot, it will use the original boot. So, is there a difference from using twrp flashed and booted?
I know that fastboot boot will trigger different booting process (meaning signatures verifying etc) but don't think that it will not mount a partition or something...
Well... anyway... so after the reboot, when you setprop in TWRP, the getprop returned the prop correctly? I recall something about getprop not returning the prop but camera2 was enabled anyway with the setprop... well... can you just confirm one thing for me?
The steps you used was... fastboot flash patchboot and then reboot into twrp and then reboot back to usual partition.
You didn't do fastboot boot patched boot -> twrp -> reboot
Right?
---------- Post added at 09:44 AM ---------- Previous post was at 09:42 AM ----------
AsItLies said:
Yes, just 'booting' twrp has been problems for everyone, "that" doesn't work (not just now, but probably never).
But, following the Guide I wrote, and 'flashing it' does work. Right Now.
Click to expand...
Click to collapse
Oh didn't see this one. OK...
Damn... hmm... strange... well thanks anyway...
---------- Post added at 09:50 AM ---------- Previous post was at 09:44 AM ----------
AsItLies said:
The dual partition thing is new to everyone, I only understand bits and pieces, like everyone. But we do know there's no more 'recovery' partition, like we use to know. And we also know the way the dual works is that when an update occurs, if the device then try's to boot it and fails, it will automagically switch to the previous partition and boot it. Pretty sure we also know that booting and flashing are different with dual slot devices, but I'm not 100% sure how different.
I've tried booting twrp and just ended in bootloops. And that may be because of diff versions of TWRP, or it may be because of basic code all TWRP's have, not sure. But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images.
I do know for sure I didn't want to brick my phone (duh). So when I found a Magisk install guide, mentioned in my Guide thread, they used TWRP to install it. It sounded like an authoritative guide to me, re the part of getting TWRP to work. So I used that just to be able to run the setprop commands. Worked perfectly. Having to use the other (non active) partition **may** have something to do with avoiding triggering any automatic code to switch partitions unnecessarily, not sure, but not going to experiment any further to find out
Again, do some research on that setprop command, one of the things you'll find is that it doesn't populate all the appropriate tables until 'after' the device has been rebooted. So doing a getprop directly after doing the setprop won't work, not until it's been rebooted.
cheers
Click to expand...
Click to collapse
Oh by the way, i saw one part
"But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images. "
I think this is wrong (at least if TWRP team didn't change stuff), but all images are bootable images... (by all images i mean... boot.img recovery.img Flashing.img).
I once thought that they used a common kernel image, but in fact, all the booting process image has the kernel image copied (literally) to prevent brick. So even with a corrupted boot img, you still can boot into recovery or into download mode.
So that's why TWRP must have a kernel.
@ricardohnn, you seem hell bent on getting twrp to boot. Good luck. Let me know how that works out for you. In the meantime I'll be enjoying my cam2api working
cheers
AsItLies said:
@ricardohnn, you seem hell bent on getting twrp to boot. Good luck. Let me know how that works out for you. In the meantime I'll be enjoying my cam2api working
cheers
Click to expand...
Click to collapse
Actually TWRP boots fine with fastboot boot...
ADB runs smooth, but it just won't keep.
But you've made me envy LOL
I will think about flashing... later...
ricardohnn said:
Actually TWRP boots fine with fastboot boot...
ADB runs smooth, but it just won't keep.
But you've made me envy LOL
I will think about flashing... later...
Click to expand...
Click to collapse
What version of TWRP did you use, there is now two versions, I used last one, from a few days ago, and in first try I did manage to boot from fastboot, not flash it, but ADB did not worked.
So, if adb did work for you, maybe it was earlier version ?
Anyway, as you say, it is not permanent setprop, maybe because the twrp is not stable one, or maybe it needs to be flashed to work, not just booted.
I personally do not have doubts that this tutorial works, I just did not want to flash twrp. :good:
TWRP Custom Recovery for the Onn Android Tablet series
This is the first fully-featured custom recovery for Walmart's MediaTek-based Onn tablets: ONA19TB002, ONA19TB003 and ONA19TB007. TWRP needs no introduction. If you have come here, you probably have some idea of what it is and what it's used for. This TWRP build does not need the bootloader unlocked or VBMeta verification disabled, although it's recommended that you at least unlock the bootloader.
DISCLAIMER
Everything described in this thread is done at your own risk. No one else will be responsible for any data loss, corruption or damage of your device, including that which results from bugs in this software.
FEATURES
Decrypted data partition
All USB modes functional: MTP, ADB, Mass Storage, OTG, Charging
Fast boot time
Adoptable storage mounting
Firmware image backup and restore
Works under locked bootloader
Android 9 build fits within the 16MB recovery partition -- no compromises or partition resizing necessary
INSTALLATION METHOD 1
Download the recovery to your PC and unzip the image
Unlock the bootloader (skip if you have already done this)
Enable OEM Unlock in Developer Options in Android Settings
Boot into fastboot mode either by holding vol. up+power to power it on and selecting "Fastboot mode", or by running the 'adb reboot bootloader' command from within Android.
Install fastboot and appropriate drivers on your PC if you have not set those up
Unlock the bootloader with the command
Code:
fastboot flashing unlock
...and follow the instructions on the screen. This will wipe your data.
Flash the custom recovery with
Code:
fastboot flash recovery twrp-3.3.1-ONA19TB002.img
(use the right file name path for your device)
Reboot to recovery with
Code:
fastboot oem reboot-recovery
INSTALLATION METHOD 2
This assumes you are familiar with SP Flash Tool or can figure it out on your own
Download the recovery to your PC and unzip the image
Get the appropriate scatter file for your device. The scatter file may be found in the device's firmware under /system/data/misc.
Set up SPFT Download tab as Download Only. Load your scatter file.
Under the recovery line, double-click Location and open your TWRP image.
Click Download and connect your powered-off tablet to your PC. SPFT will automatically flash the recovery to the emmc and disconnect when finished.
INSTALLATION METHOD 3
Head over to Amazing Temp Root for MediaTek ARMv8, read the requirements and directions, and grab the latest mtk-su.
Open a root shell with mtk-su
Flash the (unzipped) recovery with the command:
Code:
dd bs=1048576 if=twrp-3.3.1-0-ONA19TB002.img of=/dev/block/by-name/recovery
(replace the if= file name with your appropriate recovery image path)
Exit root shell
START RECOVERY
Three methods:
On a powered off tablet, hold Vol. up+power for about 3 seconds. In the menu that appears, select "Recovery mode"
With Android ADB, use the command 'adb reboot recovery'
From Android root shell, use the command 'reboot recovery' or just use any root app with OS reboot features
NOTES
Kind of important: Make a backup of your Crypto Footer as soon as you can. This is the encryption key to your data partition. When accessed from TWRP, this key can get "upgraded" so that you will get locked out of Android. TWRP uses a hacky workaround that saves and restores the original footer on every /data decrypt. But that method is not what I would call 100% reliable.
Make sure you have a backup of the untouched stock system and vendor images. There are no official firmware packages available to download.
Only mount system/vendor partitions in read/write mode if you have unlocked the bootloader. It is recommended to choose to leave system read-only at the startup prompt unless you have a specific reason to modify it. If the bootloader is locked, then dm-verity is enforced.* So merely mounting it once in r/w will cause a boot loop.
It's currently not possible to install incremental OTA updates using this TWRP. Use the stock recovery to update the FW. That will only work if you have never mounted system/vendor in write mode.
DOWNLOAD (Nov. 30, 2019)
Current version: 3.3.1-1
ONA19TB002 - Onn 8" model
ONA19TB003 - Onn 10.1" model
ONA19TB007 - Onn 10.1" w/keyboard model
Source code
ONA19TB002 | ONA19TB003 | ONA19TB007
ACKNOWLEDGEMENTS
The team behind TWRP & OmniROM
@tek3195 for testing and feedback on the 8" model
Please post feedback since these are still pretty new and not exhaustively tested. Let me know if I should port it to other models in the series.
Reserved also
grabbing this one too cuz why not
Very nice! I'll download and test the 003 one soon.
I also have a 007 model to experiment with.
I tried about a dozen times to build TWRP and failed miserably LOL. Closest I got was one that would boot but the rotation was all messed up, USB wouldn't work, didn't mount some partitions... Yeah, it was a hot mess.
Do you happen to have sources available?
Hi @NFSP G35,
I'll have the source code soon. Most of the tricks involved patching bootable/recovery. So I need to commit those changes and include the proper patch set from my tree....
Amazing!! Gonna install and test 8" right now.
Has anyone tried a GSI on these tablets yet?
MishaalRahman said:
Has anyone tried a GSI on these tablets yet?
Click to expand...
Click to collapse
I do know @tek3195 , the Onn 8 thread starter, has tried many of them as well as others here, somewhere on that thread he listed his tests and opinion of several of them.
I'm pretty sure others on that thread have also tried GSI's.
MishaalRahman said:
Has anyone tried a GSI on these tablets yet?
Click to expand...
Click to collapse
I did try both Phhuson vanilla and also Liquid Remix (I'm keeping this one for now). I didn't flash them through twrp, but using fastboot via bootloader.
WoW! AwEsOmE! I cannot wait to try this! THANK YOU!!!!!!
Hey,
This is a neat thing to see for the Onn tablets. I have a question though. I own a device based on the mt8163, and am trying to help people with another device I don't own (the powkiddy x18 which also uses the mt8163). One of the things I wanted to do was to make a custom rom for the x18, since it's stock firmware is horrible. And of course, one of the first steps to custom roms is twrp. So I have a question for you that I hope you can answer for me. How did you make this build of twrp? I have seen no device trees for this device so I was kinda curious. If you can help me in any way, I'd be so grateful, and I'm sure the other people with the x18 would be grateful for help.
@diplomatic
Is there a different procedure for installing TWRP on a locked bootloader?
I can confirm that using SP Flash to load your TWRP.img will produce a bootloop when installing to a device with the BL locked. Reflashing the original recovery.img makes the problem go away. You mentioned in the OP that this TWRP will work on a locked BL so I thought I would share my case study with you in following the procedure you defined.
MY SINCERE GRATITUDE FOR YOUR EFFORTS IN PORTING THIS TO THE ONN!
You're welcome, @Spatry.... Can you describe how you ended up with a locked BL? Was it unlocked before? Have you ever tweaked vbmeta? Also, when you say bootloop, do you mean for Android or just for recovery? I'm not going to insist that it works under locked BL. I tested it once and it did boot up...
diplomatic said:
You're welcome, @Spatry.... Can you describe how you ended up with a locked BL? Was it unlocked before? Have you ever tweaked vbmeta? Also, when you say bootloop, do you mean for Android or just for recovery? I'm not going to insist that it works under locked BL. I tested it once and it did boot up...
Click to expand...
Click to collapse
Presently, I am running stock with Magisk patched BOOT on locked bootloader, stock vbmeta. The boot loop was at the ONN Android screen, I could not get it to even boot into recovery.
At one time I did run with the bootloader unlocked (with --disable-verification on stock vbmeta) and I ran Phusson's AOSP, Liquid Remix and Bliss. I found there was no benefit to me in running the other mods so I reverted back to stock courtesy of @CaffeinePizza and the bootloader re-locked to get rid of that annoying 5 second orange state.
In each instance, I always used SP Flash tools to load all .img files. I only used fastboot to install magisk_patched.img onto the stock installation. Unlocking the bootloader erases all data and I did not feel like reinstalling everything again, so I figured I would try to install TWRP per your instruction to see if it would work while the BL was still locked... Restoring the original recovery got rid of the bootloop. I do want to try your TWRP so I will try it with BL unlocked when I get some free time to do so.
Spatry said:
Presently, I am running stock with Magisk patched BOOT on locked bootloader, stock vbmeta. The boot loop was at the ONN Android screen, I could not get it to even boot into recovery.
Click to expand...
Click to collapse
This sounds like you might have flashed a wrong/corrupt image to recovery. It may have to do with AVB checks rather than bootloader lock. But those conditions might be interdependent somehow so I can't tell you for sure. The fact that you are able to boot a patched image on a locked BL says it doesn't care too much about verification. I can tell you for sure that any recovery image must have avb metadata, not necessarily the required hash, for both Android and recovery to boot. Can you try to unzip the image file and flash it over again?
Hmm, the situation with the bootloader lock sounds eerily similar to the Nabi SE. The latter also had a similar implementation where there's not much in the way of locking things down, other than an (easily circumvented) SP Flash Tool signature check and different preloader keys. And here's the real kicker: the nearly-identical Fisher Price Nabi also ran on the MT8163, so it makes me wonder if it's possible to boot Pie on it, or perhaps a GSI assuming that Treble can be tacked onto it.
Also, do you have the source repo to this TWRP port of yours?
If anyone here gave me an XDA ad-free subscription, thanks a lot! I didn't get a notification of who it was. Using this site is a lot more bearable now.
diplomatic said:
If anyone here gave me an XDA ad-free subscription, thanks a lot! I didn't get a notification of who it was. Using this site is a lot more bearable now.
Click to expand...
Click to collapse
Where do I find crypto footer to backup
diplomatic said:
If anyone here gave me an XDA ad-free subscription, thanks a lot! I didn't get a notification of who it was. Using this site is a lot more bearable now.
Click to expand...
Click to collapse
Kinda cool without the ads isn't it. I know I sent one about a week ago or so. I think everybody ought to send you one, you deserve it. THANKS and AWESOME work.
DOES NOT WORK WITH NEW FIRMWARES FOR ANDROID 12! WILL NOT BOOT AND YOU WILL FIND YOURSELF IN EDL MODE TRYING TO UNBRICK YOUR PHONE.
Similar to https://forum.xda-developers.com/t/guide-re-locking-the-bootloader-on-the-oneplus-8t-with-a-self-signed-build-of-los-18-1.4259409/ but for pre-built custom ROMs, such as official LineageOS.
WARNING: This will wipe your data - as far as I know there is no way to change the bootloader status (locked/unlocked) without a wipe.
IMPORTANT
If you mount ANY partition R/W after installing your ROM, you will no longer be able to boot. This means you will not be able to install ANY flash-able zips, INCLUDING GAPPS!
You will still get a warning message on boot, though it will be yellow rather than orange and just point out that your operating system is custom.
It is unlikely it will fix your banking app, as the bootloader status will be yellow (rather than orange/red for unlocked).
If your ROM developer's verity key changes and you update, you will be stuck and not be able to get back to a working device without wiping your data.
In short this is pointless, carries a lot of risk and the only benefit you get is the questionable extra security of a locked bootloader that will only load an operating system that is signed by a key that you have explicitly trusted.
So how to do it?
STEP 1:
Download your ROM (eg: official LineageOS, or LineageOS with MicroG). Keep the ZIP to one side as we will need it later.
STEP 2:
Unlock your bootloader and install your ROM as normal, following the instructions given by the ROM maintainer. You must NOT flash any flash-able zips after installing the ROM or you will no longer be able to boot.
At this stage it is assumed you have your chosen ROM installed and your boot loader is unlocked.
STEP 3:
On your computer, extract the ZIP file containing the ROM.
STEP 4:
Use: payload dumper to extract the payload.bin file.
STEP 5:
Use: this tool to extract the public key from the vbmeta.img file.
Code:
ruby ./run.rb ./extracted/vbmeta.img output
This will generate "output.pem" and "output.img".
STEP 6:
Reboot into fastboot, run:
Code:
fastboot erase avb_custom_key
fastboot flash avb_custom_key ./output.img
fastboot oem lock
At this point your phone should reboot, wipe itself, have a locked boot loader and successfully boot your ROM of choice. When upgrading in the future you can extract the public key in the same way and compare it to the one you have loaded into fastboot to ensure you won't be forced into having to wipe your device again.
If something goes wrong and your ROM does not boot and gives a red error about corrupt OS, you will need to unlock the bootloader again in order for things to work.
Very nice! Will i be able to flash magisk before and still be ok?
I don't know (sorry) I've never used Magisk. I think it modifies the boot image right? If so I don't expect it would work as the boot image signature must match the one that is in the vbmeta image.
rlees85 said:
Similar to https://forum.xda-developers.com/t/guide-re-locking-the-bootloader-on-the-oneplus-8t-with-a-self-signed-build-of-los-18-1.4259409/ but for pre-built custom ROMs, such as official LineageOS.
WARNING: This will wipe your data - as far as I know there is no way to change the bootloader status (locked/unlocked) without a wipe.
IMPORTANT
If you mount ANY partition R/W after installing your ROM, you will no longer be able to boot. This means you will not be able to install ANY flash-able zips, INCLUDING GAPPS!
You will still get a warning message on boot, though it will be yellow rather than orange and just point out that your operating system is custom.
It is unlikely it will fix your banking app, as the bootloader status will be yellow (rather than orange/red for unlocked).
If your ROM developer's verity key changes and you update, you will be stuck and not be able to get back to a working device without wiping your data.
In short this is pointless, carries a lot of risk and the only benefit you get is the questionable extra security of a locked bootloader that will only load an operating system that is signed by a key that you have explicitly trusted.
So how to do it?
STEP 1:
Download your ROM (eg: official LineageOS, or LineageOS with MicroG). Keep the ZIP to one side as we will need it later.
STEP 2:
Unlock your bootloader and install your ROM as normal, following the instructions given by the ROM maintainer. You must NOT flash any flash-able zips after installing the ROM or you will no longer be able to boot.
At this stage it is assumed you have your chosen ROM installed and your boot loader is unlocked.
STEP 3:
On your computer, extract the ZIP file containing the ROM.
STEP 4:
Use: payload dumper to extract the payload.bin file.
STEP 5:
Use: this tool to extract the public key from the vbmeta.img file.
Code:
ruby ./run.rb ./extracted/vbmeta.img output
This will generate "output.pem" and "output.img".
STEP 6:
Reboot into fastboot, run:
Code:
fastboot erase avb_custom_key
fastboot flash avb_custom_key ./output.img
fastboot oem lock
At this point your phone should reboot, wipe itself, have a locked boot loader and successfully boot your ROM of choice. When upgrading in the future you can extract the public key in the same way and compare it to the one you have loaded into fastboot to ensure you won't be forced into having to wipe your device again.
If something goes wrong and your ROM does not boot and gives a red error about corrupt OS, you will need to unlock the bootloader again in order for things to work.
Click to expand...
Click to collapse
Thank You Soooooooo much, may God bless you always. By the way it's working with LineageOS microG as well.
rlees85 said:
Similar to https://forum.xda-developers.com/t/guide-re-locking-the-bootloader-on-the-oneplus-8t-with-a-self-signed-build-of-los-18-1.4259409/ but for pre-built custom ROMs, such as official LineageOS.
WARNING: This will wipe your data - as far as I know there is no way to change the bootloader status (locked/unlocked) without a wipe.
IMPORTANT
If you mount ANY partition R/W after installing your ROM, you will no longer be able to boot. This means you will not be able to install ANY flash-able zips, INCLUDING GAPPS!
You will still get a warning message on boot, though it will be yellow rather than orange and just point out that your operating system is custom.
It is unlikely it will fix your banking app, as the bootloader status will be yellow (rather than orange/red for unlocked).
If your ROM developer's verity key changes and you update, you will be stuck and not be able to get back to a working device without wiping your data.
In short this is pointless, carries a lot of risk and the only benefit you get is the questionable extra security of a locked bootloader that will only load an operating system that is signed by a key that you have explicitly trusted.
So how to do it?
STEP 1:
Download your ROM (eg: official LineageOS, or LineageOS with MicroG). Keep the ZIP to one side as we will need it later.
STEP 2:
Unlock your bootloader and install your ROM as normal, following the instructions given by the ROM maintainer. You must NOT flash any flash-able zips after installing the ROM or you will no longer be able to boot.
At this stage it is assumed you have your chosen ROM installed and your boot loader is unlocked.
STEP 3:
On your computer, extract the ZIP file containing the ROM.
STEP 4:
Use: payload dumper to extract the payload.bin file.
STEP 5:
Use: this tool to extract the public key from the vbmeta.img file.
Code:
ruby ./run.rb ./extracted/vbmeta.img output
This will generate "output.pem" and "output.img".
STEP 6:
Reboot into fastboot, run:
Code:
fastboot erase avb_custom_key
fastboot flash avb_custom_key ./output.img
fastboot oem lock
At this point your phone should reboot, wipe itself, have a locked boot loader and successfully boot your ROM of choice. When upgrading in the future you can extract the public key in the same way and compare it to the one you have loaded into fastboot to ensure you won't be forced into having to wipe your device again.
If something goes wrong and your ROM does not boot and gives a red error about corrupt OS, you will need to unlock the bootloader again in order for things to work.
Click to expand...
Click to collapse
If I may to ask, Why the OEM unlocking toggle doesn't appear in the Developer options menu after the steps above done successfully ?
ahmed.elsersi said:
If I may to ask, Why the OEM unlocking toggle doesn't appear in the Developer options menu after the steps above done successfully ?
Click to expand...
Click to collapse
The offical builds of LineageOS do not inlcude the OEM lock option in them for the 7/7Pro/8T (maybe others), so it does not appear in developers options.
To get it you'd have to recomiple LineageOS (maybe tweak build.props?).
Anyone thinking of doing this might be interested in a post I made over on reddit talking about relocking, which includes info on why using pre buildt ROM is probably a bad idea.
WhitbyGreg said:
The offical builds of LineageOS do not inlcude the OEM lock option in them for the 7/7Pro/8T (maybe others), so it does not appear in developers options.
To get it you'd have to recomiple LineageOS (maybe tweak build.props?).
Click to expand...
Click to collapse
Thank you, I appreciate it.
rlees85 said:
Similar to https://forum.xda-developers.com/t/guide-re-locking-the-bootloader-on-the-oneplus-8t-with-a-self-signed-build-of-los-18-1.4259409/ but for pre-built custom ROMs, such as official LineageOS.
WARNING: This will wipe your data - as far as I know there is no way to change the bootloader status (locked/unlocked) without a wipe.
IMPORTANT
If you mount ANY partition R/W after installing your ROM, you will no longer be able to boot. This means you will not be able to install ANY flash-able zips, INCLUDING GAPPS!
You will still get a warning message on boot, though it will be yellow rather than orange and just point out that your operating system is custom.
It is unlikely it will fix your banking app, as the bootloader status will be yellow (rather than orange/red for unlocked).
If your ROM developer's verity key changes and you update, you will be stuck and not be able to get back to a working device without wiping your data.
In short this is pointless, carries a lot of risk and the only benefit you get is the questionable extra security of a locked bootloader that will only load an operating system that is signed by a key that you have explicitly trusted.
So how to do it?
STEP 1:
Download your ROM (eg: official LineageOS, or LineageOS with MicroG). Keep the ZIP to one side as we will need it later.
STEP 2:
Unlock your bootloader and install your ROM as normal, following the instructions given by the ROM maintainer. You must NOT flash any flash-able zips after installing the ROM or you will no longer be able to boot.
At this stage it is assumed you have your chosen ROM installed and your boot loader is unlocked.
STEP 3:
On your computer, extract the ZIP file containing the ROM.
STEP 4:
Use: payload dumper to extract the payload.bin file.
STEP 5:
Use: this tool to extract the public key from the vbmeta.img file.
Code:
ruby ./run.rb ./extracted/vbmeta.img output
This will generate "output.pem" and "output.img".
STEP 6:
Reboot into fastboot, run:
Code:
fastboot erase avb_custom_key
fastboot flash avb_custom_key ./output.img
fastboot oem lock
At this point your phone should reboot, wipe itself, have a locked boot loader and successfully boot your ROM of choice. When upgrading in the future you can extract the public key in the same way and compare it to the one you have loaded into fastboot to ensure you won't be forced into having to wipe your device again.
If something goes wrong and your ROM does not boot and gives a red error about corrupt OS, you will need to unlock the bootloader again in order for things to work.
Click to expand...
Click to collapse
Great.
Thanks a lot. This worked also perfectly after installing LineageOS on enchilada (OnePlus 6).
See https://wiki.lineageos.org/devices/enchilada/install
Similar to https://forum.xda-developers.com/t/guide-re-locking-the-bootloader-on-the-oneplus-8t-with-a-self-signed-build-of-los-18-1.4259409/ but for pre-built custom ROMs, such as official LineageOS.
WARNING: This will wipe your data - as far as I know there is no way to change the bootloader status (locked/unlocked) without a wipe.
IMPORTANT
If you mount ANY partition R/W after installing your ROM, you will no longer be able to boot. This means you will not be able to install ANY flash-able zips, INCLUDING GAPPS!
You will still get a warning message on boot, though it will be yellow rather than orange and just point out that your operating system is custom.
It is unlikely it will fix your banking app, as the bootloader status will be yellow (rather than orange/red for unlocked).
If your ROM developer's verity key changes and you update, you will be stuck and not be able to get back to a working device IndigoCard Login without wiping your data.
In short this is pointless, carries a lot of risk and the only benefit you get is the questionable extra security of a locked bootloader that will only load an operating system that is signed by a key that you have explicitly trusted.
Click to expand...
Click to collapse
Thanks for the information you shared. Loved the way you explained everything in this blog.
I've gotten to the stage of
Code:
ruby ./run.rb ./extracted/vbmeta.img output
Except I run it directly in the output folder from the payload_dumper process.
When I run it, I get
Code:
ruby ./run.rb ./vbmeta.img output
Traceback (most recent call last):
1: from ./run.rb:46:in `<main>'
./run.rb:46:in `require_relative': cannot load such file -- /home/peter/Phone/phonec/output/lib/AvbVBMetaFooter.rb (LoadError)
It's looking for lib/AvbVBMetaFooter.rb. I've googled that, looked into the run.rb script, and can't find it.
Does anyone have an idea on this?
thanks very much
yiwogir691 said:
Very nice! Will i be able to flash magisk before and still be ok?
Click to expand...
Click to collapse
Working for you?
Scotm95 said:
Thanks for the information you shared. Loved the way you explained everything in this blog.
Click to expand...
Click to collapse
Working for you ?
jetcollins said:
I've gotten to the stage of
Code:
ruby ./run.rb ./extracted/vbmeta.img output
Except I run it directly in the output folder from the payload_dumper process.
When I run it, I get
Code:
ruby ./run.rb ./vbmeta.img output
Traceback (most recent call last):
1: from ./run.rb:46:in `<main>'
./run.rb:46:in `require_relative': cannot load such file -- /home/peter/Phone/phonec/output/lib/AvbVBMetaFooter.rb (LoadError)
It's looking for lib/AvbVBMetaFooter.rb. I've googled that, looked into the run.rb script, and can't find it.
Does anyone have an idea on this?
thanks very much
Click to expand...
Click to collapse
Late reply, sorry, you need to clone the whole repo and not just copy and paste run.rb
The missing files are in the same repo as run.rb
Does anyone tried this guide recently and worked?
Haven't tried it since November but I'm still having the setup running on my phone and auto updates worked without flaws so far.
Has anyone gotten this to work on a OP9 and/or Lineage 19? I was able to follow all the steps and I got a build that I think should work. In fact, it does work until I actually do the re-lock, at which point I get the red broken OS boot screen.
srwalter said:
Has anyone gotten this to work on a OP9 and/or Lineage 19? I was able to follow all the steps and I got a build that I think should work. In fact, it does work until I actually do the re-lock, at which point I get the red broken OS boot screen.
Click to expand...
Click to collapse
[GUIDE] Re-locking the bootloader on the OnePlus 8t with a self-signed build of LOS 18.1
What is this tutorial? This tutorial will: Creating an unofficial build of LineageOS 18.1 suitable for using to re-lock the bootloader on a OnePlus 8t Take you through the process of re-locking your bootloader after installing the above This...
forum.xda-developers.com
I am preparing to update my OnePlus 8T to LineageOS 19.1 MicroG edition. So far I've confirmed the key used for LineageOS 18.1 MicroG edition is the same so I shouldn't have to re-fiddle with any partitions/keys.
When I finally update I will post back here if I screw my phone/get the red message.