Hacking The RF Protocol Of An Obscure Handheld Game

When you think old school handheld games, you probably imagine something like Nintendo’s Game Boy line or the Sega Game Gear. But outside of those now iconic systems, there was a vast subculture of oddball handheld games vying for a chunk of an adolescent’s weekly allowance. Many of these were legitimately terrible and frankly aren’t worth remembering, but a few offered unique features that were arguably ahead of their time.

One such game was Hasbro’s short-lived P-O-X. As explained by [Zachary Ennenga], the game didn’t spend much time on store shelves as its core concept of defeating undetectable alien invaders hell-bent on destroying our way of life proved to be more than a little problematic when it launched in September of 2001. But that doesn’t mean it didn’t have some cool ideas, such as a wireless ad-hoc multiplayer capability that let your game autonomously battle it out with other units that got close by.

Fascinated by this feature since his youth, [Zach] set out to study how this relatively cheap kid’s toy was able to pull this off back when even the flagship handheld consoles were still using physical link cables for multiplayer. He was aided in his quest by a particularly helpful patent, which not only gave him clues as to the frequency, data rate, modulation, and encoding of the RF signal, but even explained the game’s logic and overall structure. A lot of what was in the document seemed wishful thinking on the part of Hasbro, but reading through the marketing speak still uncovered some salient technical details.

A decoded P-O-X packet.

Armed with an RTL-SDR, GNU Radio, Inspectrum, and a bit of Python, [Zach] was able to identify the signal and begin the process of decoding it. This is where things get really interesting, as the details of his reverse engineering process are widely applicable for all sorts of unknown RF signals. Even if you’re like most people and have nearly zero interest in failed handheld games of the early 2000s, it’s well worth a read. The same techniques he uses to figure out the name and physical characteristics of the invisible foe his game is transmitting could one day help you figure out how to manipulate the data from that wireless weather station you’ve got in the backyard.

Once he figured out the major parts of the protocol, [Zach] moves on to creating his own packets and broadcasting them out in such a way that the real hardware will recognize it. He even comes up with some code that will automatically battle games which wander within range of his Yardstick One, which may come in handy during the inevitable P-O-X Renaissance.

While this might seem like a lot of effort to put into a game that most people have never even heard of, we’ll remind you that some of the greatest hacks to ever grace these pages have been born of similar pursuits. Even if you’re the only person in the world to directly benefit from your current line of research and experimentation, there’s still plenty of like-minded folks in this community that are all to happy to cheer you on from the sidelines.

ExpressLRS: Open Source, Low Latency, Long Range RC Protocol

One of the major choices a newcomer to the RC flying hobby must make is on the RC link protocol. To add the list of choices (or confusion) there is now a new open-source, low latency, and long-range protocol named ExpressLRS.

ExpressLRS’s claim to fame is high packet rates of up to 500 Hz, with plans for 1000 Hz, and latency as low as 5 ms. Long-range testing has pushed it out to 30 km with a flying wing (video below), but this is not unheard of for other protocols. Most modern RC protocols run either in the 2.4 GHz or 915/868 MHz bands, with the latter having a definite advantage in terms of range.

ExpressLRS has options to run on either band, using Semtech SX127x (915/868 MHz) or SX1280 (2.4 GHz) LoRa transceivers, connected to STM32, ESP32, or ESP8285 microcontrollers. The ESP microcontrollers also allow software updates over Wi-Fi.

We’re excited to see an open-source competitor to the proprietary protocols currently dominating the market, but several open-source protocols have come and gone over the years. Hardware availability and compatibility is a deciding factor for a new protocol’s success, and ExpressLRS already has an advantage in this regard. Existing Frsky R9 transmitters and receivers, and Immersion RC Ghost receivers are compatible with the firmware. There are also DIY options available, and the GitHub page claims that several manufacturers are working on official ExpressLRS hardware.

If you’re already into the RC hobby, and you have compatible hardware lying around, be sure to give it a try and give some feedback to the developers! One scenario we would like to see tested is high interference and congested band conditions, like at RC flying events.

All the source code and hardware designs are available on GitHub, and there are active community discussions on Discord. Continue reading “ExpressLRS: Open Source, Low Latency, Long Range RC Protocol”

Universal Radio Hacker

If you are fascinated by stories you read on sites like Hackaday in which people reverse engineer wireless protocols, you may have been tempted to hook up your RTL-SDR stick and have a go for yourself. Unfortunately then you may have encountered the rather steep learning curve that comes with these activities, and been repelled by a world with far more of the 1337 about it than you possess. You give up after an evening spent in command-line dependency hell, and move on to the next thing that catches your eye.

You could then be interested by [Jopohl]’s Universal Radio Hacker. It’s a handy piece of software for investigating unknown wireless protocols. It supports a range of software defined radios including the dirt-cheap RTL-SDR sticks, quickly demodulates any signals you identify, and provides a whole suite of tools to help you extract the data they contain. And for those of you scarred by dependency hell, installation is simple, at least for this Hackaday scribe. If you own an SDR transceiver, it can even send a reply.

To prove how straightforward the package is, we put an RTL stick into a spare USB port and ran the software. A little investigation of the menus found the spectrum analyser, with which we were able to identify the 433 MHz packets coming periodically from a wireless thermometer. Running the record function allowed us to capture several packets, after which we could use the interpretation and analysis screens to look at the binary stream for each one. All in the first ten minutes after installation, which in our view makes it an easy to use piece of software. It didn’t deliver blinding insight into the content of the packets, that still needs brain power, but at least if we were reverse engineering them we wouldn’t have wasted time fighting the software.

We’ve had so many reverse engineering wireless protocol stories over the years, to pick only a couple seems to miss the bulk of the story. However both this temperature sensor and this weather station show how fiddly it can be without a handy software package to make it easy.

Via Hacker News.

The Development Of A Lightweight Wireless Protocol

BANO[Texane] had been thinking about how to monitor the state of his garage door from a remote place. The door itself isn’t around any power outlets, and is a few floors away from where his server would be located in his apartment. This presented a few design challenges – namely, the sensor itself should have a wireless connection to the server, and being low power would be a great idea. This led to the development of a minimalist framework for wireless communication that allows a sensor to run for weeks without a battery swap.

The wireless protocol itself is based on a simple key value pair; each individual sensor, coupled with a NRF905 radio, has passes an address, a key, and a value. There are allowances for checksums and acknowledgement, but as the PDF says, this is a very minimal protocol.

With the software out of the way, [Texane] turned to the hardware. The microcontroller is a simple Arduino clone, paired with a radio and a coin cell on a small board. The micro spends most of its time in a low power state, with the sensor, in this case a reed switch, tied to an interrupt pin.

There was a problem with the power consumption of the radio, though: when the short 17-byte message was transmitting, there was a significant voltage drop. This was okay with a fully charged battery, but with a partially drained coin cell, the possibility of brownouts was high. A big cap in parallel was enough to offset this voltage drop.

It’s still a little expensive for an all-in-one home automation and monitoring system, but developing a functional wireless protocol and the hardware to go with it is no small feat. It’s actually a great piece of kit that [Texane] is sure to find a few uses for.