Database Info

SM-G361F - Pre-rooted rom development

Hello,
I'm not able to build (repackage) correctly system.img for SM-G361F, output is always rejected by both Odin (10.3.7) and Heimdall
I'm trying to repackage (pre-root) system.img taken from "G361FXXU1APA2_G361FOXX1APA1_G361FXXU1APA2_HOME.tar.md5" (taken from ETL factory image named ETL-G361FXXU1APA2-20160202095551.zip )
Step-by-step:
1) tar xvf G361FXXU1APA2_G361FOXX1APA1_G361FXXU1APA2_HOME.tar.md5 system.img
2) simg2img system.img system.img.raw
3) mount system.img.raw /mnt
4) made changes
5a) make_ext4fs -s -g 32768 -b 4096 -T -1 -S file_contexts -f -l 1843M system.repack.img /mnt/
5b) mkuserimg.sh -s /mnt system.repack.img ext4 system 1843M file_contexts
6) tar --owner 0 --group 0 --numeric-owner -H ustar -c system.img > G361F_SYSTEM.tar
7a) Load either system.img through Heimdall (PIT file downloaded through Heimdall is here: http://forum.xda-developers.com/showpost.php?p=65779994&postcount=146 )
7b) Load G361F_SYSTEM.tar in Odin v3.10.7 in AP tab and flash it
On ODIN/Download screen I can see that
1) FRP LOCK: OFF
2) KNOX: 0x0
3) System status: official
4) RP SWREV: S1, L1, M1
Notes
1) I have checked the box "OEM Unlock" in Developers settings to enabled
2) "file_contexts" is taken from booted up device through ADB (adb pull /file_contexts)
3) I've tried repackage the image without making any changes
4) When I compare original and repackaged images ("ls -lsaR" outputs), it seems like owner:group permissions are not persisted
5) I've tried both simg2img/make_ext4fs/mkuserimg.sh from CM12.1 repository (up to date today) and from https://github.com/ASdev/android_img_repack_tools (branch android-5.1.1)
6) I'm not sure about size 1843M, however flashing fails in the same manner when I go with 1536M and 2048M and anything between those two
7) Heimdall fails at about 6% of flashing single (sparse system.img) file with error "Failed to unpack received packet"
OSS Kernel for SM-G361F is here: https://github.com/smarek/G361F-Kernel
OSS Platform for SM-G361F is here: https://github.com/smarek/G361F-Platform
Questions are:
1) Is there anything special to be aware of when building for Samsung devices?
2) Did I miss or misunderstood any step in system.img repackaging process?

[TOOL] imjtool - Unpack and extract a variety of OTA images from various vendors

Hello All,
My Imjtool is now at version 1.6 , supporting MediaTek images, improving QCom FBPK (SD845 and onwards ".img"), DTBO (Device tree blob overlay) slicing, super.img (liblp logical partitions) and block based update images (system.transfer.list and ..new.dat) even when compressed with Brotli (.br) compression.
By now, there's support for quite a few formats, including proprietary QCOM FBPK, Huawei UPDATE.APP, and even UEFI containers:
Code:
/**
*
* Rudimentary Android image and partition unpacking tool
*
* v0.1 - Support unpacking of BootLoader and Boot images, as well as imgdata
* v0.2 - Supports offset= (for HTC and other boot.imgs where ANDROID! is wrapped)
* Supports cmdline= (to override kernel command line)
*
* v0.3 - Integrated mkbootimg functionality, added dt_size and id
*
* v0.4 - cmdline, addrs..
*
* v0.4.1 - Fix for Edvard Holst on Essential PH1 images.. (who uses Essential nowadays, I wonder?)
*
* v0.5 - Update with LZ4 binaries, fix for extract devicetree even if can't uncompress kernel
*
* v0.6 - Samsung images (with DT > 0) - Device Tree now found whereever it may hide
*
* v0.7 - system.transfer.list support
*
* v0.8 - FBPK (SD845 CrossHatch (Pixel 3 XL) bootloader images) AND Huawei Mate
* Also compiles cleanly
*
* v0.85 - system.transfer.list support for v4 (MTK 64 bit)
*
* v1.0 - EFI. Worthy enough a feature that (after three years) I hit version 1 on it, and - JCOLOR
*
* v1.1 - Samsung baseband images ("TOC") - 03/04/2020
*
* v1.2 - DTBO, super.img (03/20/2020) and integrated Brötli
*
* v1.2.1 - Lots of QCOM EFI GUIDs added. Thanks to anonymous contributor!
*
* v1.3 - Can now also pack super.img and boot.img based on existing!
*
* v1.4 - uBoot uimage format
*
* v1.5 - MTK images!
*
* v1.5.1 - Fixes: QCOM FPBK fixed (accidentally removed during refactoring around 1.3.. oops)
* UEFI now unpacks files by UI, if presenr, rather than GUID
*
* 1.6 - Peek into images to detect payload format
*
*
* platform-innovation-framework-for-uefi-complete-specifications-v0.90-v0.97 from Intel
* was invaluable for figuring out EFI
*
*
* This tool is part of the free downloads for the book
* "Android Internals: A Confectioner's Cookbook"
* But (as of v1.0) is also quite useful or MacOS T2 firmwares
*
* Author: Jonathan Levin, http://NewAndroidBook.com
*
* (New edition of Book and the loooong overdue Vol II coming soon! Check /TOC.html on site!)
*
* License: Use freely, BUT give credit where due. This way people learn of the website and books.
*
* If you have suggestions for improvement/new image types/etc - let me know and I'll gladly
* add them in.
**/
Totally free to use, feedback or requests appreciated.
Link: NewAndroidBook.com/tools/imjtool.html

Hello!
I've stumbled into this tool while trying a stupid thing. I've realized that on Xiaomi Mi A3 (laurel_sprout) the android splash images are stored in xbl.elf.
Code:
<!-- This is LUN 1 - Boot LUN A" -->
<physical_partition>
<partition label="xbl_a" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_a" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
<!-- This is LUN 2 - Boot LUN B" -->
<physical_partition>
<partition label="xbl_b" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_b" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
I've used imjtool on Ubuntu 18.04 WSL and was able to extract xbl.elf contents, where, indeed the bmp files are stored (see attachment).
Now my question is, how to "repack" the elf file if I wanted to replace those bmp files for other ones?
Is that possible?

err.. no. But I could probably add that as a feature - I'll admit this is the first time I'm getting this request.
Thing is XBL is signed, and even if you unlock the bootloader, that only takes effect well after XBL loading (in fact, after ABL), so you won't be able to reflash XBL without risk of bricking.
Sure you need this?
Typhus_ said:
Hello!
I've stumbled into this tool while trying a stupid thing. I've realized that on Xiaomi Mi A3 (laurel_sprout) the android splash images ares stored in xbl.elf.
Code:
<!-- This is LUN 1 - Boot LUN A" -->
<physical_partition>
<partition label="xbl_a" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_a" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
<!-- This is LUN 2 - Boot LUN B" -->
<physical_partition>
<partition label="xbl_b" size_in_kb="3584" type="DEA0BA2C-CBDD-4805-B4F9-F428251C3E98" bootable="false" readonly="true" filename="xbl.elf"/>
<partition label="xbl_config_b" size_in_kb="128" type="5A325AE4-4276-B66D-0ADD-3494DF27706A" bootable="false" readonly="false" filename="xbl_config.elf"/>
<partition label="last_parti" size_in_kb="0" type="00000000-0000-0000-0000-000000000000" bootable="false" readonly="true" filename="" />
</physical_partition>
I've used imjtool on Ubuntu 18.04 WSL and was able to extract xbl.elf contents, where, indeed the bmp files are stored (see attachment).
Now my question is, how to "repack" the elf file if I wanted to replace those bmp files for other ones?
Is that possible?
Click to expand...
Click to collapse

