[Walkthrough] Extract eRecovery and boot images using payload-dumper-go

[aibd]

A workaround

… for use where eRecovery and / or secondary images are not available.

Attribution

I believe this method was first seen on the forum OnePlus - 9 Pro - lemonadep - Documentation Suggestions - #8 by bofh666 and I believe was requoted in Week 41, 2023: Development and Testing Updates and Week 42, 2023: Development and Testing Updates.

The method is run in Linux. A different Release is available for Windows, please check the Windows README.

Downloads action

(The code boxes show both the command lines starting with a $
the following lines are the output on the terminal.)

$ mkdir test
$ cd test

Download to test folder from https://github.com/ssut/payload-dumper-go/releases … a choice

I have an Intel 64bit laptop and select linux_amd64 that is
payload-dumper-go_1.2.2_linux_amd64.tar.gz

Download to test folder from https://images.ecloud.global/ the full ROM for your device, for example:
e-1.15-t-20230919331436-dev-instantnoodlep.zip

Extract payload-dumper-go

$ tar xzvf payload-dumper-go_1.2.2_linux_amd64.tar.gz payload-dumper-go
payload-dumper-go

$ ls
e-1.15-t-20230919331436-dev-instantnoodlep.zip
payload-dumper-go
payload-dumper-go_1.2.2_linux_amd64.tar.gz

Check for the usage instructions

$ ./payload-dumper-go --help
Usage of ./payload-dumper-go:
  -c int		Number of multiple workers to extract (shorthand) (default 4)
  -l			Show list of partitions in payload.bin (shorthand)
  -o string		Set output directory (shorthand)
  -p string		Dump only selected partitions (comma-separated) (shorthand)

Select the arguments to use and start to build the command

-o string # Define an output folder to be created
-o OutputFolder
-p string # Define the partitions to be created, no spaces.
-p dtbo,vbmeta,recovery

./payload-dumper-go -o OutputFolder -p dtbo,vbmeta,recovery

Complete the command with your /e/ ROM filename.zip
e-1.15-t-20230919331436-dev-instantnoodlep.zip

Run payload-dumper-go

$ ./payload-dumper-go -o OutputFolder -p dtbo,vbmeta,recovery e-1.15-t-20230919331436-dev-instantnoodlep.zip
Please wait while extracting payload.bin from the archive.
payload.bin: /tmp/payload_185369925.bin
Payload Version: 2
Payload Manifest Length: 115665
Payload Manifest Signature Length: 267
Found partitions:
abl (225 kB), aop (205 kB), bluetooth (455 kB), boot (101 MB), cmnlib (401 kB), cmnlib64 (520 kB), devcfg (57 kB), dsp (67 MB), dtbo (25 MB), featenabler (90 kB), hyp (451 kB), imagefv (1.2 MB), keymaster (266 kB), logo (9.6 MB), modem (193 MB), multiimgoem (16 kB), odm (375 MB), product (450 MB), qupfw (57 kB), recovery (101 MB), storsec (25 kB), system (1.5 GB), system_ext (371 MB), tz (3.2 MB), uefisecapp (127 kB), vbmeta (8.2 kB), vbmeta_system (4.1 kB), vendor (901 MB), xbl (4.0 MB), xbl_config (94 kB)
Number of workers: 4
recovery (101 MB)  [=============================================================================================================================================] 100 %
vbmeta (8.2 kB)    [=============================================================================================================================================] 100 %
dtbo (25 MB)       [=============================================================================================================================================] 100 %


$ ls -R
e-1.15-t-20230919331436-dev-instantnoodlep.zip
OutputFolder
payload-dumper-go
payload-dumper-go_1.2.2_linux_amd64.tar.gz

./OutputFolder:
dtbo.img  recovery.img  vbmeta.img

Samsung S9 starlte

payload-dumper-go did not work on e-1.15-r-20230915330641-stable-starlte.zip

Terminal output

$ sha256sum e-1.15-r-20230915330641-stable-starlte.zip 
f103f21e0df498d71c9e592074ac84c5bba4993ba43e7b27fe4696bd6eb33023  e-1.15-r-20230915330641-stable-starlte.zip
$ cat e-1.15-r-20230915330641-stable-starlte.zip.sha256sum
f103f21e0df498d71c9e592074ac84c5bba4993ba43e7b27fe4696bd6eb33023  e-1.15-r-20230915330641-stable-starlte.zip

