Cutting An IoT Fan Free Of The Cloud

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!

Hacking An IoT Camera Reveals Hard-Coded Root Password

Hacking — at least the kind where you’re breaking into stuff — is very much a learn-by-doing skill. There’s simply no substitute for getting your hands dirty and just trying something. But that doesn’t mean you can’t learn something by watching, with this root password exploit on a cheap IP video camera being a good look at the basics.

By way of background on this project, [Matt Brown] had previously torn into a VStarcam CB73 security camera, a more or less generic IP camera that he picked up on the cheap, and identified a flash memory chip from which he extracted the firmware. His initial goal was to see if the camera was contacting sketchy servers, and while searching the strings for the expected unsavory items, he found hard-coded IP addresses plus confirmation that the camera was running some Linux variant.

With evidence of sloppy coding practices, [Matt] set off on a search for a hard-coded root password. The second video covers this effort, which started with finding UART pins and getting a console session. Luckily, the bootloader wasn’t locked, which allowed [Matt] to force the camera to boot into a shell session and find the root password hash. With no luck brute-forcing the hash, he turned to Ghidra to understand the structure of a suspicious program in the firmware called encoder. After a little bit of poking and some endian twiddling, he was able to identify the hard-coded root password for every camera made by this outfit, and likely others as well.

Granted, the camera manufacturer made this a lot easier than it should have been, but with a lot of IoT stuff similarly afflicted by security as an afterthought, the skills on display here are probably broadly applicable. Kudos to [Matt] for the effort and the clear, concise presentation that makes us want to dig into the junk bin and get hacking.

Continue reading “Hacking An IoT Camera Reveals Hard-Coded Root Password”

Screenshot of eBay listings with Gigaset IoT devices being sold, now basically useless

A Giga-Sunset For Gigaset IoT Devices

In today’s “predictable things that happened before and definitely will happen again”, we have another company in the “smart device” business that has just shuttered their servers, leaving devices completely inert. This time, it’s Gigaset. The servers were shuttered on the 29th of March, and the official announcement (German, Google Translate) states that there’s no easy way out.

It appears that the devices were locked into Gigaset Cloud to perform their function, with no local-only option. This leaves all open source integrations in the dust, whatever documentation there was, is now taken down. As the announcement states, Gigaset Communications Gmbh has gotten acquired due to insolvency, and the buyer was not remotely interested in the Smart Home portion of the business. As the corporate traditions follow, we can’t expect open sourcing of the code or protocol specification or anything of the sort — the devices are bricks until someone takes care of them.

If you’re looking for smart devices on the cheap, you might want to add “Gigaset” to your monitored search term list — we’ll be waiting for your hack submissions as usual. After all, we’ve seen some success stories when it comes to abandoned smart home devices – like the recent Insteon story, where a group of device owners bought out and restarted the service after the company got abruptly shut down.

We thank [Louis] for sharing this with us!

Three ZigBee radios in ESD bags, marked "Zigbee Sniffer", "Router" and "Coordinator".

Crash IoT Devices Through Protocol Fuzzing

IoT protocols are a relatively unexplored field compared to most PC-exposed protocols – it’s bothersome to need a whole radio setup before you can tinker on something, and often, for low-level experiments, just any radio won’t do. This means there’s quite a bit of security ground to cover. Now, the U-Fuzz toolkit from [asset-group] helps us make up for it.

Unlike fuzzers you might imagine, U-Fuzz doesn’t go in blindly. This toolkit has provisions to parse protocols and fuzz fields meaningfully, which helps because many of devices will discard packets they deem too malformed. With U-Fuzz, you feed it a couple packet captures, help it make some conclusions about packet and protocol structure, and get suggestions on how to crash your devices in ways not yet foreseen.

This allows for basically arbitrary protocol fuzzing, and to demonstrate, we get examples on 5G, CoAP and ZigBee probing alike, with a list of found CVEs to wrap the README up. As Wikipedia often states, this list is incomplete, and you can help by expanding it. Fuzzing is an underestimated tool – it will help you hack ubiquitous wireless protocols, proprietary standards, and smart home hubs alike.

IoT Air Purifier Makes A Great Case Study In Reverse Engineering

