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:
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.
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
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):
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.
