All posts for the month September, 2016

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

Inspired by fellow SkullSpace member Edwin, who utilised a bus pirate to re-write the bluetooth device name via EEPROM (Note – this is indeed the right tool for the job) I took the initiative to get it done similarly, with my trusty Arduino Uno and some light coding.

Now, the neat thing about I2C is that it’s multi-master capable; at least, the bus is designed to be such.  This means that we can interface the EEPROM without disconnecting the usual master (ie the bluetooth IC).  So in short, you don’t need to lift the pins on your EEPROM, and toast the thing in the process:


Unfortunately I forgot about this design feature, and spent quite a bit of time trying to read this IC from the arduino. It wasn’t until I took the same method to my second Bluetooth device that I realised that the first was toasted:


After hacking a few devices (into oblivion), you eventually learn you should buy more than one…. this time around I added a terminal block and hot glue for stability

With that all wired up, I connected my arduino and started testing that I could read EEPROM addresses:



It turns out that the “AB Shutter” device name was not where I expected it to be, based on my binary image – the most likely explanation is that my binary processing program is buggy 🙂  So, undeterred, I wrote a little arduino sketch that searched through the EEPROM’s memory byte-by-byte for a simple “AB” pattern (the first two characters of the device name).  Interestingly, “AB Shutter” shows up at 0x3B44 and 0x5B44.  This is the sketch I used:


Then, knowing the address, I wrote another little sketch to over-write that address space, and confirm it by reading it back.  I wrote to 0x3B44, and it reads back correctly from both 0x3B44 and 0x5B44, suggesting some paging or mirroring going on:

And, lo and behold, my PC picked it up with the new name!….almost:


The trailing ” 3″ is part of the old name – I tried over-writing it, with no success.  Perhaps there is some paging mechanism I am not taking into account 🙂


Next steps include searching through the memory via arduino sketches, and attempting to locate where it stores its keyboard “key codes”, if at all.  This would let me change which keys are sent to the PC/smartphone, at least in theory. Stay tuned!

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
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!


I was able to squeeze in a tiny terminal header to break out the TX/RX solder pads


Pro tip – you can pop the Atmel IC out of an arduino board, and you have a simple USB <-> TTL RS232 bridge



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!

Ah, the dollar store – risky condoms, something labelled as mustard, and every permutation of pastey-looking, thin-plastic discharge courtesy of third-world prisons factories all line the utilitarian wire-shelves; How do our capitalist overlords tolerate such thrift?  Just how much nausea-ketchup must one purchase to turn a profit at $1/bottle?  I don’t even care to know, because I’m too busy ogling the most modern dollar store trinket yet(?); this Bluetooth camera shutter!




This things works right out of the box – but that’s boring, because that’s what we expected it to do (actually, I didn’t even expect it to do that.)  I decided to take this thing to SkullSpace (my local hackerspace) to see what makes this zany device tick –  this three-dollar chunk of plastic that wirelessly talks to my cell phone!?

20160904_183253See those two lines coming from the large chip to the small chip?  Yup, thats an I2C bus!  Googling the part number (RDA5871 ) reveals that the larger chip is a bluetooth IC with an integrated ARM core, and the smaller one is ostensibly a configuration ROM.  After connecting our handy logic analyser and twiddling with the I2C settings, I was able to get a log of all the data being read from the smaller chip:


saleae_log (text file, output from Saelae logic)


Lo and behold, searching through the text file for the Bluetooth name – “AB Shutter”, we find it:



1.363374400000000,7,’161′,’ ‘,Read,ACK
1.363564800000000,7,’161′,’ ‘,Read,ACK


Looks like we are reading the chip correctly!  I noticed the above block is one giant read (about 6.8kB) starting from ROM address 0x0228 – We see two writes to address 160, the data of which is 0x0228.  This is a typical I2C EEPROM “Start reading data from here” command.   The device then spits out consecutive bytes, starting from the supplied address, on every read.   I carved out the relevant 6.8k read manually, and used awk to extract the “read” column.  Then, I used this simple python script to convert the decimal “read data” output into a binary file (note – I had to change the csv data from ASCII to decimal in Saleae Logic):

test_out (Arbitrary extension, just binary data)

But what is this file?  Is it an ARM binary? I have no idea!  I was hopeful that the device was reading a full firmware image directly from the I2C ROM, but I cannot find any indication of such (yet).  I have tried looking at earlier reads in the I2C transactions to discern any kind of header information, but nothing was obvious – I’ve tried pointing the file command at it to determine it’s type via magic bytes, and I’ve also tried running it through various ARM dissemblers with no luck.

I did manage to find this defunct google code page regarding the RDA5871, and I am happy to report that the previous maintainer has replied to my random emails with some documentation on how to configure the device via ROM!  I am hopeful to get this pointed at the mystery file dump that I have.   The only hurdle is that the document is primarily in chinese, so stay tuned for when I wrangle together a translation –  for any of you willing to take a gander, here it is: rda5871_progguide