morpheus______ said:
err.. no. But I could probably add that as a feature - I'll admit this is the first time I'm getting this request.
Thing is XBL is signed, and even if you unlock the bootloader, that only takes effect well after XBL loading (in fact, after ABL), so you won't be able to reflash XBL without risk of bricking.
Sure you need this?
Click to expand...
Click to collapse
No, of course I don't "need" this. And, yes, my device is fully unlocked (critical partitions included).
Thing is, on Android community it's usual to change the splash screen but, normally, there's a splash.img (or logo.bin, etc) where all image files ares stored. Those files belong to a splash partition, which typically, isn't that "important" so even if we mess up flashing the wrong stuff onto it, a new flash with the proper img (or bin) file would solve the issue.
Now, for what I've understood, what you're saying is that we could face the risk of hard bricking the device if the "repack" would create a corruptible elf file, right?
After extracting the elf file I've noticed a LOT of stuff there, besides the 2 bpm files I wanted to change, and so if this is an unnecessary risk, I'll just forget about it.
Funny thing is, on this device (Xiaomi Mi A3), there's a splash partition and we can "dd" it but it results on a splash.img filled with zeros. I wonder if we could create a splash.img using the bpm files I've found on the xbl.elf file and flash it on the splash partition...just to check if it would overwrite the bpm files present on xbl.elf.
Don't know, guess I'll try it...just have to find a splash image tool compatible with the device resolution.
Either way, thank you for answering me.

Just making sure there - better safe than sorry, as, even with "critical partitions" unlocked, I can't vouch for your boot sequence not rejecting this - whether the ELF is valid or corrupt won't be the main risk - what will be is that the bootROM (or UEFI runtime) might reject this xbl as it won't be validly signed.
Still, it's an interesting challenge. I can get on it. I'll update, and you can always get me over DM.
BTW, I just updated imjtool.tgz (at same URL) with a minor update to accommodate for all QCOM GUIDs I could get my hands on. If you try it again you should be able to see lots more "DXE" files in human readable, rather than GUID notation..
Typhus_ said:
No, of course I don't "need" this. And, yes, my device is fully unlocked (critical partitions included).
Thing is, on Android community it's usual to change the splash screen but, normally, there's a splash.img (or logo.bin, etc) where all image files ares stored. Those files belong to a splash partition, which typically, isn't that "important" so even if we mess up flashing the wrong stuff onto it, a new flash with the proper img (or bin) file would solve the issue.
Now, for what I've understood, what you're saying is that we could face the risk of hard bricking the device if the "repack" would create a corruptible elf file, right?
After extracting the elf file I've noticed a LOT of stuff there, besides the 2 bpm files I wanted to change, and so if this is an unnecessary risk, I'll just forget about it.
Funny thing is, on this device (Xiaomi Mi A3), there's a splash partition and we can "dd" it but it results on a splash.img filled with zeros. I wonder if we could create a splash.img using the bpm files I've found on the xbl.elf file and flash it on the splash partition...just to check if it would overwrite the bpm files present on xbl.elf.
Don't know, guess I'll try it...just have to find a splash image tool compatible with the device resolution.
Either way, thank you for answering me.
Click to expand...
Click to collapse

morpheus______ said:
BTW, I just updated imjtool.tgz (at same URL) with a minor update to accommodate for all QCOM GUIDs I could get my hands on. If you try it again you should be able to see lots more "DXE" files in human readable, rather than GUID notation..
Click to expand...
Click to collapse
Cool, thanks for the update. I'll check it.
Stupid question, isn't the elf file signature one of it's files inside it's content? If it is, and if we preseve it (like don't touch it), after "repacking" wouldn't it still be signed with the same valid signature? Or the process to "repack" will forcibly resign it with a different signature?
The goal was to simply replace one bpm file (the one that states unlocked) since the other one only appears when the bootloader is locked...no point on changing that. All of the rest would remain exactly the same.
Thank you for spending time around this.

There are many ways to sign files. In the case of ELF, it's a separate section which signs all contents of the ELF but itself. The problem is, that it signs *all* contents, so that if you add a section - you've changed the header and you've messed the signature up. Same idea as signing an APK - so that you can't tamper with any of the files in it.
When you "repack" you can't re-generate the signature because it's a hash (which you can recompute easily) signed with the private key of the vendor (which you don't have). The old signature section won't be valid anymore because you will have altered the contents and/or added sections at this point.
J
Typhus_ said:
Cool, thanks for the update. I'll check it.
Stupid question, isn't the elf file signature one of it's files inside it's content? If it is, and if we preseve it (like don't touch it), after "repacking" wouldn't it still be signed with the same valid signature? Or the process to "repack" it will forcibly resign it with a different signature?
The goal was to simply replace one bpm file (the one that states unlocked) since the other one only appears when the bootloader is locked...no point on changing that. All of the rest would remain exactly the same.
Thank you for spending time around this.
Click to expand...
Click to collapse

