Database Develop

Porting (Kang) Keymaster Firmware

Anyone ever attempted to kang Keymaster Firmware from a different device? I have tried the firmware from bacon, hammerhead, and g3. I have tried with and without the TARGET_KEYMASTER_WAIT_FOR_QSEE flag.
See these commits:
https://github.com/blastagator/cm_d...mmit/a50026b03824e65e852dc975e369f89a6e8e33a6
https://github.com/blastagator/them...mmit/b5951a58a4df5cabc8f928fae2476629cc73b1fa
https://github.com/blastagator/LGG2_Kernel/commit/655b64e43cbcd4550671cadf8bc19b6c495b3190
The result is always the same in dmesg:
Code:
[0][4371: keystore]QSEECOM: qseecom_load_app: App (keymaster) does'nt exist, loading apps for first time
[0][4371: keystore]QSEECOM: qseecom_load_app: scm_call failed resp.result unknown, -12
[0][4371: keystore]QSEECOM: qseecom_ioctl: failed load_app request: -14
This is the only related thing I've found:
http://androidforums.com/threads/beta-4-4-2-stock-kitkat.952314/
Very old and no answer.
I suspect the firmware might be signed to the device type and thus we might be SOL, but I was bored and messing around. Alternatively, perhaps the kernel is missing something. I looked for commits that may be missing from qseecom.c and smc.c, but nothing jumped out at me.
Figured I'd post a dev thread and maybe we can find an answer.
edit: This is my cheat sheet to myself, so far, for how to add hardware crypto to a device:
Code:
Needed commits:
Probable problem: G2 has no keymaster firmware, need to borrow someone else's
See this commit:
https://github.com/blastagator/themuppets_proprietary_vendor_lge/commit/b5951a58a4df5cabc8f928fae2476629cc73b1fa
g2-common/g2-common-vendor-blobs.mk
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.b00:system/vendor/firmware/keymaster/keymaster.b00 \
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.b01:system/vendor/firmware/keymaster/keymaster.b01 \
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.b02:system/vendor/firmware/keymaster/keymaster.b02 \
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.b03:system/vendor/firmware/keymaster/keymaster.b03 \
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.mdt:system/vendor/firmware/keymaster/keymaster.mdt \
And, actually put the files in that folder, so they get copied.
CRUCIAL: MUST match this name and path!!! (Other things like keymaste.mdt and such are for if the files are in the modem)
Also, symlinks are NOT needed if we put the file into proprietary like this!
Device commit:
https://github.com/blastagator/cm_device_lge_g2-common/commit/a50026b03824e65e852dc975e369f89a6e8e33a6
BoardConfig
+# Encryption / Keymaster
+TARGET_HW_DISK_ENCRYPTION := true
+TARGET_KEYMASTER_WAIT_FOR_QSEE := true
+
NOTE: Not sure about wait_for_qsee --- MAYBE needed????
g2.mk
+# Keystore
+PRODUCT_PACKAGES += \
+ keystore.msm8974
+
Note: The resulting /system image will have TWO keystore files, this is correct
I checked a bacon image to confirm there are supposed to be two. One labeled msm8974 & one labeled default
Probable needed kernel changes:
Config
-# CONFIG_DM_REQ_CRYPT is not set
+CONFIG_DM_REQ_CRYPT=y
-# CONFIG_CRYPTO_DEV_QCRYPTO is not set
+CONFIG_CRYPTO_DEV_QCRYPTO=y
If dm-req-crypt.c doesn't build, need this commit:
https://github.com/blastagator/LGG2_Kernel/commit/50ddb1a013065cefa35151e9ded72aadcd210611
(platform: msm: Fix compile when CONFIG_PFT is not set)
include/linux/pft.h
-static inline int pft_get_key_index(struct inode *inode, u32 *key_index,
+static inline int pft_get_key_index(struct bio *bio, u32 *key_index,

blastagator said:
Anyone ever attempted to kang Keymaster Firmware from a different device?
Click to expand...
Click to collapse
Maybe, you have to add something like this:
https://github.com/CyanogenMod/andr...mmit/595cf776441389d147f4b4e7ec316aa02d74d14e

Rangell11 said:
Maybe, you have to add something like this:
https://github.com/CyanogenMod/andr...mmit/595cf776441389d147f4b4e7ec316aa02d74d14e
Click to expand...
Click to collapse
That is for if the firmware is in the /modem partition. I know it's finding the firmware because if I remove the files the error messages go away and the keystore service crashes without a specific error.
I've also insured permissions 0644 on the files and I've put selinux in permissive to see if that would help, but same errors.

blastagator said:
I've also insured permissions 0644 on the files and I've put selinux in permissive to see if that would help, but same errors.
Click to expand...
Click to collapse
Like this??
http://review.cyanogenmod.org/#/c/155981/
Did you try this?
http://review.cyanogenmod.org/#/c/137146/
PS:
I think our G2 not support TARGET_KEYMASTER_WAIT_FOR_QSEE flag.
http://review.cyanogenmod.org/#/c/102410/

Rangell11 said:
Like this??
http://review.cyanogenmod.org/#/c/155981/
Click to expand...
Click to collapse
After clean boot I used "setenforce 0" to see if it would load after that. (keystore service keeps repeatedly attempting to load in the background and can be seen with 'dmesg'.) Disabling enforcing should have solved any selinux problem, but the same error persisted.
Rangell11 said:
Did you try this?
http://review.cyanogenmod.org/#/c/137146/
Click to expand...
Click to collapse
Keymaster is in the system partition and not the modem partition (for my tests anyway), so this wouldn't be needed. I will say the contact was not 'context=ubject_r:firmware_file:s0', it was listed as a regular system file, however, in permissive mode this should not matter. Maybe I will try another test when I have some time where the ROM is compiled permissive and the files have the correct context.
I don't think it is this issue though, as the keymaster firmware is found and qseecomd is attempting to load it.
Rangell11 said:
PS:
I think our G2 not support TARGET_KEYMASTER_WAIT_FOR_QSEE flag.
http://review.cyanogenmod.org/#/c/102410/
Click to expand...
Click to collapse
Thanks. I did some testing and tried both, no luck with either.
Looks like there are at least a couple updates to scm that I could try:
https://github.com/dorimanx/DORIMANX_LG_STOCK_LP_KERNEL/commits/master/arch/arm/mach-msm/scm.c
https://github.com/dorimanx/DORIMANX_LG_STOCK_LP_KERNEL/commits/master/drivers/misc/qseecom.c
Will try updating kernel when I have some free time.
edit: Pulled in a bunch of kernel changes and compiled the boot image to be permissive:
https://github.com/blastagator/LGG2_Kernel/commits/cm-13.0
Still the same error codes.
Code:
[ 0.480347 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: support_bus_scaling=0x1
[ 0.480356 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: disk-encrypt-pipe-pair=0x2
[ 0.480365 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: file-encrypt-pipe-pair=0x0
[ 0.480374 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: qsee-ce-hw-instance=0x0
[ 0.480382 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: qseecom.appsbl_qseecom_support = 0x0
[ 0.480421 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: secure app region addr=0x7b00000 size=0x500000
[ 3.174366 / 01-13 05:47:06.160] init: Starting service 'qseecomd'...
[ 3.207945 / 01-13 05:47:06.193] init: Starting service 'keystore'...
[ 3.221661 / 01-13 05:47:06.206] warning: `qseecomd' uses 32-bit capabilities (legacy support in use)
[ 3.476387 / 01-01 05:47:06.146] QSEECOM: qseecom_load_app: App (keymaster) does'nt exist, loading apps for first time
[ 3.476494 / 01-01 05:47:06.146] QSEECOM: qseecom_load_app: scm_call failed resp.result unknown, -12
[ 3.476511 / 01-01 05:47:06.146] QSEECOM: qseecom_ioctl: failed load_app request: -14
[ 3.477964 / 01-01 05:47:06.146] init: Service 'keystore' (pid 275) exited with status 1
[ 3.477985 / 01-01 05:47:06.146] init: Service 'keystore' (pid 275) killing any children in process group
The last 5 lines just repeat indefinitely.
.

blastagator said:
After clean boot I used "setenforce 0" to see if it would load after that. (keystore service keeps repeatedly attempting to load in the background and can be seen with 'dmesg'.) Disabling enforcing should have solved any selinux problem, but the same error persisted.
Click to expand...
Click to collapse
Do you know why they did not use this change for our G2?
http://review.cyanogenmod.org/#/c/89419/
http://review.cyanogenmod.org/#/c/89418/

Rangell11 said:
Do you know why they did not use this change for our G2?
http://review.cyanogenmod.org/#/c/89419/
http://review.cyanogenmod.org/#/c/89418/
Click to expand...
Click to collapse
qcrypto is currently disabled, so there wouldn't be a need to apply similar patches to the current kernel, unless HW encryption were figured out.
I added those two commits, but I doubt this is the issue.

@blastagator
I've pushed my keymaster to Github: https://github.com/GalaticStryder/hardware_qcom_keymaster
This is the one we use on bacon and onyx on AOSPA builds.
Backporting 3.10 qseecom isn't needed and probably will break the APIs the blobs were compiled for. I'm gonna test this on nougat as well right now.
I'd actually ask for your help on AOSPA, I've got a semi-working RIL and some other great stuff to play with but I can't get the built-in kernel to boot after flashing, only boots when flashing my kernel externally.
The image is bumped, the mkbootimg was revisited twice but there's no go. I don't want to ship a prebuilt image to workaround this. I've tried CM14 kernel with my GCC 4.9 patches for androidkernel- toolchain and Lambda as well.

GalaticStryder said:
@blastagator
I've pushed my keymaster to Github: https://github.com/GalaticStryder/hardware_qcom_keymaster
This is the one we use on bacon and onyx on AOSPA builds.
Backporting 3.10 qseecom isn't needed and probably will break the APIs the blobs were compiled for. I'm gonna test this on nougat as well right now.
I'd actually ask for your help on AOSPA, I've got a semi-working RIL and some other great stuff to play with but I can't get the built-in kernel to boot after flashing, only boots when flashing my kernel externally.
The image is bumped, the mkbootimg was revisited twice but there's no go. I don't want to ship a prebuilt image to workaround this. I've tried CM14 kernel with my GCC 4.9 patches for androidkernel- toolchain and Lambda as well.
Click to expand...
Click to collapse
Without going too far OT, do you have a thread for the AOSPA you're working on? Curious what manifest you're using.
re: keymaster - I pulled the blobs from Bacon and it looks like the cm-13 nightlies use the latest hardware_qcom_keymaster. I don't think there have really been any big changes to the API. I could be wrong though!

blastagator said:
Without going too far OT, do you have a thread for the AOSPA you're working on? Curious what manifest you're using.
re: keymaster - I pulled the blobs from Bacon and it looks like the cm-13 nightlies use the latest hardware_qcom_keymaster. I don't think there have really been any big changes to the API. I could be wrong though!
Click to expand...
Click to collapse
I'm making progress using everything from CAF and patching the needed parts on demand.
The stuff AOSPA already has in their Github I'm sending to Gerrit: https://gerrit.aospa.co/#/q/status:open
The parts I needed to dive deeper I've forked or created the repos manually: https://github.com/GalaticStryder
My next step is to "decommonize" the power package to be able to hint impulse instead of ondemand and to update MSM8974 code that is two years old.
The only problem I'm facing is that the otapackage seems to flash the boot.img in a bad manner, causing boot certification problem. If I manually flash the boot.img after the otapackage it works like a charm, the problem is somewhere in the boot flashing script part of the ota_from_target_files python script, might be pushing the boot.img using imgdiff and causing the bootloader to refuse due to mismatching certification inside the boot sector. This is my hypothesis but it might be what is happening.

GalaticStryder said:
I'm making progress using everything from CAF and patching the needed parts on demand.
The stuff AOSPA already has in their Github I'm sending to Gerrit: https://gerrit.aospa.co/#/q/status:open
The parts I needed to dive deeper I've forked or created the repos manually: https://github.com/GalaticStryder
My next step is to "decommonize" the power package to be able to hint impulse instead of ondemand and to update MSM8974 code that is two years old.
The only problem I'm facing is that the otapackage seems to flash the boot.img in a bad manner, causing boot certification problem. If I manually flash the boot.img after the otapackage it works like a charm, the problem is somewhere in the boot flashing script part of the ota_from_target_files python script, might be pushing the boot.img using imgdiff and causing the bootloader to refuse due to mismatching certification inside the boot sector. This is my hypothesis but it might be what is happening.
Click to expand...
Click to collapse
Well beyond the scope of my dive into android fun. Wish I could help! What is your ultimate goal? Paranoid Android?
It is also very exciting to see the push of Android stuff into the mainline kernel. Hope for the future!

Realized additional blobs for qseecom:
https://github.com/blastagator/them...mmit/09bc989cdb0db9bc47f7501dbf36be2a155ca168
Also, updated boardconfig since the bacon qseecomd supports TARGET_KEYMASTER_WAIT_FOR_QSEE
https://github.com/blastagator/cm_d...mmit/6ca7cd8835afa57ebec9b47fc56514d87ee95e34
Building now. Not sure if I can test tonight, but fingers crossed, maybe it will work!
No luck. Still the same errors:
Code:
12-31 23:22:39.385 2697 2697 I keystore: Found keymaster0 module Keymaster QCOM HAL, version 3
12-31 23:22:39.385 2697 2697 I SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 122: Creating device
12-31 23:22:39.385 2697 2697 D SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 123: Device address: 0xb6b64000
12-31 23:22:39.386 2697 2697 D QCOMKeyMaster: keymaster app is loaded
12-31 23:22:39.386 2697 2697 D QCOMKeyMaster: keymaster app got loaded at attempt number 0
12-31 23:22:39.386 2697 2697 D QSEECOMAPI: : QSEECom_get_handle sb_length = 0x2000
12-31 23:22:39.386 2697 2697 D QSEECOMAPI: : App is not loaded in QSEE
12-31 23:22:39.392 2697 2697 E QSEECOMAPI: : Error::Load image request failed ret = -1, errno = 14
12-31 23:22:39.392 2697 2697 E QSEECOMAPI: : Error::Loading image failed with ret = -1
12-31 23:22:39.393 2697 2697 D QSEECOMAPI: : QSEECom_get_handle sb_length = 0x2000
12-31 23:22:39.393 2697 2697 D QSEECOMAPI: : App is not loaded in QSEE
12-31 23:22:39.393 2697 2697 E QSEECOMAPI: : Error::Cannot open the file /firmware/image/keymaste.mdt
12-31 23:22:39.393 2697 2697 E QSEECOMAPI: : Error::Loading image failed with ret = -1
12-31 23:22:39.393 2697 2697 E QCOMKeyMaster: Loading keymaster app failed
12-31 23:22:39.393 2697 2697 E keystore: Error opening keystore keymaster0 device.
12-31 23:22:39.393 2697 2697 E keystore: keystore keymaster could not be initialized; exiting
Guessing there is some sort of signature check that is matching the expected device to the keymaster firmware file. Unfortunately qseecomapi and keymaster are closed source, so it is kind of a guessing game...
Code:
/**
* @brief Open a handle to the QSEECom device.
*
* - Load a secure application. The application will be verified that it is
* secure by digital signature verification.
* Allocate memory for sending requests to the QSAPP
*
* Note/Comments:
* There is a one-to-one relation for a HLOS client and a QSAPP;
* meaning that only one app can communicate to a QSAPP at a time.
*
* Please note that there is difference between an application and a listener
* service. A QSAPP must be loaded at the request of the HLOS,
* and all requests are orginated by the HLOS client.
* A listener service on the otherhand is started during start-up by a
* daemon, qseecomd.
*
* A HLOS application may create mutiple handles to the QSAPP
*
* @param[in/out] handle The device handle
* @param[in] fname The directory and filename to load.
* @param[in] sb_size Size of the shared buffer memory for sending requests.
* @return Zero on success, negative on failure. errno will be set on
* error.
*/
int QSEECom_start_app(struct QSEECom_handle **clnt_handle, const char *path,
const char *fname, uint32_t sb_size);
Perhaps something in one of the .prop files could be changed to trick the app into passing a device check, but again, this is all very speculative.

blastagator said:
Anyone ever attempted to kang Keymaster Firmware from a different device? I have tried the firmware from bacon, hammerhead, and g3. I have tried with and without the TARGET_KEYMASTER_WAIT_FOR_QSEE flag.
The result is always the same in dmesg:
Code:
[0][4371: keystore]QSEECOM: qseecom_load_app: App (keymaster) does'nt exist, loading apps for first time
[0][4371: keystore]QSEECOM: qseecom_load_app: scm_call failed resp.result unknown, -12
[0][4371: keystore]QSEECOM: qseecom_ioctl: failed load_app request: -14
Click to expand...
Click to collapse
Hello @blastagator,
were you able to fix that Keymaster Issue , if so mind telling us how ?
Because , iam facing similar issues in YU4711 (jalebi)

sooorajjj said:
Hello @blastagator,
were you able to fix that Keymaster Issue , if so mind telling us how ?
Because , iam facing similar issues in YU4711 (jalebi)
Click to expand...
Click to collapse
No. Tried several things with no luck.

What is a keymaster firmware?
And what is it good for?

wq0913562 said:
What is a keymaster firmware?
And what is it good for?
Click to expand...
Click to collapse
Maybe this config is need for porting firmware from different devices.

wq0913562 said:
What is a keymaster firmware?
And what is it good for?
Click to expand...
Click to collapse
cryerenable said:
Maybe this config is need for porting firmware from different devices.
Click to expand...
Click to collapse
No, it is used to enable hardware backed keystore (i.e. hardware accelerated encryption)

blastagator said:
No, it is used to enable hardware backed keystore (i.e. hardware accelerated encryption)
Click to expand...
Click to collapse
hello
i'm facing a similar problem on my lineage 13 port for the lg stylo 2 plus the qseecomapi is keeping looking for the keymaste.mdt file
E QSEECOMAPI: Error::Cannot open the file /firmware/image/keymaste.mdt errno = 2
E QSEECOMAPI: Error::Loading image failed with ret = -1
Click to expand...
Click to collapse
and our device does not have one do you know how to bybass this, ty.

messi2050 said:
hello
i'm facing a similar problem on my lineage 13 port for the lg stylo 2 plus the qseecomapi is keeping looking for the keymaste.mdt file
and our device does not have one do you know how to bybass this, ty.
Click to expand...
Click to collapse
I got frustrated with it. Only other idea I had was to port all common blobs from similar device and see if that works.

blastagator said:
I got frustrated with it. Only other idea I had was to port all common blobs from similar device and see if that works.
Click to expand...
Click to collapse
Are you still active?
Just found this. Not sure if it can help.
http://bits-please.blogspot.de/2016/06/extracting-qualcomms-keymaster-keys.html
https://android.googlesource.com/platform/hardware/qcom/keymaster/+/master
Maybe I'll give it a try to port keymaster now that we have updated 3.4.113 kernel...

Nokia 8 (TA1012) fails to update to October 2018 Security Patch

I get this error message:
Error applying update: 20 (ErrorCode::kDownloadStateInitializationError)
Any ideas?

7cherubin said:
I get this error message:
Error applying update: 20 (ErrorCode::kDownloadStateInitializationError)
Any ideas?
Click to expand...
Click to collapse
root and or twrp installed?

2WildFirE said:
root and or twrp installed?
Click to expand...
Click to collapse
Nope.
Never flashed TWRP.
However, I did have root. But I uninstalled it and performed a hard reset.
After that, I also locked the bootloader.

Then try flash matching boot.img after that update again.
? Bootloader isn't needed I update every month with open bootloader

7cherubin said:
I get this error message:
Error applying update: 20 (ErrorCode::kDownloadStateInitializationError)
Any ideas?
Click to expand...
Click to collapse
+1 The same happens to me (stock boot flashed in slot b - september and a -august). No way to update.

Did you guys ever figure it out ? I'm having the exact same problem when trying to flash the November update from Stock Recovery (I tried that because normal OTA errors out). Thanks !

Hi @7cherubin would you send me the post to root TA-1012?

I have the same problem. TA-1004, trying to apply November security update.
After getting the "Installation problem" error message in the update UI, which is not very verbose, I checked the log with adb logcat. The following is what I have found:
Code:
update_engine: [1114/144758:INFO:delta_performer.cc(368)] Applying 8158 operations to partition "system"
update_engine: [1114/144758:ERROR:delta_performer.cc(1065)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
The phone's bootloader was unlocked using the official method.
TWRP has been installed, then removed (by flashing the stock boot image to both slots A and B).
The update seems to fail with or without TWRP.
Also, Magisk has been installed, then removed. Same result: update fails with or without Magisk.
Judging by the error message from the log, the problem is somehow related to the system partition and not the boot partition (where the boot image resides, and which would be affected by TWRP and/or Magisk).
The Nokia 8 doesn't seem to have a separate recovery partition, the recovery image is stored also on the boot partition (proof for this being that if you flash stock boot image, you get back the stock recovery).
Temporarily booting an image with fastboot boot <img> also doesn't work on this phone (at least if you are already on 8.1.0 with October security patch), so installing TWRP is only possible by flashing it to one of the boot slots and forcing the phone to boot from that particular slot.
Neither OST 6.0.4 nor OST 6.1.2 is able to flash the phone.
Sorry if this got too long, I am trying to stick in this post all the info that I have learned in the hopes that someone will have an idea how to fix this.

I had the same problem and had to go back to stock. I had only rooted and flashed the boot images, no TWRP. I had messed up at one point though and flashed both slots and that's where I think the problem lies. The boot images seem to be personalized to the device (keys ?) and the OTA checks for that so if you flash one with a prerooted image, then apply Magisk to the other one and ugrade on that one (after temporarily deactivating Magisk) then you're ok. After going back to stock I was able to verify this "theory", well at least it let me do the OTA multiple times.

Can someone post the link yo root TA-1012 ^_^

webvan said:
I had the same problem and had to go back to stock. I had only rooted and flashed the boot images, no TWRP. I had messed up at one point though and flashed both slots and that's where I think the problem lies. The boot images seem to be personalized to the device (keys ?) and the OTA checks for that so if you flash one with a prerooted image, then apply Magisk to the other one and ugrade on that one (after temporarily deactivating Magisk) then you're ok. After going back to stock I was able to verify this "theory", well at least it let me do the OTA multiple times.
Click to expand...
Click to collapse
Here is what I have, Nokia 8 TA-1004:
- on slot A I have Android 8.1.0 with October security patch
- on slot B I have Android 8.1.0 with September security patch
Neither of these would apply the OTA (slot A November patch, slot B October patch).
I got rid of previous root attempts by flashing:
- stock October boot image to slot A
- stock September boot image to slot B
At this point I am back to as stock as possible.
Then I tried to follow your suggestions, flashed:
- prerooted October boot image to slot A
- stock September boot image to slot B
Set the active slot to A.
Reboot.
Install Magisk from MagiskManager to the "other slot", this switches the active slot to B.
Reboot.
Check that Magisk is installed: yes. Check root with RootChecker: there is root.
Uninstall Magisk from MagiskManager with the Restore Images option, this should restore the stock boot image on the active slot, which at this point is B.
Without reboot, try to apply the OTA update to upgrade to November security patch.
Update fails. Here are a few relevant lines from the log (retrieved with adb logcat):
Code:
11-27 16:56:59.961 1107 1107 I update_engine: [1127/165659:INFO:delta_performer.cc(368)] Applying 5 operations to partition "abl"
11-27 16:56:59.965 1107 1107 I update_engine: [1127/165659:INFO:delta_performer.cc(661)] Starting to apply update payload operations
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1065)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that
the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1070)] Expected: sha256|hex = 1376DA9AFC602B63352F6611917129A8FEC841070A5A44B657826B25D3BAED0D
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1073)] Calculated: sha256|hex = 658502232C3D562E1883E66BB2C4BED4F48E98CB02B983DC43DB6D9B05ABF939
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1084)] Operation source (offset:size) in blocks: 1:1,3:1,36:14,51:16
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1250)] ValidateSourceHash(source_hasher.raw_hash(), operation, error) failed.
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(288)] Failed to perform SOURCE_BSDIFF operation 1, which is the operation 1 in partition "abl"
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:download_action.cc(325)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
Then I went back to stock boot images again, and tried the whole process the other way around: switching slots.
Stock image on slot A.
Prerooted image on slot B.
The rest of the process is the same as above.
This time I get a different error in the log:
Code:
11-27 17:07:30.788 1050 1050 I update_engine: [1127/170730:INFO:delta_performer.cc(368)] Applying 5 operations to partition "abl"
11-27 17:07:30.794 1050 1050 I update_engine: [1127/170730:INFO:delta_performer.cc(661)] Starting to apply update payload operations
11-27 17:07:30.834 1050 1050 I update_engine: [1127/170730:INFO:delta_performer.cc(368)] Applying 22 operations to partition "bluetooth"
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1065)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that
the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1070)] Expected: sha256|hex = 73D9DD6F7FCBA3C7A6900599BB66C5D321C9F77B74808FD1ADEB50DD8CE475D2
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1073)] Calculated: sha256|hex = BEFE956EC57F320FA6F96067CCDF81DEF88D227A15D7E5412B2064A941E8E7BF
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1084)] Operation source (offset:size) in blocks: 4:1,11:1
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1250)] ValidateSourceHash(source_hasher.raw_hash(), operation, error) failed.
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(288)] Failed to perform SOURCE_BSDIFF operation 11, which is the operation 6 in partition "bluetooth"
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:download_action.cc(325)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
As you can see in the first case it is complaining about the "abl" partition, in the second case it is complaining about the "bluetooth" partition.
webvan, what is your phone model? Is it TA-1004? What security patch levels were you working with in your case?

Mine is a TA-1052.
By "go back to stock" I meant fully reflashing the Oreo update with OTLA because like you nothing I tried with the boot images helped. Since I was rooted I did a backup with Titanium so it wasn't too painful.

I managed to update to 5.15d by sideloading using adb the full ROM (5.15) then sideloading 5.15a and 5.15b, I didn't sideload 5.15c I directly sideloaded 5.15d OTA update and it worked!

I have the same problem.
Slot A : stock boot with sp 2019-04 (5150)
Slot B (active): stock boot with sp 2019-05 (515A)
I tried to sideload OTA (515B with sp 2019-06) on slot B, while the "Error applying update: 20 (ErrorCode::kDownloadStateInitializationError)" message appeared.
By checking the log report, it was just after the operations to partition "system" that I had the line "the hash of the source data on disk for this operation doesn't match the expected value."
Anyone has ideas? Thanks in advance.

Moto x4 Magisk OTA updates

Has anyone gotten OTA updates to work using the magisk a/b tutorial? I've never gotten it to take an OTA, I usually have to find a recent firmware download and reflash, then go through all the OTAs until I'm done, then reroot with magisk. There's got to be a better way to do it.
I'm wondering if the problem is that I'm installing magisk via TWRP (not flashing twrp, just booting to it). Anyone have any advice?

I do not get OTAs because of unlocked bootloader. But at least I just installed an update to slot B, rebooted to A and rooted B with the Magisk app successfully.
As long as I find updates here, that's ok, I think. Updates do not come often. It's not a Xiaomi in beta test mode.

You can get OTA with an unlocked bootloader. My bootloader has been unlocked since shortly after I got my phone. I might end up doing what you suggest; I know how to get the OTA package from the logs on the phone, so I could just download the OTA and install myself. I was just hoping to get the super snazzy method that magisk allows working.
This latest update was weird. I tried my usual technique (reflash everything without wiping userdata to the last stock ROM, which removes magisk, then update with OTA), but it failed. The new version's ROM was uploaded though, so I could just use that one.
I tried something different this time in that I used the "patch boot image" method instead of installing through TWRP. I'll see if that makes a difference or not next time the updates occur.
And you're right, at least I only have to fiddle with it once a month or so.

This is from/for Lineage 15.1: https://forum.xda-developers.com/showpost.php?p=78722460&postcount=830
Sounds like you need to reflash TWRP after every update but magisk sticks.

I have gotten exactly one OTA with unlocked BL, a security patch for 8.1.
Since then, installation of every downloaded OTA failed.
I once had pulled the OTA file to my PC, but I failed to turn it into a flashable image. I have posted a question about it in the X4 forums.
EDIT: it was 8.0. => click

dougo007 said:
This is from/for Lineage 15.1: https://forum.xda-developers.com/showpost.php?p=78722460&postcount=830
Sounds like you need to reflash TWRP after every update but magisk sticks.
Click to expand...
Click to collapse
I don't have TWRP flashed anymore (I wasn't using it for anything). The problem is that it's not taking the OTA update at all. It says update failed due to unspecified error. When I look through the logs, I see that it's failing because the system partition hash isn't matching what's expected, despite me not modifying the system partiton at all (as far as I know). All I use magisk for is root for adblocking (adguard) and call recording (call recorder), and I used the vanced module from the repo. I don't think any of that should make my /system not match, but I'm not really sure.

oz42 said:
I have gotten exactly one OTA with unlocked BL, a security patch for 8.1.
Since then, installation of every downloaded OTA failed.
I once had pulled the OTA file to my PC, but I failed to turn it into a flashable image. I have posted a question about it in the X4 forums.
Click to expand...
Click to collapse
As far as I know, you can't just directly flash OTAs. You have to go into TWRP and do the sideload thing, though I could be mistaken. It's been a long time since I've tried doing it that way.

tjololo12 said:
As far as I know, you can't just directly flash OTAs. You have to go into TWRP and do the sideload thing, though I could be mistaken. It's been a long time since I've tried doing it that way.
Click to expand...
Click to collapse
I am ~90% sure that OEM OTAs (it sounds like that is what you are discussing) are installed via ADB sideload.

tjololo12 said:
When I look through the logs, I see that it's failing because the system partition hash isn't matching what's expected
Click to expand...
Click to collapse
I wonder if there's a way we can bake in the updated hash value of the system partition to trick the OTA into loading. which log file did you find this in?

trevorcobb said:
I wonder if there's a way we can bake in the updated hash value of the system partition to trick the OTA into loading. which log file did you find this in?
Click to expand...
Click to collapse
I'm not sure honestly, I just did "adb logcat" and watched it while I ran the update. I'm perfectly willing to help you or anyone troubleshoot this. I have a version of Android I can flash before the last update, if you want me to look into something. Otherwise, we can wait until the next one.

Good thread so far. Anyone find a solid work around for this last OTA?
Sent from my moto x4 using Tapatalk

trevorcobb said:
I wonder if there's a way we can bake in the updated hash value of the system partition to trick the OTA into loading. which log file did you find this in?
Click to expand...
Click to collapse
Here's the section from adb logcat
Code:
04-02 07:39:11.716 1447 1447 I update_engine: [0402/073911.715938:INFO:delta_performer.cc(385)] Opening /dev/block/bootdevice/by-name/boot_a partition without O_DSYNC
04-02 07:39:11.716 1447 1447 I update_engine: [0402/073911.716773:INFO:delta_performer.cc(129)] Caching writes.
04-02 07:39:11.716 1447 1447 I update_engine: [0402/073911.716954:INFO:delta_performer.cc(397)] Applying 2 operations to partition "boot"
<unrelated things here>
04-02 07:39:13.065 1447 1447 E update_engine: [0402/073913.065604:ERROR:fec_file_descriptor.cc(30)] No ECC data in the passed file
04-02 07:39:13.065 1447 1447 E update_engine: [0402/073913.065821:ERROR:delta_performer.cc(432)] Unable to open ECC source partition boot on slot B, file /dev/block/bootdevice/by-name/boot_b: Invalid argum
ent
04-02 07:39:13.065 1447 1447 E update_engine: [0402/073913.065902:ERROR:delta_performer.cc(1042)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean th
at the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
04-02 07:39:13.065 1447 1447 E update_engine: [0402/073913.065954:ERROR:delta_performer.cc(1047)] Expected: sha256|hex = AD67C3189DCBFF888499FF8E6D9CCF77D162421ABBB684AD93CD4D74B29D742D
04-02 07:39:13.066 1447 1447 E update_engine: [0402/073913.066004:ERROR:delta_performer.cc(1050)] Calculated: sha256|hex = CF6389937B1AD2F683C710FDA74CA518851F8DF71372C5E4A1349092E3CE25DE
04-02 07:39:13.066 1447 1447 E update_engine: [0402/073913.066057:ERROR:delta_performer.cc(1061)] Operation source (offset:size) in blocks: 0:3336,3576:1985
04-02 07:39:13.066 1447 1447 E update_engine: [0402/073913.066130:ERROR:delta_performer.cc(1345)] source_fd != nullptr failed.
04-02 07:39:13.066 1447 1447 E update_engine: [0402/073913.066183:ERROR:delta_performer.cc(301)] Failed to perform BROTLI_BSDIFF operation 244, which is the operation 0 in partition "boot"
04-02 07:39:13.066 1447 1447 E update_engine: [0402/073913.066238:ERROR:download_action.cc(337)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the
received payload -- Terminating processing
04-02 07:39:13.075 1447 1447 I update_engine: [0402/073913.075061:INFO:delta_performer.cc(317)] Discarding 18435331 unused downloaded bytes
04-02 07:39:13.077 1447 1447 I update_engine: [0402/073913.077715:INFO:multi_range_http_fetcher.cc(172)] Received transfer terminated.
04-02 07:39:13.077 1447 1447 I update_engine: [0402/073913.077897:INFO:multi_range_http_fetcher.cc(124)] TransferEnded w/ code 206
04-02 07:39:13.077 1447 1447 I update_engine: [0402/073913.077950:INFO:multi_range_http_fetcher.cc(126)] Terminating.
04-02 07:39:13.078 1447 1447 I update_engine: [0402/073913.078002:INFO:action_processor.cc(116)] ActionProcessor: finished DownloadAction with code ErrorCode::kDownloadStateInitializationError
04-02 07:39:13.078 1447 1447 I update_engine: [0402/073913.078056:INFO:action_processor.cc(121)] ActionProcessor: Aborting processing due to failure.
04-02 07:39:13.078 1447 1447 I update_engine: [0402/073913.078106:INFO:update_attempter_android.cc(470)] Processing Done.
04-02 07:39:13.079 1447 1447 I update_engine: [0402/073913.079041:INFO:update_attempter_android.cc(495)] Resetting update progress.
04-02 07:39:13.079 1447 1447 D NetdClient: setNetworkForTarget(0)
04-02 07:39:13.079 8128 17008 D OtaApp : UpdateEngineCallbackImplementation: StatusUpdate 0 percentage 0.0
04-02 07:39:13.080 1447 1447 I update_engine: [0402/073913.080598:INFO:update_attempter_android.cc(655)] metrics:({
04-02 07:39:13.080 1447 1447 I update_engine: "downloadPercentageAdminApn": 0.0,
04-02 07:39:13.080 1447 1447 I update_engine: "downloadPercentageCellular": 0.0,
04-02 07:39:13.080 1447 1447 I update_engine: "downloadPercentageWifi": 5.0,
04-02 07:39:13.080 1447 1447 I update_engine: "downloadTotalSize": 20279759,
04-02 07:39:13.080 1447 1447 I update_engine: "downloadTotalTime": 4435.0,
04-02 07:39:13.080 1447 1447 I update_engine: "errorCode": 20,
04-02 07:39:13.080 1447 1447 I update_engine: "networkId": 634765889549.0,
04-02 07:39:13.080 1447 1447 I update_engine: "networkType": "WIFI",
04-02 07:39:13.080 1447 1447 I update_engine: "sessionAttemptNumber": 1.0,
04-02 07:39:13.080 1447 1447 I update_engine: "sessionAttemptResult": 1,
04-02 07:39:13.080 1447 1447 I update_engine: "sessionDownloadDuration": 121005476.0
04-02 07:39:13.080 1447 1447 I update_engine: })
Does that help track things down? Any other way I can help look into things?

There's already a method explained in the FAQs thread for installing official OTAs on rooted stock. TWRP has to be reinstalled after though.
Are you just trying to search for a more efficient solution?

Neffy27 said:
There's already a method explained in the FAQs thread for installing official OTAs on rooted stock. TWRP has to be reinstalled after though.
Are you just trying to search for a more efficient solution?
Click to expand...
Click to collapse
Exactly what post in the FAQ are you referring to??
Sent from my moto x4 using Tapatalk

SR3TLAW said:
Exactly what post in the FAQ are you referring to??
Click to expand...
Click to collapse
Here...
Neffy27 said:
...
12. I am rooted and now Official OTAs don't install
This is a known issue with no fix. Your only option is to wait for copy of latest firmware to be available and manually flash it without the erase userdata to keep your data. Another option is if you are receiving the OTA notification, manually re-flash current firmware build without the erase userdata to keep your data and proceed to accept the OTA (You will have to re-install TWRP/re-root.)
...
Click to expand...
Click to collapse

Need Belutooth partition backup of Moto one power device having January 1st Patch

Hi all,
Can anybody please share the twrp backup of bluetooth partition of Moto One Power device having the Pie January 1st Patch? My bluetooth partition got formatted while restoring the twrp backup and restore got failed. Now I'm not able to use the bluetooth. I have got the OTA with face unlock, But thile installing the OTA I started getting bluetooth partition block verification failed saying partition got mounted rw. And while restoring the earlier backup it got formatted :crying:

Got it fixed after a hell lot of research
Hi all,
Finally after searching a lot in net, flashed the bluetooth partition with the img file available in the following site ( Phenotypically ) -> mirrors[dot]lolinet[dot]com[slash]firmware[slash]moto[slash]chef[slash]official[slash]RETIN
The root cause for getting the partition formatted is gettiing the following error, to solve it I tried to restore bluetooth partition and it resulted currupt. Hope it may help somebody who will be get the same issue and stumble upon this page.
I was getting "Update Failed" error in Moto updator. While checking for the logs via adb observed the following error :
Code:
update_engine: [0306/081413.872062:INFO:delta_performer.cc(397)] Applying 8 operations to partition "bluetooth"
update_engine: [0306/081413.885946:ERROR:fec_file_descriptor.cc(30)] No ECC data in the passed file
update_engine: [0306/081413.886903:ERROR:delta_performer.cc(432)] Unable to open ECC source partition bluetooth on slot A, file /dev/block/bootdevice/by-name/bluetooth_a: Success
update_engine: [0306/081413.887044:ERROR:delta_performer.cc(1042)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
update_engine: [0306/081413.887251:ERROR:delta_performer.cc(1047)] Expected: sha256|hex = 9F69430D4BED82B26E49AAA81E0F1E823687605099AD61F45A361A96E7BE6FEE
update_engine: [0306/081413.887321:ERROR:delta_performer.cc(1050)] Calculated: sha256|hex = 734059C0A03A2B2E61CBF3302F2982F3811FD243064D434A6CFC0FAEBDBC0E85
update_engine: [0306/081413.887393:ERROR:delta_performer.cc(1061)] Operation source (offset:size) in blocks: 0:1,6:2,34:1,101:30
update_engine: [0306/081413.887487:WARNING:mount_history.cc(66)] Device was remounted R/W 1 times. Last remount happened on 2019-03-05 03:36:34.000 UTC.
update_engine: [0306/081413.887573:ERROR:delta_performer.cc(1340)] source_fd != nullptr failed.
update_engine: [0306/081413.887652:ERROR:delta_performer.cc(301)] Failed to perform BROTLI_BSDIFF operation 4604, which is the operation 0 in partition "bluetooth"
update_engine: [0306/081413.887721:ERROR:download_action.cc(337)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
update_engine: [0306/081413.888372:INFO:delta_performer.cc(317)] Discarding 301 unused downloaded bytes
update_engine: [0306/081413.894845:INFO:multi_range_http_fetcher.cc(172)] Received transfer terminated.
update_engine: [0306/081413.895113:INFO:multi_range_http_fetcher.cc(124)] TransferEnded w/ code 206
update_engine: [0306/081413.895166:INFO:multi_range_http_fetcher.cc(126)] Terminating.
update_engine: [0306/081413.895224:INFO:action_processor.cc(116)] ActionProcessor: finished DownloadAction with code ErrorCode::kDownloadStateInitializationError
update_engine: [0306/081413.895278:INFO:action_processor.cc(121)] ActionProcessor: Aborting processing due to failure.
Since Moto One Power is having A/B Partition and seemless update support, It looks like the incremental security update was checking for the checksum of the corresponding partition before applying the incremental update. To fix this I flashed the bluetooth and other failing partitions with the apropriate images available in the above shared link.

Hi there, i'm facing the same issue. Can u please tell me which img to flash from stock firmware?

WiFi not working after installing LineageOS for microG

Hi there! I'm trying to flash LineageOS-microG version (https://lineage.microg.org), but after successful (?) installation WiFi isn't working, I'm getting an error "Failed or timed out awaiting driver ready":
Code:
09-25 19:15:36.920 894 894 E WifiHAL : Timed out wating on Driver ready ...
09-25 19:15:36.921 894 894 E [email protected]: Failed or timed out awaiting driver ready
09-25 19:15:36.921 894 894 E [email protected]: Failed to start legacy HAL: TIMED_OUT
09-25 19:15:36.929 1307 3910 E HalDevMgr: executeChipReconfiguration: configureChip error: 9 (, timed out)
09-25 19:15:36.929 1307 3910 E WifiVendorHal: Failed to create STA iface
09-25 19:15:36.929 1307 3910 E WifiNative: Failed to create iface in vendor HAL
09-25 19:15:36.930 1307 3910 E WifiClientModeManager: Failed to create ClientInterface. Sit in Idle
I've downloaded latest "-microG-bramble-recovery.img" and "-microG-bramble.zip" form https://download.lineage.microg.org/bramble/, flashed recovery, rebooted into it and flashed zip as described in official LineageOS wiki https://wiki.lineageos.org/devices/bramble/install#installing-lineageos-from-recovery.
After rebooting and post-install setup WiFi is not working :/
Official LineageOS images works fine. So, what I'm doing wrong?
I've also unpacked "payload.bin" from this image https://download.lineage.microg.org/bramble/lineage-18.1-20210914-microG-bramble.zip with some python script https://github.com/cyxx/extract_android_ota_payload and there are some noticeable differences in official and microG LineageOS editions:
LineageOS-microG payload.bin:
Code:
4,0K ./vbmeta_system.img
8,0K ./vbmeta.img
16M ./dtbo.img
96M ./boot.img
96M ./vendor_boot.img
280M ./system_ext.img
553M ./product.img
710M ./vendor.img
1,1G ./system.img
2,8G .
Official LineageOS payload.bin:
Code:
4,0K ./vbmeta_system.img
8,0K ./vbmeta.img
44K ./devcfg.img
56K ./qupfw.img
80K ./xbl_config.img
88K ./featenabler.img
124K ./uefisecapp.img
192K ./aop.img
236K ./keymaster.img
404K ./hyp.img
1,0M ./abl.img
2,9M ./tz.img
3,5M ./xbl.img
16M ./dtbo.img
96M ./boot.img
96M ./vendor_boot.img
147M ./modem.img
280M ./system_ext.img
710M ./vendor.img
948M ./product.img
2,6G ./system.img
4,9G .
Does this mean that LineageOS-microG images are broken in some way or something?
Thanks!

I had the same issues with newer versions for Pixel 5, only initial 18.1 works fine. LineageOS for microG have huge issues with connectivity for redfin, they even don't have reachable support anywhere...
Update: I just managed to install a version of Lineage-18.1-20211021-microg-redfin-recovery.img (newest) with a fully operating MicroG and a working flawlessly WiFi/cellular connectivity - I used CalyxOS installer (to update Pixel 5 firmware during the installation), then I unlocked the bootloader (in CalyxOS dev. options and later in fastboot by typing "fastboot flashing unlock" through adb), and get rid of Calyx by making a wipe and install LineageOS recovery and LineageOS for microG image.
CalyxOS has installation module for Pixel 4, so I hope it could be helpful for you.

I have the same problem. The last build of Los4microG that works is the from May 21. Would a simple firmware update do the trick as well?