Hacking Dollar-Store Bluetooth Devices (The Kindness of Strangers) part 2

This is a continuation of “Hacking Dollar-Store Bluetooth Devices (The Kindness of Strangers) part 1”

After putting the EEPROM programming document (rda5871_progguide) through google translate, I was able to discern the format of this mysterious binary dump I had created – I created a simple program to parse the Saleae log file (saleae_log) into one contiguous binary image (binary_image – extension is just to get around wordpress, it’s binary) and parse the info header as well as  some of the configuration data (hopefully).

However, the data I got back was pretty trivial:

Parsing info header…
**************
Chip ID: 0x5873
Version: 6.4
PSKey Length: 532
Data Length: 6912
PSKey: SYS_CONFIG_ID_NULL
Length: 0
Data: {}

This at least provided a sanity check against the info header format – the Chip ID matches what is laid out in the guide.  But, none of the datasheet’s “PSKey” information located at 0x88 seems to be used – just 532 bytes of “SYS_CONFIG_ID_NULL” and zero-length data blocks.  As well, the ISR code regions described seem to reside well out of the memory range of the binary dump – e.g. 0x80006880 – so it appears I am no further along in the binary image, pending further ingenuity…

 

But then I noticed some clearly labelled serial connections!

20160911_115417
I was able to squeeze in a tiny terminal header to break out the TX/RX solder pads
20160911_120627
Pro tip – you can pop the Atmel IC out of an arduino board, and you have a simple USB <-> TTL RS232 bridge

20160911_125657

 

I was able to discern from my ‘scope that the data was transmitting at a line discipline of 115200 Baud 8N1 – however, the data that it spat back at me was indecipherable.  Consistent, but gibberish.  I had some hopes that it was unicode / chinese characters, but this was quickly ruled out (unless this serial prompt also uses arabic…).  If I had to guess, this is some binary debug and/or manufacturing automation output.  Oh well.

I also noticed that the device would pair to my PC as a USB keyboard – it ends up sending a “Volume up” keystroke and a “Enter” keystroke between the two buttons.  I was hopeful that the EEPROM image would contain the keycodes for these, allowing us to change it’s behaviour, but I was unable to find such.

My next step will be to selectively write some of the EEPROM data & (hopefully) change the device’s name – stay tuned!