Hi everybody. After having read about DivestOS in other topics, I decided it would be easier to discuss everything about it here in this topic.
Thanks @SkewedZeppelin for this Custom ROM. I gave it a shot this Friday (FP3 with upgraded cameras). So far everything is great. I have been using Lineage OS rooted with Magisk for a long time now. Wanted to try using my telephone without root. Then decided to give DigestOS a try. Everything went well.
The Seedvault Backup could backup a lot of the apps (not all, because of Apps that do not allow getting backedup) from Lineage OS and I could restore them without any problem.
I also flashed the AVB custom key. However, everytime I boot, i get the message that the telephone has a different software installed. I thought that verified boot should ignore this message, right? Or am I missing something?
FP4 with iode, /e/ doesn’t have this message with locked bootloader.
My pix5 with calyx and locked bootloader has this message and calyx writes in doku that it is normal.
ROMs don’t change the bootloader, this is dependent on what keys are used to sign the system image and verified boot metadata.
DivestOS uses unique keys for each component of every device.
I strongly suspect FP3 bootloader has the AOSP test-keys marked trusted.
Any ROM with unique keys is supposed to show the “different OS” message.
If you do not see a yellow screen on a locked verified boot device with an alternate system the bootloader should be considered broken.
I have just downloaded the latest iodeOS for FP3 (iode-2.4-20220401-FP3.zip) and verified that while it uses release keys for the system, it uses the insecure public test keys for verified boot:
python verify_signature.py --file ../boot.img --vbmeta ../vbmeta.img
Boot Signature Tool v1.6 (c) B.Kerler 2017-2019
----------------------------------------------
Kernel=0x00000800, length=0x011DE800
Ramdisk=0x011DF000, length=0x008EC000
Second=0x01ACB000, length=0x00000000
QCDT=0x01ACB000, length=0x00000800
Signature start=0x01ACB800
AVB >=2.0 vbmeta detected: avbtool 1.1.0
----------------------------------------
Image-Target: boot
Salt: 3060ee5d8e693761a121db1dca43a72b06f166103d87d3fe44e416629a1d6bfc
Image-Size: 0x1acb000
Calced Image-Hash: 7b840afeda5c5bd81f57720c119d98bc8ee6b6ddda441b7e68f742d2e1f6a821
Image-Hash: 7b840afeda5c5bd81f57720c119d98bc8ee6b6ddda441b7e68f742d2e1f6a821
VBMeta-Image-Hash: 7b840afeda5c5bd81f57720c119d98bc8ee6b6ddda441b7e68f742d2e1f6a821
Signature-RSA-Modulus (n): d804afe3d3846c7e0d893dc28cd31255e962c9f10f5ecc1672ab447c2c654a94b5162b00bb06ef1307534cf964b9287a1b849888d867a423f9a74bdc4a0ff73a18ae54a815feb0adac35da3bad27bcafe8d32f3734d6512b6c5a27d79606af6bb880cafa30b4b185b34daaaac316341ab8e7c7faf90977ab9793eb44aecf20bcf08011db230c4771b96dd67b604787165693b7c22a9ab04c010c30d89387f0ed6e8bbe305bf6a6afdd807c455e8f91935e44feb88207ee79cabf31736258e3cdc4bcc2111da14abffe277da1f635a35ecadc572f3ef0c95d866af8af66a7edcdb8eda15fba9b851ad509ae944e3bcfcb5cc97980f7cca64aa86ad8d33111f9f602632a1a2dd11a661b1641bdbdf74dc04ae527495f7f58e3272de5c9660e52381638fb16eb533fe6fde9a25e2559d87945ff034c26a2005a8ec251a115f97bf45c819b184735d82d05e9ad0f357415a38e8bcc27da7c5de4fa04d3050bba3ab249452f47c70d413f97804d3fc1b5bb705fa737af482212452ef50f8792e28401f9120f141524ce8999eeb9c417707015eabec66c1f62b3f42d1687fb561e45abae32e45e91ed53665ebdedade612390d83c9e86b6c2da5eec45a66ae8c97d70d6c49c7f5c492318b09ee33daa937b64918f80e6045c83391ef205710be782d8326d6ca61f92fe0bf0530525a121c00a75dcc7c2ec5958ba33bf0432e5edd00db0db33799a9cd9cb743f7354421c28271ab8daab44111ec1e8dfc1482924e836a0a6b355e5de95ccc8cde39d14a5b5f63a964e00acb0bb85a7cc30be6befe8b0f7d348e026674016cca76ac7c67082f3f1aa62c60b3ffda8db8120c007fcc50a15c64a1e25f3265c99cbed60a13873c2a45470cca4282fa8965e789b48ff71ee623a5d059377992d7ce3dfde3a10bcf6c85a065f35cc64a635f6e3a3a2a8b6ab62fbbf8b24b62bc1a912566e369ca60490bf68abe3e7653c27aa8041775f1f303621b85b2b0ef8015b6d44edf71acdb2a04d4b421ba655657e8fa84a27d130eafd79a582aa381848d09a06ac1bbd9f586acbd756109e68c3d77b2ed3020e4001d97e8bfc7001b21b116e741672eec38bce51bb4062331711c49cd764a76368da3898b4a7af487c8150f3739f66d8019ef5ca866ce1b167921dfd73130c421dd345bd21a2b3e5df7eaca058eb7cb492ea0e3f4a74819109c04a7f42874c86f63202b462426191dd12c316d5a29a206a6b241cc0a27960996ac476578685198d6d8a62da0cfece274f282e397d97ed4f80b70433db17b9780d6cbd719bc630bfd4d88fe67acb8cc50b768b35bd61e25fc5f3c8db1337cb349013f71550e51ba6126faeae5b5e8aacfcd969fd6c15f5391ad05de20e751da5b9567edf4ee426570130b70141cc9e019ca5ff51d704b6c0674ecb52e77e174a1a399a0859ef1acd87e
Signature-n0inv: 1440285869
!!!! Image seems to be signed by google test keys, yay !!!!
AVB-Status: VERIFIED, 0
No experience on FP3, only on FP4
For FP4 they are using the avb_custom_key-FP4.bin
Do you think this is also just the public test key only with another file name?
Snipped from google doc: Device State, User-settable root of trust:
If an user-settable root of trust is set, the device should allow a version of Android signed with either the built-in root of trust or the user-settable root of trust to boot.
what difference regarding Trust does it makes?
As I understand it, it is still possible to boot any kernel as long as it is signed with the built-in key, because both will be accepted. Right? Or do I understand it wrong?
In the case you install a properly signed ROM on such a broken bootloader, the
verified boot should be functional.
I am more concerned about the ROMs signing verified boot metadata with test-
keys.
If you could get EDL access you can very likely swap out the system without
triggering a wipe of usredata.
