Hackaday.io contributor extraordinaire [davedarko] gets hot in the summer. We all do. But what separates him from the casual hacker is that he beat the heat by ordering four 120 mm case fans. He then 3D printed a minimalistic tower frame for the fans, and tied them all together with a ULN2004 and an ESP8266. The whole thing is controlled over the network via MQTT. That’s dedication to staying cool.
We really like the aesthetics of this design. A fan made up of fans! But from personal experience, we also know that these large case fans can push a lot of air fairly quietly. That’s important if you’re going to stand something like this up on your desk. While we’re not sure that a desk fan really needs networked individual PWM speed control, we can see the temptation.
Now that they’re individually controlled, nothing stops [davedarko] from turning this into a musical instrument, or even using the fans to transmit data. The only thing we wouldn’t do, despite the temptation to stick our fingers in the blades, is to complicate the design visually. Maybe that would finally teach the cat not to walk around on our desk.
[CNLohr] just can’t get enough of the ESP8266 these days — now he’s working on getting a version of V-USB software low-speed USB device emulation working on the thing. (GitHub link here, video also embedded below.) That’s not likely to be an afternoon project, and we should warn you that it’s still a project in progress, but he’s made some in-progress material available, and if you’re interested either in USB or the way the mind of [CNLohr] works, it’s worth a watch.
In this video, he leans heavily on the logic analyzer. He’s not a USB expert, and couldn’t find the right resources online to implement a USB driver, so he taught himself by looking at the signals coming across as he wiggled a mouse on his desk. Using the ever-popular Wireshark helped him out a lot with this task as well. Then it was time to dig into Xtensa assembly language, because timing was critical.
Speaking of timing, one of the first things that he did was write some profiling routines so that he could figure out how long everything was taking. And did we mention that [CNLohr] didn’t know Xtensa assembly? So he wrote routines in C, compiled them using the Xtensa GCC compiler, and backed out the assembly. The end result is a mix of the two: assembly when speed counts, and C when it’s more comfortable.
Software defined radios are getting better and better all the time. The balaclava-wearing hackers know it, too. From what we saw at HOPE in New York a few weeks ago, we’re just months away from being able to put a femtocell in a desktop computer for under $3,000. In less than a year, evil, bad hackers could be tapping into your cell phone or reading your text message from the comfort of a van parked across the street. You should be scared, even though police departments everywhere and every government agency already has this capability.
These rogue cell sites have various capabilities, from being able to track an individual phone, gather metadata about who you have been calling and for how long, to much more invasive surveillance such as intercepting SMS messages and what websites you’re visiting on your phone. The EFF calls them cell-site simulators, and they’re an incredible violation of privacy. While there was most certinaly several of these devices at DEF CON, I only saw one in a hotel room (you catchin’ what I’m throwin here?).
No matter where the threat comes from, rogue cell towers still exist. Simply knowing they exist isn’t helpful – a proper defence against governments or balaclava wearing hackers requires some sort of detection system.. For the last few months [Eric Escobar] has been working on a simple device that allows anyone to detect when one of these Stingrays or IMSI catchers turns on. With several of these devices connected together, he can even tell where these rogue cell towers are.
A Stingray / cell site simulator detector
Stingrays, IMSI catchers, cell site simulators, and real, legitimate cell towers all broadcast beacons containing information. This information includes the radio channel number, country code, network code, an ID number unique to a large area, and the transmit power. To make detecting rogue cell sites harder, some of this information may change; the transmit power may be reduced if a tech is working on the site, for instance.
To build his rogue-cell-site detector, [Eric] is logging this information to a device consisting of a Raspberry Pi, SIM900 GSM module, an Adafruit GPS module, and a TV-tuner Software Defined Radio dongle. Data received from a cell site is logged to a database along with GPS coordinates. After driving around the neighborhood with his rogue-cell-site detector sitting on his dashboard, [Eric] had a ton of data that included latitude, longitude, received power from a cell tower, and the data from the cell tower. This data was thrown at QGIS, an open source Geographic Information System package, revealing a heatmap with the probable locations of cell towers highlighted in red.
This device really isn’t a tool to detect only rogue cell towers – it finds all cell towers. Differentiating between a rogue and legitimate tower still takes a bit of work. If the heatmap shows a cell site on a fenced-off parcel of land with a big tower, it’s a pretty good bet that cell tower is legit. If, however, the heatmap shows a cell tower showing up on the corner of your street for only a week, that might be cause for alarm.
Future work on this cell site simulator detector will be focused on making it slightly more automatic – three or four of these devices sprinkled around your neighborhood would easily allow you to detect and locate any new cell phone tower. [Eric] might also tackle triangulation of cell sites with an RF-blocking dome with a slit in it revolving around the GSM900 antenna.
[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.
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!
[David]’s family acquired a swimming pool. While it’s not his favorite activity in the world, every now and then he’ll indulge in the blue plastic bin full of water occupying previously pristine land in his backyard.
As he says, cool beer is pleasant, but cool water tends to put a damper on the experience. Rather than do something pedestrian like touch the water himself to discover its temperature; he saw an opportunity for a fun little project in a wireless temperature monitor.
The heart of the device is a Telecom Design TD1208 which runs on the French SigFox network. For a small fee any device on the network can send up to 140 12byte packets of data a day. Not a lot, but certainly acceptable for the Microchip MCP9700 temperature sensor it uses. He got the board up and running, and even made his own custom helical coil antenna.
The case was 3D printed out of PLA. It’s a tiered cylindrical bobber. The wider top section floats on the water and the base acts as a ballast, holding the battery and sensor. The bobber is powered by a combination of a questionable Chinese lithium battery, charging circuit, and solar panel. [Dave] was keen to point out that the battery is, technically, water cooled.
He wrapped up the code for the bobber and used SigFox’s SDK to build a nice web interface. Now, when the rare mood strikes him, he can remain inside if the conditions aren’t right for a swim.
We toss together our own PCB designs, throwing in a microcontroller here or there. Anything more demanding than that, and we reach for a Raspberry Pi or BeagleBone (or an old Linksys router). Why don’t we just whip together a PCB for a small Linux computer? Because we don’t know how…but [Jonas] apparently does. And when we asked him why he did it, he replied “because I can!”
His Ethernet-to-6LoWPAN gateway project is a small, OpenWRT-capable Linux computer in disguise. Rather than yet another Raspberry Pi project, he designed around an Atmel AT91SAM9G25 400 MHz CPU, and added some memory, Ethernet, and a CC2520 radio chip to handle the wireless side. It’s all done on a four-layer board, and hotplate/skillet reflowed. This seems temptingly like something within our reach. [Jonas] had access to X-ray machines to double-check his reflow work, which probably isn’t necessary, although it looks really cool.
When finished, the project will link together a 6LoWPAN network (probably home automation) and his home wired network. That makes this device a rival to something like Philips’ Hue Bridge, which was the subject of some controversy when they locked out other devices for a few days until they recanted. Indeed, in response to this, there’s been quite a lot of effort at hacking the firmware of the Hue device, just to stay on the safe side in case Philips plays shenanigans again.
Soon, that’s not going to be necessary. [Jonas]’s design is open from the ground up, and coupled with open software running on top of the OpenWRT router operating system, that’s the full stack. And that’s great news for folks who are thinking about investing in a home automation technology, but afraid of what happens then the faceless corporations decide to pull the plug on their devices.
Last year, the Federal Communications Commission proposed a rule governing the certification of RF equipment, specifically wireless routers. This proposed rule required router manufacturers to implement security on the radio module inside these routers. Although this rule is fairly limited in scope – the regulation only covers the 5GHz U-NII bands, and only applies to the radio subsystem of a router, the law of unintended consequences reared its ugly head. The simplest way to lock down a radio module is to lock down the entire router, and this is exactly what a few large router manufacturers did. Under this rule, open source, third-party firmwares such as OpenWRT are impossible.
Now, router manufacturer TP-Link has reached an agreement with the FCC to allow third-party firmware. Under the agreement, TP-Link will pay a $200,000 fine for shipping routers that could be configured to run above the permitted power limits.
This is a huge success for the entire open source movement. Instead of doing the easy thing – locking down a router’s firmware and sending it out the door – TP-Link has chosen to take a hit to their pocketbook. That’s great news for any of the dozens of projects experimenting with mesh networking, amateur radio, or any other wireless networking protocol, and imparts a massive amount of goodwill onto TP-Link.
