Hacking a Dollar Store Bluetooth Device

Hardware hackers are always looking for devices to tear apart and scavenge from. It’s hardly a secret that purchasing components individually is significantly more expensive than the minuscule cost per unit that goes along with mass manufacturing. Bluetooth devices are no exception. Sure, they’re not exactly a luxury purchase anymore, but they’re still not dirt cheap either.

Luckily for [Troy Denton], it seems dollar stores have started carrying a Bluetooth camera shutter for just a few dollars (it was three bucks, perhaps the dollar store actually means divisible-by). The device is designed to pair with a smart phone, and has two buttons allowing you to control the camera from afar. The fact that it works at all at that price is a small miracle, but the device also has potential for hacking that adds to its appeal.

Inside is a Bluetooth chips with integrated ARM controller. It connects to an EEPROM via I2C. Using an oscilloscope, an Arduino, and a Bus Pirate, [Troy] has so far succeeded in dumping and deciphering the EEPROM and was successful in renaming the device. He has high hopes that he’ll be able to discover something juicy from his preliminary explorations of the USART on the Bluetooth chip.

Ultimately he plans to document his quest to rewrite which keys the device’s buttons emulate. Once that’s accomplished, this dollar store find will have a lot of potential for cheap Bluetooth control. If you’re a reverse engineering veteran we’d love to hear some suggestions of low hanging fruit for him to explore. If you’re eager to learn more about about what you can do with Bluetooth, check out our awesome BLE primer.

