We're in!

Honestly, that was easier than I expected :-)

First things first, let's have a look around. We've got the flash binary, so shouldn't be able to irreversibly break anything, but better to be careful in case we can't reflash for whatever reason. I had formatted a microSD card to ext4, inserted, and tried to mount it to a directory (a handy existing directory /mnt/extsd/) but I got errors. Huh. Scrolling back through the boot messages, I see mentions for squashfs, vfat and exfat, but not ext4. No ext4 support? Reformatting the card as exFat seemed to help, as I could then mount it, and copied the entire root filesystem onto it - this allows my to look through the filesystem on the laptop while doing other stuff on the serial console - no multiuser support there...

Next, a check on the commands available (busybox is there, the shell is ash, top, less and more and available, but no text editing binaries are present. Cat, awk and sed are there... this could be painful... Busybox is very minimal - ed is definitely not there, even the help isn't compiled in. Lucky we've got rm and cp and a microSD card...)

top and ps show the running processes. Three interesting ones - sdvcam (killing this kills the GUI, and the device doesn't really recover without rebooting), lylink (appears to handle the wireless AAuto etc), and tc_daemon (a watchdog of sorts? killing this reboots the device after a couple of seconds).

Boot is init.d and rc script based. rc.S10app in the init.d directory looks like it starts sdvcam, which must then start lylink - no other mention. There's mention of a /etc/flag_systemlog file which promised to trigger a script that copies various logs onto the microSD card. Be rude not to... "touch /etc/flag_systemlog" works, rebooting the device... ah, it doesn't automatically mount the microSD card while it's formatted in exFat, so I let the device reformat the disk as it likes (it offers to do so on the GUI) and try again. This results in various files dumped on the card, but are unreadable. A closer look at the 'log' script reveals that the log files are encrypted by an executable on the device... fortunately we can also decrypt using the same binary!

The logs are quite useful, including boot messages, the output of 'free', 'ps', etc, and the sdvcam debug(!) logs. If the microSD card is left mounted, more logs are periodically stored, but encrypted again... let's sort that out.

I copy the 'log' script across to the microSD card, mount it on my laptop, and comment out the lines that call the encryption binary. microSD card back to the device, mount, and overwrite those files... seems to succeed. The altered files survive a reboot (the overlay filesystem works!) and the log files written to the microSD card remain unencrypted. Good, that makes reading them easier, and also means we can make edits to various files (the overlayfs is only a few KB is size - plenty for config files and scripts, but not big enough for decent binaries... we'll worry about that later).

The sdvcam logs mention some missing configuration settings (and the default values) so that means there must be some setting files somewhere. A quick look through the filesystem downloaded to the laptop finds /usr/share/res/ (mostly layout xml files for the GUI, also icons, fonts etc. Seems to use miniGUI.c) and /data/ - data contains various settings controlling the bluetooth names, wifi names and addresses, and also casting settings - Carplay, mirrorlink, HiCar and Android Auto! Included in these setting files is one labeled "andauto.fullscreen", set to 0. Changing that to '1' (copying the file to the microSD card, unmounting, mounting on the laptop, editing the file, unmounting, back to the device, remounting, rm and cp...) and rebooting...

Partial success... the AAuto stream is now centred, and there's no camera 'frame' visible, but it doesn't take up the whole screen, leaving wide black bars left and right.