Ah the issue was my inclusions

I think I've figured out a fix finally

Idk how it works but it does now

me everytime i fix a bug

ah shit, here we go again

hello

what if froot returned but to A13 😳

i've gotten better at commit messages

hello yall how have u been im back

some rabbit r1 rants coming up, until then:

oh no cringe

So some context:
You guys probably know a fair bit of this but here it goes anyways:
The R1 is a mt6765 device with a completely unsecure preloader and brom. The brom isn’t easily accessible and in my experience it isn’t too easy to crash preloader and enter brom, even with existing exploits. Maybe I was doing something wrong, but we don’t need it anyways.

The partition layout can be misleading. It appears as if the rabbit team took clean alps and stripped components out of it. The partition layout has vendor_boot and init_boot, which would normally suggest a GKI, but these partitions are blank and unused. They hardly even renamed device identifiers.

The “RabbitOS” system is basically alps with a flutter app set as the launcher, and a service called “Judy” that actively turns off adb. Reversing Judy and RabbitLauncher we find quite a few interesting things.

I didn’t want to do this by hand, so here’s a janky generator:
https://github.com/RabbitHoleEscapeR1/scatter_gen

Next let’s talk about Judy.

I think that's self explanatory.

You can build your own weirdo boot-debug.img by touching a force_debuggable file in ramdisk, copying adb_debug.prop from AOSP, touching a blank userdebug_plat_sepolicy.cil file in ramdisk. Further, anything added to adb_debug.prop takes precedence, you can mark ro.build.type=eng or userdebug to bypass judy and force enable adb

There was some way to keep adb enabled on the first firmware, but unfortunately for me, my unit updated as soon as I connected to wifi (you must realise i had no idea about what this orange contraption was). There are still references in the RabbitLauncher code to enable a factory mode that grants adb but I'm sure this is stripped out.

Coming to unlocking the bootloader. You can simply unlock it using mtkclient's seccfg commands. But for some reason, I quite often was left with dm-verity issues when using seccfg directly. Don't get me wrong, it did work most of the times, but I wanted a more reliable way to unlock. I opted for pulling partition frp, flipping the last byte, and writing it back to the device. Then booting to fastboot using meta bootcmd/sequence, and issuing fastboot flashing unlock. Since there are no volume keys, it automatically selects "Yes". If frp was updated correctly, the bootloader unlocks normally.