$ ./payload-dumper-go -l e-1.15-r-20230915330641-stable-starlte.zip
Please wait while extracting payload.bin from the archive.
2023/10/17 17:44:38 Failed to extract payload.bin from the archive```

A simple unzip command (or “Extract here” by GUI method)

$ unzip e-1.15-r-20230915330641-stable-starlte.zip

Within the extracted e-1.15-r-20230914330641-stable-starlte/ (among other files) is:

boot.img
firmware-update/
vendor.img
recovery.img

[Manoj]

Hi @aibd thanks for this post. While the v1.16 release is expected to include the partitions in the recovery, having an alternate process in place is always good as a backup. Have also marked it as a wiki that will make it editable in case there are changes in future in the build folder structure.

[mihi]

Thx aibd for the walkthrough. Can you maybe explain further what to do when vendor firmware needs to be updated? That was all along the intention of eOS developers with Android T.

I came across this ‘hotdog’ guide at lineage (https://wiki.lineageos.org/devices/hotdog/fw_update) and since my pixel 4a needs also a firmware upgrade. I want to try update my R v1.15 stable to T v1.15 dev (or eventually to T v1.16dev) by dirty flashing it (and I am lazy to go to stock). Before I do anything I would make backup’s if it won’t work so I can still go the stock route. Can you tell me which of these image files need to be flashed? Or where I can check? I wasn’t able to find any documentation for it. I have expected that Murena would provide it in the device section.

The payload.bin of e-1.15-t-20230918331436-dev-sunfish.zip has these files:

./payload-dumper-go payload.bin
payload.bin: payload.bin
Payload Version: 2
Payload Manifest Length: 91078
Payload Manifest Signature Length: 267
Found partitions:
abl (1.0 MB), aop (168 kB), boot (67 MB), devcfg (45 kB), dtbo (8.4 MB), hyp (397 kB), keymaster (254 kB), modem (74 MB), product (552 MB), qupfw (53 kB), system (1.5 GB), system_ext (440 MB), tz (2.1 MB), uefisecapp (127 kB), vbmeta (4.1 kB), vbmeta_system (4.1 kB), vendor (664 MB), xbl (3.4 MB), xbl_config (90 kB)
Number of workers: 4
abl (1.0 MB)            [======================================================================================] 100 %
aop (168 kB)            [======================================================================================] 100 %
boot (67 MB)            [======================================================================================] 100 %
devcfg (45 kB)          [======================================================================================] 100 %
dtbo (8.4 MB)           [======================================================================================] 100 %
hyp (397 kB)            [======================================================================================] 100 %
keymaster (254 kB)      [======================================================================================] 100 %
modem (74 MB)           [======================================================================================] 100 %
product (552 MB)        [======================================================================================] 100 %
qupfw (53 kB)           [======================================================================================] 100 %
system (1.5 GB)         [======================================================================================] 100 %
system_ext (440 MB)     [======================================================================================] 100 %
tz (2.1 MB)             [======================================================================================] 100 %
uefisecapp (127 kB)     [======================================================================================] 100 %
vbmeta (4.1 kB)         [======================================================================================] 100 %
vbmeta_system (4.1 kB)  [======================================================================================] 100 %
vendor (664 MB)         [======================================================================================] 100 %
xbl (3.4 MB)            [======================================================================================] 100 %
xbl_config (90 kB)      [======================================================================================] 100 %

[aibd]

Hi @mihi, this is somewhat speculative.

Always take a full backup first !

In your /e/ ROM “Found partitions” I find it interesting to see vendor (664 MB). I guess this is at least a pointer to the idea that using this ROM (as per instructions) will provide the needed vendor parts to avoid going back to Stock ROM. Does the /e/OS page https://doc.e.foundation/devices/sunfish/upgrade tell us to avoid an Upgrade from R → T ? I guess I assumed it would be good for S → T (only, idk !)

The OnePlus hotdog fw_update page probably does not give us much insight to recovery / preparation of a Google Pixel (there is no equivalent sunfish fw_update page). Partition structure is not the same over all manufacturers.

Further research at Google might help: https://developers.google.com/android/images#sunfish – if this page is unreadable, please go to up a level to https://developers.google.com/android/images and read the warnings and Acknowledge. A download and inspection by payload dumper of a ROM from that source might give more insight.

@mihi

Can you maybe explain further what to do when vendor firmware needs to be updated?

It is my understanding that the Android 13 (T) builds of LineageOS and /e/OS both contain the “vendor blobs” required to avoid the need to go back to a stock ROM. (At least in the case of a standard upgrade from S → T).

I have not studied a lot of /e/OS upgrade pages, but it was my impression that we are no longer advised to go back to stock ROM as “standard practice” for an Upgrade from S → T. (Some devices may deviate, idk.)

What do I mean by “vendor blobs” ? The proprietary bits that form part of the manufacturer’s software revisions which may accompany an upgrade of Android version.

Your research above suggests that a “whole new updated vendor partition” (664 MB) is provided with the ROM.

[mihi]

Thank for your deep reply.

I went to the google page and with ‘adb shell getprop’ I checked ro.build.fingerprint (google/sunfish/sunfish:12/SP2A.220305.012/8177914:user/release-keys) and compared them together, this image exists on the firmware site: 12.1.0 (SP2A.220305.012, Mar 2022)

Do I allready have vendor blobs for A 12(S)?

[aibd]

If you are running “R v1.15 stable” how would you account for the mismatch March 2023 Android 12 ?

Did you last update the device to Google Official in March 2022 (tbh, I don’t know enough about build fingerprint to answer definitively) ?

Having looked at your List of partitions on your /e/ ROM (and the link with the hotdog firmware) I was thinking along these lines:

What partitions exist on an Official Google Android 13 (T) ROM
… and to what extent do they look like a near match with the /e/OS ROM
… does vendor (664 MB) exist
… if yes, do the two vendor (664 MB) share the same sha256sum ?

Pixels are easy to recover … so since

@mihi

by dirty flashing it (and I am lazy to go to stock)

I think my ideas may be too much detail !

Maybe we need to be careful by the use of “dirty flashing” – upgrading from S → T without change of build type (not your case) would be a clean upgrade, I believe, Always take a full backup first !

Edit on a Samsung, this from about Phone > Android version this baseband version is a direct link to the preinstalled vendor firmware. Does your phone have an equivalent ?

[mihi]

Did not find time to check on it and v1.16 was delayed also. I figured sideloading something newer is better. I will let you about the journey as soon as I try. AND YES I WILL MAKE BACKUP

UPDATE (22.10.2023): After making Backup’s and copying it to the PC, I started reading into install/update instructions… Then I realized there is no ‘recovery.img’ from eOS. Which made me doubt the whole process.

I was hopeful with the promise from Murena not to need to go back to stock for major upgrade to T but documentation is not really updated (in my opinion). So I expect to be needing to go to stock (I am reserved about doing a dirty flashing), so I will keep to R and hope in the future it will be more clear how to proceed. I have no issues at the moment which need me to upgrade, ‘never touch a running system’

[mihi]

Little update, I just booted into eOS v1.16-t, without wipe or going back to stock and even switching from stable to dev.
I did some reading how Google flashes it to stock and some xda ost on others doing manual update on Pixels. After another Backup I figured what ever happens, happens.

My steps we’re these:

fastboot flash bootloader bootloader-sunfish-s5-0.5-8633307.img
fastboot reboot-bootloader
fastboot flash radio radio-sunfish-g7150-00091-220617-b-8737049.img
fastboot reboot-bootloader
fastboot flash boot recovery-e-1.16-t-20231019342574-dev-sunfish.img → Couldn’t boot into recovery, fastboot showed an error
fastboot flash dtbo dtbo.img → I figured it won’t hurt
Then I had to reboot bootloader
fastboot flash boot recovery-e-1.16-t-20231019342574-dev-sunfish.img
adb sideload copy-partitions-20220613-signed.zip → for possible future problems to negate
adb sideload e-1.16-t-20231019342574-dev-sunfish.zip → had to reboot recovery again install had an error and said reboot recovery, on the second try it worked

Checking the ‘Android Version’ I saw that ‘Baseband-Version’ is even newer, this is surely because in the payload.bin there is a radio.img. Vendor Patch is also 05.09.2023.
Bootloader has also a higher number than the one I flashed, when I check fastboot.
Now I wonder if bootloader and radio flash even was needed…anyway

Now my last question in this regard for future OTA’s is, if you think of an issue which might occur when updating to v1.17?