morpheus______ said:
There are many ways to sign files. In the case of ELF, it's a separate section which signs all contents of the ELF but itself. The problem is, that it signs *all* contents, so that if you add a section - you've changed the header and you've messed the signature up. Same idea as signing an APK - so that you can't tamper with any of the files in it.
When you "repack" you can't re-generate the signature because it's a hash (which you can recompute easily) signed with the private key of the vendor (which you don't have). The old signature section won't be valid anymore because you will have altered the contents and/or added sections at this point.
J
Click to expand...
Click to collapse
Right, I understand.
Anyway, is the tool updated already? I'm just asking since I've tried it right now and it shows the exact same content after extracting xbl.elf again.

yep.
NewAndroidBook.com/tools/imjtool.tgz is direct link.
Patching ELF might take me a while
J
Typhus_ said:
Right, I understand.
Anyway, is the tool updated already? I'm just asking since I've tried it right now and it shows the exact same content after extracting xbl.elf again.
Click to expand...
Click to collapse

How to repack super.img
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...

bagbyte said:
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...
Click to expand...
Click to collapse
Update: I've found my answer: https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70

That's because 'make' wasn't designed for super.img creation, but for initrd (boot.img).
Now that I know people need this, I'll add that in. Updates to follow.
J
bagbyte said:
I^m trying to modify system.img inside super.img.
First step extract super.img file:
Code:
imjtool super.img extract
It creates a file image.img, inspecting it with imjtool I get:
Code:
$ imjtool image.img
liblp dynamic partition (super.img) - Blocksize 0x1000, 2 slots
LP MD Header @0x3000, version 10.0, with 4 logical partitions on block device at partition super, first sector: 0x800
Partitions @0x3080 in 2 groups:
Group 0: default
Group 1: group_basic
Name: system (read-only, spanning 1 extents and 4613 MB)
Name: vendor (read-only, spanning 1 extents and 574 MB)
Name: product (read-only, spanning 1 extents and 665 MB)
Name: odm (read-only, spanning 1 extents and 4 MB)
I proceed with extracting the content of image.img
Code:
imjtool image.img extract
It extracts 4 files:
system.img
vendor.img
product.img
odm.img
After mouting system.img and make my change, how can I repack the 4 files and recreate super.img?
I've tried with
Code:
imjtool make super.img system.img vendor.img product.img odm.img
but the result is something different...
Click to expand...
Click to collapse

This is very helpful. Many thanks!
Chaser

Yeah great stuff... just used imjtool to extract abl.img and hunt for hidden fastboot commands.
This is an awesome tool!!!
Thanks a lot and best regards,
scholbert

morpheus______ said:
That's because 'make' wasn't designed for super.img creation, but for initrd (boot.img).
Now that I know people need this, I'll add that in. Updates to follow.
J
Click to expand...
Click to collapse
Thank you for this tool!! I could also definitely use the ability to do this ^^^ with imjtool.

Unpacking/Repacking for Samsung S9
Hey, nice work, thank you!
I pulled the working boot.img from a Samsung Galaxy S9. I am just trying to unpack it, repack it and flash it back, and see it working (as a test, if that works I'll move to replace the kernel).
Your tool also extracts the DTB, which is great, abootimg didn't do that. However, when I repack like
Code:
imjtool.x86_64 make boot-repacked.img extracted/kernel extracted/ramdisk extracted/kernelimage extracted/devicetree.dtb
the result is only 38M large, the original is 55M, which seems already fishy. When I flash it anyway (using heimdall if it matters), it results in a bootloop.
So my questions are:
Am I using your tool wrong? Is the Samsung S9 not supported? Or is it a bug?
Another thing that puzzles me:
imjtool unpacks
Code:
devicetree.dtb kernel kernelimage ramdisk
abootimg unpacks
Code:
bootimg.cfg initrd.img zImage
So I know abootimg apparently misses the DTB (and "kernelimage" which is the .config used when the kernel was built) - But is your tool missing the info in bootimg.cfg (e.g. kernel command line?)
Thanks for your work/help!
This is what imjtool printed when extracting, in case it matters:
Code:
Boot image detected
Part Size Pages Addr
Kernel: 29126664 14223 0x10008000
Ramdisk: 9880749 4825 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 1787904 bytes
ID: d251a0a387fd671226676852a14905ff726e6c79000
Name: SRPQH16B002KU
CmdLine: androidboot.selinux=permissive androidboot.selinux=permissive
Found GZ Magic at offset 13352456
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
57.7% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x2534800
Found DT Magic @800

Hi Arcepth,
Odd; I have an S9 myself, and re-creating the image worked for me way back when I tried it. Could you do me a favor and send your boot.img? DM is fine.
The kernel command line should be taken from the boot.img, (the .cfg file abootimg generates is artificial). You can specify cmdline= to imjtool and it will embed that cmdline.
Samsung's odd with their device tree. They put it as the secondary, whereas others just fuse it to the kernel.
Any deviation from what Samsung expects will boot loop. I know this the very hard way
Anyway, DM me.

Using imjtool on S20 boot.img
I am having the same issue with Galaxy S20's "boot.img".
The original is ~60MB but after repack is ~38MB
-----------------------------Log---------------------------
root:/home/tools/imjtool# ./imjtool.x86_64 boot.img extract
Boot image detected
Part Size Pages Addr
Kernel: 37801996 18459 0x10008000
Ramdisk: 889691 435 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 2 bytes
ID: ##################################
Name: S##########
CmdLine: androidboot.hardware=exynos990 androidboot.selinux=permissive androidboot.selinux=permissive
Found GZ Magic at offset 16951272
extracted/kernelimage.gz:
gzip: extracted/kernelimage.gz: decompression OK, trailing garbage ignored
62.7% -- replaced with extracted/kernelimage
Extracting kernel
Extracting ramdisk
Searching for DT at 0x24e7800
Unable to locate device tree
-----------------------------------End Log---------------------------------
My command for repack:
roothome:/home/tools/imjtool# ./imjtool.x86_64 make boot2.img extracted/kernel extracted/ramdisk extracted/kernelimage [cmdline='androidboot.hardware=exynos990 androidboot.selinux=permissive androidboot.selinux=permissive'] [addr=0x10008000]
I didn't try to flash this though.

Thank you for the feedback! The tool is built around my use cases, but I don't get to experience all the crazy variants in image formats out there..
Anyway - I got this one: It took a bit to figure out but Samsung shoves a LOT of stuff after the DT which isn't part of the boot.img specification, as well as stuff which now is (AVB0) but I wasn't aware of when I started imjtool. So - I'm updating imjtool to handle this. I can already reliably detect and extract all their extras:
Code:
[email protected]öst (~/Documents/Android/src/Imjtool) %./imjtool ~/Downloads/boot.original.img
Boot image detected
Part Size Pages Addr
Kernel: 29126664 14223 0x10008000
Ramdisk: 9880749 4825 0x11000000
Secondary: 0 0 0x10f00000
Tags: 0x10000100
Flash Page Size: 2048 bytes
DT Size: 1787904 bytes
Found Samsung DTBH @0x2534800 with 6 trees
[email protected] (0x49000 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x10-0x10
[email protected] (0x49000 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x11-0x11
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x12-0x13
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x14-0x16
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x17-0x19
[email protected] (0x48800 bytes): Chip:0x2652 Platform:0x50a6 subtype:0x217584da hw_rev:0x1a-0xff
DTBH block ends @0x26e9000
Warning: DT ends 0x26e9000, but filesize is 0x3700000 - looking further
Found [email protected]
ID: d251a0a387fd671226676852a14905ff726e6c79000
Name: SRPQH16B002KU
CmdLine: androidboot.selinux=permissive androidboot.selinux=permissive
And I'm working on finalizing a "repack" command which will use the base boot.img you provide and just enable the select overriding of portions or values.
Please try this build: http:// NewAndroidBook.com /tools /imjtoolbeta.tgz
You can use repack (base.img) and then change a variety of parameters. New image will be repacked.img in same dir.

Repacked size looks better now
Tried the beta and it looks much better! The "repacked.img" is much closer to the original size (I tried with a kernel built from official source code).
Only issue left is that ODIN fails to flash my created "boot.img.tar" file to the S20.
Just see a generic "RQT_CLOSE" message on ODIN.
Any clue what I'm missing? (already LZ4 compressed, tarballed with various methods, even disabled AVB)

[RECOVERY] TWRP 3.5.2 | Unihertz Jelly 2

How to install:
Unlock bootloader:
Boot your device into the official OS.
Go to Settings > About phone, tap the "build number" several times to enable developer settings.
Go to Settings > System > Developer Settings, enable OEM unlocking and ADB debugging.
Connect your phone to your PC and open a terminal or a command line window.
Run adb reboot bootloader on your PC (there is no way to enter bootloader directly, only possible through adb).
Once your device has finished booting run fastboot flashing unlock and comfirm unlock on device (THIS WILL WIPE ALL DATA!).
Run fastboot reboot to reboot your device and now you should see an unlocked warning during boot screen.
Disable AVB:
Download vbmeta.img from the latest release page of your device.
Connect your phone to your PC and open a terminal or a command line window.
Run adb reboot bootloader on your PC to put your device in bootloader mode.
Once your device has finished booting run fastboot flash --disable-verification --disable-verity vbmeta vbmeta.img
Then run fastboot flash --disable-verification --disable-verity vbmeta_system vbmeta.img
Also run fastboot flash --disable-verification --disable-verity vbmeta_vendor vbmeta.img
Flash recovery image:
Connect your phone to your PC and open a terminal or a command line window.
Run adb reboot bootloader on your PC to put your device in bootloader mode.
Once your device has finished booting run fastboot erase recovery. For some reason, image may be not actually flashed, even if fastboot reported success (at least over the stock recovery image), so in order make sure that the custom image is always flashed it's better to always erase the partition before flashing. After the erasing run fastboot flash recovery recovery.img
Run fastboot reboot and after the screen goes dark press volume up until you see the TWRP logo. Also you can type fastboot reboot recovery to boot to recovery mode immediately.
Please note that booting in stock ROM will bring stock recovery back.
This recovery image is built using binaries from non-european (TEE) version of Jelly 2. Theoretically it should work on european (EEA). If it won't - contact me, I'll prepare an image based on EEA binaries.
Source code https://github.com/Meetoul/twrp_device_Unihertz_Jelly2

Thanks!
This fantastic!
its work on EEA!

Meetoul said:
Source code https://github.com/Meetoul/twrp_device_Unihertz_Jelly2
Click to expand...
Click to collapse
I just received my Jelly 2. It was on 2020 and I went straight through your files. Your TWRP does not respond on my European Jelly 2. Meaning, the touch screen does not respond. But I connected an USB trackball and switched in between adb sideloads. So I finally got it working.
For some reason during reboot TWRP warns me that there is no OS installed. But LoS 18.1 (yours) booted fine. Also flashed opengapps 2707 nano.
After a reboot (phone is still restoring apps) there is a "serial console is enabled" message "performance is impacted, check bootloader". Any instructions on how to get rid of that?.

I cannot seem to mount system as R/W with GSI image from https://github.com/phhusson/treble_experimentations/releases from within TWRP. I guess that's a more general problem, though
Any ideas?

kkazakov13 said:
I cannot seem to mount system as R/W with GSI image from https://github.com/phhusson/treble_experimentations/releases from within TWRP. I guess that's a more general problem, though
Any ideas?
Click to expand...
Click to collapse
Dave you tried the latest release a suggested by Meetoul?
[ROM] [UNOFFICIAL] Lineage OS 17.1 | Unihertz Jelly 2
https://drive.google.com/drive/u/0/folders/1VSmj_-a1PYNzFWtUfbsDGWg4uIh-Tgkd This ROM is built using binaries from non-european (TEE) version of Jelly 2. Theoretically it should work on european (EEA). If it won't - contact me, I'll prepare ROW...
forum.xda-developers.com
Release Fix gt1151qm touch in recovery · Meetoul/twrp_device_Unihertz_Jelly2_TEE
Recovery image based on new kernel image with patches for both gt1x and gt1151qm touch panel drivers.
github.com

Great Job!
I have Jelly2_JP.
I tried your recovery.img for Jelly2_TEE.
It can boot my Jelly2_JP, and it can enable adb shell, but it looped the splash screen.
But I execute following command in adb shell, twrp starts gui("Keep System Read only?" screen)
Jelly2_TEE:/ # mount -o ro /dev/block/mapper/system /
Touchscreen works fine.
Next, I tried to build twrp for Jelly2_JP using your device tree.
But it has same problem. (It looped the splash screen until I mount system partition.)
Do you have any advice?
Attachments
recovery_tee.log is pulled file from /tmp/recovery.log in your twrp for Jelly2_TEE. Line 1119 is after I mount system partition by adb shell.
recovery_jp.log is pulled file from /tmp/recovery.log in my twrp for Jelly2_JP. Line 1356 is after I mount system partition by adb shell.
My build instructions
$ cd ~/twrp
$ repo init -u https://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-10.0
$ vi .repo/local_manifests/roomservice.xml
$ repo sync --force-sync
$ cd device/Unihertz
$ cp -r Jelly2_TEE Jelly2_JP
$ cd Jelly2_JP
$ mv omni_Jelly2_TEE.mk omni_Jelly2_JP.mk
$ grep -l Jelly2_TEE * | xargs sed -i 's/Jelly2_TEE/Jelly2_JP/g'
$ grep -l g55v71c2k_dfl_tee * | xargs sed -i 's/g55v71c2k_dfl_tee/g55v71c2k_dfl_jp_felica/g'
$ ./extract-files.sh ~/stock_jp/extracted
$ unpack_bootimg --boot_img ~/stock_jp/recovery.img --out ~/stock_jp/recovery
$ cp ~/stock_jp/recovery/kernel prebuilt/Image.gz
$ cp ~/stock_jp/recovery/dtb prebuilt/dtb/mt6771.dtb
$ cp ~/stock_jp/recovery/recovery_dtbo prebuilt/dtbo.img
$ cd ~/twrp
$ source build/envsetup.sh
$ lunch omni_Jelly2_JP-eng
$ mka recoveryimage
$ ls out/target/product/Jelly2_JP/recovery/root/vendor
bin etc
$ cp -r vendor/Unihertz/Jelly2_JP/proprietary/reovery/root/vendor out/target/product/Jelly2_JP/recovery/root
$ mka recoveryimage

file upload again.
Sorry, I can't upload Attach files.
I clicked "Attach files" button and choose file.
I clicked "Save" button, but file link did not inserted.
I uploaded recovery.log to github.

How to get vbmeta.img

Three knife said:
How to get vbmeta.img
Click to expand...
Click to collapse
Direct Link
Google Drive: Sign-in
Access Google Drive with a Google account (for personal use) or Google Workspace account (for business use).
drive.google.com
See Also
Jelly 2 firmware made available by Unihertz
A post to let people interested in small Android phones know that the firmware of the Jelly 2 has been made available by Unihertz. Would be great if a LineageOS version of this could be made...
forum.xda-developers.com
Or
[HOWTO] Flash a blank vbmeta
Hey guys, As some of you know samsung made had a bunch of different changes since the release of Android 10. It took me a week to figure it out but it was really simple. I had to do two things: Repatch the the magisk boot image with Preserve AVB...
forum.xda-developers.com

I found the crash point in Jelly2_JP.
The crash point is CHECK() on line 772 of twrp/hardware/interfaces/keymaster/4.0/support/Keymaster.cpp.
C++:
CHECK(error == ErrorCode::OK)
<< "Failed to get HMAC parameters from " << *keymaster << " error " << error;
CHECK() is defined on line 495 of twrp/system/core/base/include/android-base/logging.h
C++:
#define CHECK(x) \
LIKELY((x)) || ABORT_AFTER_LOG_FATAL_EXPR(false) || \
::android::base::LogMessage(__FILE__, __LINE__, ::android::base::DEFAULT, \
::android::base::FATAL, _LOG_TAG_INTERNAL, -1) \
.stream() \
<< "Check failed: " #x << " "
I thought /system/bin/recovery was crashing due to a bug.
But it is not a bug.
/system/bin/recovery is programmed to abort if CHECK() fails.
Next, I compared the results of CHECK().
1. using your recovery.img for Jelly2_TEE.
Code:
$ adb shell
Jelly2_TEE:/ # uname -a
Linux localhost 4.14.141+ #15 SMP PREEMPT Wed May 19 11:04:10 CST 2021 aarch64
Jelly2_TEE:/ # mount -o ro /dev/block/mapper/vendor /vendor
Jelly2_TEE:/ # md5sum /vendor/lib64/libkeymaster4.so
17f162aedb3a9584e51d7f732ebbac7f /vendor/lib64/libkeymaster4.so
Jelly2_TEE:/ # umount /vendor
Jelly2_TEE:/ # md5sum /vendor/lib64/libkeymaster4.so
22ede18944c5f47daf04d699a72717b2 /vendor/lib64/libkeymaster4.so
Jelly2_TEE:/ # logcat -v brief -d -s /system/bin/recovery
E//system/bin/recovery( 324): Failed to get IAshmemDeviceService.
W//system/bin/recovery( 324): [libfs_mgr]Warning: unknown flag: resize
W//system/bin/recovery( 324): [libfs_mgr]Warning: unknown flag: resize
I//system/bin/recovery( 324): [libfs_mgr]Created logical partition product on device /dev/block/dm-0
I//system/bin/recovery( 324): [libfs_mgr]Created logical partition system on device /dev/block/dm-1
I//system/bin/recovery( 324): [libfs_mgr]Created logical partition vendor on device /dev/block/dm-2
W//system/bin/recovery( 324): DM_DEV_STATUS failed for system_image: No such device or address
W//system/bin/recovery( 324): DM_DEV_STATUS failed for vendor_image: No such device or address
W//system/bin/recovery( 324): DM_DEV_STATUS failed for product_image: No such device or address
I//system/bin/recovery( 324): fscrypt_initialize_systemwide_keys
I//system/bin/recovery( 324): List of Keymaster HALs found:
I//system/bin/recovery( 324): Keymaster HAL #1: HardwareKeymasterDevice from TrustKernel SecurityLevel: TRUSTED_ENVIRONMENT HAL: [email protected]::IKeymasterDevice/default
F//system/bin/recovery( 324): Keymaster.cpp:150] Check failed: error == ErrorCode::OK Failed to get HMAC parameters from HardwareKeymasterDevice from TrustKernel SecurityLevel: TRUSTED_ENVIRONMENT HAL: [email protected]::IKeymasterDevice/default error SECURE_HW_COMMUNICATION_FAILED
2. using my recovery.img for Jelly2_JP.
This is built with Jelly2_JP's kernel and /vendor/*.
Code:
$ adb shell
Jelly2_JP:/ # uname -a
Linux localhost 4.14.141+ #5 SMP PREEMPT Wed May 19 12:15:37 CST 2021 aarch64
Jelly2_JP:/ # mount -o ro /dev/block/mapper/vendor /vendor
Jelly2_JP:/ # md5sum /vendor/lib64/libkeymaster4.so
17f162aedb3a9584e51d7f732ebbac7f /vendor/lib64/libkeymaster4.so
Jelly2_JP:/ # umount /vendor
Jelly2_JP:/ # md5sum /vendor/lib64/libkeymaster4.so
17f162aedb3a9584e51d7f732ebbac7f /vendor/lib64/libkeymaster4.so
Jelly2_JP:/ # logcat -v brief -d -s /system/bin/recovery
E//system/bin/recovery( 327): Failed to get IAshmemDeviceService.
W//system/bin/recovery( 327): [libfs_mgr]Warning: unknown flag: resize
W//system/bin/recovery( 327): [libfs_mgr]Warning: unknown flag: resize
I//system/bin/recovery( 327): [libfs_mgr]Created logical partition product on device /dev/block/dm-0
I//system/bin/recovery( 327): [libfs_mgr]Created logical partition system on device /dev/block/dm-1
I//system/bin/recovery( 327): [libfs_mgr]Created logical partition vendor on device /dev/block/dm-2
W//system/bin/recovery( 327): DM_DEV_STATUS failed for system_image: No such device or address
W//system/bin/recovery( 327): DM_DEV_STATUS failed for vendor_image: No such device or address
W//system/bin/recovery( 327): DM_DEV_STATUS failed for product_image: No such device or address
I//system/bin/recovery( 327): fscrypt_initialize_systemwide_keys
I//system/bin/recovery( 327): List of Keymaster HALs found:
I//system/bin/recovery( 327): Keymaster HAL #1: HardwareKeymasterDevice from TrustKernel SecurityLevel: TRUSTED_ENVIRONMENT HAL: [email protected]::IKeymasterDevice/default
F//system/bin/recovery( 327): Keymaster.cpp:150] Check failed: error == ErrorCode::OK Failed to get HMAC parameters from HardwareKeymasterDevice from TrustKernel SecurityLevel: TRUSTED_ENVIRONMENT HAL: [email protected]::IKeymasterDevice/default error SECURE_HW_COMMUNICATION_FAILED
They are same Error code SECURE_HW_COMMUNICATION_FAILED.
Unfortunately, my recovery.img wasn't improved from your recovery.img when used with Jelly2_JP.

I'm sorry for the continuous posting.
I solved the decryption by modifying omni_Jelly2_JP.mk as follows.
Code:
PRODUCT_NAME := omni_Jelly2_JP
PRODUCT_DEVICE := Jelly2_JP
PRODUCT_MODEL := Jelly2_JP
PRODUCT_BOARD := g55v71c2k_dfl_jp_felica
BUILD_FINGERPRINT := "Unihertz/Jelly2_JP/Jelly2_JP:10/QP1A.190711.020/root.20210422.092852:user/release-keys"
PRODUCT_BUILD_PROP_OVERRIDES += \
TARGET_DEVICE=Jelly2_JP \
PRODUCT_NAME=Jelly2_JP \
PRIVATE_BUILD_DESC="Jelly2-user 10 QP1A.190711.020 root.20210422.092852 release-keys"
My mistake was that I only replaced "Jelly2_TEE" with "Jelly2_JP".
I had to replace "Jelly2" with "Jelly2_JP".
Anyway, now I can display the decryption screen.
Next, I tried HOW-TO-PATCH.md.
However, the touch screen does not respond on the patched kernel.
Code:
$ head -n 1 symbl_tee.txt
ffffff81dd680800 T do_undefinstr
$ grep get_boot_mode symbl_tee.txt
ffffff81ddda5b30 T get_boot_mode
$ zcat twrp/device/Unihertz/Jelly2_TEE/prebuilt/Image.gz > Image
$ aarch64-linux-android-objdump -D -b binary -m aarch64 --adjust-vma=0xffffff81dd680000 --start-address=0xffffff81ddda5b30 Image| head
ffffff81ddda5b30: d0009cc8 adrp x8, 0xffffff81df13f000
ffffff81ddda5b34: b947ad09 ldr w9, [x8,#1964]
ffffff81ddda5b38: 7100093f cmp w9, #0x2
I think you are using a different technique to enable the touch screen, because "cmp w9, #0x2" is not patched to "cmp w9, #0x0".
Please teach me your technique after you are not busy with work.

谢谢你,我用的是中国的没有Google Play的版本,按照你的步骤成功了,不过在安装完recovery.img之后,内部存储有可能无法写入,需要在recovery里删除data分区,然后就可以了

Thanks for this!
I flashed this TWRP, then installed AOSP 11, v313 of this GSI: https://github.com/phhusson/treble_experimentations/releases/tag/v313
Things seem good, except:
the battery seems to drain a little quickly
no IR blaster (ZaZa remote does not recognize it)
TWRP cannot decrypt the phone's contents, so I cannot flash gapps.
Is TWRP not able to decrypt because I'm using Android 11 and the TWRP was built for 10?

@karoooo
Sorry for not responding to you, for some reason email notifications from XDA were stopped. Please tell me if you still need patched kernel, I will try to patch it explain you the technique.

zxczxc4 said:
Thanks for this!
I flashed this TWRP, then installed AOSP 11, v313 of this GSI: https://github.com/phhusson/treble_experimentations/releases/tag/v313
Things seem good, except:
the battery seems to drain a little quickly
no IR blaster (ZaZa remote does not recognize it)
TWRP cannot decrypt the phone's contents, so I cannot flash gapps.
Is TWRP not able to decrypt because I'm using Android 11 and the TWRP was built for 10?
Click to expand...
Click to collapse
Actually, data decryption on MTK SoCs is very painful thing. I'm still waiting for stable release of Android 11 from Unihertz, but they are in no hurry...
I know that beta 11 available. Unfortunately, I was not able to update using the official way. The bootloader was locked and the moment of updating, but probably the reason is that it was unlocked before (it possible to relock bootloader using SP Flash Tool). But I manager to fetch zip update package and install it via TWRP After that I even managed to make package for SP Flash Tool based on this package, so I can to flash pure FW without updating and have locked bootloader!
UPD. I see that Unihertz have published Android 11 SW package for SP Flash Tool on their Google Drive! Soon I will try to make recovery based on this package.

@Meetoul
Thank you for your response.
Yes, yes, yes!
I want to know your technique.
Best Regards.

HI.
Summary: FRONT CAMERA not working after Bootloader Unlock
I am using Jelly2_JP (on latest Android 10) and I was wondering,
has anyone has experinced the Front Camera not working after Bootloader Unlock, and possibly the three " --disable-verification --disable-verity" commands?
The stock camera app won't recognize the front camera (not front/back switch button where there should be one), and other apps cant use the front camera either.
I can confirm that the front camera worked before unlocking the bootloader.
Reflashing stock image using SP Flash Tool and relocking Bootlader did not fix the issue.
Is anyone else experiencing the same issue?

karoooo said:
@Meetoul
Thank you for your response.
Yes, yes, yes!
I want to know your technique.
Best Regards.
Click to expand...
Click to collapse
Since Unihertz has released Android 11, I think that there is no sense to work on patching the old kernel.
Btw, now I'm working on TWRP based on Android 11 binaries from the latest FW, but no luck so far, it seems that kernel doesn't even start to boot...

@Meetoul
I wanted to learn your technique so that I could work on my own when Android 11 was released.
If Android 11 is formidable, prioritize working with Android 11.
Unfortunately, Android 11 for Jelly2_JP has not been released yet.
@kendzhi
I unlocked the bootloader with Jelly2_JP, but the front camera is still working.

@karoooo
Thank you for the reply!
May I ask, was your Jelly2_JP shipped before the latest Andorid 10 update (2021051912_g55v71c2k_dfl_jp_felica), meaning did your phone come with the previous Firmware (2020101915_g55v71c2k_dfl_jp_felica)?
I have two Jelly2_JP from Japan which came preshipped with the latest andorid Andorid 10 update (there was no need for OTA update). And in both phones, upon executing "fastboot flashing unlock" (without disableling AVB & without Rooting), the the front camera stopped working (not recognized by the system).
I even went into the Debug/Diagnostic? mode that was in Chinese (Booting by Vol down + Connecting to PC via USB), and peformed a hardware test for the Front Camera and the test froze the phone.
So I'm suspecting that Jelly2_JP that was shipped to Japan with the latest Firmware has some issues with Bootloader Unlocking breaking the Front Cam...

Qualcomm abl (Android bootloader) packing/signing

The Qualcomm XBL (SBL1) and Firehose loader images are packed somewhat reasonably.
They are ELF images (32 or 64 bit) with no sections but 3 or more programs:
Code:
E:\>elfview xbl /p
# Type Flags Size Offset Address
-- ------- ----- ------- ------ --------
0 null 960 000000 00000000 // this is the standard ELF header
1 null 6952 001000 9fdb6000 // this is the signing
2 load RX 350012 003000 14015000 // these are various things that actually get loaded
3 load RWZ 0 058740 14077000
4 load RW 31844 058740 1407a000
5 load RWZ 0 0603B0 14084800
6 load RWZ 0 0603B0 85e00000
7 load RX 11824 0603B0 146ae000
8 load RW 2916 0631E0 146b1000
9 load RWX 107032 063D50 14098000
10 load RWZ 0 07DF70 146b2000
11 load RWX 1792000 07DF70 9fc00000
12 load RX 78208 233770 14699000
13 load RX 171536 2468F0 85e35000
14 load RW 6409 270700 85ea8000
15 load RWZ 0 272010 85e97000
That is to say:
Code:
32 bit ELF file
Program table
Signing
Header
Hashes // one for each program, the 2nd is zeroes as you can't hash the hash!*
Signature
Certificate chain
Payload // multiple programs
So the XBL loads the next one, usually abl which is the Android bootloader which also implements the fastboot protocol.
Now we get a bit deep in the gumbo:
Code:
E:\>elfview abl /p
# Type Flags Size Offset Address
-- ------- ----- ------- ------ --------
0 null 148 000000 00000000 // this is the standard ELF header
1 null 6536 001000 9fa22000 // this is the signing
2 load RWX 139264 003000 9fa00000
Code:
32 bit ELF file
Program table
Signing
Header
Hashes
Signature
Certificate chain
LZMA archive
MZ Windows executable
PE Portable executable
64 bit ARM code
This is all (U)EFI compatibility so it has sworn fealty to Intel/Microsoft.
So, accepting all the idiocy of this, my question remains:
7-Zip can extract the structure of what is the #2 (i.e. the third) program:
Code:
C:\>7zip ablefi
Type = UEFIf
ERRORS:
Headers Error
Physical Size = 139264
Method = LZMA
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
D.... 9E21FD93
D.... 9E21FD93\EE4E5898
..... 0 9E21FD93\EE4E5898\0.raw
D.... 9E21FD93\EE4E5898\VOLUME
..... 20 9E21FD93\EE4E5898\VOLUME\FFFFFFFF
..... 376832 9E21FD93\EE4E5898\VOLUME\LinuxLoader.efi
------------------- ----- ------------ ------------ ------------------------
376852 139264 3 files, 3 folders
Errors: 1
The "program" itself starts with 16 bytes 0x00.
If I remove these 16 bytes then 7-Zip can't decypher the file.
The ultimate question is that while I can trivially reverse engineer the actual abl and modify it so that "orange state" doesn't wait 30 seconds when rebooting, how can I LZMA-ish pack the modified results so that it's acceptable?
LZMA normally has a 13 byte header. Why does this all start with nulls?
*Please note that although you can't hash the hash, you can Can the Can

@Appreciative
Sorry, I don't have anything technical documents on this at all except for Qualcomm stuff at the level of a PowerPoint.
All that stuff from booting onward is non-disclosure aggreement restricted.
I think that SecureBoot is in a OTP (one time programmable) fuse, but I don't know.
I can monitor the hardware console while booting the Firehose loader:
Code:
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.4-00246-S660LZB-1
S - IMAGE_VARIANT_STRING=Sdm660LA
S - OEM_IMAGE_VERSION_STRING=cibuild
S - Boot Interface: Unknown
S - Secure Boot: Off
S - Boot Config @ 0x00786070 = 0x000001c1
S - JTAG ID @ 0x00786130 = 0x000cc0e1
S - OEM ID @ 0x00786138 = 0x00000000
S - Serial Number @ 0x12345678 = 0x12345678
S - OEM Config Row 0 @ 0x00784188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x00784190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x007841a0 = 0x007030000b580100
S - Feature Config Row 1 @ 0x007841a8 = 0x00000000000000c0
S - Core 0 Frequency, 3715 MHz
S - PBL Patch Ver: 5
S - I-cache: On
S - D-cache: On
B - 0 - PBL, Start
B - 7024 - bootable_media_detect_entry, Start
B - 141363 - bootable_media_detect_success, Start
B - 141369 - elf_loader_entry, Start
B - 19372540 - auth_hash_seg_entry, Start
B - 19372841 - auth_hash_seg_exit, Start
B - 19481121 - elf_segs_hash_verify_entry, Start
B - 19534026 - elf_segs_hash_verify_exit, Start
B - 19534831 - auth_xbl_sec_hash_seg_entry, Start
B - 19563960 - auth_xbl_sec_hash_seg_exit, Start
B - 19563963 - xbl_sec_segs_hash_verify_entry, Start
B - 19570674 - xbl_sec_segs_hash_verify_exit, Start
B - 19570719 - PBL, End
B - 0 - SBL1, Start
I've also pieced together some addresses from logs and dumping the DTB:
Code:
00780000 msm-core
00780350 secure_boot
00784138 serial_number
00784188 oem_config0
00784190 oem_config1
007841a0 feature_config0
007841a8 feature_config1
00786040 jtagfuse
00786070 boot_config
00786130 jtag_id
00786138 oem_id

Nice work. This saved me days of hard work.
Renate said:
The ultimate question is that while I can trivially reverse engineer the actual abl and modify it so that "orange state" doesn't wait 30 seconds when rebooting, how can I LZMA-ish pack the modified results so that it's acceptable?
LZMA normally has a 13 byte header. Why does this all start with nulls?
Click to expand...
Click to collapse
Did you ever find a solution to this re-pack problem? I'd like to do something similar for the bootloader on my tablet.

Yahoo Mike said:
Did you ever find a solution to this re-pack problem? I'd like to do something similar for the bootloader on my tablet.
Click to expand...
Click to collapse
Nope, I havn't gotten back to this yet.
I guess it's just a question of biting the bullet and diving into this swamp of stupid packing.

Renate said:
...
The ultimate question is that while I can trivially reverse engineer the actual abl and modify it so that "orange state" doesn't wait 30 seconds when rebooting, how can I LZMA-ish pack the modified results so that it's acceptable?
LZMA normally has a 13 byte header. Why does this all start with nulls?
Click to expand...
Click to collapse
After a bit of research, I can answer that question.
It starts with nulls because it's not an LZMA header. It's a UEFI Firmware Volume (FV) header, in which the first 16 bytes are always zero.
I looked at a few UEFI FV editing tools, but none of them do quite what we want. So I've started on my own. I'll keep you posted on progress.
Here's a summary of my research:
Code:
The layout of a UEFI Firmware Volume
====================================
see: UEFI Platform Initialization Specification, Vol. 3 (https://uefi.org/specifications)
see also: https://sudonull.com/post/125061-UEFI-BIOS-file-device-part-two-UEFI-Firmware-Volume-and-its-contents
+----------------+----------------+
| | FV Header |
| |================|--------------------+-------------------+
| | | | FF Header |
| | | |===================|---------------+
| | | | | FS Header |
| | | | FF Section (FS) |===============|
| | | | #1 | data |
| | | Firmware File (FF) | | |
| | | #1 |-------------------|---------------+
| | | | . . . | . . .
| | | |-------------------|
| | | | FF Section (FS) |
| UEFI | Firmware | | #N |
| Firmware | File |--------------------|-------------------+
| Volume (FV) | System (FFS) | | . . .
| | | . . . |
| | | |
| | |--------------------|
| | | |
| | | Firmware File (FF) |
| | | #N |
| | | |
+----------------+----------------+--------------------+
To implement this, an object model might look like this:
* a FirmwareVolume object has 1 FirmwareFileSystem
* a FirmwareFileSystem has 0..n FirmwareFile objects
* a FirmwareFile object has 0..n FirmwareFileSection objects
Just to make life interesting, one type of FF Section is the EFI_SECTION_FIRMWARE_VOLUME_IMAGE.
It has a UEFI Firmware Volume as its data. So there can be FVs nested in other FVs ad infinitum.
FF Sections can also be encrypted, compressed or encoded by an OEM.
Once decrypted/decompressed/decoded, these sections contain further FF sections.
And in accordance with Murphy's Law, the file we want (LinuxLoader.efi) is in one of those nested firmware volumes. ...And you guessed it - the nested FV is compressed using LZMA. Presumably that's deliberate - so you can't directly edit the bootloader in the abl.elf.
So I plan for my tool to do two things:
extract the LinuxLoader.efi file from the abl.elf file
repack a modified LinuxLoader.efi back into the ELF file.
I don't know if a repack will work. There are some checksums in the EFi headers. And the whole ABL.ELF might be signed by a private RSA key and the SoC will refuse to load it without the correct signature. We'll see..

Yahoo Mike said:
After a bit of research, I can answer that question.
It starts with nulls because it's not an LZMA header. It's a UEFI Firmware Volume (FV) header, in which the first 16 bytes are always zero.
Click to expand...
Click to collapse
Well, that's very clever of them. Most standards use "magic" values in the header.
These guys have taken a bold stand: "When you see 16 0x00 it's an unambiguous sign that you've found our UEFI FV!"
<rant>
I've dealt with kernels that were uncompressed, compressed with gzip or compressed and a decompressor stub.
So, imagine my surprise when I ungzipped a kernel from a boot image recently and found that it starts with "MZ".
"OMG, did Bill Gates buy Android? Is this the MS-DOS compatibilty layer?"
No, it's just the MS-DOS header stuck on a Windows PE header stuck on a kernel.
Code:
00000000 t _head
00000000 T _text
00000040 t pe_header
00000044 t coff_header
00000058 t optional_header
00000070 t extra_header_fields
000000f8 t section_table
00001000 T do_undefinstr
00001000 t efi_header_end
00001000 T _stext
</rant>

Renate said:
Well, that's very clever of them. Most standards use "magic" values in the header.
These guys have taken a bold stand: "When you see 16 0x00 it's an unambiguous sign that you've found our UEFI FV!"
<rant>
I've dealt with kernels that were uncompressed, compressed with gzip or compressed and a decompressor stub.
So, imagine my surprise when I ungzipped a kernel from a boot image recently and found that it starts with "MZ".
"OMG, did Bill Gates buy Android? Is this the MS-DOS compatibilty layer?"
No, it's just the MS-DOS header stuck on a Windows PE header stuck on a kernel.
Code:
00000000 t _head
00000000 T _text
00000040 t pe_header
00000044 t coff_header
00000058 t optional_header
00000070 t extra_header_fields
000000f8 t section_table
00001000 T do_undefinstr
00001000 t efi_header_end
00001000 T _stext
</rant>
Click to expand...
Click to collapse
Yes, very clever. But there is method in their madness. According to the spec: "The first 16 bytes are reserved to allow for the reset vector of processors whose reset vector is at address 0."
There is a bit of magic at byte 0x28 in the FV header. It's always "_FVH". That's how you identify a UEFI FV. But I guess the first 16 nulls are always a big hint.
...and it's great to see that the ghost of MS-DOS lives on. It reminds me of what we used to say in my early programming days: "DOS is boss".

I've been looking into this hashing business.
I know that I'm basically on the right track.
I can take a Firehose loader (basically a custom xbl) make a trivial spelling change somewhere and it will refuse to load.
I can recalculate the SHA256, replace it and it will load correctly.
I have a WIP that checks the hashes on xbl/abl/firehose loaders (all basically the same).
I see tons of files that check out 100%.
Code:
C:\>qcomview /h poke3.bin
64 bit ELF, SHA256
0 00000000 00000318 a117dbc5 e643e404 361bfe30 45fbda01 4c153842 59a4cbe8 09b7da55 a2dd413e OK
1 00001000 00001ac8
2 00003000 0005709c 7b833734 f2763b9e 35f3310c f6fb22a9 a514eac0 3eddbe46 b5ff339b 3c7b045c OK
3 0005a0a0 00000000
4 0005a0a0 00009f00 6296c006 31852f79 b99691c3 e8d598f2 9d323e9a ba0358aa b742901f 506709d5 OK
5 00063fa0 00009908 41176495 3e07ad84 8923398e ce854131 91066dca 43f253fa c027c4f4 a3c21483 OK
6 0006d8b0 00000000
7 0006d8b0 00001e7c fe77c473 b02e4a71 d3f287e4 cf85ccbe b5a43326 53930bd8 d68e4e40 6e71a0b8 OK
8 0006f730 00000000
9 0006f730 000188d8 1bfef74c ed467a22 8616419d e71ab1ea 22a717e5 4874c704 541793ed f5d5c5e5 OK
10 00088010 00000000
11 00088010 00000000
12 00088010 00012dc0 b72cb77e 81026632 446c3462 cc6c83fc d7904333 cb8807cc 27d6e4c9 189c7ca4 OK
I see a bunch of files that don't check out at all.
I can SHA256 a program chunk and the SHA256 appears nowhere in the entire file.
Are they salting the SHA256 or using a different hash?
Edit: Oh, it looks like SHA512. Er, maybe SHA3 512?
Edit: Ok, big deal, so I can't count. It's SHA(2)-384. WIP can be found http://www.temblast.com/qcomview.htm
The SHA256 displays the calculated and verifies.
The SHA384 displays the file content and does not verify (yet). calculated and verifies.
There is also an option to dump an ASN1 listing of the certificate chain.

Renate said:
WIP can be found http://www.temblast.com/qcomview.htm
Click to expand...
Click to collapse
qcomview works great. Thanks.
With @Renate 's invaluable guidance, I put together a tool to extract the LinuxLoader from the abl.elf file, and to repack a modified LinuxLoader back into the abl.elf file. But it comes with a warning: don't try to run a modified abl.elf on a device with SecureBoot on - if you do, you will probably brick your device. Of course, if SecureBoot is off, this tool should work for you.
If you want to try it, the tool source is available at: github.com/Yahoo-Mike/lltool. It's still in beta. It was only tested on a limited number of ELF files and it might need some fine-tuning for different OEMs. So feel free to report issues or send pull requests. If it doesn't work on your ELF file, send me a link to the file and I'll see what I can do.

Yahoo Mike said:
If you want to try it, the tool source is available at...
Click to expand...
Click to collapse
Nice work! (And a bunch of it.)
I just got around to modding my abl. I just did it manually.
You just split your abl at 0x3078. The high piece is just the LZMA. You expand/mod/compress and stick it back.
Then you have to pad it nicely, change the size in the program table, fix the signing on program #0 and #2.
And just like that you're done!
It made a world of difference. I got rid of the 30 second delay for being Orange. It seems I waste half a day with that 30 seconds.
Have you got a SecureBoot=off device?
I'm sure many people are getting sick of all the restrictions.

Renate said:
You just split your abl at 0x3078. The high piece is just the LZMA. You expand/mod/compress and stick it back.
Then you have to pad it nicely, change the size in the program table, fix the signing on program #0 and #2.
And just like that you're done!
Click to expand...
Click to collapse
Spot on!
Renate said:
Have you got a SecureBoot=off device?
Click to expand...
Click to collapse
No, unfortunately. That's why I'm still hunting around for other options. I'm currently thinking about self-signing the modded abl.elf. Maybe I'll get lucky and the OEM allows that on my device...
BTW, I don't suppose you know the answer to this question: How to find "hw_soc_version" for a QCom SOC?

Usually the SHA256 of the root CA corresponds to the "Hash" burned into the chip.
I see that's true for about 80% of the loaders in the repository.
There may be a newish wrinkle where there is an encryption step or something.
But if you're SecureBoot, everything has to match all the way down.

Some trivia from our favorite loader repository:
Code:
Older style, not an ELF [ 89]
32 bit ELF, Version 3, SHA256 [460]
32 bit ELF, Version 3, SHA384 [ 8]
64 bit ELF, Version 3, SHA256 [ 31]
64 bit ELF, Version 5, SHA256 [ 65]
32 bit ELF, Version 6, SHA384 [ 4]
64 bit ELF, Version 6, SHA384 [ 54]
Of course a bunch of these are duplicated and put in different directories.

Renate said:
I just got around to modding my abl. I just did it manually.
You just split your abl at 0x3078. The high piece is just the LZMA. You expand/mod/compress and stick it back.
Then you have to pad it nicely, change the size in the program table, fix the signing on program #0 and #2.
And just like that you're done!
Click to expand...
Click to collapse
I've got it down to 100% automatic now. It uses a makefile and a few of my "glue" utilities.
Code:
hexcalc size(ablmod)-3000 > hexcalc.tmp

My Xperia XZ2 got turned off secure boot after unlocking bootloader, is this actually off? I don't trust secure:no in fastboot getvar secure

I'm wondering if my phone will brick if flashing abl mod

cuynu said:
I'm wondering if my phone will brick if flashing abl mod
Click to expand...
Click to collapse
It's hard to tell. I don't trust fastboot getvar secure
Still, my not-SecureBoot device says no and my SecureBoot device says yes.
Do you have a Firehose loader for your device? Have you tried EDL on it?
The easiest, safest, bullet-proof way to determine if you're secure is to take a Firehose loader, modify it trivially (spelling on message), rehash it and see if it works.
If it's a standard Firehose loader, just tell me the MD5 and I'll patch it for you.

Renate said:
It's hard to tell. I don't trust fastboot getvar secure
Still, my not-SecureBoot device says no and my SecureBoot device says yes.
Do you have a Firehose loader for your device? Have you tried EDL on it?
The easiest, safest, bullet-proof way to determine if you're secure is to take a Firehose loader, modify it trivially (spelling on message), rehash it and see if it works.
If it's a standard Firehose loader, just tell me the MD5 and I'll patch it for you.
Click to expand...
Click to collapse
Unfortunately, there is no firehose loader for Xperia XZ2 nor sony phones

Renate said:
It's hard to tell. I don't trust fastboot getvar secure
Still, my not-SecureBoot device says no and my SecureBoot device says yes.
Do you have a Firehose loader for your device? Have you tried EDL on it?
The easiest, safest, bullet-proof way to determine if you're secure is to take a Firehose loader, modify it trivially (spelling on message), rehash it and see if it works.
If it's a standard Firehose loader, just tell me the MD5 and I'll patch it for you.
Click to expand...
Click to collapse
I can get to EDL by short testpoint in the mainboard, but the PID not 9008, it is PID:ADE5

cuynu said:
I can get to EDL by short testpoint in the mainboard, but the PID not 9008, it is PID:ADE5
Click to expand...
Click to collapse
Mmm, that seems strange.
Because the VID/PID comes out of the ROM PBL and I've never seen any override on 05c6/9008.
OTOH fastboot often has wacky VID/PIDs.
Look at the manufacturer/product strings and see if it's Qualcomm CDMA Technologies MSM and QUSB__BULK.
https://www.ftdichip.com/Support/Utilities.htm#MicrosoftUSBView

[SOLVED] GSI on BV 4900 Pro: "Cannot load Android system. Your data may be corrupt. "

tl;dr: I followed the procedure to flash Android's Generic System Image (gsi_gms_arm64-exp-TP1A.220624.014-8819323-8a77fef1) on my Blackview BV 4900 Pro, but I am stuck in a bootloop that ends with "Cannot load Android system. Your data may be corrupt."
In details:
Prep​I made sure that my phone could support GSI​
$adb shell getprop ro.treble.enabled
true
$adb shell cat /system/etc/ld.config.29.txt | grep -A 20 "\[vendor\]"
…
namespace.default.isolated = true
…
$adb shell getprop ro.product.cpu.abi
arm64-v8a
Additional Checks​
Bootloader is unlocked.
Device was launched with Android 9 or higher (it was launched with Android 10)
Android 13 GSIs was downloaded (build Build: TP1A.220624.014) was downloaded from https://developer.android.com/topic/generic-system-image/releases and checksum for ARM64+GMS was confirmed to be 8a77fef1842da4a4cff68e36802f779d65e52ae0cfce024a33901d5dc48d47d0.
The phone has Android Verified Boot (AVB):
$adb shell getprop ro.boot.veritymode
enforcing
Flashing​
I followed the official tutorial for flashing GSIs but changed a couple of things (I may have the order wrong, but I essentially did, once I was in fastboot mode
fastboot flashing unlock # To unlock bootloader
fastboot flash --disable-verity --disable-verification vbmeta vbmeta.img # Disable secure boot
fastboot reboot fastboot # Restart in fastbootd
fastboot delete-logical-partition product # I didn't have enough space for Resizing 'system' (I had FAILED (remote: 'Not enough space to resize partition'))
fastboot erase system
fastboot format:ext4 system # because when I tried to flash system.img the first time, I had "Invalid sparse file format at header magic"
fastboot flash system system.img
fastboot format:ext4 userdata
fastboot erase userdata
fastboot format:ext4 metadata
fastboot erase metadata
fastboot erase cache
But when I restart, I am always prompted with
Android Recovery
Blackview /BV4900Pro_US/BV4900Pro10/…
user/release-keys
Use volume up/down and power
Can't load Android system. Your data
may be corrupt. If you continue to get
this message, you may need to perform a
factory data reset and erase all user
data stored on this device
-------------------------
Try again
Factory data reset
-------------------------
Supported API:3
I have tried to reset factory data and to reboot, but I always have the same message…
$ adb --version
Android Debug Bridge version 1.0.41
Version 33.0.3-8952118

I just realized / remembered that this phone uses super.img instead of system.img, maybe I need to repack the system.img into a super.img, following this procedure?

tl;dr: Yes, repacking the system.img into a super.img and then flashing it was key to success.
I have essentially followed what I have described here: https://forum.xda-developers.com/t/...n-blackview-bv-4900-pro.4453955/post-87029001
Except that the three images I used were the original vendor.img, the original product.img, and
aosp_arm64-exp-TP1A.220624.014-8819323-996da050/system.img (available at
Generic System Images (GSIs) | Platform | Android Developers
developer.android.com
)
I used the command
python3 lpmakesimple.py lpbinary/binary/lpmake ./super_20220510.img 4294967296 system=system.img,vendor=./vendor.img,product=./product.img
(4294967296 being picked semi-randomly: it's a multiple of the block size (65536), less than the size of the super partition but more than the size of the three images combined + some more).
That's it: I flashed that super_20220510.img using fastboot flash super super_20220510.img and it was all good!