Starlink has been making tremendous progress towards providing world-wide access to broadband Internet access, but there are a number of downsides to satellite-based internet such as the cluttering of low-Earth orbit, high expense, and moodiness of CEO. There are some alternatives if standard Internet access isn’t available, and one of the more ambitious is providing Internet access by balloon. Project Loon is perhaps the most famous of these (although now defunct), but it’s also possible to skip the middleman and build your own high-altitude balloon capable of connection speeds of 500 Kbps.
[Stephen] has been working on this project for a few months and while it doesn’t support a full Internet connection, the downlink on the high altitude balloon is fast enough to send high-resolution images in near-real-time. This is thanks to a Raspberry Pi Zero on board the balloon that is paired with an STM32 board which handles the radio communication on a RF4463 transceiver module. The STM32 acts as an intermediary or buffer to ensure reliable information is sent out on the radio, rather than using the Pi directly. [Stephen] also wrote a large chunk of the software responsible for handling all of these interactions, optimized for balloon flight specifically.
The blog post for this project was written a few weeks ago with a reported first launch date for the system already passed, so we will eagerly anticipate the results and the images he was able to gather using this system. Eventually [Stephen] hopes the downlink will be fast enough for video as well.Balloons are an underappreciated tool as well, and this isn’t the only way that they can be used to help send radio signals from place to place.
All you want is a decent night’s sleep, so you decide to invest in one of those fancy adjustable beds. At first, it’s fine — being able to adjust the mattress to your needs on the fly is a joy, and yet…something isn’t quite right. Something nags at you every night, thwarting your slumber and turning your dreams of peaceful sleep into a nightmare once you realize your bed has locked you into a vertically integrated software ecosystem from which there’s no escape.
Or is there? That’s what [Chris Laplante] wanted to know, and why he reverse-engineered his Tempur-Pedic remote control. As many products these days do, his bed was touted as having an Android application for smartphone adjustability, but alas, the app hasn’t been updated since 2014 (!) and doesn’t appear to work on modern phones. [Chris] decided to take matters into his own hands and build a gateway to talk to the bed using its native RF protocol.
Most good reverse engineering stories start with research, and this one is no exception. Digging into the FCC database revealed a wealth of clues, such as the frequency — 433-MHz ISM band, no surprise — and even spectrum analyzer screenshots of the remote’s signals. A HackRF One revealed more about the signals, but it turned out that sniffing in on the SPI bus between the microcontroller and the Si4431 RF transceiver with a Salae logic analyzer was more fruitful, allowing him to dig into the packet structure.
The engineers at Tempur-Pedic threw quite a few challenges at [Chris], like an application-level CRC in addition to the CRC used by the Si4431, and interesting complications to control the massage features of the bed. In the end, [Chris] managed to get a pretty complete snapshot of the conversation between the bed and the remote, and is now in the process of building a gateway that’ll actually connect to his phone, plus integrate into his home automation system. We’re looking forward to updates on that.
The amateur radio community often gets stereotyped as a hobby with a minimum age requirement around 70, gatekeeping airwaves from those with less experience or simply ignoring unfamiliar beginners. While there is a small amount of truth to this on some local repeaters or specific frequencies, the spectrum is big enough to easily ignore those types and explore the hobby without worry (provided you are properly licensed). One of the best examples of this we’ve seen recently of esoteric radio use is this method of using packet radio to play a game of Colossal Cave Adventure.
Packet radio is a method by which digital information can be sent out over the air to nodes, which are programmed to receive these transmissions and act on them. Typically this involves something like email or SMS messaging, so playing a text-based game over the air is not too much different than its intended use. For this build, [GlassTTY] aka [G6AML] is using a Kenwood TH-D72 which receives the packets from a Mac computer. It broadcasts these packets to his node, which receives these packets and sends them to a PDP-11 running the game. Information is then sent back to the Kenwood and attached Mac in much the same way as a standard Internet connection.
The unique features of packet radio make it both an interesting and useful niche within the ham radio community, allowing for all kinds of uses where data transmission might otherwise be infeasible or impossible. A common use case is APRS, which is often used on VHF bands to send weather and position information out, but there are plenty of other uses for it as well.
Continue reading “Long-Distance Gaming Over Packet Radio”
No matter what the job at hand is, if you’re going to tackle it, you’re going to need the right kit of tools. And if your job includes making sense out of any of the signals in the virtual soup of RF energy we all live in, then you’re going to need something like the FISSURE RF framework.
Exactly what FISSURE is is pretty clear from its acronym, which stands for Frequency Independent SDR-Based Signal Understanding and Reverse Engineering. This is all pretty new — it looks like [Chris Poore] presented a talk at DEFCON a few weeks back about using FISSURE to analyze powerline communications between semi-trucks and their trailers, and they’ve got a talk scheduled for next month’s GNU Radio Conference as well. We’ve been looking through all the material we can find on FISSURE, and it appears to be an RF hacker’s dream come true. They’ve got a few examples on Twitter, like brute-forcing an old garage door opener with a security code set by a ten-position DIP switch, and sending tire pressure monitoring system (TPMS) signals to a car. They also mention some of the framework’s capabilities on the GitHub README; we’re especially interested in packet crafting for various protocols. The video below has some more examples of what FISSURE can do.
It looks like FISSURE could be a lot of fun, and very handy for your RF analysis and reverse engineering work. If you’ve been using Universal Radio Hacker like we have, this looks similar, only more so. We’ll be downloading it soon and giving it a try, so be on the lookout for a hands-on report.
Continue reading “Introducing FISSURE: A Toolbox For The RF Hacker”
[Benjojo] got interested in where the magic number of 1,500 bytes came from, and shared some background on just how and why it seems to have come to be. In a nutshell, the maximum transmission unit (MTU) limits the maximum amount of data that can be transmitted in a single network-layer transaction, but 1,500 is kind of a strange number in binary. For the average Internet user, this under the hood stuff doesn’t really affect one’s ability to send data, but it has an impact from a network management point of view. Just where did this number come from, and why does it matter?
[Benjojo] looks at a year’s worth of data from a major Internet traffic exchange and shows, with the help of several graphs, that being stuck with a 1,500 byte MTU upper limit has real impact on modern network efficiency and bandwidth usage, because bandwidth spent on packet headers adds up rapidly when roughly 20% of all packets are topping out the 1,500 byte limit. Naturally, solutions exist to improve this situation, but elegant and effective solutions to the Internet’s legacy problems tend to require instant buy-in and cooperation from everyone at once, meaning they end up going in the general direction of nowhere.
So where did 1,500 bytes come from? It appears that it is a legacy value originally derived from a combination of hardware limits and a need to choose a value that would play well on shared network segments, without causing too much transmission latency when busy and not bringing too much header overhead. But the picture is not entirely complete, and [Benjojo] asks that if you have any additional knowledge or insight about the 1,500 bytes decision, please share it because manuals, mailing list archives, and other context from that time is either disappearing fast or already entirely gone.
Knowledge fading from record and memory is absolutely a thing that happens, but occasionally things get saved instead of vanishing into the shadows. That’s how we got IGNITION! An Informal History of Liquid Rocket Propellants, which contains knowledge and history that would otherwise have simply disappeared.
There’s something thrilling about decoding an unknown communications protocol. You start with a few clues, poke at the problem with some simple tools, and eventually work your way up to that first breakthrough that lets you crack the code. It can be frustrating, but when you eventually win, it can be very rewarding.
It seems that [Jason] learned this while decoding the wireless conversation between his mass-market quad and its controller. The quad in question, a Yuneec Q500, is one of those mid-range, ready-to-fly drones that’s targeted at those looking to get in the air easily and take some cool pictures. Unsure how the drone and controller were talking, [Jason] popped the covers and found a Zigbee chipset within. With the help of a $14 Zigbee USB dongle and some packet sniffing software from TI, [Jason] was able to see packets flowing, but decoding them was laborious. Luckily, the sniffer app can be set up to stream packets to another device, so [Jason] wrote a program to receive and display packets. He used that to completely characterize each controller input and the data coming back from the drone. It’s a long and strange toolchain, but the upshot is that he’s now able to create KML in real time and track the drone on Google Earth as it flies. The video below shows the build and a few backyard test flights.
Congratulations to [Jason] for breaking the protocol and opening up drones like this for other hackers. If you’re interested in learning more about Zigbee sniffing, you can actually hack a few smarthome gadgets into useful sniffers.
Continue reading “Drone Gives Up Its Wireless Secrets To Zigbee Sniffer”
Everyone’s favorite packet sniffing tool, Wireshark, has been around for almost two decades now. It’s one of the most popular network analysis tools available, partially due to it being free and open source. Its popularity guaranteed that it would eventually be paired with the ESP32/8266, the rising star of the wireless hardware world, and [spacehuhn] has finally brought these two tools together to sniff WiFi packets.
The library that [spacehuhn] created uses the ESP chip to save Pcap files (the default Wireshark filetype) onto an SD card or send the data over a serial connection. The program runs once every 30 seconds, creating a new Pcap file each time. There are many example scripts for the various hardware you might be using, and since this is written for the ESP platform it’s also Arduino compatible. [spacehuhn] has written this as a proof-of-concept, so there are some rough edges still, but this looks very promising as a network analysis tool.
[spacehuhn] is no stranger to wireless networks, either. His YouTube channel is full of interesting videos of him exploring various exploits and testing other pieces of hardware. He’s also been featured here before for using an ESP8266 as a WiFi jammer.
Continue reading “ESP To Wireshark”