WOPR: Security Loses Some Of Its Obscurity

As we’ve seen time and time again, the word “hacker” takes on a different meaning depending on who you’re talking to. If you ask the type of person who reads this fine digital publication, they’ll probably tell you that a hacker is somebody who likes to learn how things work and who has a penchant for finding creative solutions to problems. But if you ask the average passerby on the street to describe a hacker, they might imagine somebody wearing a balaclava and pounding away at their laptop in a dimly lit abandoned warehouse. Thanks, Hollywood.

The “Hollywood Hacker” Playset

Naturally, we don’t prescribe to the idea of hackers being digital villains hell-bent on stealing your identity, but we’ll admit that there’s something of rift between what we call hacking versus what happens in the information security realm. If you see mention of Red Teams and Blue Teams on Hackaday, it’s more likely to be in reference to somebody emulating Pokemon on the ESP32 than anything to do with penetration testing. We’re not entirely sure where this fragmentation of the hacking community came from, but it’s definitely pervasive.

In an attempt bridge the gap, the recent WOPR Summit brought together talks and presentations from all sections of the larger hacking world. The goal of the event was to show that the different facets of the community have far more in common than they might realize, and featured a number of talks that truly blurred the lines. The oscilloscope toting crew learned a bit about the covert applications of their gadgets, and the high-level security minded individuals got a good look at how the silicon sausage gets made.

Two of these talks which should particularly resonate with the Hackaday crowd were Charles Sgrillo’s An Introduction to IoT Penetration Testing and Ham Hacks: Breaking into Software Defined Radio by Kelly Albrink. These two presentations dealt with the security implications of many of the technologies we see here at Hackaday on what seems like a daily basis: Bluetooth Low Energy (BLE), Software Defined Radio (SDR), home automation, embedded Linux firmware, etc. Unfortunately, the talks were not recorded for the inaugural WOPR Summit, but both presenters were kind of enough to provide their slides for reference.

Continue reading “WOPR: Security Loses Some Of Its Obscurity”

EBay Modules And Custom PCBs Make A Plug And Play Ham Transceiver

Many of us have fond memories of our introduction to electronics through the “200-in-1” sets that Radio Shack once sold, or even the more recent “Snap Circuits”-style kits. Most of eventually us move beyond these kits to design our circuits; still, there’s something to be said for modular designs. This complete amateur radio transceiver is a great example of that kind of plug and play construction.

The rig is the brainchild of [jmhrvy1947], who set out to build a complete transceiver using mostly eBay-sourced modules. Some custom PCBs are used, but those are simple boards that can be etched and drilled easily. The transceiver is only for continuous-wave (CW) use, which would normally mean you’d need to know Morse, but thanks to some clever modifications to open-source apps like Quisk and FLDigi, Morse can be received and sent directly from the desktop. That will no doubt raise some hackles, but we think it’s a great way to learn code. The rig is QRP, or low power, transmitting only 100 mW with the small power amp shown. Adding eBay modules can jack that up to a full 100 Watts, which also requires adding a 12-volt power supply, switchable low-pass filters, a buck-boost converter, and some bandpass filters for band selection. It ends up looking very experimental, but it works well enough to make contacts.

We really like the approach here, and the fact that the rig can be built in stages. That makes it a perfect project for our $50 Ham series, which just kicked off. Perhaps we’ll be seeing it again soon.

Continue reading “EBay Modules And Custom PCBs Make A Plug And Play Ham Transceiver”

This SDR Uses A Tube

When you think of a software defined radio (SDR) setup, maybe you imagine an IC or two, maybe feeding a computer. You probably don’t think of a vacuum tube. [Mirko Pavleski] built a one-tube shortwave SDR using some instructions from [Burkhard Kainka] which are in German, but Google Translate is good enough if you want to duplicate his feat. You can see a video of [Mirko’s] creation, below.

The build was an experiment to see if a tube receiver could be stable enough to receive digital shortwave radio broadcasts. To avoid AC line hum, the radio is battery operated and while the original uses an EL95 tube, [Mirko] used an EF80.

Continue reading “This SDR Uses A Tube”

The Cat, The Aircraft, And The Tiny Computer

Sharing your life with a cat is a wonderful and fulfilling experience. Sharing your life with an awake, alert, and bored cat in the early hours when you are trying to sleep, is not. [Simon Aubury] has just this problem, as his cat [Snowy] is woken each morning by a jet passing over. In an attempt to identify the offending aircraft, he’s taken a Raspberry Pi and a software-defined radio, and attempted to isolate it by spotting its ADS-B beacon.

The SDR was the ubiquitous RTL chipset model, and it provided a continuous stream of aircraft data. To process this data he used an Apache Kafka stream processing server into which he also retrieved aircraft identifying data from an online service. Kafka’s SQL interface for interrogating multiple streams allowed him to untangle the mess of ADS-B returns and generate a meaningful feed of aircraft. This in turn was piped into an elasticsearch search engine database, upon which he built a Kibana visualisation.

