Help me extract/replace some audio hidden somewhere inside a SPI flash chip

[Psi]

So i have this Bluetooth Audio receiver/transmitter but it has an annoying Chinese woman who keeps saying
"Bluetooth Connected"
"Low Battery"
etc..
And for my intended application this is undesirable.

I would really like to pull all those audio blocks out of the thing, maybe replace them with silence or a beep.

The device uses a JYD8860 Bluetooth chip - I cant see much info on this but i'm guessing its a MCU+bluetooth radio IC.

It also has a P25Q80H 8Mbit SPI flash chip, which is what interests me.

I figured it would most likely be storing some raw audio samples in the SPI flash chip somewhere and that i could simply zero them out.
However i just dumped the SPI flash (attached below) and i now suspect 2 things.
- The SPI flash chip is also being used for some firmware or at the very least Bluetooth pairing data.
- The files are in MP3 format, because i found what looks like arrays of MP3 filenames inside the dump.

Code: [Select]

..\..\platform\resource\di_cn.mp3..\..\platform\resource\di_cn.mp3..\..\platform\resource\pairing_cn.mp3
..\..\platform\resource\connected_cn.mp3..\..\platform\resource\linein_cn.mp3..\..\platform\resource\charging_cn.mp3
..\..\platform\resource\chargeok_cn.mp3..\..\platform\resource\lowpower_cn.mp3..\..\platform\resource\lowestpower_cn.mp3
..\..\platform\resource\zero_cn.mp3..\..\platform\resource\one_cn.mp3..\..\platform\resource\two_cn.mp3
..\..\platform\resource\three_cn.mp3..\..\platform\resource\four_cn.mp3..\..\platform\resource\five_cn.mp3
..\..\platform\resource\six_cn.mp3..\..\platform\resource\seven_cn.mp3..\..\platform\resource\eight_cn.mp3
..\..\platform\resource\nine_cn.mp3..\..\platform\resource\du_cn.mp3..\..\platform\resource\di_cn.mp3


Does anyone have any helpful tips/tricks to figure out where the MP3 data blocks start/stop within the file?
They don't look to have an ID3 tags


P25Q80H  Datasheet here
http://www.puyasemi.com/uploadfiles/2018/08/201808071525322532.pdf

[ruffy91]

File Magic for MP3 without ID3 Tags is 0xff 0xfb.
You should then be able to find the frames and confirm they are indeed the searched for mp3 by looking at the headers.
If they are files with names probably there is also a filesystem which you can mount and just replace them with empty files or even other soundfiles.

[GromBeestje]

You can look for MPEG frame headers, they begin a synchronisation of 11 bits consecutive bits set to 1 .

See https://www.mp3-tech.org/programmer/frame_header.html  for some more trails

[ogden]

Starting from 0000059CC0 there's 24 data structures, 16 bytes each. Immediately after mentioned data structure array, at 0000059E40, list of 24 .mp3 file name cstrings follows. Most likely not coincidence. Each structure contains 4 entries, 4 bytes (unsigned long) each. First seems to be ID counting (0, 1, 2, 3....), next seems to be offset from first byte of chargeok_cn.mp3 wherever it is located, then it may be length (samples? bytes?) of recording, then there's pointer to cstring of the name. First hack to try - shorten length, set something like 100 for all mp3's, see what happens. If it works then edit length as needed. First 4 entries of structure and name list:

Code: [Select]

0000059CC0: 00 00 00 00 00 00 00 00 ? A2 36 00 00 40 AE 24 00
0000059CD0: 01 00 00 00 00 37 00 00 ? 62 2D 00 00 50 AE 24 00
0000059CE0: 02 00 00 00 00 65 00 00 ? C8 2A 00 00 60 AE 24 00
0000059CF0: 03 00 00 00 00 90 00 00 ? 5C 06 00 00 71 AE 24 00

0000059E40: 63 68 61 72 67 65 6F 6B ? 5F 63 6E 2E 6D 70 33 00  chargeok_cn.mp3
0000059E50: 63 68 61 72 67 69 6E 67 ? 5F 63 6E 2E 6D 70 33 00  charging_cn.mp3
0000059E60: 63 6F 6E 6E 65 63 74 65 ? 64 5F 63 6E 2E 6D 70 33  connected_cn.mp3
0000059E70: 00 64 69 5F 63 6E 2E 6D ? 70 33 00 64 75 5F 63 6E   di_cn.mp3 du_cn

