[:< ANDROID BLUETOOTH SNOOPERY -- UNROOTED! >:]
android_hax.2[hci_analysis]
Description
In this part we're going to start getting into the nitty-gritty of packet analysis, or at least how I ended up approaching it. This is going to be a higher end description of the process, so that even though your packets may be different, you can still follow along. My goal is to have a clear understanding of what these captured logs actually mean. Then hopefully assess if any of it is interesting. Interesting (to me) meaning anything that could possibly be perceived as sensitive / useful information (I should do a better job of defining this at some point).Materials
* android bluetooth hci logsWhat are Bluetooth HCI Logs?
If you're a bit tense at this point, it's okay! I find this to be the most nerve wracking part. "There's just too much information! Where do I start?". Just start. Start asking the questions, and start getting the answers. Progress is progress! So that's where we begin, a super simple question: what even is a Bluetooth HCI Log?Bluetooth
You likely already know what bluetooth is given your interest in this series, but just in case: bluetooth is, in essence, a short-range (2.402 Ghz to 2.48 Ghz range) wireless technology. It's basically a radio wave that's sending invisible data through the air. AKA magic. For our purposes, all we really need to know, is that it's a radio wave, that transmits over short distances (~33ft or 10 metres), and anyone can read / see them given the right receiver + software etc (more on this shortly). If you're curious to know more, wikipedia can be a good starting point, or you can check out the official bluetooth docs.
HCI (Host Controller Interface)
For this all you need to know is that HCI (Host Controller Interface) is a standardized Bluetooth interface for sending commands, receiving events, and for sending and receiving data. Texas Instrument has some really good documentation on this stuff. One of the docs is just on Capturing Bluetooth Host Controller Interface Logs, and it has some pretty good pictures I think, the other is just on HCI and vendor specific bluetooth low energy stuff which we'll be diving into shortly.
Log
AKA a list. A log file is typically just a list of events (in this case bluetooth packets), usually paired with dates and times, and other pertinent information. I may be getting way too granular with this definition here, but you never know. ¯\_(ツ)_/¯TL;DR
The Bluetooth HCI Snoop Log is a log file containing transmissions sent through the Android device.Reading Our Logs
In the last module we generated some logs, and extracted them into BTSNOOP.log. Now that we've got that, it's time to see what's in it. If we just run cat BTSNOOP.log, we'll see that the logs are pretty much illegible:
That's okay though, because we can use wireshark to read it!
Step 0: Download Wireshark
If you don't already have it installed you can follow wireshark's official download link and docs, or if you're running a debian based distro, you should be able to just run:sudo apt install wireshark
Now let's open this log up and read them: File -> Open,
then navigate to your file titled BTSNOOP.log, and it should open a screen that looks something like this:
Step 1: Getting Familiar w/ Wireshark
There are a lot of resources out there on using Wireshark, so I'm not going to go too in depth here, but at a glance you'll notice that the screen is plit into three parts:* Top:
On the top part we have a big ol' list of all our logs.
* Middle:
When you click on one of the logs in the top part, the middle part displays the beautiful parsing job wireshark has done. You can click on each of these labels (that demarcate different parts of the packet) to get the more in depth parsing of that section of the packet.
* Bottom:
You may have noticed that as you clicked the different sections in the middle, parts of this bottom part were getting highlighted. This is what's known as a "hex dump" representation of the data. Hexadecimal is a kind of encoding, where instead of representing data as binary (1s and 0s), we see it as base16, or hexadecimal values. These being 0-9, then a-f, where a-f represents the numbers 10-15. To the right of the hex values you may see some stuff you can actually read. This is the ASCII representation of the raw data. ASCII, which stands for American Standard Code for Information Interchange, is just a character representation of the numbers we see on the left. There's a whole chart you can reference, which displays what hex values correlate to what characters:
The wiki pages on hex and ASCII do a pretty good job of covering what you'll need to know for this project.
Given the above information, we can see that wireshark has done a lot of the heavy lifting for us. To get a sense of what I'm looking at, I'll choose a packet with some ASCII I can actually read. I saw that this one has the words Kuna companion in it. With a quick google search I find out that Kuna companion is actually a brand of security light. I'll take a look to see if that matches the information we see in wireshark by first, searching for Kuna companion in the middle section:
Sure enough, I can see that this is marked as the Device Name portion of the packet. Clicking around in the middle section I see that there's some more information to be derived. I can find the devices UUID, and there also seems to be a Flags field that seems interesting.
Flags are a series of binary true / false values, where 0 = false and 1 = true. Taking a look at this packet's flags, I can see that BR/EDR is not supported (BR/EDR being Bluetooth Basic Rate/Enhanced Data Rate), and it is currently in LE (low energy) discoverable mode.
With this information, and a quick glance at the top section:
I can see that this is an advertised, or openly broadcasted packet. With this information I'd say that this is a bluetooth packet that gets sent out every so often by a Kuna companion security light, which is checking to see if any devices want to connect to it.
Step 2: Looking at the Logs -- Anything Interesting?
Lets start by getting a quick overview of our data here. With a quick scroll of the top section I can see that my logs consist of two protocols: HCI_EVTs, and HCI_CMDs. The HCI_CMDs seem to happen less often, and it seems that they happen in clusters: they must be a timed command set that android runs intermittently, like the Kuna companion light checking for pairable devices. Cool! I also see that a huge portion of the packet information is marked as Rcvd LE Meta (LE Advertising Report), where as the cluster of commands have different information fields.As an aside, a big part of the research process here is finding consistencies and anomalies in data. If I can split the data into these two groups, it makes it a lot easier to find things that could be considered "interesting" in the data.
These clustered commands have peaked my interest, so I'm going to focus on them.
Step 3: Deep Dive
Beginning like we did earlier, I do a quick skim of the packets to see if there's anything in the ascii encoded view of the packet that I can read. Unfortunately, there's nothing in that department, so I take a look at the broader Info field in the top view...
and it stands out to me that there are some commands where the Vendor Command, and opcode are not specified, but are actually just hex values? Cool! Something wireshark doesn't seem to know.
This is the part where persistence is key. You may not find the documentation right away or at all, you may follow rabbit holes to dead ends, that's okay! After some digging I did stumble on this really helpful piece of source code! Referencing the above screenshot, I can see that the command 0xFD57 is for specifying the Android Bluetooth Low Energy Advertising Filter:
and that the opcode 157 is for specifying Read Clock...
Well that's a bit dissapointing; nothing too exciting. However, it is in line with what I'm seeing from the surrounding packets, which do have commands and opcodes that wireshark recognizes! Looks like these clustered command packets are just a scheduled series of commands between the host and controller that do things like, enable the low energy advertisement filter, and set extended scan parameters! The important part of taking the time to deep dive into this possible dead ends, is in the process build are intuition to what this bluetooth traffic looks like! Also, spending many painful ours searching for opcodes has a way of making me remember them! （ ´∀｀）
After another more thorough scan over the logs, I can see that it's just a bunch of repeats of the same stuff I've already looked into. Looking like nothing in here, but I've noticed that a lot of this stuff seems scheduled. This tells me that... maybe I just didn't wait long enough. Either way, I'm not seeing anything regarding the application I'm actually testing out.
At this point I see two options, and have a little research question for myself:
1. Generate more logs.
2. Reverse the actual application API to search for bluetooth related code.
Q: Does the bluetooth hci log actually capture all incoming and outgoing bluetooth packets?
I've actually answered this question for myself (by running btle sniffer in tandem with log captrues and diffing the files) the answer is:
NO
the android bluetooth hci log does not capture all inbound and outbound traffic! This is really good to know.
This means that inorder to get more verbose pcap I should be using my btle sniffer. More coming on this in part 3!