Contents of the button: some passives and a small transistor mic preamp, an electret mic and a speaker, a blob with the main logic and a 25F40-style 512KByte SPI flash chip.

Desoldering the flash chip and connecting it via a header means I can easily read and write it without having to resolder it. I really ought to design a PCB for this, hand-soldering the wires gets tedious after a while.

Flash seems to have a few regions: some sort of partition table at 0x0, a few bytes @0x1000, some unencrypted data (entropy-wise) at 0x1100, then some encrypted or compressed data at 0xB000. Initial guess is that the firmware is at 0x1100, the audio at 0xB000.

However, recording a new message and diffing the flash proves that wrong: it seems the data at 0x1000 is some sort of length indicator, and the data at 0x1100 is likely the recorded waveform. Looking at the hex data closelier, the data is probably recorded as umcompressed PCM.

It's interesting that they did it this way around... it likely means that there's only around 40K of sample memory available, with the firmware containing the following 24K... leaving the remaining 450K of flash entirely empty and unusable. I guess they designed the system with a 64K flash chip in mind, but nowadays 512K is the cheapest you can get? Strange.

I'm wondering if I'm able to figure out what CPU this thing runs and change the firmware... could do something like put Never Gonna Give You Up in the remaining flash, then do something with a RNG and have 5% chance of it playing that rather than the recorded sample. It doesn't *look* like the firmware is encrypted or compressed, there are regions of consecutive bytes and null bytes in there. On the other hand, there aren't any strings (not that you'd necessarily expect any in a console-less microcontroller app) and no recognizable instruction alignment either. Plus, cpu_rec and isadetect.com do not detect anything sane in there.

Hm, sleepy time here. If anyone else wants to play along at home, here's a binary.