Here at Hackaday, about the only thing we like more than writing up tales of reverse engineering heroics is writing up tales of reverse engineering heroics that succeed in jailbreaking expensive widgets from their needless IoT dependency. It’s got a real “stick it to the man” vibe that’s hard to resist.

The thing is, we rarely see a reverse engineering write-up as thorough as the one [James Warner] did while integrating an IoT air purifier into Home Assistant, so we just had to make sure we called this one out. Buckle up; it’s a long, detailed post that really gets down into the weeds, but not unnecessarily so. [James] doesn’t cloud-shame the appliance manufacturer, so we can’t be sure who built this, but it’s someone who thought it’d be a swell idea to make the thing completely dependent on their servers for remote control via smartphone. The reverse engineering effort started with a quick look at the phone app, but when that didn’t pay off in any useful way, [James] started snooping on what the device was talking about using Wireshark.

One thing led to another, wires were soldered to the serial pins on the ESP32 on the purifier’s main board, and with the help of a FlipperZero as a UART bridge, the firmware was soon in hand. This gave [James] clues about the filesystem, which led to a whole Ghidra side quest into learning how to flash the firmware. [James] then dug into the meat of the problem: figuring out the packet structure used to talk to the server, and getting the private key used to encrypt the packets. This allowed a classic man-in-the-middle attack to figure out the contents of each packet and eventually, an MQTT bridge to let Home Assistant control the purifier.

If it sounds like we glossed over a lot, we know — this article is like a master class on reverse engineering. [James] pulled a lot of tools out of his kit for this, and the write-up is clear and concise. You may not have the same mystery fan to work with, but this would be a great place to start reverse engineering just about anything.

Thanks to [ThoriumBR] for the tip.

IOT Message Board Puts Fourteen-Segment Displays To Work

We’re not sure, but the number of recognizable alphanumeric characters that a seven-segment display can manage seems to have more to do with human pattern recognition than engineering. It takes some imagination, and perhaps a little squinting, to discern some characters, though. Arguably better is the fourteen-segment display, which has been pressed into service in this just-for-funsies IOT message board.

As [Steve] tells the story, this is one of those “boredom-buster” projects that start with a look through the junk bin to see what presents itself. In his case, some fourteen-segment common-cathode LEDs presented themselves, and the result was a simple but fun build. [Steve] used some clever methods to get the display stuffed onto two protoboards, including mounting the current-limiting resistors cordwood-style between the boards. A Raspberry Pi drives the display through a very neatly routed ribbon cable, and the whole thing lives in a tidy wooden box.

The IOT part of the build allows the display to show messages entered on [Steve]’s web page, with a webcam live stream to close the loop. Strangely, the display seems stuck on the “HI HACKADAY!” we entered as a test after [Steve] tipped us off, so we’re not sure if we busted it or what. Apologies if we did, [Steve]. And by the way, if your cats are named [Nibble] and [Pixel], well done!

No matter what you do with them, multi-segment displays are pretty cool. But if you think they’re something new, you’ve got another think coming.

Supercon 2022: Irak Mayer Builds Self-Sustainable Outdoor IoT Devices

[Irak Mayer] has been exploring IoT applications for use with remote monitoring of irrigation control systems. As you would expect, the biggest challenges for moving data from the middle of a field to the home or office are with connectivity and power. Obviously, the further away from urbanization you get, the sparser both these aspects become, and the greater the challenge.

[Irak] solves his connectivity problem by assuming there is some WiFi network within range, building a system around the Blues Wireless WiFi note card. Substituting their cellular card would be an option for applications out of WiFi range, but presumably without changing too much on the system and software side of things. Leveraging the Adafruit FeatherWing INA219, which is a bidirectional current sensor with an I2C interface, for both the power generation and system consumption measurements. For control, [Irak] is using an Adafruit ESP32 board, but says little more about the hardware. On the software side, [Irak] is using the Blues Wireless NoteHub for the initial connection, which then routes the collected data onto the Adafruit IoT platform for collation purposes. The final part of the hardware is a LiPo battery which is on standby to soak up any excess power available from the energy harvesting. This is monitored by an LC709203f battery fuel gauge.

Continue reading “Supercon 2022: Irak Mayer Builds Self-Sustainable Outdoor IoT Devices”