In this Article we will learn about Hacking a Smart Bulb with Bluetooth.
Let’s get started.
Hacking a Smart Bulb with Bluetooth
Short Primer on CSR – In this section we will learn a little about CSR and how it interacts with the bulb to give you an idea of how we can connect and interact with the bulb using CSR.
As said above, the CSR is like a USB, so we plug it into the laptop. First, we will have to check if the laptop detects the CSR dongle or not. This can be checked using hciconfig command as below –
Above is the result obtained when the CSR is not connected to the laptop. hci0 is the laptop’s default Bluetooth interface.
Above is the result obtained when connecting the CSR to the laptop. hci1 is the new interface obtained by connecting the CSR to the laptop. So our dongle was detected by the laptop.
Next step – Connection to the light bulb
Whenever we want to connect to any device via Bluetooth, we first turn on the Bluetooth of our device. We have already turned on the Bluetooth of our laptop.
Now we will need to search for available Bluetooth devices. In our case, the laptop will search for Bulb using the dongle. For this we will use the following command – sudo hcitool lescan
lescan will search for available Bluetooth devices nearby as shown below –
As above we got the MAC address of the bulb – F4:B8:5E:E2:BA:E9
Now we can connect to the bulb using the following command – sudo gatttool –I –b device_mac_address
Command Explanation –
-I à make the connection interactive
-b à specifying the mac address of the device.
The screenshot for the same is given below –
If you look at the screenshot above, in the second line I wrote connect to connect to the bulb. The last line (blue color) shows that we have successfully connected to the bulb.
Now let’s look at the services and features of the bulb. To list services and characteristics, we use ‘primary’ and ‘characteristics’ commands as below −
As seen above, the bulb has four services and 21 characteristics. If we read primary services, the 1st service starts from handle (attr handle) 0x0001 and ends at handle (end grp handle) 0x000b. You might think that the start value is 0x0001 and the end value is 0x000b. What about values between 0x0001 and 0x000b??? Right??
If you recall we discussed service and characteristics and I said that there are different characteristics within services. So the missing values between 0x0001 and 0x000b are the different characteristics that the bulb offers. You can verify the same by reading the output of the characteristics command. If you look at it, we can see 0x0002, 0x0004 to 0x000a. 0x000a should be followed by 0x000b, but what we have is 0x000d. Where is 0x000b and 0x000c?
Look at the output of the primary command. You will see 0x000b (end grp handle) and 0x000c (attr handle). So 0x000b is the value at which the 1st primary service ends and at 0x000c the second primary service begins.
From this we deduce – 1st primary service starts at 0x0001 and ends at 0x000b and has five characteristics starting at 0x0002 and ending at 0x000a.
Similarly, we can specify other services and their properties that the bulb uses.
Handle – Each service and property has a unique field called Handle. A handle is a unique identifier to identify a service or property. So all services and characteristics are referenced using a handle. Also, if we want to write or change the value of any characteristic, we need to identify a handle for it and write or read the value using the particular handle value.
The most important point – Some services and characteristics are predefined by the Bluetooth SIG and are implemented in the same way as in IoT devices. Some services and features are implemented by the vendor in their device. Now the question is what should you do when you are testing an IoT device. You can either use predefined Bluetooth SIG services, or you can use vendor-defined services. Right??
If you abuse the predefined services, the seller is not responsible for it and simply asks us to report it to the SIG, because it has nothing to do with the predefined services and also cannot fix it. Therefore, you should always use the services defined by the supplier
Now the next question is – how to identify vendor services and predefined services?
Just look at the output of the characteristic command in the screenshot above – If you read the value of the “uuid” field, some of the values are 0000fff1, 0000fff2….0000fff6. The rule is – For vendor-specific characteristics, values should always start with ‘f’, i.e. the series 0000f***. So if you come across values starting with “f”, you should be aware that this is a vendor specific property and we only need to use those properties. I hope it is crystal clear to identify the vendor and SIG specific characteristics.
About the light bulb –
The bulb is a smart bulb from Reos. It can be controlled using a mobile app called “Reos Lite”. The mobile app allows the user to change the color, receive notifications and change the bulb to different modes. The sample image of the light bulb and the mobile app are given below –
Now I’m going to communicate with the bulb using an Android app via Bluetooth. At the same time – all interaction between the light bulb and the mobile phone is automatically recorded and saved to the mobile phone.
The first step is to connect to the light bulb. For this the mobile should be Bluetooth enabled and then we will connect our mobile to the Bulb through the mobile app as below –
As seen we are connected to the bulb, and the name is “Lite-1”.
Now I am changing the color of the bulb. Sample pictures for the same are shown below –
This was just a small overview of the interaction of the light bulb and the mobile application.
Exploitation – This is where the mining part begins:
From this point we changed the color of the bulb and I captured the Bluetooth packet and transferred it to my computer.
Now I use Wireshark to open the log file as shown –
There were about 650-700 packets. Analyzing all of them was not an easy task at all. I was looking for a specific packet that wrote data to the bulb. By data I mean the color change of the light bulb in our case.
This is what I did –
If we look at the protocol column, there are three protocols – HCI_EVT, HCI_CMD and ATT. I just googled their functionality and found that only the ATT protocol is used to write data to the bulb, while the other two protocols are used as the Host Controller Interface (HCI). That’s the only information I needed, and I quickly realized that I needed to go through the ATT packets.
A sample ATT packet is given below –
I’ve highlighted a few things in the diagram above. Starting from the top – The first highlighted part is the write from localhost (mobile) to remote (bulb) command. If we read the Info column – we see something called handle and the value for handle is 0x002b. It means the mobile application has written something to handle 0x002b. In the above section, we used a mobile app to change the color of the light bulb. So we can say that we refer to handle 0x002b to change the color of the bulb.
Now we come to the third highlighted part – we see a field called Value and the value of the “Value” field is something 0f0d03…….
What we understand is – the value 0f0d03…… was used on handle 0x002b to change the color of the bulb. Similarly, I looped through the other ATT packets and created a list of the “Value” field as shown below –
Now we have the values of the “Value” field and the handle with us, what we can do is simply replay the packet. We can use different tools to play the packet but we will use Bluetooth CSR as mentioned above. We also need the handle value to change the color which is 0x002b as shown above.
Now I have connected the CSR to the laptop and I can change the bulb color by typing the following command – value char-write-req handle_value
handle_value – is the handle value
value – the value to change the color.
The same was shown in the below screenshot –
As seen above, just enter the handle i.e. 0x002b and the ‘value field’ value to change the color of the bulb as shown below –