Hacking
Ok, so now I knew the protocol and the core-chip: let's start hacking the firmware! But how to get it? It seemed the protocol to retrieve photos off the device downloaded the photos straight from flash. That was interesting: if the device only has 2M of memory, what happens if I try to fetch something above that limit? A small testing program later, I had the firmware. The fetches actually 'wrap around': the firmware lives in the first 64k, the photo's after that. If you then request the photo at 2M-64K, the firmware adds the offset of the start of the picture area and ends up with an adress at 2M. It'll try to fetch the byte there by making an address line high which isn't connected to the flash, so the flash'll think the processor actually requested address 0, and return that information.
Using a 65c02 disassembler, I quickly found out that the firmware was programmed quite securily (which, by the way, was mostly because of the processor design), so I couldn't inject my own code by e.g. triggering a buffer overflow. Luckily, some alternate official software for the device had a button to flash new firmware. A simple test with firmware with a string modified in it immediately revealed why that option wasn't in my version: it didn't work! Seemingly, the firmware was developed for a flash-part with only 32K sectors. The one used here stores the firmware in a 16K and 2 8K-sectors. What happened is that a firmware update only erased the first 8K and left the other 24K intact. In other words: any hack I did would have to live in the first 8K.
Now, what to modify? In the end, I decided on adding an extra address to write data to to the list that the device already had: if you now write to 0x4200, the data will end up in the memory of the LCD-controller. This way, the device can be used to show e.g. real-time statistics of a server, which actually is the main thing I bought this device for.