[amyk]

- The files are in MP3 format, because i found what looks like arrays of MP3 filenames inside the dump.

I suspect not --- those are the just the names of the original files used to build the firmware.

Near the start of the file I can see a few blocks of data with a certain "texture" to it --- like these:

Code: [Select]

00030800:  BB BB BD DD-DD DD DE EE-EE EE EF 77-77 77 77 BB
00030810:  BB BB BB DD-DD DD DD EE-EE EE EE F7-77 77 77 7B
00030820:  BB BB BB BD-DD DD DD DE-EE EE EE EF-77 77 77 77
00030830:  BB BB BB BB-DD DD DD DD-EE EE EE EE-F7 77 77 77Each one has a prefix of "9C 31 21" which I didn't recognise at first, but the texture of the data feels a bit like a low bitrate audio codec.

The block offsets do line up with the second dords of the structure in the table ogden found --- first one is at 10200, next one is 13900 (10200 + 3700), then 16700 (10200 + 6500), etc. The length of the first block is 36A2, which is the third dord in the structure.

A little more digging at what Bluetooth-specific audio codecs exist reveals that the data is likely to be encoded with SBC.

[daqq]

I'm not sure that the data will be compressed - decoding MP3 or similar takes a fair amount of resources that stuff like low power Bluetooth ICs might not have.

At 0x592B0 you will find this:

wav instance malloc false!  wav dac open!   wav set signal failed!  wavout open id: wavout invalided id!    wav da set info, sp:%d, ch:%d, bps:%d
  wav dac not opened! wavout invalided Func!  wavout connect failed!  wavout set gain invalied id!    wavout cur_wav_info.cur_

Though there are also strings for MP4, OGG vorbis and MP3.

See 0x83150. That looks like raw wave data maybe (it differs from the last 'sample' by a very small value).

[Psi]

Thanks guys/gals!

I have tried playing the entire raw file in various uncompressed sample formats.
mono/stereo
8/16
unsigned/signed
pcm/u-law

It's mostly just digital noise, Nothing that jumps out as sounding like a form of uncompressed audio.
So whatever it is, i think its compressed.

But i think Amyk will be right, it's going to be some audio codec that the bluetooth stack in the main IC can decompress.

[amyk]

It's SBC.

Attached are the extracted bitstreams and their decoded versions, as well as an SBC decoder and encoder (from the BlueTooth A2DP spec, the full package is at the bottom of https://habr.com/en/post/456182/ .)

[Psi]

Awesome!  Thanks Amyk

[Psi]

Success!!

I did what ogden suggested.

I changed the sample length in the index table to about 1/2 and re-flashed the chip to see if it would only play some of the sounds.
It worked perfectly.

So now I'm changing them all to something really small so it only plays a few ms.
I could try 0 but that might mess up the logic, it probably expects there to be something to play.
The files all start with like 100ms of silence anyway. So i doubt it will mater.

[BravoV]

Bookmarked, congrats n thanks for sharing.

[Psi]

Here's the details. In case anyone else wants to copy what i did.

The BT audio device is a cheap china one. Excelvan Bluetooth RT-B6 Adapter
It can do BT audio receive or transmit (i've only tried the receiver part)

Here is a link to what i bought
https://www.aliexpress.com/item/32973972999.html

I have attached my patched SPI flash bin file below, it will probably work on other units too.
Although, there could be some sort of BLE mac or identifier that links the main controller IC to the SPI pairing data.
Your mileage may vary.

[amyk]

Yes, MAC and other config is probably saved in the flash.

It also opens up the possibilty of changing the voices to something else more "interesting", as long as they fit inside the flash.

Article with detailed teardown and inspection (Russian): https://mysku.ru/blog/china-stores/55754.html

This is the actual manufacturer: http://www.soeasy188.com/2016/ezcast_0504/16.html

The JYD8860 may be a clone of the common CSR8670 --- maybe tools for the latter may work for the former.

[Psi]

It also opens up the possibilty of changing the voices to something else more "interesting", as long as they fit inside the flash.

Yes, i considered trying that, it should work fine. Just a bit more effort.
For shorter audio clips than what was there ya can just set the length value to match.

Might also be able to write an oversize recording and overwrite the recordings stored after it in flash.
A lot of the sounds stored in the SPI flash are in Chinese and i have never actually heard the unit play them. So they're effectively not used.
If the slot after the one you want to change is in Chinese you can probably overwrite it and adjust the length accordingly.