I have a bluetooth speaker which announces interface events like "connected", "powering off". I want to silence these announcements. The way I thought of doing this is to get at the sound files that the speaker uses, and replacing/deleting that data.

I had earlier asked a question about extracting this data and using the advise received, I've managed to successfully extract the memory of this speaker.

I'm now trying to analyse the extracted binary and find the sound files. But I haven't been successful.

The extracted binary is here: https://drive.google.com/file/d/1e9yG8xMkZ331C2TOTOzo9Y93L4abxX9F/view?usp=sharing

The chip is XT25F08B. It's a 1 MB memory. I extracted the data over SPI0 and SPI3 interfaces multiple times (using an Arduino that i programmed for this purpose), and diff compared the outputs to ensure that I had the right data.

Also running strings command on the binary shows a long history of device names that I recognize as various phones / computers I use to connect to the speaker. This adds to my confidence that the extracted data isn't corrupted.

Looking at the binary in binvis.io shows:

enter image description here

There seem to be three chunks separated by unwritten memory.

According to binwalk(binwalk --disasm data.bin), the middle chunk (43KB starting at offset 991232) is ARM thumb code.

991232        0xF2000         ARM executable code, 16-bit (Thumb), little endian, at least 2500 valid instructions

This chunk is actually filled with the device name history. I'm not sure why this would be ARM code, because the processor for the speaker is ATS2815 which is an integrated bluetooth audio processor, and it's datasheet doesn't seem to indicate any type of relation to ARM architecture, but I'm not sure.

Binwalk also thinks the last chunk (4KB starting at 1044480 and ending at the final binary address) contains ARM code about half way through.

The first chunk though is totally opaque to me. See the entropy image (also binvis):

enter image description here

Clearly the first chunk is either encrypted or compressed. This is just a bluetooth speaker, what would you be protecting by encrypting though? Also the entropy isn't fully random, there are some subtle variations, indicating perhaps it's compressed. But I'm not sure.

Running binwalk -X data.bin seems to indicate that almost every second byte is a raw deflate compression stream!

41834         0xA36A          Raw deflate compression stream
41837         0xA36D          Raw deflate compression stream
41986         0xA402          Raw deflate compression stream
42290         0xA532          Raw deflate compression stream
42291         0xA533          Raw deflate compression stream
42300         0xA53C          Raw deflate compression stream
42510         0xA60E          Raw deflate compression stream
42543         0xA62F          Raw deflate compression stream
42758         0xA706          Raw deflate compression stream
42789         0xA725          Raw deflate compression stream
42920         0xA7A8          Raw deflate compression stream
42948         0xA7C4          Raw deflate compression stream
42967         0xA7D7          Raw deflate compression stream
43867         0xAB5B          Raw deflate compression stream
44226         0xACC2          Raw deflate compression stream

And this goes on to pretty much till the last address. Does this mean that the whole file is compressed? Surely not, there are raw strings in the binary, so that can't be true.

So maybe just the first chunk is compressed? But I haven't been able to decompress either. I've tried multiple methods to do so. gunzip, unlzma, zlib-flate, unxz on both data.bin and an extracted-first-chunk-only bin. But I end up with either "File format not recognized" or "Invalid header check" etc. errors.

I also tried disassembling the middle and last chunks. https://onlinedisassembler.com/odaweb/K2AmuJIN https://onlinedisassembler.com/odaweb/TcU2x8ZR

I chose arm as the architecture just to see, and you can see that the disassembly is peppered with " instruction: 0x...". Which likely means it's not the correct architecture and thus not the correct disassembly.

Where do I go from here? How do I penetrate the large opaque chunk of the binary. How do I decompress this? How do I disassemble the other chunks assuming they are code that the main processor loads.

Am I missing something obvious?

More than anything else though I'd like to get the sound files that the speaker uses. I'm certain they are in this binary data here, since there is no other memory chip in the device, and the processor itself doesn't have enough ROM to keep such data.

  • One thing you can try is importing the firmware into Audacity as raw data (trying different PCM formats). If the audio exists uncompressed (and lossless), you'll be able to listen to the firmware! Here's a similar question I had a while back reverseengineering.stackexchange.com/questions/22435/… – genghiskhan May 7 at 19:55
  • Hah. That got me excited! I went ahead and tried it, no dice unfortunately. – Capstone May 7 at 20:15
  • Too bad! Good luck on the project – genghiskhan May 7 at 20:28

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.