Odin Vbmeta

[Ane Neemann]

As I do not have personal experience of this device, I am not going to tell you what to do, just point you to the material that has the clues you need! The second link points to 12 user experiences, one or two of which might be relevant to you; the third link is vital reading - Document Suggestions contains any user feedback where the successful installer kindly left clues for those who follow.

Your Odin mode image does not go right to the margin ! So that you get all the clues and can tell for certain if something changes, it might be helpful to write down here exactly what you see in this format (correcting what I cannot see !):

Post script As well as asking whether the phone was new, with regards to the possibility of a simple Region lock, I should have asked if you got it through a regular retail channel or whether there is any possibility the phone was not sold in its intended market? This is often seen in devices imported to USA !

I tried to flash it multipile times but the packages just failed to pass the SW REV CHECK in odin mode. And I joined this forum because I tried to flash vbmeta.tar and it failed ALL the time either giving me a security error saying I flashed unauthorized firmware or a vbmeta/AndroidVerifiedBoot image or a screen with a issue reporting on the screen like ERROR: error verifying vbmeta image, invalid vbmeta header and this weird corrupted-looking text. The text would be:

I've flashed LineageOS in the past (see lg-g3-d852and htc-one-s) but the rather hostile IRC communityhas always been undesirable to me. Still, it's kind of the baselinethat everyone looks at for everything, and has a crushing number ofsupported devices, including this one.

Oddly, it also ships one proprietary maps app, MagicEarth. They make their own privacy-branded phones now. Alsoships with this weird App Lounge that blends together apps fromthe Google Store and F-Droid, although the latter is shipped throughthis weird CleanAPK thing (see also the /e/ FAQ aboutthis). See also What's in /e/OS? and defaultapplications.

The Q, R and S builds are /e/ code names for Android versions,according to ChatGPT. It seems like after Android 9 "Pie" Googlestopped using candy names publicly and instead refer only to numbersalthough internally they still use incrementing literal versions,according to Wikipedia. So /e/ seems to be taking a cue from thatand has this map of versions so that Q is Androind 10, R is 11and S is 12, which means that /e/ is one major version behind thelatest Android.

The microG LOS installation instructions are basically the sameas LOS's except they have their own fork of the update_verifier(which, interestingly, LOS doesn't actually mention in theirinstructions). I have quickly audited commit7529ac8fdd82c758ab9520b20ea42b956811dcdb of the microG fork and itseems somewhat like a legit implementation of a ZIP signature check.

While this device is (still in 2023!) supported by LOS, it stilldoesn't seem possible to flash it without Windows (reddit). Ihave tried with Heimdall and tried to follow the postmarketinstructions to use Heimdall with:

It seems this is a known problem with Heimdall and that thispatch fixes it! The patch was never merged though and it lookslike the Heimdall project is moribund. This fork includes a bunchof patches (including the above) and /e/ OS and LineageOS alsohave forks. Heimdall does detect the device:

Heimdall is not very well documented. Part of the problem I'm having(even before failing to communicate with the device above) is thatHeimdall expects .pit files or "Heimdall Firmware Package" files,which I don't know how to create. The Heimdall Linux README hasmore information which could possibly fix this, but then thecommunication issue keeps me from even downloading the original pitfile.

It does seem like this person produces images for the Samsung S5ethat are usable. And this reddit thread shows how to usethem. But neither of those because I can't communicate with thedevice with any Heimdall version.

I retried this a few times and at some point it reached 100% but withtons of errors. After this, the boot loader was kind of hosed andwould fail to boot the device with some checksum error onvbmeta.img... Oops. Possibly that I should really have loaded allthose units at once instead of just the one recovery. I have sincethen tried to load all files from the LOS .zip file without muchsuccess:

The TWRP install instructions require eitherrooting the box with Magisk (some obscure process I believe I failedto follow last time I attempted this) or Odin. At first, this seemedlike a dead end, but eventually, it worked, see success-output.txt.

Every time I retried this, I had to reboot by holding volumedown and power together then, after the screenflashes off, release the keys and immediately press and holdvolume down, volume up and powertogether until the download menu comes up. Then press volumeup twice to get to the actual download mode.

