WiFi Deauthentication VS WiFi Jamming: What is the difference?

Terminology is something that gets us all mixed up at some point. [Seytonic] does a great job of explaining the difference between WiFi jammers and deauthenticators in the video embedded below. A lot of you will already know the difference however it is useful to point out the difference since so many people call deauth devices “WiFi Jammers”.

In their YouTube video they go on to explain that jammers basically throw out a load of noise on all WiFi channels making the frequencies unusable in a given distance from the jammer. Jammers are also normally quite expensive, mostly illegal, and thus hard to find unless of course you build your own.

WiFi deauthentication on the other hand works in a very different way. WiFi sends unencrypted packets of data called management frames. Because these are unencrypted, even if the network is using WPA2, malicious parties can send deauthentication commands which boot users off of an access point. There is hope though with 802.11w which encrypts management frames. It’s been around for a while however manufacturers don’t seem bothered and don’t implement it, even though it would improve the security of a WiFi device from these types of attacks.

Continue reading “WiFi Deauthentication VS WiFi Jamming: What is the difference?”

FLEX Pager Protocol in Depth

We love pager hacks. One of our earliest head-slappers was completely reverse-engineering a restaurant pager’s protocol, only to find out that it was industry-standard POCSAG. Doh!

[Corn] apparently scratches the same itch, but in the Netherlands where the FLEX protocol is more common. In addition to walking us through all of the details of the FLEX system, he bought a FLEX pager, gutted it, and soldered on an ATMega328 board and an ESP8266. The former does the FLEX decoding, and the latter posts whatever it hears on his local network.

These days, we’re sure that you could do the same thing with a Raspberry Pi and SDR, but we love the old-school approach of buying a pager and tapping into its signals. And it makes a better stand-alone device with a lot lower power budget. If you find yourself in possession of some old POCSAG pagers, you should check out [Corn]’s previous work: an OpenWRT router that sends pages.

Making a Cheap Radar Unit Awesome

[JBeale] squeezed every last drop of performance from a $5 Doppler radar module, and the secrets of that success are half hardware, half firmware, and all hack.

On the hardware side, the first prototype radar horn was made out of cardboard with aluminum foil taped around it. With the concept proven, [JBeale] made a second horn out of thin copper-clad sheets, but reports that the performance is just about the same. The other hardware hack was simply to tack a wire on the radar module’s analog output and add a simple op-amp gain stage, which extended the sensing range well beyond the ten feet or so that these things are usually used for.

With all that signal coming in, [JBeale] separates out the noise by taking an FFT of the Doppler frequency-shift signal. Figuring that people walk around 2.2 miles per hour, [JBeale] focuses on the corresponding 70 Hz frequency bin and finds that the radar will detect people out to 80 feet. Wow!

This trick of taking an el-cheapo radar unit and amplifying the signal to do something useful isn’t new to Hackaday. [Mathieu] did it with the very same HB-100 unit way back in 2013, and then again with a more modern CDM324 model. But [JBeale]’s hacked horn and clever backend processing push out the limits of what you can expect to do with these cheap units. Kudos.

[via PJRC]

Quick Robin! The Bat Keychain!

We don’t know if Batman has a keychain for the keys to the Bat mobile, the Bat copter, and all his other vehicles. But we are guessing if he did, it didn’t look like the one [krishnan793] picked up cheap. It had a little button that lit up some LEDs and played a little tune. [Krishnan] thought he could do better with an ESP8266. After chopping up some headphones and adding a LiPo battery, he wound up with an improved key chain you can see in the video below. The first video is the before video. The second is after the modification. Sure, it is only a small improvement on LEDs and a simple tune, but now it is hackable to do more interesting things if you want to take the trouble to do so.

Continue reading “Quick Robin! The Bat Keychain!”

“Borrow” Payment Cards with NFC Proxy Hardware

Contactless payments are growing in popularity. Often the term will bring to mind the ability to pay by holding your phone over a reader, but the system can also use NFC tags embedded in credit cards, ID card, passports, and the like. NFC is a reasonably secure method of validating payments as it employs encryption and the functional distance between client and reader is in the tens of centimeters, and often much less. [Haoqi Shan] and the Unicorn team have reduced the security of the distance component by using a hardware proxy to relay NFC interactions over longer distances.

The talk, give on Sunday at DEF CON, outlined some incredibly simple hardware: an NFC antenna connected to a PN7462AU, an NRF24L01 wireless transceiver, and some power regulation. The exploit works by using a pair of these hardware modules. A master interfaces with the NFC reader, and a slave reads the card. The scenario goes something like this: a victim NFC card is placed near the slave hardware. The master hardware is placed over a payment kiosk as if making a normal payment. As the payment kiosk reader begins the process to read an NFC card, all of the communications between it and the actual card are forwarded over the 24L01 wireless connection.

The demo video during the talk showed a fast-food purchase made on the Apple Pay network while the card was still at a table out in the dining area (resting on the slave hardware module). The card used was a QuickPass contactless payment card from China UnionPay. According to a 2016 press release from the company, over two billion of these cards had been issued at the time. With that kind of adoption rate there is a huge incentive to find and patch any vulnerabilities in the system.

