In a move that would induce ire in Lord Helmet, [Kedar Nimbalkar] has recreated Instructables user spacehun’s version of WiFi jammer that comes with a handful of features certain to frustrate whomever has provoked its wrath.
The jammer is an ESP8266 development board — running some additional custom code — accessed and controlled by a cell phone. From the interface, [Nimbalkar] is able to target a WiFi network and boot all the devices off the network by de-authenticating them. Another method is to flood the airspace with bogus SSIDs to make connecting to a valid network a drawn-out affair.
This kind of signal interruption is almost certainly illegal where you live. It does no permanent damage, but once again raises the existing deauth exploit and SSID loophole. [Nimbalkar]’s purpose in recreating this was for educational purposes and to highlight weaknesses in 802.11 WiFi protocols. The 802.11w standard should alleviate some of our fake deauth woes by using protected frames. Once the device authenticates on a network it will be able to detect fake deauth packets.
We featured a more targeted version of this hack that can be done using a PC — even targeting itself! And more recently there was a version that can target specific devices by jumping on the ACK.
Continue reading “Sir, It Appears We’ve Been Jammed!”
WiFi networking is one of those things that is reasonably simple to use, but has a lot of complex hidden features (dare we say, hacks) that make it work, or work better. For example, consider the Distributed Coordination Function (DCF) specified in the standard. Before a station can send, it has to listen for a certain time period. If the channel is clear, the station sends. If not, it has to delay a random amount of time before trying again. This is a form of Carrier Sense Multiple Access (CSMA) channel management.
Unfortunately, listening time is dead time when–at least potentially–there is no data transmitted on the network. DCF allows you to use various handshaking packets to do virtual carrier detection and ready/clear to send, but these are also less efficient use of bandwidth. There are other optional coordination functions available in the WiFi standard, but they all have their drawbacks.
[Aleksandar Kuzmanovic] at Northwestern University and two of his students have recently published a paper with a new way to coordinate multiple unrelated wireless networks using ubiquitous FM broadcast radio signals called WiFM. Instead of trying to synchronize to the WiFi data channel, this new scheme selects a strong FM radio station that broadcasts Radio Data Service (RDS) data (the data that populates the song titles and other information on modern radios).
Continue reading “Improving WiFi Throughput with FM Radio”
Announced at the 2014 Maker Faire in New York, the latest Arduino WiFi shield is finally available. This shield replaces the old Arduino WiFi shield, while providing a few neat features that will come in very handy for the yet-to-be-developed Internet of Things.
While the WiFi Shield 101 was announced a year ago, the feature set was interesting. The new WiFi shield supports 802.11n, and thanks to a few of Atmel’s crypto chip offerings, this shield is the first official Arduino offering to support SSL.
The new Arduino WiFi Shield 101 features an Atmel ATWINC1500 module for 802.11 b/g/n WiFi connectivity. This module, like a dozen or so other WiFi modules, handles the heavy lifting of the WiFi protocol, including TCP and UDP protocols, leaving the rest of the Arduino free to do the actual work. While the addition of 802.11n will be increasingly appreciated as these networks become more commonplace, the speed offered by ~n isn’t really applicable; you’re not going to be pushing bits out of an Arduino at 300 Mbps.
Also included on the WiFi shield is an ATECC508A CryptoAuthentication chip. This is perhaps the most interesting improvement over the old Arduino WiFi shield, and allows for greater security for the upcoming Internet of Things. WiFi modules already in the space have their own support for SSL, including TI’s CC3200 series of modules, Particle‘s Internet of Things modules, and some support for the ESP8266.
The Amazon Dash Button is a tiny WiFi-enabled device that’s a simple button with a logo on the front. If you get the Tide-branded version, simply press the button and a bottle of laundry detergent will show up at your door in a few days. Get the Huggies-branded version, and a box of diapers will show up. Get the sugar-free Haribo gummi bear-branded version, and horrible evil will be at your doorstep shortly.
[Matt] picked up one of these Dash Buttons for 99 cents, and since a button completely dedicated to buying detergent wasn’t a priority, he decided to tear it apart.
The FCC ID reveals the Amazon Dash Button is a WiFi device, despite rumors of it having a Bluetooth radio. It’s powered by a single AA battery, and [Matt] posted pictures of the entire board.
Since this piece of Amazon electronics is being sold for 99 cents, whatever WiFi radio chip is inside the Dash Button could be used for some very interesting applications. If you have an idea of what chips are being used in [Matt]’s pictures, leave a note in the comments.
The ESP8266 is the answer to “I want something with Wifi.” Surprisingly, there are a number of engineers and hobbyists who have not heard of this chip or have heard of it but don’t really understand what it is. It’s basically the answer to everything IoT to so many engineering problems that have plagued the hobbyist and commercial world alike.
The chip is a processor with integrated RAM, some ROM, and a WiFi radio, and the only external components you will need are 4 capacitors, a crystal and an external flash! It’s CHEAP, like $4/ea cheap! Or $5 if you want it on a nice, convenient carrier board that includes all these components. The power consumption is reasonable (~200mA)1, the range is insane ~300m2 without directional equipment, and a PCB trace antenna and ~4km if you want to be ridiculous.
One place thing that more people need to know about is how to program directly for this chip. Too many times projects use it as a crutch via the AT commands. Read on and find out how to hello world with just this chip.
Continue reading “How to Directly Program an Inexpensive ESP8266 WiFi Module”
A router with WPS requires a PIN to allow other devices to connect, and this PIN should be unique to every router and not derived from other easily accessible data found on the router. When [Craig] took a look at the firmware of a D-Link DIR-810L 802.11ac router, he found exactly the opposite; the WPS PIN was easily decipherable because it was generated entirely from the router’s MAC address and could be reverse engineered by sniffing WiFi.
When [Craig] was taking a look at the disassembled firmware from his router, he noticed a bit of code that accessed the NVRAM used for storing device-specific information like a serial number. This bit of code wasn’t retrieving a WPS pin, but the WAN MAC address instead. Instead of being unique to each device and opaque to every other bit of data on the router, the WPS pin was simply generated (with a bit of math) from the MAC address. This means anyone upstream of the router can easily derive the WPS pin of the router, and essentially gives everyone the keys to the castle of this router.
A few years ago, it was discovered the WPS pin was extremely insecure anyway, able to be brute-forced in a matter of minutes. There are patches router manufacturers could apply to detect these brute force attacks, closing that vulnerability. [Craig]’s code, though, demonstrates that a very large number of D-Link routers effectively broadcast their WPS PIN to the world. To make things even worse, the BSSID found in every wireless frame is also derived from the WAN MAC address. [Craig] has literally broken WPS on a huge number of D-Link routers, thanks to a single engineer that decided to generate the WPS PIN from the MAC address.
[Craig] has an incomplete list of routers that are confirmed affected on his site, along with a list of confirmed unaffected routers.