[ROM] DivestOS 20.0 for mata

[Psk.It]

@SkewedZeppelin sorry to be OT, I saw the build for Oneplus 9 / 9 pro
i did a couple of attempt starting from OOS and starting from Lieage19.1
also installing fastboot zip or sideloading the other zip file, i ran always on qualcomm crashdum
where can I found specific instruction?

thank you

 

[SkewedZeppelin]

@SkewedZeppelin sorry to be OT, I saw the build for Oneplus 9 / 9 pro
i did a couple of attempt starting from OOS and starting from Lieage19.1
also installing fastboot zip or sideloading the other zip file, i ran always on qualcomm crashdum
where can I found specific instruction?

thank you

OnePlus 9 Pro - Starting with a Fresh, Stock, Fully updated ROM to 12 - Getting Qualcomm Crash Dump screen · Issue #125 · Divested-Mobile/DivestOS-Build

So I've tried this a few times now. Just bought a brand new One Plus 9 Pro yesterday (New, unlocked, directly from OnePlus - upgrading from my trusty OnePlus 7 Pro) Updated the OOS to latest over t...

github.com

 

[foueddyf]

Just saw this month's update in the updater but there are 2 files. Is the smaller one (55mb) needed?

 

[foueddyf]

Also, I don't see mata anymore on DivestOS device list page:
https://divestos.org/index.php?page=devices&base=LineageOS#device-mata

Should we be worried?

 

[SkewedZeppelin]

Just saw this month's update in the updater but there are 2 files. Is the smaller one (55mb) needed?

The smaller one is a delta that downloads quicker. Contains the update just as the large one.

Also, I don't see mata anymore on DivestOS device list page:
https://divestos.org/index.php?page=devices&base=LineageOS#device-mata

Should we be worried?

There is a cache to the page, when builds are uploading I move the old ones to an old folder, and the new ones upload.
During the upload the page will be missing devices.

I rarely remove devices and I note it on the news page when I do.

 

[foueddyf]

The smaller one is a delta that downloads quicker. Contains the update just as the large one.

Does the delta update only show up if it's safe to flash it?
In other words, say I was on the April 19.1 build, would this delta update show up?
I was always under the impression delta updates only work if you're 1 version behind and not more.

I guess, if in doubt, just get the full update.
Glad to hear mata is not going away

 

[SkewedZeppelin]

Does the delta update only show up if it's safe to flash it?
In other words, say I was on the April 19.1 build, would this delta update show up?
I was always under the impression delta updates only work if you're 1 version behind and not more.

Deltas can be generated between any two images no matter how old.
The updater will only provide delta images that are compatible with the current installed image.
Furthermore it will only apply changes if it is validated to apply successfully by the update engine.

 

[foueddyf]

Deltas can be generated between any two images no matter how old.
The updater will only provide delta images that are compatible with the current installed image.
Furthermore it will only apply changes if it is validated to apply successfully by the update engine.

That's awesome, thanks

 

[hedgecore44]

Has anyone gotten the DoorDash app to work on newest 19.1 version?

 

[SkewedZeppelin]

Has anyone gotten the DoorDash app to work on newest 19.1 version?

If it doesn't work try disabling the content blocker in Settings > Security.

If that doesn't fix it, you can try the make sure the `Enable native code debugging` option above that is checked.

If that doesn't fix it, it may depend on Safetynet and not work.

 

[hedgecore44]

If it doesn't work try disabling the content blocker in Settings > Security.

If that doesn't fix it, you can try the make sure the `Enable native code debugging` option above that is checked.

If that doesn't fix it, it may depend on Safetynet and not work.

Thanks for the quick response. None of those options got it working. It works on my other degoogled phone with GrapheneOS so I thought it would work here.. No problem, I will just use the browser.

 

[nexuspb]

Great ROM! Thank you for developing this as I wanted to try a secure ROM (harden malloc etc) like grapheneOS but do not have a pixel. I have a few questions about this since I'm very new to this stuff

