Edit: The audio data is on a separate IC
There are a few seconds of audio in a toy's 128 kB firmware - somewhere...
Here is a downsampled look at the bits (white = 1):
My beginner's attempts to analyse the disassembly in order to find the audio data blocks have not been successful so far. There appear to be sections that are visually different, although it's not something very obvious. Trying the different raw audio import options in Audacity only results in "noise".
I am assuming a (simple?) compression scheme is in use, so maybe RLE, DPCM or even ADPCM.
My guess is that the areas that do not show the byte boundary (LSB/MSB set = white) as clearly (=higher bit frequency?) are worth a closer look.
I am going to try to gather information about the audio resolution and rate by analysing the audio output, to help get an estimate of what I am looking for.
A few ideas on how to proceed:
Finding data (as opposed to code) from program analysis:
- use analysers showing data sections (= no instructions, not reached in program flow) - which? what limitations apply?
- find
const
data (not copied to RAM at initialisation)
Finding audio data directly by:
- properties of audio data (AC signal)
- compare with samples of data patterns in simple audio compression
Working with a debugger:
- it might be possible to set a data change / register write breakpoint for the peripheral that is likely to generate the audio output (Timer/PWM/DAC/DMA) and work backwards from there
But all of these require a lot of legwork and more background knowledge than I currently have, so the outlook is rather limited..
What other approaches to finding data in firmware should I consider?