ELIF: How to / is it possible to create an integration based on sniffed communication between an Android app and a Bluetooth device?

Development
1

I found a single other topic asking something similar to this, and for a newbie on the IoT area like me, just stating “check wireshark” didn’t help much. Also, not sure if this is the best topic category, sorry in advance :sweat_smile:

I made the title to be as agnostic as possible, but my practical example is below, if extra context is needed.

Is it possible to use WireShark or similar apps to understand how the app communicates with the device and mimic it (maybe even be the main paired device)?
If so, what would be roughly the main steps, and/or the main problems found? I guess it circles around…

  1. what to use / how to sniff communication between the app and the device
  2. how to bootstrap a script to mimic that communication (I guess you’ll suggest some Python libs, so it can further be used inside HA)
  3. how to package whatever comes out of that to be used as a HA(CS) integration

I wonder if there’s encryption involved which would block understanding of those packets, among other complications which are placed for security but which also works for DIY obfuscation.

Context: I have a pet collar which stores information for a couple of days in it, until the manufacturer’s app is launched and a button is pressed - it will trigger communication with the collar and bring back activity details, such as timestamps where the pet was asleep or in activity, and some other stuff.
There’s a rough integration based on the manufacturer’s API, but as expected, it’s quite faulty and incomplete - for instance, it only brings the current activity level of the day for the moment I synchronized with the app, instead of a history of activity - if I sync at midnight, the value will mostly be zero, for instance haha

2

If you know the IP/port source/destination, you could set up a proxy to catch the traffic as I did for my pellet stove:

('tx: ', '\x1bRDC00069&')
('rx: ', '\x1bE5900043&')
('tx: ', '\x1bRC400059&')
('rx: ', '\x1b00000020&')
('tx: ', '\x1bRC50005A&')
('rx: ', '\x1b00000020&')

Which eventually led to my own integration (available in HACS)

1 Like
3

From the title, I assume this is about Bluetooth BLE, though, so the proxy trick would not apply. Furthermore, note that this will only work for unencrypted communication.

Maybe check “ble sniff wireshark”, then :wink:
Honestly, there is not much hope. A basic of any kind of security system is “non replayability”, specifically preventing you to hack through simply by replaying the same bytes.

All hope is not lost, though, as cheap device makers typically do not give a damn about security.
I did something similar, but I went the “decompile the android app” route, where I was lucky that the app was not obfuscated and I could reproduce at least some commands by reading the code.

1 Like
4

The easiest way is to use an esp32 and look at the ble component in esphome.

Example here Chinese bluetooth BBQ meat probe with ESP32

1 Like
5

Yeah, indeed non replayability makes a lot of sense.

I managed to, apparently, discover how to log bluetooth communication on my Android and how to extract that log, but in the end Wireshark found only 5 relevant packets (which mention the MAC for any of the two collars I have to test), all of them with 60 bytes only and no information that I could find relevant - they are among other packets of the same type, so there wasn’t anything useful before or after them. They’re attached in this Gist, if anyone find something useful on them.

Obviously, there are a LOT more stuff in the bth log, but I have no clue what to look for :man_shrugging:

6

Try this… How To Reverse Engineer A Bluetooth Device - YouTube

If your Bluetooth device comms are encrypted though, not sure there’s anything you can do this way.

7

AHA!

This is pretty much what I did before, but with two essential twists:

  • I didn’t know I was looking for the btatt / ATT protocol, this filters up a LOT of stuff in Wireshark
  • I tried this time with a second (older) device, which
    1. actually shows ATT commands on the logs I was able to get (my main device didn’t?)
    2. I can use live wireshark with, making it much easier to identify exactly the operation I just triggered

As a sample for future Igor (got no time for deep fiddling now), here’s a packet that triggers the sound locator on one of the collars:
image