Delicious sheets of wallboard coated with yummy latex paints, all kept warm and moist by a daily deluge of showers and habitually forgetting to turn on the bathroom exhaust fan. You want mildew? Because that’s how you get mildew.
Fed up with the fuzzy little black spots on the ceiling, [Innovative Tom] decided to make bathroom ventilation a bit easier with this humidity-sensing IoT control for his bathroom exhaust fan. Truthfully, his build accomplishes little more than a $15 timer switch for the fan would, with one critical difference — it turns the fan on automatically when the DHT11 sensor tells the WeMos board that the relative humidity has gone over 60%. A relay shield kicks the fan on until the humidity falls below a set point. A Blynk app lets him monitor conditions in the bathroom and override the automatic fan, which is handy for when you need it for white noise generation more than exhaust. The best part of the project is the ample documentation and complete BOM in the description of the video below, making this an excellent beginner’s project.
No bathroom fan? Not a problem — this standalone humidity-sensing fan can help. Or perhaps you have other bathroom ventilation needs that this methane-sensing fan could help with?
Continue reading “Fight Mold and Mildew with an IoT Bathroom Fan”
The Espressif ESP8266 chipset makes three-dollar ‘Internet of Things’ development boards an economic reality. According to the popular automatic firmware-building site nodeMCU-builds, in the last 60 days there have been 13,341 custom firmware builds for that platform. Of those, only 19% have SSL support, and 10% include the cryptography module.
We’re often critical of the lack of security in the IoT sector, and frequently cover botnets and other attacks, but will we hold our projects to the same standards we demand? Will we stop at identifying the problem, or can we be part of the solution?
This article will focus on applying AES encryption and hash authorization functions to the MQTT protocol using the popular ESP8266 chip running NodeMCU firmware. Our purpose is not to provide a copy/paste panacea, but to go through the process step by step, identifying challenges and solutions along the way. The result is a system that’s end-to-end encrypted and authenticated, preventing eavesdropping along the way, and spoofing of valid data, without relying on SSL.
We’re aware that there are also more powerful platforms that can easily support SSL (e.g. Raspberry Pi, Orange Pi, FriendlyARM), but let’s start with the cheapest hardware most of us have lying around, and a protocol suitable for many of our projects. AES is something you could implement on an AVR if you needed to.
Continue reading “Practical IoT Cryptography on the Espressif ESP8266”
Today we’re excited to announce the winners of the Internet of Useful Things phase of The Hackaday Prize. The future will be connected, and this is a challenge to build devices connected to the Internet that are useful. These projects are the best the Internet of Things have to offer, and they just won $1000 each and will move on to the final round of the Hackaday Prize this fall.
Hackaday is currently hosting the greatest hardware competition on Earth. We’re giving away thousands of dollars to hardware creators to build the next great thing. Last week, we wrapped up the second of five challenges. It was all about showing a design to Build Something That Matters. Hundreds entered and began their quest to build a device to change the world.
There are still three more challenges to explore over the next few months. So far, the results have been spectacular. The winners for the Internet of Useful Things portion of the Hackaday Prize are, in no particular order:
Internet of Useful Things Hackaday Prize Finalists:
Continue reading “Twenty IoT Builds That Just Won $1000 in the Hackaday Prize”
A car is a rolling pile of hundreds of microcontrollers these days — just ask any greybeard mechanic and he’ll start his “carburetor” rant. All of these systems and sub-systems need to talk to each other in an electrically hostile environment, and it’s not an exaggeration to say that miscommunication, or even delayed communication, can have serious consequences. In-car networking is serious business. Mass production of cars makes many of the relevant transceiver ICs cheap for the non-automotive hardware hacker. So why don’t we see more hacker projects that leverage this tremendous resource base?
The backbone of a car’s network is the Controller Area Network (CAN). Hackaday’s own [Eric Evenchick] is a car-hacker extraordinaire, and wrote up most everything you’d want to know about the CAN bus in a multipart series that you’ll definitely want to bookmark for reading later. The engine, brakes, doors, and all instrumentation data goes over (differential) CAN. It’s fast and high reliability. It’s also complicated and a bit expensive to implement.
In the late 1990, many manufacturers had their own proprietary bus protocols running alongside CAN for the non-critical parts of the automotive network: how a door-mounted console speaks to the door-lock driver and window motors, for instance. It isn’t worth cluttering up the main CAN bus with non-critical and local communications like that, so sub-networks were spun off the main CAN. These didn’t need the speed or reliability guarantees of the main network, and for cost reasons they had to be simple to implement. The smallest microcontroller should suffice to roll a window up and down, right?
In the early 2000s, the Local Interconnect Network (LIN) specification standardized one approach to these sub-networks, focusing on low cost of implementation, medium speed, reconfigurability, and predictable behavior for communication between one master microcontroller and a small number of slaves in a cluster. Cheap, simple, implementable on small microcontrollers, and just right for medium-scale projects? A hacker’s dream! Why are you not using LIN in your multiple-micro projects? Let’s dig in and you can see if any of this is useful for you. Continue reading “Embed With Elliot: LIN is for Hackers”
[TrendMicro] are reporting that yet another IoT botnet is emerging. This new botnet had been dubbed Persirai and targets IP cameras. Most of the victims don’t even realize their camera has access to the Internet 24/7 in the first place.
Trend Micro, have found 1,000 IP cameras of different models that have been exploited by Persirai so far. There are at least another 120,000 IP cameras that the botnet could attack using the same method. The problem starts with the IP cameras exposing themselves by default on TCP Port 81 as a web server — never a great idea.
Most IP cameras use Universal Plug and Play, which allows them to open ports from inside the router and start a web server without much in the way of security checks. This paints a giant target in cyber space complete with signs asking to be exploited. After logging into a vulnerable device the attacker can perform a command injection attack which in turn points gets the camera to download further malware.
The exploit runs in memory only, so once it has been rebooted it should all be fine again until your next drive by malware download. Check your devices, because even big named companies make mistakes. IoT is turning into a battlefield. We just hope that with all these attacks, botnets, and hacks the promise of the IoT idea isn’t destroyed because of lazy coders.
Part of feature image from Wikipedia, Creative Commons license.
Let’s build the Internet of USEFUL Things, not just the Internet of Things. IuT ! IoT
That’s what we’ll be doing over the next five weeks. The second challenge of the 2017 Hackaday Prize begins today. We’re looking for the best ideas we can find for useful connected devices. Twenty entries will recieve $1,000 and move on to the final round to vie for the top prizes ranging from $5,000 to $50,000.
There is no doubt that the future is connected. It has been our future since the advent of the telegraph, and we’re unarguably becoming more connected at a faster rate. The phone in your hand, pocket, or bag connects you to the bulk of human knowledge. But it doesn’t yet connect you to very many “things”. It won’t be that way for long.
Already we’ve seen cameras (security, baby monitor, and everything in between) appear as some of the earliest connected devices, and they’ve brought with them all of the unintended consequences of poorly secured computer gear connected to the wider Internet. At least remote cameras have a purpose; there have been more than enough product launches for things that don’t. Our go-to counter-example is the Internet-connected toaster which is the topic of our wonderful art from Joe Kim this morning. Who needs to toast remotely? Nobody.
Let’s Invent the IoT
Here is our chance to do it right. How can Internet of Things make life better? What things become more meaningful when added to a network and what does that look like? How do we continue to connect our world while safeguarding privacy and being mindful of security. Finding answers to these questions will lead you to Build Something that Matters.
[Symantec] Reports Hajime seems to be a white hat worm that spreads over telnet in order to secure IoT devices instead of actually doing anything malicious.
[Brian Benchoff] wrote a great article about the Hajime Worm just as the story broke when first discovered back in October last year. At the time, it looked like the beginnings of a malicious IoT botnet out to cause some DDoS trouble. In a crazy turn of events, it now seems that the worm is actually securing devices affected by another major IoT botnet, dubbed Mirai, which has been launching DDoS attacks. More recently a new Mirai variant has been launching application-layer attacks since it’s source code was uploaded to a GitHub account and adapted.
Hajime is a much more complex botnet than Mirai as it is controlled through peer-to-peer propagating commands through infected devices, whilst the latter uses hard-coded addresses for the command and control of the botnet. Hajime can also cloak its self better, managing to hide its self from running processes and hide its files from the device.
The author can open a shell script to any infected machine in the network at any time, and the code is modular, so new capabilities can be added on the fly. It is apparent from the code that a fair amount of development time went into designing this worm.
So where is this all going? So far this is beginning to look like a cyber battle of Good vs Evil. Or it’s a turf war between rival cyber-mafias. Only time will tell.