The hardware components in this build aren’t really anything special. We’ve seen these Nordic wireless modules used in numerous projects over they years, and the NXP chip is just NFC build around an ARM core. The leaps that tie this together are the speed-ups to make it work. NFC has tight timing and a delay between the master and slave would invalidate the handshake and subsequent interactions. The Unicorn team found some speedups by ensuring the chip was waking from suspend mode (150 µS) and not a deeper sleep. Furthermore, [Haoqi] mentioned they are only transmitting “I/S/R Block Data” and not the entirety of the interaction to save on time transmitting over the 24L01 wireless link. He didn’t expand on that so if you have details about what those blocks actually consist of please let us know in the comments below.

To the card reader, the emulated payment card is valid and the payment goes through. But one caveat to the system is that [Haoqi] was unable to alter the UID of the emulator — it doesn’t spoof the UID of the payment card being exploited. Current readers don’t check the UID and this could be one possible defense against this exploit. But to be honest, since you need close physical proximity of the master to the reader and the slave to the payment card simultaneously, we don’t see mayhem in the future. It’s more likely that we’ll see hacker cred when someone builds a long-range link that lets you leave your NFC cards at home and take one emulator with you for wireless door access or contactless payments in a single device. If you want to get working on this, check out the talk slides for program flow and some sourcecode hints.

Michael Ossmann Pulls DSSS Out of Nowhere

[Michael Ossmann] spoke on Friday to a packed house in the wireless hacking village at DEF CON 25. There’s still a day and a half of talks remaining but it will be hard for anything to unseat his Reverse Engineering Direct Sequence Spread Spectrum (DSSS) talk as my favorite of the con.

DSSS is a technique used to transmit reliable data where low signal strength and high noise are likely. It’s used in GPS communications where the signal received from a satellite is often far too small for you to detect visually on a waterfall display. Yet we know that data is being received and decoded by every cell phone on the planet. It is also used for WiFi management packets, ZigBee, and found in proprietary systems especially any dealing with satellite communications.

[Michael] really pulled a rabbit out of a hat with his demos which detected the DSSS signal parameters in what appeared to be nothing but noise. You can see below the signal with and without noise; the latter is completely indiscernible as a signal at all to the eye, but can be detected using his techniques.

Detecting DSSS with Simple Math

[Michael] mentioned simple math tricks, and he wasn’t kidding. It’s easy to assume that someone as experienced in RF as he would have a different definition of ‘simple’ than we would. But truly, he’s using multiplication and subtraction to do an awful lot.

DSSS transmits binary values as a set called a chip. The chip for digital 1 might be 11100010010 with the digital 0 being the inverse of that. You can see this in the slide at the top of this article. Normal DSSS decoding compares the signal to expected values, using a correlation algorithm that multiplies the two and gives a score. If the score is high enough, 11 in this example, then a bit has been detected.

To reverse engineer this it is necessary to center on the correct frequency and then detect the chip encoding. GNU radio is the tool of choice for processing a DSSS capture from a SPOT Connect module designed to push simple messages to a satellite communication network. The first math trick is to multiply the signal by itself and then look at spectrum analysis to see if there is a noticeable spike indicating the center of the frequency. This can then be adjusted with an offset and smaller spikes on either side will be observed.

When visualized in a constellation view you begin to observe a center and two opposite clusters. The next math trick is to square the signal (multiply it by itself) and it will join those opposite clusters onto one side. What this accomplishes is a strong periodic component (the cycle from the center to the cluster and back again) which reveals the chip rate.

Detecting symbols within the chip is another math trick. Subtract each successive value in the signal from the last and you will mostly end up with zero (high signal minus high signal is zero, etc). But every time the signal spikes you’re looking at a transition point and the visualization begins to look like logic traced out on an oscilloscope. This technique can deal with small amounts of noise but becomes more robust with a bit of filtering.

This sort of exploration of the signal is both fun and interesting. But if you want to actually get some work done you need a tool. [Michael] built his own in the form of a python script that cobbles up a .cfile and spits out the frequency offset, chip rate, chip sequence length, and decoded chip sequence.

Running his sample file through with increasing levels of noise added, the script was rock solid on detecting the parameters of the signal. Interestingly, it is even measuring the 3 parts per million difference between the transmitter and receiver clocks in the detected chip rate value. What isn’t rock solid is the actual bit information, which begins to degrade as the noise is increased. But just establishing the parameters of the protocol being used is the biggest part of the battle and this is a dependable solution for doing that quickly and automatically.

You can give the script a try. It is part of [Michael’s] Clock Recovery repo. This talk was recorded and you should add it to your reminder list for after the con when talks begin to be published. To hold you over until then, we suggest you take a look at his RF Design workshop from the 2015 Hackaday Superconference.

OpenEMS Makes Electromagnetic Field Solving… Merely Difficult

To ordinary people electronics is electronics. However, we know that the guy you want wiring your industrial furnace isn’t the guy you want designing a CPU. Neither of those guys are likely to be the ones you want building an instrumentation amplifier. However, one of the darkest arts of the electronic sects is dealing with electromagnetic fields. Not only is it a rare specialty, but it requires a lot of high-powered math. Enter OpenEMS, a free and open electromagnetic field solver.

We would like to tell you that OpenEMS makes doing things like antenna analysis easy. But that’s like saying Microsoft Word makes it easy to write a novel. In one sense, yes, but you still need to know what you are doing. In fairness, though, the project does provide a good set of tutorials, ranging from a simple wave guide to a sophisticated phased array of patch antennas. Our advice? Start with the waveguide and work your way up from there.

The software uses Octave or MATLAB for scripting, plotting, and support. You can download it for Windows or Linux.

If you want to start with something more intuitive for electromagnetic field visualization, this might help. If you prefer your models more concrete and less abstract, perhaps you should work at Lincoln Lab.