The result was that any aircraft could be identified at a glance, and potential noise hotspots forecast. Whether all this heavy lifting was worth the end result is for you to decide, however it does provide an interesting introduction to the technologies and software involved. It is however possible to monitor ADS-B traffic considerably more simply.

Thanks [Oleg Anashkin] for the tip.

MIT IAP Tackles Radio

MIT is well known for rigorous courses, but they also have a special four-week term at the start of each year called the IAP — Independent Activities Period. This year, the MIT Radio Society had several interesting presentations on both the history and application of radio. You weren’t there? No problem, as the nine lecture were all recorded for you to watch at your leisure. You can see one of the nine, below.

These aren’t some five minute quicky videos, either. They are basically live captures that run anywhere from an hour to almost two hours in length. The topics are a great mix including radio history, software-defined radio, propagation, radio astronomy, RADAR, and even 5G.

You might have to pick and choose. Some of the lectures are suitable for just about anyone. Some assume a bit more radio expertise in electronics or math. Still, they are all worth at least a cursory skim to see if you want to really sit and watch in detail. The only nitpick is that some presenters used a laser pointer that doesn’t show up on the inset slide graphics in the video. That makes sense because the inset slides are not really in the room, but it can make it a little difficult to understand what the speaker is pointing to on a crowded slide.

Of course, if you want to dive deep and you need more background, MIT — along with many other institutions — will let you use their learning material for free. We were especially fans of the circuits class but there are many others including just raw materials from OCW.

Continue reading “MIT IAP Tackles Radio”

Radio Telescopes Horn In With GNU Radio

Who doesn’t like to look up at the night sky? But if you are into radio, there’s a whole different way to look using radio telescopes. [John Makous] spoke at the GNU Radio Conference about how he’s worked to make a radio telescope (PDF) that is practical for even younger students to build and operate.

The only real high tech part of this build is the low noise amplifier (LNA) and the project is in reach of a typical teacher who might not be an expert on electronics. It uses things like paint thinner cans and lumber. [John] also built some blocks in GNU Radio that made it easy for other teachers to process the data from a telescope. As he put it, “This is the kind of nerdy stuff I like to do.” We can relate.

The telescope is made to pick up the 21 cm band to detect neutral hydrogen from the Milky Way. It can map the hydrogen in the galaxy and also measure the rotational speed of the galaxy using Doppler shift. Not bad for an upcycled paint thinner can. These are cheap enough, you can even build a fleet of them.

This would be a great project for anyone interested in radio telescopes or space. However, it is particularly set up for classroom use. Students can flex their skills in math, engineering, programming, and — of course — astronomy and physics.

Continue reading “Radio Telescopes Horn In With GNU Radio”

Underclocking The ESP8266 Leads To WiFi Weirdness

Sometimes the best hacks come from the most basic of questions. In this case, [CNLohr] was wondering what would happen if he started to reduce the clock speed of the ESP8266’s Baseband PLL (BBPLL) while still trying to communicate with it. You know, as one does. The results ended up being fairly surprising, and while it’s not immediately clear if there’s a practical application for this particular trick, it’s certainly worth some additional research.

Code for stepping through clock speeds

The idea here is that the BBPLL is the reference clock for the entire system, including all of the peripherals. So underclocking it doesn’t just slow down code execution as you might expect, but it also slows down the chip’s interactions with the outside world. [CNLohr] demonstrates this concept in the video below, showing how the baud rate used to view the serial output from the ESP8266 needs to be adjusted to match the chip’s frequency or else you’ll only get garbage on the line.

But what happens to the WiFi? As [CNLohr] discovered, while the center frequency itself doesn’t change, the channel width gets narrower as the clock rate is lowered. When viewed on the waterfall display of a software defined radio (SDR), the transmission can be seen “compressing” in a step pattern as the clock rate is reduced. As one might expect, the 802.11 packets become indecipherable to a normal WiFi device running in monitor mode. The signal is still at the correct frequency, but the devices can no longer understand each other.

Now it was time for another of those basic questions. What would happen if you did the same thing to a second ESP8266? Much to his surprise, [CNLohr] discovered that the two devices could still communicate successfully as long as their BBPLL clock speed was the same. From an outsider’s perspective it looked like gibberish, but to the two ESPs which had been slowed by the same amount, everything worked as expected even though the 802.11 standards say it shouldn’t.

So what can you do with this? The most obvious application is a “stealth” WiFi connection between ESP8266s which wouldn’t show up to normal devices, a communications channel invisible to all but the most astute eavesdropper. [CNLohr] has made all the source code to pull this trick off public on GitHub, and it should be interesting to see what kind of applications (if any) hackers find for this standards-breaking behavior.

If your thing is devices being forced into operations they were never intended to by particularly twisted hackers, check out our recent coverage of the USB serial adapter turned SDR by [Ted Yapo].

Continue reading “Underclocking The ESP8266 Leads To WiFi Weirdness”