Scanning through update_engine_log it seems as I suspected that modified partitions fail checksum match and terminates update process. Does anyone think we can either replace the update mechanism or edit it to skip hash checking and thereby receive updates even after bootloader unlocked and rooted? Here's a section of the log showing reason for failure
Spoiler
[1006/063705.167791:INFO:delta_performer.cc(411)] Applying 1 operations to partition "vbmeta"
[1006/063705.175198:ERROR:fec_file_descriptor.cc(30)] No ECC data in the passed file
[1006/063705.175541:ERROR:delta_performer.cc(445)] Unable to open ECC source partition vbmeta on slot A, file /dev/block/bootdevice/by-name/vbmeta_a: Invalid argument (22)
[1006/063705.179547:ERROR:delta_performer.cc(1243)] 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.
[1006/063705.179693:ERROR:delta_performer.cc(1248)] Expected: sha256|hex = 0C796C77ECA2953B6BB82373F04C7B3B32FE2A2DA1CD01FFB79574F7543FB282
[1006/063705.179744:ERROR:delta_performer.cc(1251)] Calculated: sha256|hex = B53A4381CB3450B275EFC8053DDCFD45C8F334F46D725E91755CEEA0D71FA83E
[1006/063705.179794:ERROR:delta_performer.cc(1262)] Operation source (offset:size) in blocks: 0:2
[1006/063705.179893:ERROR:delta_performer.cc(1583)] source_fd != nullptr failed.
[1006/063705.179949:ERROR:delta_performer.cc(308)] Failed to perform BROTLI_BSDIFF operation 4642, which is the operation 0 in partition "vbmeta"
[1006/063705.180001:ERROR:download_action.cc(336)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
[1006/063705.180534:INFO:delta_performer.cc(325)] Discarding 699 unused downloaded bytes
[1006/063705.180600:INFO:libcurl_http_fetcher.cc(548)] Requesting libcurl to terminate transfer.
[1006/063705.189709:INFO:multi_range_http_fetcher.cc(177)] Received transfer terminated.
[1006/063705.189903:INFO:multi_range_http_fetcher.cc(129)] TransferEnded w/ code 206
[1006/063705.189951:INFO:multi_range_http_fetcher.cc(131)] Terminating.
[1006/063705.260827:INFO:action_processor.cc(116)] ActionProcessor: finished DownloadAction with code ErrorCode::kDownloadStateInitializationError
[1006/063705.261119:INFO:action_processor.cc(121)] ActionProcessor: Aborting processing due to failure.
[1006/063705.261198:INFO:update_attempter_android.cc(765)] Processing Done.
[1006/063705.274880:INFO:delta_performer.cc(2172)] Resetting recorded hash for prepared partitions.
[1006/063705.276056:INFO:update_attempter_android.cc(797)] Resetting update progress.
[1006/063705.276283:INFO:dynamic_partition_control_android.cc(265)] Destroying [my_carrier_b, my_engineering_b, my_heytap_b, my_manifest_b, my_product_b, my_region_b, my_stock_b, odm_b, product_b, system_b, system_ext_b, vendor_b] from device mapper
[1006/063705.337743:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped my_carrier_b from device mapper.
[1006/063705.400757:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped my_engineering_b from device mapper.
[1006/063705.472685:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped my_heytap_b from device mapper.
[1006/063705.536658:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped my_manifest_b from device mapper.
[1006/063705.607942:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped my_product_b from device mapper.
[1006/063705.672630:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped my_region_b from device mapper.
[1006/063705.753403:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped my_stock_b from device mapper.
[1006/063705.831976:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped odm_b from device mapper.
[1006/063705.908274:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped product_b from device mapper.
[1006/063705.972447:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped system_b from device mapper.
[1006/063706.052763:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped system_ext_b from device mapper.
[1006/063706.169196:INFO:dynamic_partition_control_android.cc(251)] Successfully unmapped vendor_b from device mapper.
[1006/063706.196356:INFO:metrics_reporter_android.cc(131)] Current update attempt downloads 67 bytes data
[1006/104832.103780:INFO:main.cc(74)] A/B Update Engine terminating with exit code 0
If we could replace or modify the update mechanism to regain updates capability after rooting and layout a defined procedure for enabling and disabling updates without so much effort of freezing and unfreezing system apps related to update we could have a way to recieve updates as they come out and maintain root by utilizing the magisk system update tool the keep root across updates without much hassle
Also I suspect this to be the reason for DSU sideloader failing after making any modifications to the system and/or having an update waiting to be installed interfering with any gsi that DSU sideloader may be attempting to install as I believe a system update attempt would override anything DSU sideloader tries to do
this statement tells me these are the partitions that are affected by updates and should probably be the only partitions besides modems that may need to be considered when trying to use a different security patch in a recovery attempt. this is not to say that other partitions are not updated with a security patch number during some other portion of the update
[1006/063705.276283:INFO:dynamic_partition_control_android.cc(265)] Destroying [my_carrier_b, my_engineering_b, my_heytap_b, my_manifest_b, my_product_b, my_region_b, my_stock_b, odm_b, product_b, system_b, system_ext_b, vendor_b] from device mapper
Related
MSM7227 S1Boot has been patched to ignore SIN header signature by the_laser.
You need phone which you either did not unlock by cable, or phone which you unlocked via SEtool2 only.
If you unlocked with Omnius, in C:\ProgramData\Omnius for SE\Backups\Xperia X8
you have file called: Xperia X8_IMEI_DATE_SIMLock.opd
Restore that TA backup, then use semc.cmd in the_laser's release to unlock bootloader - you'll restore SIM lock this way!
Currently there is no unlocked bootloader for Omnius unlocked phones.
Read all instructions here: http://forum.xda-developers.com/showthread.php?p=17338716#post17338716
What will this allow:
* custom kernels
* better/fully working Gingerbread
* no need for chroot to avoid init crash bug
* overclock/Synaptics fake DT/Cypress real DT/MDDI fix built in kernel
This will not enable:
* real DT on Synaptics digitizer
Greetings.
warning.
if you are not developer, please quit reading that post.
wait for user friendly tool with one big button.
here ( View attachment msm7227.7z ) is toolset to permanently "unlock" semcboot of msm7227 semc phones.
that means, you can use own kernel and so on.
steps,precautions, etc.
unpack archive to any directory.
if you using eset antivirus or similar ****, it will find evil virus in adb.exe.
ignore that, it is not virus in any way, it is standard android debug bridge, bundled in one file to save space and usability.
now, if your phone unlocked officially:
flash phone with standard 2.0,2.1 android firmware,because kernel mapper module compiled for "2.6.29" kernel.
of course, enable "usb debugging"
run msm7227_semc.cmd,
( if you want, examine it before run, it is pretty straightforward. )
you will get similar output
Code:
process requires standard 2.x android firmware.
Press any key to continue . . .
Getting ROOT rights.
1743 KB/s (585731 bytes in 0.328s)
error: protocol fault (no status)
Waiting ...
Removing NAND MPU restrictions via SEMC backdoor. Permanent. Require ROOT rights.
192 KB/s (3087 bytes in 0.015s)
success
Waiting ...
Getting ROOT rights.
Waiting ...
Writing patched semcboot. Two step process
First, we need get access to semcboot area
504 KB/s (8064 bytes in 0.015s)
Second, we need to write semcboot ;)
1130 KB/s (596916 bytes in 0.515s)
successfully wrote 0003ff00
Press any key to continue . . .
bingo, your phone now has unlocked bootloader.
if your phone unlocked by setool2 software, use msm7227_setool2.cmd
if your phone unlocked by 3rd-party software other than setool2, do not run anything -
it will disable radio capability of your phone and you will need to unlock phone by setool2 software.
hopefully, mizerable flea and mOxImKo will release something similar for your phone.
okay, now about other details.
1.
unlocked bootloader require unlocked loader, yep ?
loader\loader.sin is special unlocked loader, which will be accepted ONLY after your "unlock" semcboot with previous steps.
to distinguish unlocked semcboot and original semcboot, first letter in version tag of semcboot output will be lower case, i. e. "r8A029"
( same applies for loader version tag )
so, all that stuff with signatures are not for us, so i removed them - loader will ignore signature part of SIN file.
2.
we should make SIN file somehow, right ?
for that i prepared "dumb" bin2sin utility.
Syntax : bin2sin [input] [partition info, 32 digits] [type] [block size]
Click to expand...
Click to collapse
[input] - is input binary file.
[partition info]
android implementation on s1 semc qualcomm phones based on partitions,so we MUST define it for our file.
you can get required partition info from standard semc sin files, it is first 0x10 bytes of DATA, right after header, i.e.
e10 kernel partition info
03000000010000402001000040000000
Click to expand...
Click to collapse
[type] - partition type, 9 - partition without spare, 0xA - partition with spare.
kernel partition is partition without spare.
if that parameter omitted, type = 9
[block size] - nand block size, if omitted, it is standard size 0x20000
there is example in sinTools\example_build.cmd
3.
kernel should be prepared specially to be accepted by semcboot.
for that there is tool bin2elf.
Syntax : bin2Elf.exe [nbrOfSegments] [EntryPoint] [Segment1] [LoadAddress1] [Attributes1] ...
Click to expand...
Click to collapse
we need 2 segments:
segment 1 is unpacked linux kernel image, i.e.
( e10/kernel/arch/arm/boot/Image )
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x00208000
attributes for image 0x0
segment 2 is ramdisk.
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x01000000
set attributes for ramdisk 0x80000000, that is extremly important.
there is simple kernel example in sinTools\example_build.cmd
ps.
@blagus:
NAND MPU disabler has only one relation to rFoNe - he took it from setool2, together with entire idea for msm7227 bypass.
your 6-wings friend with many nicks done exactly same.
NAND MPU has nothing to do with memory firewall, so it will not help with kexec things, however, who will care now.
Thread closed because i'm boring of all this OFF TOPICS.
@ Blagus: you can open it when you have something to post.
@ Others: Use topic in general forum from NOW.
EDIT: After 3 hours i'm going to open again this thread, WARNING every off topic here will gain an infraction as " Failed to cooperate with a moderator", so, don't blame on me when you will see the infraction point.
So who will help to x8 devs to make custom kernel now!
the_laser said:
Greetings.
warning.
if you are not developer, please quit reading that post.
wait for user friendly tool with one big button.
here ( View attachment 712577 ) is toolset to permanently "unlock" semcboot of msm7227 semc phones.
that means, you can use own kernel and so on.
steps,precautions, etc.
unpack archive to any directory.
if you using eset antivirus or similar ****, it will find evil virus in adb.exe.
ignore that, it is not virus in any way, it is standard android debug bridge, bundled in one file to save space and usability.
now, if your phone unlocked officially:
flash phone with standard 2.0,2.1 android firmware,because kernel mapper module compiled for "2.6.29" kernel.
of course, enable "usb debugging"
run msm7227_semc.cmd,
( if you want, examine it before run, it is pretty straightforward. )
you will get similar output
Code:
process requires standard 2.x android firmware.
Press any key to continue . . .
Getting ROOT rights.
1743 KB/s (585731 bytes in 0.328s)
error: protocol fault (no status)
Waiting ...
Removing NAND MPU restrictions via SEMC backdoor. Permanent. Require ROOT rights.
192 KB/s (3087 bytes in 0.015s)
success
Waiting ...
Getting ROOT rights.
Waiting ...
Writing patched semcboot. Two step process
First, we need get access to semcboot area
504 KB/s (8064 bytes in 0.015s)
Second, we need to write semcboot ;)
1130 KB/s (596916 bytes in 0.515s)
successfully wrote 0003ff00
Press any key to continue . . .
bingo, your phone now has unlocked bootloader.
if your phone unlocked by setool2 software, use msm7227_setool2.cmd
if your phone unlocked by 3rd-party software other than setool2, do not run anything -
it will disable radio capability of your phone and you will need to unlock phone by setool2 software.
hopefully, mizerable flea and mOxImKo will release something similar for your phone.
okay, now about other details.
1.
unlocked bootloader require unlocked loader, yep ?
loader\loader.sin is special unlocked loader, which will be accepted ONLY after your "unlock" semcboot with previous steps.
to distinguish unlocked semcboot and original semcboot, first letter in version tag of semcboot output will be lower case, i. e. "r8A029"
( same applies for loader version tag )
so, all that stuff with signatures are not for us, so i removed them - loader will ignore signature part of SIN file.
2.
we should make SIN file somehow, right ?
for that i prepared "dumb" bin2sin utility.
[input] - is input binary file.
[partition info]
android implementation on s1 semc qualcomm phones based on partitions,so we MUST define it for our file.
you can get required partition info from standard semc sin files, it is first 0x10 bytes of DATA, right after header, i.e.
[type] - partition type, 9 - partition without spare, 0xA - partition with spare.
kernel partition is partition without spare.
if that parameter omitted, type = 9
[block size] - nand block size, if omitted, it is standard size 0x20000
there is example in sinTools\example_build.cmd
3.
kernel should be prepared specially to be accepted by semcboot.
for that there is tool bin2elf.
we need 2 segments:
segment 1 is unpacked linux kernel image, i.e.
( e10/kernel/arch/arm/boot/Image )
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x00208000
attributes for image 0x0
segment 2 is ramdisk.
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x01000000
set attributes for ramdisk 0x80000000, that is extremly important.
there is simple kernel example in sinTools\example_build.cmd
ps.
@blagus:
NAND MPU disabler has only one relation to rFoNe - he took it from setool2, together with entire idea for msm7227 bypass.
your 6-wings friend with many nicks done exactly same.
NAND MPU has nothing to do with memory firewall, so it will not help with kexec things, however, who will care now.
Click to expand...
Click to collapse
Here the link for original thread, so for who is interessed can keep reading next steps...
http://forum.xda-developers.com/showpost.php?p=17338716&postcount=300
I had known about it. and broke up his phone thus burned it.
I came across this site of a guy named Dan Rosenburg stating that he exploited the At&t and Verizon variants. Maybe this is helpful for exploiters I don't know but thought I'd post. :good:variants.http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html?m=1
Azimuth Security
Azimuth Security
Thursday, May 23, 2013
Exploiting Samsung Galaxy S4 Secure Boot
Launched in April 2013, the Samsung Galaxy S4 is expected to be one of the top-selling smartphones of the year, having sold 10 million units in its first month of sales. While the majority of released models include an unlocked bootloader, which allows users to flash custom kernels and make other modifications to the software on their own devices, AT&T and Verizon branded devices ship with a locked bootloader that prevents these types of modifications. In this post, I'll provide details on how Samsung implement this locking mechanism, and publish a vulnerability in the implementation that allows bypassing the signature checks to run custom unsigned kernels and recovery images.
Both the AT&T (SGH-I337) and Verizon (SCH-I545) models utilize the Qualcomm APQ8064T chipset. As described in my previous blog post on Motorola's bootloader, Qualcomm leverages software-programmable fuses known as QFuses to implement a trusted boot sequence. In summary, each stage of the boot process cryptographically verifies the integrity of the subsequent stage, with the trust root originating in QFuse values. After the early boot stages bootstrap various hardware components, Samsung's APPSBL ("Application Secondary Bootloader") is loaded and run. This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.
A quick glance at aboot (adopting the name of the partition on which this bootloader resides) revealed that it is nearly identical to the open source lk ("Little Kernel") project, which undoubtedly saved me many hours of tedious reverse engineering. By locating cross-references to strings found in both lk and aboot, I was able to quickly identify the functions that implement signature verification and booting of the Linux kernel.
The central logic to load, verify, and boot the Linux kernel and ramdisk contained in either the boot or recovery partitions is implemented in the boot_linux_from_mmc() function. First, the function determines whether it is booting the main boot partition, containing the Linux kernel and ramdisk used by the Android OS, or the recovery partition, which contains the kernel and ramdisk used by the Android recovery subsystem. Then, the first page of the appropriate partition is read into physical memory from the eMMC flash storage:
if (!boot_into_recovery) {
index = partition_get_index("boot");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No boot partition found\n");
return -1;
}
}
else {
index = partition_get_index("recovery");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No recovery partition found\n");
return -1;
}
}
if (mmc_read(ptn + offset, (unsigned int *) buf, page_size)) {
dprintf(CRITICAL, "ERROR: Cannot read boot image header\n");
return -1;
}
This code is straight out of lk's implementation. Next, after performing some sanity-checking of the boot image, which contains a custom header format, the function loads the kernel and ramdisk into memory at the addresses requested in the boot image header:
hdr = (struct boot_img_hdr *)buf;
image_addr = target_get_scratch_address();
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask) + 0x200;
imagesize_actual = (page_size + kernel_actual + ramdisk_actual);
memcpy(image_addr, hdr, page_size);
offset = page_size;
/* Load kernel */
if (mmc_read(ptn + offset, (void *)hdr->kernel_addr, kernel_actual)) {
dprintf(CRITICAL, "ERROR: Cannot read kernel image\n");
return -1;
}
memcpy(image_addr + offset, hdr->kernel_addr, kernel_actual);
offset += kernel_actual;
/* Load ramdisk */
if (mmc_read(ptn + offset, (void *)hdr->ramdisk_addr, ramdisk_actual)) {
dprintf(CRITICAL, "ERROR: Cannot read ramdisk image\n");
return -1;
}
memcpy(image_addr + offset, hdr->ramdisk_addr, ramdisk_actual);
offset += ramdisk_actual;
This is still essentially identical to lk's implementation, with the addition of code to copy the individual pieces of the boot image to the image_addr location. Finally, the function performs signature verification of the entire image. If signature verification succeeds, the kernel is booted; otherwise, a tampering warning is displayed and the device fails to boot:
if (check_sig(boot_into_recovery))
{
if (!is_engineering_device())
{
dprintf("kernel secure check fail.\n");
print_console("SECURE FAIL: KERNEL");
while (1)
{
/* Display tampered screen and halt */
...
}
}
}
/* Boot the Linux kernel */
...
The is_engineering_device() function simply returns the value of a global variable that is set at an earlier stage in the boot process based on whether or not the chipset ID (an unchangeable hardware value) of the device indicates it is an engineering or production device.
Examining the check_sig() function in more detail revealed that aboot uses the open-source mincrypt implementation of RSA for signature validation. The bootloader uses an RSA-2048 public key contained in aboot to decrypt a signature contained in the boot image itself, and compares the resulting plaintext against the SHA1 hash of the boot image. Since any modifications to the boot image would result in a different SHA1 hash, it is not possible to generate a valid signed boot image without breaking RSA-2048, generating a specific SHA1 collision, or obtaining Samsung's private signing key.
The astute reader will have already noticed the design flaw present in the above program logic. Notice the order in which the steps are performed: first, aboot loads the kernel and ramdisk into memory at the addresses requested by the boot image header, and then signature validation is performed after this loading is complete. Because the boot image header is read straight from eMMC flash prior to any signature validation, it contains essentially untrusted data. As a result, it's possible to flash a maliciously crafted boot image whose header values cause aboot to read the kernel or ramdisk into physical memory directly on top of aboot itself!
Exploitation of this flaw proved to be fairly straightforward. I prepare a specially crafted boot image that specifies a ramdisk load address equal to the address of the check_sig() function in aboot physical memory. In my malicious boot image, I place shellcode where the ramdisk is expected to reside. I flash this image by leveraging root access in the Android operating system to write to the boot block device. When aboot reads the supposed ramdisk from eMMC flash, it actually overwrites the check_sig() function with my shellcode, and then invokes it. The shellcode simply patches up the boot image header to contain sane values, copies the actual kernel and ramdisk into appropriate locations in memory, and returns zero, indicating the signature verification succeeded. At this point, aboot continues the boot process and finally boots my unsigned kernel and ramdisk. Victory!
Check the date. I do believe that is the loki exploit.
It is Loki.... Doesn't work past MDK...
However if you check the other bootloader thread, Dan just released some stuff today that may lead to an exploit for us on builds later than that!
Jraider44 said:
It is Loki.... Doesn't work past MDK...
However if you check the other bootloader thread, Dan just released some stuff today that may lead to an exploit for us on builds later than that!
Click to expand...
Click to collapse
Oh ok thank for the reply mind sending me a link if his other thread? And hopefully we get the bootloader unlocked before 2015
instarichisdope said:
Oh ok thank for the reply mind sending me a link if his other thread? And hopefully we get the bootloader unlocked before 2015
Click to expand...
Click to collapse
The thread can be found here: http://forum.xda-developers.com/showthread.php?t=2500826
Yeah all hopes! Surge and the other guys working out of that thread are all great devs, and if anybody can do anything with the information released today, they can.
Closing this thread as the info is already out there.
I'm learning how various OEM stores their dm-verity public key in such a way that it cannot be replaced by user owned public key even with the help of memory editing electronic programmers. According to Google's documentation on implementing dm-verity, it says the key is stored in /boot/verity_key.
verity_key verifies the vbmeta.img that contains root hash of the hashtree (and it's metadata like salt and offset) of other partitions. In this way integrity of every partition is verified.
Where exactly this key is stored which makes it tamper proof? Some of the answers I've been given is that it can be embedded in TPM or can be hardcoded in Extended Bootloader itself or somewhere in read only memory.
Here's the answer I learned after some more research. /boot/verity_key which verifies vbmeta.img is itself signed by OEM private key. The OEM public key is hardcoded in bootloader at compilation time. The bootloader is verified by Extended bootloader and Extended bootloader is verified by Primary bootloader (PBL) which is burned on non-writable read only memory (also called BootROM). The chain of trust starts from PBL. But I don't think that all OEMs hardcode key in bootloader this way.
0
Seppppx said:
Does that mean that you could dd the bootloader and reverse engineer it somehow to get the public key?
Click to expand...
Click to collapse
You can simply extract public key by dumping bootloader partition in EDL mode. But even if you manage to extract it, there's not much you can do with that knowledge except to verify verity_key yourself.
Seppppx said:
Also what do you mean by "chain of trust" if that means the verification process then why does (or what does it exactly mean) it start from the PBL when it verifies the extended bootloader which verifies the bootloader.
Click to expand...
Click to collapse
Chain of trust here is the verification process of each stage in the boot process. A chain of trust is usually verified from the end point and goes up to the root node but in boot process it verifies the root node first and goes all the way down to the OS.
PBL is burned on CPU die (underlying circuitry on which CPU is mounted) which can be tampered with physical access in theory but not feasible enough in practise and not scalable either.
PBL verifies itself with Qualcomm's public key which is also hardcoded with PBL. Before PBL is verified, Qualcomm's public key is also verified with the hash stored in eFuse. This entire region is non-writable. This is why PBL is treated as root of trust.
Hi guys, I am asking you some help due to an emergency.
I had to downgrade an Android 10 rom where I had encryption turnen on (rom).
All I did was flashing a previous (minor) version of the rom via TWRP with just a "wipe cache/dalvik".
After rebooting my pin was not recognized anymore by both Android and TWRP.
I did many tentatives and at some point I typed "default_password" as pin, when asked by Android during the boot, and there was a important change:
1. After rebooting I typed my old pin, and now Android always tells me: "The password you entered is correct, but unfortunately your data is corrupt".
2. Now when TWRP asks for the password, it accepts the old pin too. But it is "unable to mount storage".
3. The system partition's contents are now visible: before they were not showing at all. The data partition is not accessible (error decrypting…).
I have done a lot of studying and tentatives to get the phone working without formatting and losing the data, but I could not solve the issue. I don't think the data is actually corrupted, because the rom downgrade was a minor version and it did not modify anything about encryption.
Could you please point me to the right direction? I am trying to understand what could have gone wrong, and find some possible solution.
EDIT: more details and list of the attempted solutions in this post: https://forum.xda-developers.com/t/...sue-after-rom-downgrade.4168821/post-85210619
JackSlaterIV said:
After rebooting I typed my old pin, and now Android always tells me: "The password you entered is correct, but unfortunately your data is corrupt".
Click to expand...
Click to collapse
Look inside here.
jwoegerbauer said:
Look inside here.
Click to expand...
Click to collapse
Both methods cause /data to be erased, which is what I don't want. Thanks anyway.
guess if something has changed since your dirty flash, it must be something in last 16384 bytes where the crypto footer is
there are some bytes which are most likely one or eight flag(s)
Flags : 0x00000000
you can locate and copy the crypto footer like this
- check fstab for location if it says encryptable=footer (or see recovery.log)
- get partition size and calculate the offset -16384
- extract the footer to /sdcard with dd (any file name)
{
"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"
}
on PC open that file with Hex Editor
- the crypto footer will start with magic 0xD0B5B1C* (little endian). in my case it's C5 B1 B5 D0 as it's a samsung device.
- you should also see a string aes-cbc-essiv:sha256 (in my case aes-xts)
inspect the crypto footer with python script. you can't decrypt since android uses scrypt+keymaster but it will give you a nice layout
- install python 2.7
- run that script bruteforce_stdcrypto.py
Code:
Android FDE crypto footer
-------------------------
Magic : 0xD0B5B1C4
Major Version : 1
Minor Version : 3
Footer Size : 2352 bytes
Flags : 0x00001008
Key Size : 128 bits
Failed Decrypts : 36
Crypto Type : aes-xts
Encrypted Key : 0xCCE7D93B501B400D3D81726806F92936
Salt : 0x51B68B017C2A181E3ABD0B041FBFAA14
KDF : scrypt+keymaster
N_factor : 15 (N=32768)
r_factor : 3 (r=8)
p_factor : 1 (p=2)
crypt type : PIN
FS size : 52453304
encrypted upto : 52453304
-------------------------
as you can see in your case the flags are 0x00001008 so you can easier locate that in your Hex Editor
- convert the string little endian 0x00 00 10 08 -> 08 10 00 00
- you will find that four bytes at offset 13 in the first line
- reset the flags to 00 00 00 00 and save the file
if you prefer linux you can also use that shell script for doing that. fde_crypto.sh
Before messing up your data partition do a full dump for backup purposes (because we don't know what we are doing here, encryption is complicated stuff). In case you broke something you can just adb push it later
Code:
adb pull /dev/block/bootdevice/by-name/userdata
Now, write the new crypto footer back to end of userdata partition
- copy the file back to the device (another file name)
- get partition size and calculate the offset -16384
- write the footer to offset with dd (seek)
Code:
adb push data-footer.bin /sdcard
adb shell
cd /sdcard
blockdev --getsize /dev/block/bootdevice/by-name/userdata
dd bs=512 seek=$((52453336-32)) count=32 if=data-footer.bin of=/dev/block/bootdevice/by-name/userdata
Note: i don't know if that works. indeed, that's all guesswork based on your input in pm. good luck!
Hi and thanks again. As you wrote we spoke a lot via PM before your post.
I reset the footer flags to 00 00 00 00. Then used dd as you suggested to overwrite the userdata footer.
During the first Android boot, it asked me to enter the pin, but then it failed to decrypt, and now is always showing the old message "The password you entered is correct, but unfortunately your data is corrupt" .
So looks like the flag at least reset the default mode.
And TWRP still can't decrypt the partition.
It's no surprise because, as you showed me, the userdata partition may be corrupted.
I wanted to get the updated footer back from the phone to my PC. I used this:
dd bs=512 seek=$((52453336-32)) count=32 if=/dev/block/bootdevice/by-name/userdata of=/tmp/data-footer-new.bin
32+0 records in
32+0 records out
16384 bytes (16.0KB) copied, 0.009945 seconds, 1.6MB/s
Then Adb pull tmp/data-footer-new.bin
But it started downloading a few GB of data. I checked the size via ls -l:
-rw-rw-rw- 1 root root 26856108032 Dec 20 14:04 data-footer-new.bin
What I did wrong? Is it a bug?
usage problem - this is expected behavior for dd seek. when the output file is too small or doesn't exist, a zero padding is filled to create a big file before the offset starts, where it finally starts to write the real data (32 x 512 bytes)
you have mixed up parameters skip/seek, in your case copied first 16384 bytes from userdata into the end of a big file data.footer.bin
btw the userdata partition is not corrupt per se (or at least there is no proof i could show ever) you will never find ext4 file system magic 0xEF53 on encrypted userdata, only on dm-0 (if decrypted successfully). but true, mounting is a different case, indeed mount may fail even for successfully decrypted file system (like for Redmi 5). so the safest way to know if decrypted successfully is looking for zero paddings, first 1024 bytes will have enough of it...
you can try lot of other values for this flag (0x00001000 like for LG?) or try other (undiscovered) flags. you need a lot patient and time as you are the first one trying this. also reset the failed decrypts counter as this may important for gatekeeper timeout
i recommend to decrypt straight from twrp command line, should "work" without reboot
edit: i could even imagine automatizing that with script (10 sec/attempt - min timeout)
edit 2: interesting too would be binary (or checksum) compare of userdata before/after failed attempt (without footer) to figure out if changes happen elsewhere (other than footer)
even more interesting, you could factory reset and reproduce the mistake, make a snapshot before/after and bitwise compare where the changes happen
if the key itself has changed, there is no possible way to revert as the old key is lost
but decryption should still be possible on the newer android version, all you need is working twrp that fits
edit: factory reset is maybe not the best idea! turns out for FBE file-based-encryption the KEK is stored in TEE and depending on rollback resistance (not related to version binding) master key may deleted on factory reset. FBE is introduced with Android 7.1 - your device is still running good old FDE full-disk-encryption - but who knows what additional protections Android 10 enforces? can't guarantee that KEK is encrypted by hardware-backed RSA-2048 private key and screenlock credentials only and everything is stored in crypto footer only, although the documentation doesn't indicate contradictory
aIecxs said:
usage problem - this is expected behavior for dd seek. when the output file is too small or doesn't exist, a zero padding is filled to create a big file before the offset starts, where it finally starts to write the real data (32 x 512 bytes)
you have mixed up parameters skip/seek, in your case copied first 16384 bytes from userdata into the end of a big file data.footer.bin
Click to expand...
Click to collapse
Can you confirm this is the correct command to get the new footer?
dd bs=512 skip=$((52453336-32)) count=32 if=/dev/block/bootdevice/by-name/userdata of=/tmp/data-footer-new.bin
I think that this new big file may have caused some corruption.
I want to restore the userdata partition backup, but I read it's not easy as a simple adb push: https://android.stackexchange.com/q...n-image-of-android-partition-from-my-linux-pc
Can you tell me any reliable way to do this, apart using busybox as in the above replies?
btw the userdata partition is not corrupt per se (or at least there is no proof i could show ever) you will never find ext4 file system magic 0xEF53 on encrypted userdata, only on dm-0 (if decrypted successfully). but true, mounting is a different case, indeed mount may fail even for successfully decrypted file system (like for Redmi 5). so the safest way to know if decrypted successfully is looking for zero paddings, first 1024 bytes will have enough of it...
Click to expand...
Click to collapse
Thanks for clarifying this.
you can try lot of other values for this flag (0x00001000 like for LG?) or try other (undiscovered) flags. you need a lot patient and time as you are the first one trying this. also reset the failed decrypts counter as this may important for gatekeeper timeout
i recommend to decrypt straight from twrp command line, should "work" without reboot
edit: i could even imagine automatizing that with script (10 sec/attempt - min timeout)
edit 2: interesting too would be binary (or checksum) compare of userdata before/after failed attempt (without footer) to figure out if changes happen elsewhere (other than footer)
Click to expand...
Click to collapse
Indeed I had already tried 0x00001000 and resetting the counter, before the mess up with my dd command.
Do you know any other combination I could try?
Something I could try is see what happens to /userdata if I type default_password at the first boot.
yes, that is the right command
no, you didn't mess up with big file because of= is the only thing written (and /tmp is only in RAM)
yes, simple adb push is fine and works quite well for single partition. the link is talking about something different (whole eMMC including gpt and bootloader)
no, i have no clue about the flags. the source code might help but it's above my knowledge (yet)
found some explanation for flags
https://www.0xf8.org/2019/01/analyz...axy-s7-data-partition-with-samsung-encryption
have implemented the above link, not sure if i am doing it right but have a look into script fde_crypto.sh
Hello alecxs, thanks for your last messages. Sorry for this long delay.
I did not write any update because I couldn't find anything useful in the footer and the full data images. The phone is still not in use, in a drawer.
I had tried different flags, but after each tentative I had the same result. The "system" tells that data may be corrupted and updates the flag accordingly.
I had compared before vs after data images and did not find any difference. There is only one field in the footer that is modified after each tentative: the sha256 of the footer (offset 90c).
Without further information I cannot tell what causes this issue, if the data is corrupt or not. It would be useful having a more verbose mode in the mount command, so that it shows the reason of the failed mount. I guess it's not possible.
i think it is caused by rollback resistance and you should try higher android version (that one that messed up everything) with compatible TWRP. besides recovery.log you can check dmesg and logcat for additional information
Hi again,
I am attaching dmesg and recovery log, taken from TWRP after a failed mount of the data partition, using my pin, with the crypto footer flags reset to zero.
I could not find anything, so I hope someone reading this could give me a hint.
From what I can see, anti rollback and verified boot are disabled in Mi5 and in LineageOS based roms (see here).
Regarding TWRP I always used the same version recommended by the rom developer.
EDIT: file attachment not working for me...
See them here:
dmesg.log
Shared with Dropbox
www.dropbox.com
recovery.log
Shared with Dropbox
www.dropbox.com
looks like double encryption bug. try to dump content of dm-0 and restore it to userdata, that should at least eliminate the FDE encryption. second encryption is FBE? let binwalk analyze usually there is unencrypted area
aIecxs said:
... you should try higher android version [...]
Click to expand...
Click to collapse
just as a reference: for this you would find errors like
E vold : upgrade_key failed, code -38
E Cryptfs : Failed to upgrade key
which is not the case here.
(note: yes it says "upgrade" but in my example the installed key is from a higher version so actually a downgrade would be needed - which is not possible at all.)
(see a full example and details here and google details here)
JackSlaterIV said:
Hi again,
I am attaching dmesg and recovery log, taken from TWRP after a failed mount of the data partition, using my pin, with the crypto footer flags reset to zero.
I could not find anything, so I hope someone reading this could give me a hint.
From what I can see, anti rollback and verified boot are disabled in Mi5 and in LineageOS based roms (see here).
Regarding TWRP I always used the same version recommended by the rom developer.
EDIT: file attachment not working for me...
See them here:
dmesg.log
Shared with Dropbox
www.dropbox.com
recovery.log
Shared with Dropbox
www.dropbox.com
Click to expand...
Click to collapse
the interesting part is here:
Code:
<3>[ 5.880909] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -65,app_id = 0,lstr = 12288
<3>[ 6.007678] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -71,app_id = 0,lstr = 12288
<3>[ 6.007697] QSEECOM: __qseecom_set_clear_ce_key: process_incomplete_cmd FAILED, resp.result -71
<3>[ 6.007716] QSEECOM: qseecom_create_key: Failed to create key: pipe 2, ce 0: -22
<3>[ 6.007726] QSEECOM: qseecom_ioctl: failed to create encryption key: -22
<3>[ 6.098357] scm_call failed: func id 0x72000501, ret: -2, syscall returns: 0xffffffffffffffbf, 0x0, 0x0
<3>[ 6.225071] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -71,app_id = 0,lstr = 12288
<3>[ 6.225082] QSEECOM: __qseecom_set_clear_ce_key: process_incomplete_cmd FAILED, resp.result -71
<3>[ 6.225096] QSEECOM: qseecom_create_key: Failed to create key: pipe 2, ce 0: -22
<3>[ 6.225104] QSEECOM: qseecom_ioctl: failed to create encryption key: -22
the main error is likely:
Code:
<3>[ 5.880909] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -65,app_id = 0,lstr = 12288
[..]
<3>[ 6.007716] QSEECOM: qseecom_create_key: Failed to create key: pipe 2, ce 0: -22
<3>[ 6.007726] QSEECOM: qseecom_ioctl: failed to create encryption key: -22
-65 means: ATTESTATION_APPLICATION_ID_MISSING whatever that means actually.
aIecxs said:
looks like double encryption bug. try to dump content of dm-0 and restore it to userdata, that should at least eliminate the FDE encryption. second encryption is FBE? let binwalk analyze usually there is unencrypted area
Click to expand...
Click to collapse
interesting idea especially as it actually can decrypt /dev/dm0 according to the recovery.log but then failing to mount it.
I would +1 here and try if you can dump the content of /dev/dm0 after trying the decryption ( e.g. when you have an ext sdcard: `dd if=/dev/dm0 of=/external_sd/dump.img bs=4096` )
Other then that it might be an issue with your blobs - either in TWRP, or the device
i think your issue is bit different and the links provided are about FBE. afaik FDE does not hold keys in TEE (except for hardware-backed RSA-2048 private key which is not flushable) so i am not sure if upgradeKey affects crypto-footer but deleteKey is clearly some keystore thing
to eliminate issues with TWRP i would do decryption test on working block encryption (and maybe try OrangeFox) only then you can determine issues with faulty crypto-footer
Hello guys, thanks for your help.
I dumped both sda14 and dm-0 partitions (using adb dump).
The dm-0 ("decrypted" partition) is a smaller binary file (26.856.091.648 bytes) vs sda14 (26.856.108.032 bytes).
I compared these binary files using HxD and they look different. dm-0 does not contain the crypto footer section (the 16384 bytes difference).
I just installed binwalk for the suggested purpose, and started analyzing dm-0 (binwalk dm-0). It is outputting something and I don't have any idea of how much time it would take to complete the task.
Let's see if I can attach a screenshot..
okay not sure binwalk may just false detect random data or it may real files. anyway you can concatenate dm-0 with crypto-footer from userdata and check what TWRP says about this garbage then
aIecxs said:
okay not sure binwalk may just false detect random data or it may real files. anyway you can concatenate dm-0 with crypto-footer from userdata and check what TWRP says about this garbage then
Click to expand...
Click to collapse
Yes indeed.
I did not find any text in the dm-0 binary.
Can you suggest me how I concatenate these files? I have dm-0 and crypto-footer in separate files. EDIT: just by using HxD.
To overwrite the partition can I use "adb push dm-0-new /dev/block/sda14"?