First I extracted the ZIP file and then all the tar.md5 files (whichare really just normal .tar files) and then the embedded .lz4files. There were 32 files. I tried to generate a single commandlineto flash them all:

Noticing TWRP was complaining about Android 11 right after doing acomparison of TZ, I figured i might be able to flash just thatpartition and fool TWRP in going ahead. So I foolishly uploaded somebinary I found on the internet, from theSamfw.com_SM-T720_XAC_T720XXS3DWA1_fac.zip file.

Now the device is all blank. It's unclear if it's powered down atall. Plugging in a USB-C cable into my laptop doesn't bring it to lifeat all either, and Linux complains about the port being messed up:

There are multiple ways from which you can easily flash custom ROMs, add rooting privileges, enhance performance, and increase battery life. For all of those perks, installing a TWRP recovery would be an initial step.

If you desire to install TWRP recovery on the Samsung Galaxy S24 Ultra, it would be great to download the following resource files. Usually, you need the TWRP file, vbmeta, and Disable DM verity Force Encrypt files for the upcoming process.

Note: You need to store the Disable DM Verity Force Encrypt file in your Samsung Galaxy S24 Ultra internal storage. You can transfer this file directly from your PC if you have already downloaded it from the above section.

We covered the important resources and necessary steps so that you can install TWRP on the Samsung Galaxy S24 Ultra with no worries. With our step-by-step guide, you can unlock the bootloader, access download mode, and flash the TWRP recovery file.

Verified boot is the process of assuring the end user of the integrity of the software running on a device. It typically starts with a read-only portion of the device firmware which loads code and executes it only after cryptographically verifying that the code is authentic and doesn't have any known security flaws. AVB is one implementation of verified boot.

The central data structure used in AVB is the VBMeta struct. This data structure contains a number of descriptors (and other metadata) and all of this data is cryptographically signed. Descriptors are used for image hashes, image hashtree metadata, and so-called chained partitions. A simple example is the following:

where the vbmeta partition holds the hash for the boot partition in a hash descriptor. For the system and vendor partitions a hashtree follows the filesystem data and the vbmeta partition holds the root hash, salt, and offset of the hashtree in hashtree descriptors. Because the VBMeta struct in the vbmeta partition is cryptographically signed, the boot loader can check the signature and verify it was made by the owner of key0 (by e.g. embedding the public part of key0) and thereby trust the hashes used for boot, system, and vendor.

A chained partition descriptor is used to delegate authority - it contains the name of the partition where authority is delegated as well as the public key that is trusted for signatures on this particular partition. As an example, consider the following setup:

In this setup the xyz partition has a hashtree for integrity-checking. Following the hashtree is a VBMeta struct which contains the hashtree descriptor with hashtree metadata (root hash, salt, offset, etc.) and this struct is signed with key1. Finally, at the end of the partition is a footer which has the offset of the VBMeta struct.

This setup allows the bootloader to use the chain partition descriptor to find the footer at the end of the partition (using the name in the chain partition descriptor) which in turns helps locate the VBMeta struct and verify that it was signed by key1 (using key1_pub stored in the chain partition descriptor). Crucially, because there's a footer with the offset, the xyz partition can be updated without the vbmeta partition needing any changes.

The VBMeta struct is flexible enough to allow hash descriptors and hashtree descriptors for any partition to live in the vbmeta partition, the partition that they are used to integrity check (via a chain partition descriptor), or any other partition (via a chain partition descriptor). This allows for a wide range of organizational and trust relationships.

Chained partitions need not use a footer - it is permissible to have a chained partition point to a partition where the VBMeta struct is at the beginning (e.g. just like the vbmeta partition). This is useful for use-cases where all hash- and hashtree-descriptors for the partitions owned by an entire organization are stored in a dedicated partition, for example vbmeta_google. In this example the hashtree descriptor for system is in the vbmeta_google partition meaning that the bootloader doesn't need to access the system partition at all which is helpful if the system partition is managed as a logical partition (via e.g. LVM techniques or similar).

These numbers are referred to as rollback_index[n] and are increased for each image as security flaws are discovered and fixed. Additionally the device stores the last seen rollback index in tamper-evident storage:

c80f0f1006