The cloud is supposed to make everything better. You can control things remotely, with the aid of a benevolent corporation and their totally friendly servers. However, you might not like those servers, and you might prefer to take personal control of your hardware. If that’s the case, you might like to follow the story of [ouaibe] and their quest to free a fan from the cloud.
The unit in question was a tower fan from Dreo. [ouaibe] noted that there was already a project to control the fans using Home Assistant, but pure lower-level local control was the real goal here. Work began on pulling apart the Dreo Android app to determine how it talked to the fan, eventually turning up a webserver on board, but little progress. The next step was to disassemble the unit entirely. That turned up multiple PCBs inside, with one obviously for wireless communication and another hosting a Sino Wealth microcontroller. Dumping firmwares followed, along with reverse engineering the webserver, and finally establishing a custom ESPHome integration to fully control the fan.
[ouaibe] has shared instructions on how to cut your own fan from the cloud, though notes that the work won’t be extended to other Dreo products any time soon. In any case, it’s a great example of just how much work it can take to fully understand and control an IoT device that’s tethered to a commercial cloud server. It’s not always easy, but it can be done!
Sigh.
The amount of brilliant work required to free this fan from the cloud is awesome. I mean this without irony.
It also makes me really, really happy that I own fan that has an on/off switch. If I’m hot, I turn it on, if I’m cold I turn it off. No carbon footprint for the cloud servers, no smart phone to boot up and use to control the fan.
Cheers.
Very true. I love posts like this since they do the hard bits and you can get up to speed quickly.
The worst about cloud things is when they can’t work without and the service goes poof…
You turned things around a bit.
The amount of brilliant work required to free this fan from the cloud is atrocious. The user manual of such things should come including how to control the API and lists of commands with descriptions. But it is commendable that a hacker is willing to put in enough time and effort to create this missing documentation.
You have done a great feat to reverse engineered the fan from using the cloud.
I would be highly interested to use my home server instead of using the cloud for all my IOT devices. I’m no specialist to reverse engineering, but I am certain many of those owning a house server would be happy to disconnect from the cloud by somehow bypassing the “coding” from the manufacturer’s cloud.
OK, I usually see the usefulness of cloud-connected functionality, however minor, but I do not see any whatsoever for a cloud-connected pedestal fan. Even if you want to enable a phone app to control the fan, you don’t need cloud computing to do that. Worst, Dreo is only one of many companies selling cloud-connected fans. We’re so doomed.
I applaud this beautiful effort. I wish more “cloud only” devices received the custom firmware treatment.
I wish that people would just ignore such silly cloud things and not support them with their hard-earned money. It would make that crap disappear from the market within an instant and no longer waste the time of bright minds.
Instead of trying to free IOT crap from its chains, don’t buy it in the first place and buy something you can control. My fan just has a knob with 4 settings on it, “off” and 3 speeds.
I would start with wireshark and record the incoming messages between fan and cloud that control the fan.
The next step is to test if a simple replay of the messages on the local network has any effect on the fan.
This is probably a first reaction to use the tools you have at hand.
Nowadays, that communication is usually encrypted in some fashion and that’s where my knowledge is insufficient to proceed… have been looking at a number of wireshark captures, only to later shrug my shoulders, rip out the main pcb and replace it, or maybe attach a microcontroller to the buttons instead…
I would start by buying a fan that just plugs into the wall. I have one in the almost exact same form factor it came with an ir remote if I’m too lazy to get out of bed of the middle of the night… it’s a effing fan you can’t really benefit from it without being too far away from it
Wouldn’t it be easier to just rewrite firmware for the fan from scratch? There is nothing complex inside to control, even simple Arduino IDE sketch will be more than enough and much quicker than following that rabbit hole of cloud networking emulation. Especially taking in account that you will never be sure you firewalled every host this thing could try to connect to and leak outside.
In the worst case, if manufacturer used OTP or some marginal or unmarked chips for “brains” you could just get rid of original SoC and around and wire in regular ESP32/8266 module to pull the heater/motor/display drivers inputs and read buttons/sensors. For sure, this [ouaibe] dude did much more work than that, to eventually achieve less.
IDK, may be there is some legal issues with replacing firmware or hardware of “smart” devices with your own one, but since when this ever stopped hackers?
I wonder when router manufacturers start adding a feature to spoof specific DNS responses to redirect requests from proprietary cloud to user-defined location. It would make hacks like these trivial. Sniff traffic, wrote a couple of lines of Python to handle the request on a Raspberry Pi, add a rule et voila!
Oh, and if those routers also exposed a Lua interpreter for simple, sandboxed responses, that could solve all the problems of the first world ;-) Also open a whole new can of worms, literally.
This is rather like the ESP8266 based smart outlets I got cheap when the orange place dumped them. Hooked the serial port and found a massive amount of traffic (including my WiFi credentials in clear text) being exchanged between the outlet and a server in China. After I stopped laughing I identified the pins connected to the button and relay, and flashed the ESP8266 with a program that did what I needed. Similarly, this thing is just a fan. The most basic controller for it is a toggle switch.
“orange place”?
I’m guessing Home Depot…
The other approach to hacking these, of course, is to analyze the network traffic to understand the protocol, do some firewall juggling to block the remote server, and transmit your own commands to the beast. This is easier if the network connection is not encrypted, but for good or ill (mostly ill) many iot devices have minimal, if any, network security and you are ideally positioned to do a man in the middle attack on your own hardware.
And if you can make that work, no hardware or firmware alterations are required.
Of course, if you explicitly look for devices which speak Zigbee or Z-Wave, those are already talking to local hubs using standard protocols. Theoretically Matter ought to be in that space.
In my opinion, IoT devices would not have needed a cloud connection if IPv4 didn’t get exhausted, and static ips and personal domains were plentiful, and if computer education was better than it is now. The device could just open a listen port on your internet connection and assuming the protocol is simple and secure, would do the job perfectly.
It’s just a fan.
With all due respect:
Easy fix: power switch, relay, done.
Complex fix: cheap micro, motor controller, potentiometer, power switch, done.
Both fit into the Hackaday ethos!
B^)
Sometimes its the journey not the end goal, and thanks for sharing, was a great read, as well as fantastic results, well done!!!