Back in the day, when wardriving was still useful (read: before WPA2 was widespread), we used to wander around with a Zaurus in our pocket running Kismet. Today, every cellphone has WiFi and a significantly more powerful processor inside. But alas, the firmware is locked down.
Enter the NexMon project. If you’ve got a Nexus 5 phone with the Broadcom BCM4339 WiFi chipset, you’ve now got a monitor-mode, packet-injecting workhorse in your pocket, and it looks a lot less creepy than that old Zaurus. But more to the point, NexMon is open. If you’d like to get inside what it took to reverse-engineer a hole into the phone’s WiFi, or make your own patches, here’s a great starting place.
But wait, there’s more! The recently released Raspberry Pi 3 has a similar Broadcom WiFi chipset, and has been given the same treatment, turning your RPi 3 into a wireless-sniffing powerhouse. How many Raspberry Pi “hacks” actually hack the Raspberry Pi? Well, here’s one.
We first learned of this project from a talk given at the MetaRhein-Main Chaos Days conference which took place last weekend. The NexMon talk (in German, but with slides in English) is just one of the many talks, all of which are available online.
The NexMon project is a standout, however. Not only do they reverse the WiFi firmware in the Nexus 5, but they show you how, and then apply the same methods to the RPi3. Kudos times three to [Matthias Schulz], [Daniel Wegemer], and [Matthias Hollick]!
In a lot of ways, portable toilets are superior to standard indoor-plumbing-style toilets. This is mostly due to the fact that they have a status indicator on the door. It’s a shame that no indoor bathrooms have figured this out yet, especially in office buildings where your awkward coworkers bang on every door rather than just check for feet in the huge gap that for some reason exists between the floor and the stall door. Anyway, [Chris] and [Daniel] came up with a solution for this issue, which also eliminates wait time for bathrooms in their office.
Their system is an automated bathroom status indicator that reports information about the bathroom’s use over WiFi. Since the bathrooms at their facility are spread out, it was helpful to be able to look up which bathroom would be free at any given moment. Several Raspberry Pis form the nerves of the project. Custom sensors were attached to a variety of different door locks to detect status. Each Pi reports back over WiFi. This accomplishes their goal of being subtle and simple. They also point out that they had to write very little code for this project since there are so many Unix and embedded hardware tools available to them. Checking the status of the bathroom can be as simple as running netcat.
If you’re looking to roll out your own bathroom status monitor solution, [Chris] and [Daniel] have made their code available on GitHub. There are a number of other ways to automate your bathroom, too, like switching the exhaust fan on when it gets too smelly or humid, or even creating a device that dispenses your toilet paper for you.
“Security” is the proverbial dead horse we all like to beat when it comes to technology. This is of course not unjust — we live in a technological society built with a mindset of “security last”. There’s always one reason or another proffered for this: companies need to fail fast and will handle security once a product proves viable, end users will have a harder time with setup and use if systems are secured or encrypted, and governments/law enforcement don’t want criminals hiding behind strongly secured systems.
This is an argument I don’t want to get bogged down in. For this discussion let’s all agree on this starting point for the conversation: any system that manages something of value needs some type of security and the question becomes how much security makes sense? As the title suggests, the technology du jour is home automation. When you do manage to connect your thermostat to your door locks, lights, window shades, refrigerator, and toilet, what type of security needs to be part of the plan?
Join me after the break for an overview of a few Home Automation security concerns. This article is the third in our series — the first asked What is Home Automation and the second discussed the Software Hangups we face.
These have all been inspired by the Automation challenge round of the Hackaday Prize. Document your own Automation project by Monday morning to enter. Twenty projects will win $1000 each, becoming finalists with a chance at the grand prize of $150,000. We’re also giving away Hackaday T-shirts to people who leave comments that help carry this discussion forward, so let us know what you think below.
Continue reading “Asking the Security Question of Home Automation”
[TK] has a stretch goal for his RC car project — enabling it to recharge on solar power during the day and roam around under remote Internet control at night. It’s like a miniature, backyard version of NASA’s Curiosity rover.
Right now, he’s gotten a Raspberry Pi Zero and a camera on board, and has them controlling the robot over WiFi. He looks like he’s having a great time piloting it around his house. Check out the video down below for (crashy) remote-controlled operation.
We can’t wait to see if solar power is remotely possible (tee-hee!) as an option for this vehicle. The eventual plan to connect it via 3G cellular modem is still off in the future, and will probably demand more of the smarts of the Raspberry Pi than at present. But we love the idea of a long-running autonomous vehicle, so we’re pulling for you, [TK]!
Continue reading “Hackaday Prize Entry: Solar WiFi Rover Roves At Night”
WiFi is all around us, but if you want to work with this ubiquitous networking protocol, you’ll need to pull out a laptop or smartphone like a caveman. [Daniel] has a better idea. It’ s a simple, compact tool for cracking WiFi passwords or sending deauth packets to everyone at the local Starbucks. It’s an ESP Swiss Army Knife, and a great entry for the Hackaday Prize.
As you would expect, this WiFI Swiss Army Knife is powered by the ESP8266 and features a tiny OLED display and a bunch of buttons for the UI. With this, [Daniel] is able to perform a deauth attack on a network, kicking anyone off the network, provided this device already has the MAC address of the victim.
This tiny wireless tool also has an SD card, making it possible to collect authentication frames for later decryption on a device that actually has the power to crack a network. With a LiPo charge controller and a sufficiently large battery, this tiny device could be left in the corner of an office collecting authentication packets for days until it’s later retrieved, opening up the network to anyone with a sufficiently fast computer. It’s a great build and very useful, making this a great entry for The Hackaday Prize.
[KC Budd] wanted to make a car-tracking GPS unit, and he wanted it to be able to phone home. Adding in a GSM phone with a data plan would be too easy (and more expensive), so he opted for the hacker’s way: tunneling the data over DNS queries every time the device found an open WiFi hotspot. The result is a device that sends very little data, and sends it sporadically, but gets the messages out.
This system isn’t going to be reliable — you’re at the mercy of the open WiFi spots that are in the area. This certainly falls into an ethical grey zone, but there’s very little harm done. He’s sending a 16-byte payload, plus the DNS call overhead. It’s not like he’s downloading animated GIFs of cats playing keyboards or something. We’d be stoked to provide this service to even hundreds of devices per hour, for instance.
If you’re new here, the idea of tunneling data over DNS requests is as old as the hills, or older, and we’ve even covered this hack before in different clothes. But what [KC] adds to the mix is a one-stop code shop on his GitHub and a GPS application.
Why don’t we see this being applied more in your projects? Or are you all tunneling data over DNS and just won’t admit it in public? You can post anonymously in the comments!
[Aleksejs Mirnijs] needed a tool to accurately measure the power consumption of his Raspberry Pi and Arduino projects, which is an important parameter for dimensioning adequate power supplies and battery packs. Since most SBC projects require a USB hub anyway, he designed a smart, WiFi-enabled 4-port USB hub that is also a power meter – his entry for this year’s Hackaday Prize.
[Aleksejs’s] design is based on the FE1.1s 4-port USB 2.0 hub controller, with two additional ports for charging. Each port features an LT6106 current sensor and a power MOSFET to individually switch devices on and off as required. An Atmega32L monitors the bus voltage and current draw, switches the ports and talks to an ESP8266 module for WiFi connectivity. The supercharged hub also features a display, which lets you read the measured current and power consumption at a glance.
Unlike most cheap hubs out there, [Aleksejs’s] hub has a properly designed power path. If an external power supply is present, an onboard buck converter actively regulates the bus voltage while a power path controller safely disconnects the host’s power line. Although the first prototype is are already up and running, this project is still under heavy development. We’re curious to see the announced updates, which include a 2.2″ touchscreen and a 3D-printable enclosure.