A while back, [cnlohr] needed a USB keyboard and mouse. His box ‘o junk didn’t hold this particular treasure, and instead of hopping on Amazon like a normal geek or venturing into the outside realm on a mid-level ‘store’ quest like a normal person, [cnlohr] decided to turn an ESP8266 into a USB keyboard and mouse. How hard could it be? The ESP doesn’t support USB, but bitbanging hasn’t stopped him before. The end result is a USB stack running on the ESP8266 WiFI module.
[cnlohr] has been working for about a month on this USB implementation for the ESP, beginning with a logic analyzer, Wireshark, Xtensa assembly, and a lot of iteration. The end result of this hardware hacking is a board based on the ESP8285 – an 8286 with integrated Flash – that fits snugly inside a USB socket.
This tiny board emulates low-speed USB (1.5 Mbps), and isn’t really fast enough for storage, serial, or any of the fancier things USB does, but it is good enough for a keyboard and mouse. Right now, [cnlohr]’s ESP USB device is hosting a webpage, and by loading this webpage on his phone, he has a virtual keyboard and mouse on a handheld touchscreen.
If you’re keeping track, [cnlohr] has now brought Ethernet and USB to a tiny microcontroller that can be bought for a few bucks through the usual online outlets. If you’d like to build your own ESP USB stick, all the files are over on the Gits.
In honor of my-own-damn-self, we’re going to call it Elliot’s Law: “When any two interesting parts get cheap enough on eBay, someone will make an interface PCB for them.”
And so it is with [Johan Kanflo]’s latest bit of work: a PCB that mounts an ESP8266 module onto the back of an ILI9341 color display, with user button, power supply, and an auxiliary MOSFET. Four bucks for the screen, four bucks for the ESP8266 module, and a few bucks here and there on parts and PCB, and you’ve got an Internet-enabled, full-color, 320×240 graphical display. That’s pretty awesome, and it’s entirely consistent with Elliot’s Law.
However, we almost can’t forgive [Johan] for the extreme geek-baiting. Posting the cuuuute little screen next to a Stormtrooper Lego figure is already hitting below the belt, but displaying a Commodore-64 startup screen, in what’s got to be exactly the right font and color combo, borders on being pathologically emotionally manipulative. You’re playing with our hearts, [Kanflo]!
We love projects like his ESP8266-and-RFM69 mashup and his gutted-Macintosh-planespotter-gizmo, so we’re inclined to forgive. And besides, we’re still on a high from naming our first law and we’re wondering which two eBay parts are up next.
In a recently released FCC filing, Google has announced their experimental protocol for testing the new CBRS. This isn’t fast Internet to a lamp pole on the corner of the street yet, but it lays the groundwork for how the CBRS will function, and how well it will perform.
Google will be testing the propagation and interference of transmissions in the 3.5 GHz band in places around the US. Most of the Bay Area will be covered in the tests, as well as Boulder, CO, Kansas City, Omaha, Raleigh, NC, Provo, UT, and Reston, VA. Tests will consist of a simple CW tone broadcast in the 3.5 GHz band.
The 3.5 GHz band is already allocated to shipborne navigation and military radar systems, posing an obvious problem to any wireless broadband system using this spectrum. To this end, the FCC is proposing a novel solution to the problem of coexistence between the CBRS and the military. Instead of simply banning transmissions in the spectrum, FCC Chairman Wheeler proposes, “computer systems can act like spectrum traffic cops.” A computer is able to direct the wireless traffic much more effectively than a blanket ban, and will allow better utilization of limited spectrum.
Google’s FCC filing is just for testing propagation and interference, and we have yet to hear anything about how a network built on 3.5 GHz spectrum will be laid out. One thing is for certain, though: you will not have a 3.5 GHz USB networking dongle for the same reason you don’t have a Google Fiber input on your desktop.
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!
