For those of us who worry about the security of our wireless devices, every now and then something comes along that scares even the already-paranoid. The latest is a device from [Samy] that is able to log the keystrokes from Microsoft keyboards by sniffing and decrypting the RF signals used in the keyboard’s wireless protocol. Oh, and the entire device is camouflaged as a USB wall wart-style power adapter.
The device is made possible by an Arduino or Teensy hooked up to an NRF24L01+ 2.4GHz RF chip that does the sniffing. Once the firmware for the Arduino is loaded, the two chips plus a USB charging circuit (for charging USB devices and maintaining the camouflage) are stuffed with a lithium battery into a plastic shell from a larger USB charger. The options for retrieving the sniffed data are either an SPI Serial Flash chip or a GSM module for sending the data automatically via SMS.
The scary thing here isn’t so much that this device exists, but that encryption for Microsoft keyboards was less than stellar and provides little more than a false sense of security. This also serves as a wake-up call that the things we don’t even give a passing glance at might be exactly where a less-honorable person might look to exploit whatever information they can get their hands on. Continue past the break for a video of this device in action, and be sure to check out the project in more detail, including source code and schematics, on [Samy]’s webpage.
Thanks to [Juddy] for the tip!
Continue reading “Keystroke Sniffer Hides as a Wall Wart, is Scary”
[Ray] has created RFToy, a simple gadget to aid in setting up wireless systems with a variety of common radio modules. RFToy is an open source microcontroller board running on an ATmega328. While RFToy is Arduino code compatible, [Ray] chose to ditch the familiar Arduino shield layout for one that makes it easier to install RF modules, and is more handheld friendly.
[RFToy] includes headers for the popular nRF24L01 2.4 GHz transceiver, as well as 433/315 transmitters and receivers found in many low-cost wireless electronic devices. The 128×64 pixel OLED screen and 3 button interface make it easy to set up simple user interfaces for testing new designs.
[Ray] hasn’t broken any new ground here. What he has done is create a simple tool for wireless projects. Anyone who’s worked on a wireless system can tell you that tools like this are invaluable for debugging why your circuit isn’t talking. Is it the transmitter? The receiver? Something else in the power supply circuit?
Check out [Ray’s] demo video after the break. In it, he sniffs, records, and plays back signals from several remote-controlled outlets. [Ray] also has a great demo of sending temperature data back and forth using an nRF24L01.
Continue reading “RFToy Makes Wireless Projects Easier”
A recent company move has left [kigster] and his 35 coworkers in a frustrating situation. Their new building only has two single occupancy bathrooms. To make matters worse, the bathrooms are located on two different floors. Heading to one bathroom, finding it occupied, then running upstairs to find the second bathroom also occupied became an all to common and frustrating occurrence at the office.
It was obvious the office needed some sort of bathroom occupancy monitoring system – much like those available on commercial aircraft. [kigster] asked for a budget of about $200 to build such a system. His request was quickly granted it by office management. They must have been on their way to the bathroom at the time.
[kigster] began work on BORAT: Bathroom Occupancy Remote Awareness Technology. The initial problem was detecting bathroom occupancy. The easiest method would be to use door locks with embedded switches, much those used in aircraft. Unfortunately, modifying or changing the locks in a rented office space is a big no-no. Several other human detection systems were suggested and rejected. The final solution was a hybrid. Sonar, Passive Infrared (PIR), and light sensors work in concert to detect if a person is in the bathroom. While we think the final “observer unit” is rather cool looking, we’re sure unsuspecting visitors to the office may be wondering why a two eyed robot is staring at them on the throne.
The display side of the system was easy. The entire system communicates with the venerable nRF24L01+ radio modules, so the display just needed a radio module, an arduino, and a way of displaying bathroom status. Two LED matrices took care of that issue.
We really like this hack. Not only is it a great use of technology to solve a common problem, but it’s also an open source system. BORAT’s source code is available on [kigster’s] github.
Want to know more about BORAT? Kigster is answering questions over on his thread in the Arduino subreddit.
If you want to take a photograph with a professional look, proper lighting is going to be critical. [Richard] has been using a commercial lighting solution in his studio. His Lencarta UltraPro 300 studio strobes provide adequate lighting and also have the ability to have various settings adjusted remotely. A single remote can control different lights setting each to its own parameters. [Richard] likes to automate as much as possible in his studio, so he thought that maybe he would be able to reverse engineer the remote control so he can more easily control his lighting.
[Richard] started by opening up the remote and taking a look at the radio circuitry. He discovered the circuit uses a nRF24L01+ chip. He had previously picked up a couple of these on eBay, so his first thought was to just promiscuously snoop on the communications over the air. Unfortunately the chips can only listen in on up to six addresses at a time, and with a 40-bit address, this approach may have taken a while.
Not one to give up easily, [Richard] chose a new method of attack. First, he knew that the radio chip communicates to a master microcontroller via SPI. Second, he knew that the radio chip had no built-in memory. Therefore, the microcontroller must save the address in its own memory and then send it to the radio chip via the SPI bus. [Richard] figured if he could snoop on the SPI bus, he could find the address of the remote. With that information, he would be able to build another radio circuit to listen in over the air.
Using an Open Logic Sniffer, [Richard] was able to capture some of the SPI communications. Then, using the datasheet as a reference, he was able to isolate the communications that stored information int the radio chip’s address register. This same technique was used to decipher the radio channel. There was a bit more trial and error involved, as [Richard] later discovered that there were a few other important registers. He also discovered that the remote changed the address when actually transmitting data, so he had to update his receiver code to reflect this.
The receiver was built using another nRF24L01+ chip and an Arduino. Once the address and other registers were configured properly, [Richard’s] custom radio was able to pick up the radio commands being sent from the lighting remote. All [Richard] had to do at this point was press each button and record the communications data which resulted. The Arduino code for the receiver is available on the project page.
[Richard] took it an extra step and wrote his own library to talk to the flashes. He has made his library available on github for anyone who is interested.
We’re sure that some of our readers are familiar with the difficult task that debugging/sniffing nRF24L01+ communications can be. Well, [Ivo] developed a sniffing platform based on an Arduino Uno, a single nRF24L01+ module and a computer running the popular network protocol analyzer Wireshark (part1, part2, part3 of his write-up).
As these very cheap modules don’t include a promiscuous mode to listen to all frames being sent on a particular channel, [Ivo] uses for his application a variation of [Travis Goodspeed]’s technique to sniff Enhance Shockburst messages. In short, it consists in setting a shorter than usual address, setting a fix payload length and deactivating the CRC feature. The Arduino Uno connected to the nRF24L01+ is therefore in charge of forwarding the sniffed frames to the computer. An application that [Ivo] wrote parses the received data and forwards it to wireshark, on which can be set various filters to only display the information you’re interested in.
With The Hackaday Prize, you’re not just limited to one entry. Of course it would be better to devote your time and efforts to only one project if you’re competing for a trip to space, but if you’re [Necromant], you might be working on two highly related project that are both good enough for The Hackaday Prize
[Necromant]’s first project is rf24boot, an over-the-air bootloader using the very cheap and very popular NRF24L01 2.4GHz wireless module. There have been many, many projects that add wireless bootloading to microcontrollers using XBees and the NRF24, but [Necromant] is doing something different with this project: he’s building in support for a wide variety of microcontrollers, that include the STM32, MSP430, PIC32, 8051, and of course AVR chips for that ever so popular Arduino compatibility.
The support of multiple microcontroller platforms is a result of [Necromant]’s other entry to The Hackaday Prize, Antares, the Linux kernel-like build system for microcontrollers. The idea behind Antares is to separate the writing of code from microcontrollers away from compiling and burning. Think of it as a giant makefile on steroids that works with everything, that also includes a few libraries for common projects.
Supported platforms for Antares include the popular aforementioned targets, and allow you to use any IDE you could possibly desire. emacs? Sure. Eclipse? Right on. Arduino? You’re a masochist. For a really great overview of Antares you can check out the Readme, or the post we did a year or so ago.
It’s all very cool stuff, and very easy to see the potential of what [Necromant]’s working on. Combining the two together, it’s almost a complete system for developing that Internet of Things we’ve been hearing about – uploading code to simple AVRs for simple sensors, and deploying significantly more complex code for your ARM-powered dishwasher or microwave.
[Sven337] just blogged about a gas consumption monitoring setup he finished not long ago. As his gas meter was located outside his apartment and nowhere near any electrical outlet, a battery-powered platform that could wirelessly send the current consumption data to his Raspberry Pi was required. His final solution therefore consists of a JeeNode coupled with the well known nRF24L01+ wireless transmitter, powered by 3 supposedly dead alkaline batteries.
[Sven337] carefully looked at the different techniques available to read the data from his meter. At first he had thought of using a reflective sensor to detect the number 6 which (in France at least) is designed to reflect light very well. He then finally settled for a magnetic based solution, as the Actaris G4 gas meter has a small depression intended for magnetic sensors. The PCB you see in the picture above therefore has a reed sensor and a debug LED. The four wires go to a plastic enclosure containing the JeeNode, a couple of LEDs and a reset switch. Using another nRF24L01, the Raspberry Pi finally receives the pulse count and reports it to an eeePC which takes care of the storage and graphing.