Signing boot images for Android Verified Boot (AVB) [v8]

[EldonBroady]

Android 8.0

Android 8.0 and higher includes a reference implementation of Verified Boot called Android Verified Boot (AVB) or Verified Boot 2.0.

 

[akshay.ku]

The attached log doesn't contain any attempt of flashing a zip - I guess you've uploaded the wrong log.

I got only that log
I'm now on stock ROM
Installed twrp
It was not decrypted due to no screen lock
Rebooted
Flashed magisk again from twrp
After reboot and setting up lock screen
Twrp is getting encrypted
So thinking something like decryption zip can work



Sent from my Pixel using Tapatalk

 

[nvertigo67]

I got only that log

A log not containing the flash you complain about is useless. Get the log right after flashing a zip without reboot or anything.

I'm now on stock ROM
Installed twrp
It was not decrypted due to no screen lock

No passphrase doesn't mean unencrypted (decryption is done on each boot with "default_password"). Never mix unencrypted and decrypted!

Rebooted
Flashed magisk again from twrp
After reboot and setting up lock screen
Twrp is getting encrypted
So thinking something like decryption zip can work



Sent from my Pixel using Tapatalk

Again: decryption is done on each boot. unencrypted means no encryption on the userdata partiotion. twrp is not encrypted, the userdata partition is. The only way to unencrypt userdata is formating. For decryption ypu don't need a zip, but the decryption passphrase (which is "default_password" if you don't set it otherwise - roms and twrp know of "default_password", that's why they don't ask). Some roms have forced encryption (which means the userdata partition is encrypted on the first boot if the rom finds userdata unencrypted, as long as you don't disable forced encryption in fstab).

Non of the above is related to a signed boot partition/image by any means and shouldn't be discussed in this thread.

 

[osm0sis]

Turns out it's simple enough of an executable that it can be compiled from the command line!

The only trick was getting the bouncycastle dependencies in there, which an IDE would usually handle (extracting and including only the necessary ones), but I worked around that by just taking them directly out of the latest prebuilt boot_signer.jar from Android CI.

git clone --depth 1 https://android.googlesource.com/platform/system/extras aosp-system-extras
cd aosp-system-extras

# download boot_signer-support-images-with-dt.patch from [url]https://issuetracker.google.com/issues/143810860[/url] to current directory

patch --forward -p1 < boot_signer-support-images-with-dt.patch
cd verity
rm -rf build boot_signer*.jar
mkdir build prebuilt

# download latest AOSP boot_signer.jar and dx.jar from Android CI per [url]https://forum.xda-developers.com/showpost.php?p=80680681&postcount=2272[/url] to prebuilt directory

unzip prebuilt/boot_signer.jar 'org/*' -d build
javac -cp build -d build *.java
jar -cvfm boot_signer.jar BootSignature.mf -C build .
java -jar prebuilt/dx.jar --dex --output=boot_signer-dexed.jar boot_signer.jar

Fresh compiles with my patch to support bootimg hdr "v0" with dt section attached. Note boot_signer.jar is the actual correct name for this when built in AOSP, not BootSignature.jar, and I'll be updating my own projects accordingly. :good:

 

[akshay.ku]

A log not containing the flash you complain about is useless. Get the log right after flashing a zip without reboot or anything.







No passphrase doesn't mean unencrypted (decryption is done on each boot with "default_password"). Never mix unencrypted and decrypted!







Again: decryption is done on each boot. unencrypted means no encryption on the userdata partiotion. twrp is not encrypted, the userdata partition is. The only way to unencrypt userdata is formating. For decryption ypu don't need a zip, but the decryption passphrase (which is "default_password" if you don't set it otherwise - roms and twrp know of "default_password", that's why they don't ask). Some roms have forced encryption (which means the userdata partition is encrypted on the first boot if the rom finds userdata unencrypted, as long as you don't disable forced encryption in fstab).



Non of the above is related to a signed boot partition/image by any means and shouldn't be discussed in this thread.

Thank you for sharing the info.


Sent from my SM-G770F using Tapatalk

 

[VD171]

How can I sign my boot.img with BFBF header ?

 

[osm0sis]

How can I sign my boot.img with BFBF header ?

This thread is for AVBv1 signing. So not only are you cross-posting with my AIK thread, but you're off-topic. Read more and post less, please.

 

[mizzunet]

This thread is for AVBv1 signing. So not only are you cross-posting with my AIK thread, but you're off-topic. Read more and post less, please.

Hi, I'm on Q. Google update AVB in Q from v1 to be, right? I happened read that in new AVB, with locked bootloader kernel modification (like magisk) can't be made, if did it will show read warning and no boot.(I haven't tried it yet). So I wonder if there's any update for this getting Magisk as well. Sorry if I'm bothering you
Thanks??

 

[Stephen Tellis]

Does this work for lenevo

Hello sir I m using lenevo vibe k5 note

Story: this phone doesn't have a bootloader unlock I have tried many tweaks but none work and there is a xda thread for hacking bootloader of this phone but has got no solution so I gained temp root using mtk su and flashed twrp compiled by me but it gave me red State warning so I flashed my stock recovery using spft and now it's fine but when I flashed my lk.bin tweaked by me I bricked so there was only one option format all + download

Question: can this thread help me in any way to get a custom rom/recovery

 

[LoganDark]

OnePlus 7 Pro here, running latest TWRP 3.4.0-0.

Trying to flash this verified boot signer zip results in this:

********************************
* Android Verified Boot Signer *
* v8: (c) Chainfire 2017-05-28 *
********************************

mount: losetup failed 1
cat: /fstab.*: No such file or directory
System:
Filesystem root inside /system
Boot: /dev/block/bootdevice/by-name/boot_a

Extracting files
Archive:  /sdcard/VerifiedBootSigner-v8.zip
  inflating: META-INF/MANIFEST.MF
  inflating: BootSignature_Android.jar
  inflating: META-INF/CERT.RSA
  inflating: META-INF/CERT.SF
  inflating: supersu.pk8
  inflating: META-INF/com/google/android/updater-script
  inflating: META-INF/com/google/android/update-binary
  inflating: supersu.x509.der
Dumping boot image
196608+0 records in
196608+0 records out
100663296 bytes transferred in 0.297 secs (338933656 bytes/sec)
Verifying boot image

Warning: unexpected result

initialize runtime
initialize runtime

Something unexpected has happened. Please pull /tmp/recovery.log and post it to the thread on XDA

Continuing and treating boot image as unsigned
/tmp/updater[416]: /system/bin/dalvikvm: not found
Signing boot image
Verifying signed boot image
Abort: verification failed
umount: /system: Invalid argument
umount: /system_other: No such file or directory
umount: /dev/random: Invalid argument

Something unexpected has happened. Please pull /tmp/recovery.log and post it to the thread on XDA

Updater process ended with ERROR: 1
I:Install took 1 second(s).
Error installing zip file '/sdcard/VerifiedBootSigner-v8.zip'

I made sure to disable "unmount system before installing a zip" in settings. Not sure what is going on here. Does this script expect to be run in Android or something?

I think the issue is that for some reason dalvikvm is saying "initialize runtime"?

 

[LoganDark]

Alright, tried signing boot images manually. No luck.

I'm not sure if this thread is a support thread for this kind of stuff but the signed boot images don't work on my device.

0 LoganDark ~/super-bootimg/scripts/keystore_tools
java -jar BootSignature.jar /boot boot_a.img keystore.pk8 keystore.x509.pem boot_a_signed.img
NOTE: truncating file boot_a.img from 100663296 to 53870592 bytes
0 LoganDark ~/super-bootimg/scripts/keystore_tools
java -jar BootSignature.jar /boot boot_b.img keystore.pk8 keystore.x509.pem boot_b_signed.img
NOTE: truncating file boot_b.img from 100663296 to 53870592 bytes
0 LoganDark ~/super-bootimg/scripts/keystore_tools fastboot flash boot_a boot_a_signed.img
Sending 'boot_a' (52609 KB)                        OKAY [  1.316s]
Writing 'boot_a'                                   OKAY [  0.150s]
Finished. Total time: 1.480s
0 LoganDark ~/super-bootimg/scripts/keystore_tools fastboot flash boot_b boot_b_signed.img
Sending 'boot_b' (52609 KB)                        OKAY [  1.210s]
Writing 'boot_b'                                   OKAY [  0.151s]
Finished. Total time: 1.375s
0 LoganDark ~/super-bootimg/scripts/keystore_tools fastboot flash boot_a boot_a.img
Sending 'boot_a' (98304 KB)                        OKAY [  2.410s]
Writing 'boot_a'                                   OKAY [  0.329s]
Finished. Total time: 2.753s
0 LoganDark ~/super-bootimg/scripts/keystore_tools fastboot flash boot_b boot_b.img
Sending 'boot_b' (98304 KB)                        OKAY [  2.205s]
Writing 'boot_b'                                   OKAY [  0.341s]
Finished. Total time: 2.563s

My device refused to boot at all when I flashed the signed images. Neither system nor recovery worked. With a locked bootloader it said the device was corrupt. However, the original boot images I have work just fine, and boot TWRP and Android fine.

What gives? Again, sorry if this is the wrong thread, please point me in the right direction if so.

 

[LoganDark]

Alright, so now I've learned that the OP7P uses AVBv2, which isn't supported by BootSignature.jar. That's cool. I've also happened upon this which looks like a couple of commands I can use to create a new vbmeta and boot image to use. I'll try it out in a bit and see if it works. Thanks @osm0sis for letting me know what to look for

 

[ssiddall]

I'm trying to root a Pixel.

I booted the 3.4.0 TWRP img file successfully and installed the associated .zip file. There were a couple of errors, but the overall process seemed to be successful.
But verifiying failed. The process told me to upload the recovery.log (a portion of which is below) to XDA.

...
Image patching complete!

Done installing TWRP!

*** NOTE: You are now unrooted! ***
I:Updater process ended with RC=0
I:Install took 11 second(s).
Updating partition details...
Failed to mount '/system_root' (Invalid argument)
I:Actual block device: '/dev/block/sda33', current file system: 'ext4'
I:Unable to mount '/system_root'
I:Actual block device: '/dev/block/sda33', current file system: 'ext4'
Failed to mount '/vendor' (Invalid argument)
I:Actual block device: '/dev/block/bootdevice/by-name/vendor_a', current file system: 'ext4'
Iata backup size is 3154MB, free: 111347MB.
...done
I:Set page: 'flash_done'
Iperation_end - status=0
I:Set page: 'clear_vars'
I:Set page: 'install'
I:Set page: 'flash_confirm'
I:Set page: 'flash_zip'
Iperation_start: 'Flashing'
Installing zip file '/sdcard/Download/VerifiedBootSigner-v8.zip'
Checking for Digest file...
Unmounting System...
I:Update binary zip
Verifying package compatibility...
Package doesn't contain compatibility.zip entry
I:Extracting updater binary 'META-INF/com/google/android/update-binary'
I:Zip does not contain SELinux file_contexts file in its root.
I:Legacy property environment not used in updater.

********************************
* Android Verified Boot Signer *
* v8: (c) Chainfire 2017-05-28 *
********************************

mount: losetup failed 1
cat: /fstab.*: No such file or directory
mount: '/system' not in fstab
mount: '/system' not in fstab
mount: '/system' not in fstab
System:
Boot: /dev/block/bootdevice/by-name/boot_a

Extracting files
Archive: /sdcard/Download/VerifiedBootSigner-v8.zip
inflating: META-INF/MANIFEST.MF
inflating: BootSignature_Android.jar
inflating: META-INF/CERT.RSA
inflating: META-INF/CERT.SF
inflating: supersu.pk8
inflating: META-INF/com/google/android/updater-script
inflating: META-INF/com/google/android/update-binary
inflating: supersu.x509.der
Dumping boot image
65536+0 records in
65536+0 records out
33554432 bytes transferred in 0.463 secs (72471775 bytes/sec)
Verifying boot image

Warning: unexpected result

initialize runtimeinitialize runtime


Something unexpected has happened. Please pull /tmp/recovery.log and post it to the thread on XDA

Continuing and treating boot image as unsigned
/tmp/updater[416]: /system/bin/dalvikvm: not found
Signing boot image
Verifying signed boot image
Abort: verification failed
umount: /system: Invalid argument
umount: /system: Invalid argument
umount: /system_root: Invalid argument
umount: /system_other: No such file or directory
umount: /dev/random: Invalid argument

Something unexpected has happened. Please pull /tmp/recovery.log and post it to the thread on XDA

Updater process ended with ERROR: 1
I:Install took 1 second(s).
Error installing zip file '/sdcard/Download/VerifiedBootSigner-v8.zip'
Updating partition details...
Failed to mount '/system_root' (Invalid argument)
I:Actual block device: '/dev/block/sda33', current file system: 'ext4'
I:Unable to mount '/system_root'
I:Actual block device: '/dev/block/sda33', current file system: 'ext4'
Failed to mount '/vendor' (Invalid argument)
I:Actual block device: '/dev/block/bootdevice/by-name/vendor_a', current file system: 'ext4'
Iata backup size is 3154MB, free: 111347MB.
...done
I:Set page: 'flash_done'
Iperation_end - status=1
I:Set page: 'clear_vars'
I:Set page: 'install'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Set page: 'advanced'
I:Set page: 'filemanagerlist'
I:Set page: 'filemanageroptions'
I:Set page: 'choosedestinationfolder'
I:Set page: 'filemanagerconfirm'
I:Set page: 'filemanageraction'
Iperation_start: 'Command'
I:Running command: 'cp "/tmp/recovery.log" "/sdcard/Download"'

 

[jcmm11]

I'm trying to root a Pixel.
...snip ..

What version Pixel?
What version Android?
Why are you trying to flash verifiedbootsigner? That has nothing to do with rooting your Pixel. Really the wrong thread for this but you should install Magisk Manager
Extract your boot image from a factory image (or use TWRP to get a copy of the existing boot image)
Patch the extracted boot image via Magisk Manager
Install the patched boot image. TWRP will probably work. Fastboot definitely will.

For more info you should see your device thread.

 

[mizzunet]

Turns out it's simple enough of an executable that it can be compiled from the command line!

The only trick was getting the bouncycastle dependencies in there, which an IDE would usually handle (extracting and including only the necessary ones), but I worked around that by just taking them directly out of the latest prebuilt boot_signer.jar from Android CI.

git clone --depth 1 https://android.googlesource.com/platform/system/extras aosp-system-extras
cd aosp-system-extras

# download boot_signer-support-images-with-dt.patch from [url]https://issuetracker.google.com/issues/143810860[/url] to current directory

patch --forward -p1 < boot_signer-support-images-with-dt.patch
cd verity
rm -rf build boot_signer*.jar
mkdir build prebuilt

# download latest AOSP boot_signer.jar and dx.jar from Android CI per [url]https://forum.xda-developers.com/showpost.php?p=80680681&postcount=2272[/url] to prebuilt directory

unzip prebuilt/boot_signer.jar 'org/*' -d build
javac -cp build -d build *.java
jar -cvfm boot_signer.jar BootSignature.mf -C build .
java -jar prebuilt/dx.jar --dex --output=boot_signer-dexed.jar boot_signer.jar

Fresh compiles with my patch to support bootimg hdr "v0" with dt section attached. Note boot_signer.jar is the actual correct name for this when built in AOSP, not BootSignature.jar, and I'll be updating my own projects accordingly. :good:

Hi, could you help me on this?
I tried sign boot image using BootSigner zip through TWRP, this was the result.
ROM was A11

 

[Chrissanctus]

Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.

Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.

Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.

For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.

Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.

Generating custom signing keys

The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.

# private key
openssl genrsa -f4 -out verifiedboot.pem 2048
openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt

# public key
openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem
openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der

For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.

Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.

Signing the boot image

Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:

java -jar BootSignature.jar /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
java -jar BootSignature.jar -verify boot_signed.img

Instead of /boot, /recovery and other values may be used. Their use should be obvious.

From Android

Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:

dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature -verify boot_signed.img

The base command can be extended as follows to make it able to run without any precompiled files present on the device:

/system/bin/dalvikvm -Xbootclasspath:/system/framework/core-oj.jar:/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/bouncycastle.jar -Xnodex2oat -Xnoimage-dex2oat -cp BootSignature_Android.jar com.android.verity.BootSignature ...

Flashable ZIP

Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.

I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.

Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.

If the boot image is already signed when you flash the ZIP, it will offer to abort or force re-sign.

If you place custom.pk8 and custom.x509.der files inside the ZIP, these keys will be used for flashing instead of SuperSU's default keys. Additionally, /tmp/avb/custom.pk8 and /tmp/avb/custom.x509.der will override any keys from the ZIP.

There is some more documentation in the update-binary file inside the ZIP as well.

Note: If you're using TWRP's manual slot selection on the Pixel (XL), you must be using TWRP-v3.1.0-RC2 or newer, or it will not work as expected.

Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature

My tecno Camon 15 keeps telling me it needs a verified image file to work and i am already stuck in a bootloop
i don't if this will work for it and i don't even know how to apply it

 

[Franc89]

This working on Samsung android 9 and 10 boot also?

 

[theGeekyLad]

Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.

Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.

Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.

For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.

Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.

Generating custom signing keys

The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.

# private key
openssl genrsa -f4 -out verifiedboot.pem 2048
openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt

# public key
openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem
openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der

For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.

Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.

Signing the boot image

Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:

java -jar BootSignature.jar /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
java -jar BootSignature.jar -verify boot_signed.img

Instead of /boot, /recovery and other values may be used. Their use should be obvious.

From Android

Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:

dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature -verify boot_signed.img

The base command can be extended as follows to make it able to run without any precompiled files present on the device:

/system/bin/dalvikvm -Xbootclasspath:/system/framework/core-oj.jar:/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/bouncycastle.jar -Xnodex2oat -Xnoimage-dex2oat -cp BootSignature_Android.jar com.android.verity.BootSignature ...

Flashable ZIP

Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.

I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.

Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.

If the boot image is already signed when you flash the ZIP, it will offer to abort or force re-sign.

If you place custom.pk8 and custom.x509.der files inside the ZIP, these keys will be used for flashing instead of SuperSU's default keys. Additionally, /tmp/avb/custom.pk8 and /tmp/avb/custom.x509.der will override any keys from the ZIP.

There is some more documentation in the update-binary file inside the ZIP as well.

Note: If you're using TWRP's manual slot selection on the Pixel (XL), you must be using TWRP-v3.1.0-RC2 or newer, or it will not work as expected.

Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature

Fast-forward to 2021 and this doesn't work on my Walleye. Flashed Resurrection Remix and followed this process to the letter to sign boot_a.img and boot_b.img. Flashing it back, locking the bootloader and booting the device leaves me with the following message -

ERROR: Slot Uunbootable: Load Error.

Where am I possibly going wrong, if that is?