Running custom code

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


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    

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.

« Prev 3 Next »

© 2006-2016 Sprite_tm - Contact