A better way to fix this:
https://android.googlesource.com/platform/hardware/qcom/sdm845/media/+/5a8ea3ba6dfacf354e7f9c6f6456a37b98b87234

Forgot to share this here, everything other than camera works :D

yeet

Workaround for framework blobs (PRODUCT_BOOT_JARS)

https://github.com/pe-wip/vendor_aosp/commit/9f33bd4fd9dc3a7639b15aa01943fd24d9021a09

-> https://gitlab.com/PixelExperience/vendor_xiaomi

AOSP source, in frameworks/base/core/java/android/os/Build.java

@fancypants For those who don't know, that's a quote from "Q" in Star Trek The Next Generation with Picard :D

thinking of shitposting my begonia (mtk) experiments here too hmmmmmmmm

yum

ok lmao

I'm actually an idiot.

So, fast forward, I'm bricked now for the second time. Luckily, from the first time, I have the BROM Flash log from SP Flash Tools. For those unaware on why a Mi authorized account is needed in the first place (speaking wrt to MTK platforms), MTK provides for a feature called SLA, which happens to be Serial Link Authentication/Authorization. Most OEMs don't implement this and MediaTek's own release of SP Flash doesn't have much in regards to SLA.
Xiaomi has SLA implemented and does things server side. The device generates 16 random bytes that it expects decrypted. If you give it the right answer, it'll continue with connect_brom and start flashing whereas wrong answer, it puts itself in an endless loop and won't listen to any more commands until BROM times out and goes for a reboot.

Now, if we are able to send DA to the device and connect to it without actually doing SLA, we wouldn't need to do SLA at all. A simple change to SP Flash should be enough to reflash the device.

update: I got bored again; managed to handshake with BROM xD

So far, so good xD

MTK_AllInOne_DA_mt6765_mt6785.bin:
Data sent to the device is between 0x39DC and 0x3B9DC

I tried running SLA and providing it weird data. The device just stops responding until it times out for restart

I gave it back the data it wanted to decrypt xD