45 thoughts on “Hacking a Dollar Store Bluetooth Device

    1. I knew it was a HID device, way hoping to use it to convert a folding palm keyboard to bluetooth. Found the stuff he found.

      Also was kind of thinking of it as having the potential to be kind of like a nano with bluetooth, i/o limited though.

  1. I found mine at 5 Below. Bought it with hopes that pairing it with my computer it’d send a keystroke, which it does. Was able to map it to my python script to help do my store’s inventory with.

  2. i think i saw something similar at Dollar Tree but i ignored it assuming it was the type that used the headphone connector. I’ll check there again sometime, hopefully it’s the bluetooth kind.

  3. I looked at the provided dump from the eeprom

    looks like it is the patch ram for the bt chip
    structure seems to me:
    u32 magic
    u32 num_entries
    u32 patch_addrs[num_entries]
    u8 padding[up to 0xb0]
    …patch code here

    instruction set appears to be ARMv4

    1. Yeah, Just looking at the shape of the data, after the first 32-bits from 0x05 up-to 0xb0 could be considered 32-bit integer quantities with the (little-endian) MSB set to 0. The final of those 32-bit quantities is 0x00000000.

      Then the 0xff padding from 0x90 to 0xaf. Then from 0xb0 up-to 0x1ff are 64-bit quantities in the form [04 f0 1f e5 XX YY ZZ 00], where XX and YY can be pretty varied, but ZZ is always in the range [ 00 – 03 ]. Maybe the first 32-bits are an opcode and the last 32 are an integer quantity?

      The rest looks like it’s 32-bit aligned (Lots of 0x34X bytes in the last byte of these groups), up-to 0x18f8 where there are 5 repetitions of the 64-bit patten [ 0x58 0x71 0x00 NN 0x00 NN 0x00 0x00 ] – Where NN is _mostly_ a 1-up, except for the first group where one of the 2 copies is 0x00.

      Then there’s the string “AB Shutter 3\0\0\0”.

      Then it’s finally padded-out with 0xff values to the end at 0x1b00.

  4. I’ve tried walking the dump, no luck. Been working with Troy on this over at SkullSpace (Winnipeg’s hackerspace). C code for walking as well as my firmware dumps from two different bluetooth devices can be found here:

    If anyone wants to lend a hand, find us on the Facebook page for SkullSpace if you’re into the social media thing.

    1. Awesome, keep up the good work.

      I was wondering if the serial output might get defaulted to a console, monitor or debugger if something like this was tried… http://hackaday.com/2016/08/08/pwning-with-sewing-needles/ in spirit, i.e. corrupting the output from the eprom or disconnecting it from I2C (Try it on the one that the ROM got killed, or is that behaving 100% dead now?)

      The 5871 has some ROM in it, so I’m assuming there’s some basic functions happening without the code in the 8 pin.

      1. There’s actually a ROM tool called Mix. Look for it on the Google Code or Plex sites. I had no luck. These devices also have the write-protect line high, so you have to snap it off.

        I’ve renamed mine, but I wasn’t able to find make/break codes.

        I think me and Troy are going to try decompiling the data section this weekend as he’s got more assembly skills than I do.

        If anyone wants to be added to SkullSpace’s Slack, e-mail me at edwknguy@gmail.com with the subject “SkullSpace Bluetooth”

  5. Spot on with the “divisible by” comment!
    If you pay more than a dollar for something, is it really still a dollar store?

    If a dollar store is not defined by the price of $1 and less, what’s the difference between a dollar store and every other store?

  6. If you’re in the UK, try looking in “Poundworld”, which is where I found mine. Can’t yet get it working with a Raspberry Pi, although it does work as a selfie button with a suitable phone app.

      1. Aha! If it’s the same as the one I bought, it’s not bluetooth. It’s actually a microcontroller that plays a high frequency audio tone pattern, which is then picked up by the microphone of the smartphone to trigger the camera shutter, which is why it needs a separate app. YMMV, but I could actually hear the tone mine made and confirmed it by capturing the audio signal.

  7. We have them here as well as one with zoom in and zoom out.
    I looked at the doc. he was talking about. and google translate seem to have no problems converting it to english.
    I have no time to do this or I would of.
    Im going to keep a eye on this one. this sounds like gold to me.
    Thanks great work.

  8. Just remember the dollar store also sells rechargeable usb batteries that explode and 2 GB usb sticks that don’t work, so be sure whatever you test your DS finds with you’re not too attached to.

  9. Picked up a couple at Dollarama. Same store, same packaging, but grabbed different coloured cases–the white-cased one has the same blue PCB, but another with a green case has a larger, green PCB. The green PCB uses a RDA-branded 5871 (white case is not branded). It also uses a 24c64 EEPROM, a different brand/package though.

    1. It is, the bluetooth suite provided by Jabra for their USB dongle I bought a few years ago spoiled me. But it was on windowsXP. Every other implementation on desktop windows has pissed me off. The strange thing is that what was used on windows CE/Mobile was quite workable, not super polished, but got the job done. I am actually unsure if the installed bluetooth on my laptop is working, win8/10 interfaces to it being so appalling.

    1. Is there any central place with hacking info on these?

      I’m REALLY hoping someone will find a way to make one of these into a pokemon go plus. I know there are a few projects on the pokemon go front, being able to use the hardware from one of these would be brilliant.

      1. The main task would be to find out what BT device sends to the connected phone and where that data resides.
        Here’s a link for SDK : https://5871e.codeplex.com/ you can compile it with ARM toolchain. The SDK also contains some tools to create binary EEPROM flashable, more on this later.

        See my last comment, I posted a link to entire EEPROM dump. This is what I’ve understood after reading the docs and comparing it with EEPROM.
        1) starting 8 bytes are information head. (This is what blogger also found).
        2) starting two bytes are used for chip validation, if you change those values then the device won’t work.

        Then there is a section of config values which configures the how BT device would interact with its host:
        _config_eeprom_lowPowerInit
        _config_eeprom_lowPowerToggle
        _config_eeprom_scaninit
        _config_eeprom_scanToggle
        _config_eeprom_linkeyAddr
        _config_eeprom_scanDuration
        _config_eeprom_testDebug
        _config_eeprom_sniffAttmpt
        _config_eeprom_sniffTimeout
        _config_eeprom_ioCapability
        _config_eeprom_sleepTime

        3) At address 0xD4 (see EEPROM dump), the value 0x1C indicates sleep time of the device.

        4) The next byte at address 0xD5 indicates the ioCapabilty of BT device. This link explains what is ioCapability in detail :http://blog.bluetooth.com/bluetooth-pairing-part-1-pairing-feature-exchange/, the default value is 0x02 which is the value for ‘KeyboardOnly’. If you change that to 0x04 it will ask for pairing key.

        5) There is also a byte for variable _config_eeprom_testdebug which has 6 different config values:
        HID_DEBUG_UART 0x01
        HID_DEBUG_CUSTOMER 0x02
        HID_DEBUG_SLEEP 0x04
        HID_DEBUG_LOW_POWER 0x08
        HID_DEBUG_SNIFF_3 0x010
        HID_DEBUG_SPP 0x020
        These are defined in the header files in the src folder of SDK.

        6) From address 0x15E to 0x12B, the entire block holds the data under name ‘SDP keyboard descriptor’. I tried to zero-out the entire block but nothing happened.

        7) From the address 0x1FB0, next 6 bytes is the MAC address of the BT device. Changing these values would change the MAC.

        8) The values at 0x1FC0 to 0x1FD9 are unique for each BT device. (I tested 3 BT devices). So my guess is they are the data for pairing keys.

        This is all I found in the EEPROM dump. I also connected the Arduino to UART interface as the blogger did. All I got is the 4 digits ‘4314’, I’m not sure what they mean, but if you see the source code there’s a function called p_spp_rx_ack which sends some data to UART lines. So it could be the those ACK values ( I stand to be corrected) which BT send when it finishes the EEPROM reading.

        Finally, as I said earlier, there’s a tool called MIX_SDK_toolset which converts .pac files which are available in a folder called ‘pac’. into an EEPROM flashable .bin files. You can open this files in Hex editor and see the contents.

        .There also a section in EEPROM called ‘data’ in which vendor specific data resides. Unfortunately, I couldn’t find what exact data BT sends to the Host device.

        For fun, I had made a Python script which lets you control LED using BT device. link: https://www.hackster.io/adikhandkar/selfie-blink-control-leds-using-selfie-bluetooth-remote-93558e

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s