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):

enter image description here

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?

  • 1
    As long as you don't know the format finding it requires a lot of luck. If possible I would check the chip executing the code regarding the supported audio formats. – Robert Feb 11 at 13:57
  • I'd guess mu law 8KHz mono, since that's fairly common in telephony (and a good step up from linear 8-bit PCM if you've got a 12+ bit DAC), and it doesn't feel worth going overboard with anything complex for only a few seconds of audio. Here's the widely used (I think) Sun decode code: search for bytes 0F and F0 near lots of shift instructions, and you might get lucky. – Rup Feb 11 at 17:56
  • If it's a simple enough compression scheme (ADPCM, uLaw, etc.), playing it as if it's PCM will sometimes actually work. You'll get something that's noisy as heck but the underlying audio (e.g. voice, music) will be audible under the noise. This lets you determine at least two things: the bitrate/sample rate of the audio, and where in the file the audio is. (I realize you've tried this - but maybe try listening very carefully to the noise!) – nneonneo Feb 12 at 1:00
  • 1
    I've used Audacity to convert a recording of the desired audio into a few different formats (with compression) to have something as a reference. Indeed, with some formats, the original audio can be recognized when playing back the raw data. Meanwhile, I have found out the audio actually comes from another IC... Must have been the cheapest option. – handle Feb 20 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.