Last saturday while grocerie shopping I saw a wifi controlled "Smart Kettle" in the special offers isle. This reminded me of the as april fools joke written HTTP status code 418 "I'm a tea pot" and posted jokingly this toot on mastodon.

Well the itch got worse and so I finally bought one of these high tech devices to boil some water.

Since I had not yet done any projects or hacking on smart wifi IoT devices ,I had no idea how it works and what I had to expect. My first thought was, the smartphone app talks directly to the smart kettle, on which runs some kind of server / api one could talk to.

First things first, I hooked up the kettles base to mains power and pushed the wifi button on it. It beeped, flashed and who would have guessed, it spawned it's own open access point. ;)



I was able to connect to it but it did not distribute IPs via DHCP.

For the next try, I installed the Lidl Smart Home App on my smartphone, run the initial setup where I entered my wifi credentials, connected to the kettles own wifi from where the data was transferred to it. After some beeping the kettle connected to my wifi and it was available in the app.

Here I have the amazing options to set the water temperature for boiling and a time for warm keeping. It also offers some predefined "programs" / temperatures for different teas etc.. Also the status of the kettle and water temperature is shown.
There is a calender icon at the bottom but it is not possible to schedule a boil.




Thanks to the fritzbox notification about new devices on the network I already got it's IP. With that I run a nmap scan to see what is running on the kettle.


It was one port open, TCP 6668 but nmap could not identify what is running here.
I tried to grab a banner via netcat.

 nc 192.168.178.70 6668

Connection could be established but I did not get any banner back, giving hints what is running.

Visiting http or https://192.168.178.70:6668 in the browser also failed.
Would have been to easy. ;)

So next up, trying to setup a fake access point for a man in the middle attack to see what traffic flows between the smartphone and kettle.



For that I had a Kali vm running and a alpha usb wifi dongle connected to it. The home wifi from the host OS is connected to the vm as wired network on eth0.

1. I disable the network manager service, since it overrides the manual set IPs on the interfaces
   

sudo systemctl stop NetworkManager.service

2. Configured a fix IP on eth0 and set default route to the homerouter (fritzbox)
   

sudo ifconfig eth0 192.168.66.129/24 up 
sudo route add default gw 192.168.66.2 eth0

3. set fix IP on wlan0
   

sudo ifconfig wlan0 10.0.0.1/24 up   

4. set iptables rules to forward traffic from wlan0 to eth0
   

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -P FORWARD ACCEPT
sudo iptables --table nat -A POSTROUTING -o eth0 -j MASQUERADE

5. configure and run dhcp server
   

cat dnsmasq.conf                                                                                                                                    
interface=wlan0
dhcp-range=10.0.0.10,10.0.0.250,12h
dhcp-option=3,10.0.0.1
dhcp-option=6,10.0.0.1
server=8.8.8.8
log-queries
log-dhcp

cat fakehosts.conf 
127.0.0.1 test.de

sudo dnsmasq -C dnsmasq.conf -H fakehosts.conf -d

6. configure and run ap service
   

cat hostapd.conf 
interface=wlan0
driver=nl80211
ssid=fake
channel=1

sudo hostapd ./hostapd.conf  

7. start wireshark and listen on wlan0
   
   

With the fake wifi set up I reset the kettle and run the initial setup in the app again. These time I configured it to use the fake wifi. And look at that - the setup worked and I can see the traffic from the app and the kettle. A bit disappointed, I could not see any traffic directly between the app and the kettle.
Only traffic to IPs in the azure cloud. The kettle regularly connects to the cloud via a tls 1.2 encrypted connection and I guess pushes the state and tries to pull new commands.

Now my thought was, how can we break the tls connection to see what is going on. Since we are the man in the middle / access point we could try to deliver the kettle a fake certificate so we can encrypt the traffic and forward it encrypted with the public key from the azure server to normally to the cloud. Ettercap or bettercap could do that as far as I know but I haven´t tried it in the end.

Instead I did a quick MAC address lookup to see who build the wifi module, Tuya. New name, let's ask aunt google. And here we see tuya.com, seems to be a big "IoT" as a service provider. You can build devices with their modules or finished products, put your logo on it, click together a control app and use the Tuya cloud servers as backend.
If you had a wifi IoT device in your hand, chances seems to be quite high that it's one of tuyas.
But hey, what do we have here? A full developer documentation on the hardware, api & co. https://developer.tuya.com/en. Seems they don´t speak HTCPCP :(

Thanks to replies to my toot (thanks Zach) , I learned that it was possible to flash the wifi controller via ota firmware to put a "freed" firmware on it to run it without the tuya cloud. But it seems my device is to young for that.

https://community.home-assistant.io/t/kogan-smart-kettle/165466/63
https://github.com/tasmota/tasmotizer

So this little adventure of IoT hacking ends on a disappointed note. No direct traffic between app und kettle, no webservice on the kettle to talk to and no implementation of HTCPCP and no error 418. :(

Maybe we can do fun stuff directly with the hardware? ;)
But that's for another little adventure...!