Do you like my hacking? If so, please consider leaving something in the
Fediverse (Mastodon etc): @Sprite_tm@social. spritesmods.com
So, with the serial port connected, what mysteries did the camera shout at me? Seems I hit the jackpot. First of all, there were some very verbose boot messages, partially confirming what I knew from inspecting the PCBs and looking at the strings of the firmware update: the devices SOC is a chip by Ambarella, it contains an ARM and a DSP and unfortunately, the device doesn't run Linux or another open-source OS but PrKernelV4, a proprietary product.
After the device had booted, something more interesting came along, though:
***************************************************************** * * * ambsh ;) * * * ***************************************************************** rtos mesg enabled dsp mesg disabled type 'help' for help a:\>
Aha! A nice command line I can play with. Let's see what the help has to say:
a:\> help
supported built-in commands:
bp cardmgr cat cd
chmod config cp cpu
date deletedir descrypt dmesg
dramcfg drives dsputil echo
eeprom eval false ffuc
format help history hotboot
ioerr jobs kill ls
md5 mesg mkboot mkdir
morph mv nanddb nice
poweroff pref ps pwd
ramdisk readb readl readw
reboot reset resume rm
rmdir savebin sleep suspend
sysmon t test time
touch trap true vol
writeb writel writew yyinfo
usbclass ver vin vout
sm show gs bkcr
gp bd gapi mm
ww ds pmov chtv
getfwdate pause saveclbdata corefreq
dramfreq idspfreq dll cleandir
volcfg firmfl nvd nftl
romfs
a:\>
Ok, lots of handy commands. After playing with them for a while, I noticed it wouldn't be as easy to hack the firmware as I expected: the kernel, OS and userspace tools seemed to be linked into one unwieldy binary, with no obvious way to load custom code into memory. While there was a command named 'savebin' you can use to dump a piece of memory to SD-card, there wasn't even a command to do the opposite. Still: the readl/writel-commands, used to read and write words from/to memory, were indispensible for poking around and seeing what does what.
In the end, I decided to just dump all of the 128M of memory to disk and throw it into a disassembler. There the grinding started: find out the command routines, see if I could locate the C-routines like printf and fopen and generally making sense of the binary lump of data. The disassembly confirmed my fears: there was no stable binary API for any functions, so I had to find everything I needed in the code and hardcode the address in my program.
Anyway, to make a long story short, I eventually found the routines I needed to load a file from disk into memory. But how to get that piece of code calling those running on the Zx3? Another find helped a great deal: I noticed references to a strange file called 'd:\autoexec.ash'. After some testing, it seemed that if such a file exists on the SD-card, it gets run by the command interpreter that also provides the serial shell thingy.
With that, I was set: I could automatically generate an autoexec.ash-file which would use the 'writel'-shellcommand to poke the loader code to memory. It would then execute that loader by altering the shell-command 'eval' to jump to the loader, and then simply calling 'eval'. The loader would then load whatever code I fancied into an unused piece of RAM. It would also patch the main program so that a function in the configuration menu of the camera, which used to do nothing at all, would invoke the loaded code. The device was now completely mine.