Hijacking Your Home IoT Appliance, part 1
Last year I bought this cool new Heater for the winter that had WiFi connectivity. At first I thought it was pretty cool that I could control it from my phone, but the App was very limited and I could only turn it on, off, and set the temperature. I always thought there could be much more done on these devices with the right hack, for example to schedule when you want the device to turn on/off, to set the heating power based on the temperature in the house, or to turn on and off the heater when I enter and leave the house.
In this article, I’ll try to explain how these devices connect, how the protocol in which they communicate works, and lastly how to hijack them and configure them for your own projects.
My configuration
- Heater with WiFi connectivity
- WiFi Router that you can manage, hopefully with DD-WRT or DNS server
- Raspberry Pi
- A Laptop with Wireshark installed on it.
Understanding how IoT appliances communicate
In this article I don’t pretend to explain this technology in depth, since there are plenty of information out there that does a better job at it, so I’ll basically just go only a bit over this.
Most devices talk to each other using a protocol called MQTT (Message Queue Telemetry Transport) that sits on top of the TCP transfer protocol, and works by doing what is called a publish-subscribe messaging method.
MQTT works in a star network type of topology, in which at the middle you have a MQTT Broker, which handles subscriptions and delivers published messages to each of the subscribers connected to it.
Sample Topology
IoT devices have two different implementations of MQTT, one of them is MQTT Direct, which is the most simple implementation, and the second one is MQTT over Websockets, which it could be more secure since it can use certificates for authenticating a connection, and also, for some corporate environments, wrapping protocols over Websockets allows them to travel outbound when there are very restrictive firewalls.
For our experiment, we will cover the use of MQTT Direct.
MQTT Direct
In MQTT Direct, you have a MQTT Broker listening on port 1883, and the subscribers which are all of the IoT devices that are connected to this network, plus all servers that could be listening for messages for logging or reporting purposes.
When a device subscribes to the broker, it does it by passing its Client Id and the Topic to which it wants to listen to. Optionally, the device can also authenticate using a user and password. In the same manner, the publisher connects to the broker with its Client Id and the Topic to which it wants to publish the message. Understand the topic as a “channel”, a mechanism to organize all of the messages traveling back and forth through the network.
Enough information on MQTT, please browse the Web for further information on the protocol.
My Network Topology
Analyzing and Dissecting an Actual IoT Communication
To analyze the connection we are going to use Wireshark on a laptop, and tcpdump on a Raspberry Pi and/or Router.
Since we just want to hack our home appliance in our home network, we can just access our Wifi Access Point through telnet or ssh and use tcpdump to sniff every single packet that the Heater (our IoT device) sends to the manufacturer’s cloud.
Let’s fire up tcpdump to get all the traffic between the appliance and the router.
# tcpdump -i br0 -s 65535 host 192.168.1.106 -w dump.pcapThis command will sniff all the data going to and from the IP 192.168.1.106 (or heater or home IoT appliance) and save it into the file dump.pcap. We will later read this file using Wireshark, which will allow us to analyze better the traffic.
When we open up the dump file using Wireshark we see the following:
The image above shows us all the connections coming to and originating from the appliance, we see DHCP connections, as well as DNS, and MQTT.
This tells us that first the appliance tried to get an IP from the router, which DHCP assigned it the IP 192.168.1.106. Secondly, the appliance tried to “phone home” by connecting to the manufacturer’s cloud hostname: mq.gw.tuyaus.com which resolved to 54.68.252.52.
Understanding the MQTT communication
As we saw earlier on this article, on a standard MQTT connection there is a: Command CONNECT, after this is acknowledged, there is SUBSCRIBE command to a specific topic, and later all published messages will show through a Publish message received. Let’s see how this looks on Wireshark.
If we dig deeper we will understand exactly how the appliance is talking to its manufacturer’s server, and find out how we could later control it on our own.
Connect Command:
This is the packet capture for the record number 26 on the screenshot.
MQ Telemetry Transport ProtocolConnect Command0001 0000 = Header Flags: 0x10 (Connect Command)Msg Len: 200Protocol Name: MQIsdpVersion: 31100 1110 = Connect Flags: 0xceKeep Alive: 30Client ID: 002000080054******Will Topic: tuya/smart/willWill Message: {“clientId”:”002000080054******",”deviceType”:”GATEWAY”,”message”:”11",”userName”:”002000080054*****"}
User Name: 002000080054******
Password: 84ce39dc******
This is getting interesting, now we know that out appliance connects with its client id: 002000080054******, and later with username 002000080054****** and password: 84ce39dc*****.
Subscribe Request
This is the packet capture for the record number 31 on the above screenshot.
MQ Telemetry Transport ProtocolSubscribe Request1000 0010 = Header Flags: 0x82 (Subscribe Request)Msg Len: 34Message Identifier: 1Topic: smart/gw/002000080054*******…. ..00 = Granted Qos: Fire and Forget (0)
Now this is very important, our appliance subscribe to the topic smart/gw/002000080054****** which it will use for all communications with its manufacturers cloud, and where it will receive commands to operate the appliance, such as turn on/off, change temperature, etc.
Publish Message
This is the packet capture for the record 136 on the above screenshot
These the messages published through the broker, and that our appliance is listening to in order to operate. Let’s look at a sample.
MQ Telemetry Transport ProtocolPublish Message0011 0000 = Header Flags: 0x30 (Publish Message)Msg Len: 195Topic: smart/gw/002000080054*******Message: {“protocol”:5,”type”:null,”gwId”:null,”data”:{“gwId”:”002000080054******",”devId”:”002000080054*****",”dps”:{“10”:null}},”pv”:”1.0",”t”:1494370798,”sign”:null}
So, we can see that this message was sent through the topic subscribed before, and the message published was:
{“protocol”:5,”type”:null,”gwId”:null,”data”:{“gwId”:”002000080054*****",”devId”:”00200008005******",”dps”:{“10”:null}},”pv”:”1.0",”t”:1494370798,”sign”:null}Our final part to understand how our appliance is operated remotely, requires us to send command through our phone App to the manufacturer’s cloud, and then listen to what message it sends to the appliance through the MQTT subscribed topic.
Learning the commands
We will now go through some commands on our mobile App which is the manufacturer’s recommended way to connect to the appliance, and we will write down what the message looks like on Wireshark, pay special attention to the field “dps” which has a field and value pair:
When we click on the turn on button on the App, we see the following message traveling from the manufacturer’s server directly to the appliance:
Message: {“protocol”:5,”type”:null,”gwId”:null,”data”:{“gwId”:”002000080054*****",”devId”:”002000080054******",”dps”:{“6”:true}},”pv”:”1.0",”t”:1494370898,”sign”:null}When we try with other commands available, and by checking the field “dps” we learned the following codes:
dps: 6:true //turns on heaterdps: 6:false //turns off the heaterdps: 2:30 //sets temperature to 30 degreesdps: 5:true //turns on the purifierdps: 5:false //turns off the purifierdps: 8:true //turns on the eco modedps: 8:false //turns off the eco modedps: 11:60 //sets the timer to 60 minutes
Wrapping up this chapter
This work has been great to understand how IoT devices communicate and connect using a practical example such as my heater. Our analyzis showed us how this appliance goes online, how it reaches for its manufacturer’s server, and how it talks to it using the standard IoT protocol of MQTT.
On part 2 of this article, we’ll go straight to hijacking our appliance and using it at our will.
Alex Harasic
CTO and Head of Business Intelligence
Operatio SpA
Email: aharasic@operatio.cl
