Operation Smart Kettle – Börzels Blog
Recorded: Sept. 13, 2026, 8:09 a.m.
| Original | Summarized |
Operation Smart Kettle | Börzels Blog Menu Blog Kontakt | Impressum | Datenschutz Suche Suche : Schließen Börzels Blog Operation Smart Kettle 15.01.2323 Benjamin Börzel 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. 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. nc 192.168.178.70 6668 Visiting http or https://192.168.178.70:6668 in the browser also failed. 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. I disable the network manager service, since it overrides the manual set IPs on the interfaces sudo systemctl stop NetworkManager.service Configured a fix IP on eth0 and set default route to the homerouter (fritzbox) sudo ifconfig eth0 192.168.66.129/24 up set fix IP on wlan0 sudo ifconfig wlan0 10.0.0.1/24 up set iptables rules to forward traffic from wlan0 to eth0 sudo sysctl -w net.ipv4.ip_forward=1 configure and run dhcp server cat dnsmasq.conf cat fakehosts.conf sudo dnsmasq -C dnsmasq.conf -H fakehosts.conf -d configure and run ap service cat hostapd.conf sudo hostapd ./hostapd.conf 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. 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. 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 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? ;) Blog Navigation vorheriger Eintrag © Börzels Blog - 2026 | Back to top |
The author initiated an investigation into a wifi-controlled smart kettle, inspired by the HTTP status code 418 joke, leading to the purchase of the device. The initial exploration focused on understanding the device’s operational mechanisms, starting with the hypothesis that the smartphone application communicates directly with a local server or API running on the kettle. The author first found that activating the kettle’s wifi button spawned its own open access point. Subsequent attempts to interact with the device involved connecting the device to the author's network and using the Lidl Smart Home App to set water temperatures and timers, which provided status updates. To gain further insight into the device’s network activity, the author proceeded to perform network scanning. After obtaining the device's IP address via a fritzbox notification, an nmap scan revealed a single open port, TCP 6668, but attempts to retrieve banner information using netcat or accessing the port via a web browser were unsuccessful, suggesting that the service running on the port was not easily identifiable. The investigation then shifted to a sophisticated attempt to perform a man-in-the-middle attack to observe the traffic flow between the mobile application and the kettle. For this purpose, the author configured a virtual machine running Kali Linux and utilized an alpha usb wifi dongle to set up a fake access point. The process involved intricate network configuration, including setting static IP addresses and routes for the virtual and physical interfaces, configuring a dnsmasq server to handle dynamic IP assignments, and setting up hostapd to manage the fake wifi network. When the kettle was reset and reconfigured to use this simulated network, the setup process successfully completed. However, the observed network traffic was limited; direct communication between the application and the kettle was not seen. Instead, the device demonstrated regular connections to Azure cloud services via a TLS 1.2 encrypted connection, suggesting that the device pushes its state and pulls commands from the cloud. Further investigation led the author to identify the hardware manufacturer, which was traced to Tuya, an entity that operates as an Internet of Things service provider. Reviewing the developer documentation indicated reliance on the Tuya cloud servers for functionality. Although the author discovered information regarding flashing the wifi controller via OTA firmware to obtain a "freed" firmware, they concluded that the current device was likely too young for this method. Ultimately, this exercise in IoT hacking concluded without revealing direct traffic between the application and the kettle, the presence of a local webservice, or an implementation of HTCPCP, resulting in a disappointing outcome regarding direct exploitation of the device's communication protocols. |