1. Since mata does not have AVB, what exactly are we verifying in the verified boot? From what I found online, it will just check for a valid signature but not if it's signed by a vendor. Is this true?
2. I'm mostly afraid of bricking my device given that EDL mode recovery is not an option, would keeping the bootloader unlocked prevent any hard brick situations? Also, does an unlocked bootloader only protect against physical attacks (nothing remote)?

 

[SkewedZeppelin]

1. Since mata does not have AVB, what exactly are we verifying in the verified boot? From what I found online, it will just check for a valid signature but not if it's signed by a vendor. Is this true?

Verified boot on these non AVB devices from my understanding is that the ramdisk is trusted because it is there and locked, and everything after the ramdisk (/system, and /vendor) are verified by the kernel in the ramdisk against the keys in the ramdisk.

On AVB devices the ramdisk would be verified against the avb key partition.

2. I'm mostly afraid of bricking my device given that EDL mode recovery is not an option, would keeping the bootloader unlocked prevent any hard brick situations? Also, does an unlocked bootloader only protect against physical attacks (nothing remote)?

As long as you keep the option to `allow oem unlocking` in Settings, you should always be able to unlock from fastboot even if the system/recovery are non-functional.

And verified boot is not enforcing when the bootloader isn't locked. So yes any malware that tries to gain persistence via modifying a verity partition would be blocked. (although there are obviously other ways for persistence)

 

[SkewedZeppelin]

-deleted duplicate message that submitted twice-

 

[nexuspb]

As long as you keep the option to `allow oem unlocking` in Settings, you should always be able to unlock from fastboot even if the system/recovery are non-functional.

Thank you for the quick reply! I really appreciate it. This might be unrelated, but how do other mata devices get hard bricked then? I saw on reddit/xda that people were getting hard bricked with unlocked & locked bootloaders? In what situation would fastboot not even work? Is this only when oem unlocking is disabled?

And verified boot is not enforcing when the bootloader isn't locked. So yes any malware that tries to gain persistence via modifying a verity partition would be blocked. (although there are obviously other ways for persistence)

Do you mean "modifying a verity partition wouldn't get blocked"?

 

[SkewedZeppelin]

This might be unrelated, but how do other mata devices get hard bricked then? I saw on reddit/xda that people were getting hard bricked with unlocked & locked bootloaders? In what situation would fastboot not even work? Is this only when oem unlocking is disabled?

Many devices *do* support locking as this project has proven, users saying locking is "guaranteed 100% brick" is just a wrong blanket statement given the device wasn't too mutilated by the vendor and that the OS you are flashing is signed correctly.

Do you mean "modifying a verity partition wouldn't get blocked"?

In the case the bootloader was unlocked, yes.

 

[nexuspb]

Thank you! I've been using this rom for a bit and really enjoy it.

I'm still struggling to understand the AVB 1.0 boot process for mata.

In this case, how does DivestOS verify the boot partition? I see that the bootloader needs to verify the boot partition with it's OEM key which we don't have in this case? Or are you changing the OEM boot key?

Thank you for the help

 

[SkewedZeppelin]

@nexuspb
The bootloader appears to pin the keys of the boot partition after lock for future boots, if it is changed it should boot red.
The kernel itself then verifies the system and vendor image against its stored key.

 

[nexuspb]

@nexuspb
The bootloader appears to pin the keys of the boot partition after lock for future boots, if it is changed it should boot red.
The kernel itself then verifies the system and vendor image against its stored key.

So this means it will boot yellow? I would just need to ensure that the hash matches when I boot my phone to ensure no tampering?

I appreciate the help

 

[SkewedZeppelin]

So this means it will boot yellow? I would just need to ensure that the hash matches when I boot my phone to ensure no tampering?

Yes:
- After flashing and unlocked it should be orange.
- Upon locking it'll be yellow and show the hash listed here: https://divestos.org/index.php?page=verified_boot_hashes