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.

Now, my first plan of action was to just try a GSI. After all, I have no kernel source, and this was not a certified device. Would be interesting to see what a GSI would do, would it even boot?

bootloader unlocked

It does boot, but there's constant crashes, mostly with launcher3. Looking at the logs and some sifting through AOSP, I realised, vendor doesn't have handheld_core_hardware.xml and other standard handheld smartphone permission files & configs.

I copied over the GSI target from AOSP and started working on that, adding what was missing, initial IMS port and figuring out what to do with the keys and camera. For keys, you have 2 approaches:
1. framework keyhandler
2. keylayout
I have both on my tree, but I'm actively using only the framework keyhandler approach, since it lets me retain default behaviour for when someone manages to port a simple rabbitlauncher apk.