RTL-SDR: Seven Years Later

July 31, 2019 by Tom Nardi 40 Comments

Before swearing my fealty to the Jolly Wrencher, I wrote for several other sites, creating more or less the same sort of content I do now. In fact, the topical overlap was enough that occasionally those articles would get picked up here on Hackaday. One of those articles, which graced the pages of this site a little more than seven years ago, was Getting Started with RTL-SDR. The original linked article has long since disappeared, and the site it was hosted on is now apparently dedicated to Nintendo games, but you can probably get the gist of what it was about from the title alone.

When I wrote that article in 2012, the RTL-SDR project and its community were still in their infancy. It took some real digging to find out which TV tuners based on the Realtek RTL2832U were supported, what adapters you needed to connect more capable antennas, and how to compile all the software necessary to get them listening outside of their advertised frequency range. It wasn’t exactly the most user-friendly experience, and when it was all said and done, you were left largely to your own devices. If you didn’t know how to create your own receivers in GNU Radio, there wasn’t a whole lot you could do other than eavesdrop on hams or tune into local FM broadcasts.

Nearly a decade later, things have changed dramatically. The RTL-SDR hardware and software has itself improved enormously, but perhaps more importantly, the success of the project has kicked off something of a revolution in the software defined radio (SDR) world. Prior to 2012, SDRs were certainly not unobtainable, but they were considerably more expensive. Back then, the most comparable device on the market would have been the FUNcube dongle, a nearly $200 USD receiver that was actually designed for receiving data from CubeSats. Anything cheaper than that was likely to be a kit, and often operated within a narrower range of frequencies.

Today, we would argue that an RTL-SDR receiver is a must-have tool. For the cost of a cheap set of screwdrivers, you can gain access to a world that not so long ago would have been all but hidden to the amateur hacker. Let’s take a closer look at a few obvious ways that everyone’s favorite low-cost SDR has helped free the RF hacking genie from its bottle in the last few years.

Continue reading “RTL-SDR: Seven Years Later” →

Reverse Engineering Cyclic Redundancy Codes

June 27, 2019 by Ted Yapo 17 Comments

Cyclic redundancy codes (CRC) are a type of checksum commonly used to detect errors in data transmission. For instance, every Ethernet packet that brought you the web page you’re reading now carried with it a frame check sequence that was calculated using a CRC algorithm. Any corrupted packets that failed the check were discarded, and the missing data was detected and re-sent by higher-level protocols. While Ethernet uses a particularly common CRC, there are many, many different possibilities. When you’re reverse-engineering a protocol that contains a CRC, although it’s not intended as a security mechanism, it can throw a wrench in your plans. Luckily, if you know the right tool, you can figure it out from just a few sample messages.

A case in point was discussed recently on the hackaday.io Hack Chat, where [Thomas Flayols] came for help reverse engineering the protocol for some RFID tags used for race timing. Let’s have a look at the CRC, how it is commonly used, and how you can reverse-engineer a protocol that includes one, using [Thomas’] application as an example.

Continue reading “Reverse Engineering Cyclic Redundancy Codes” →

Homemade Magic Makes The Metcal Go

June 16, 2019 by Kerry Scharfglass 29 Comments

First soldering irons are often of the ~~Radioshack or Maplin~~ firestarter variety. They’re basically wall power shorted across a nichrome heater or similar with some inline resistance to make it harder to burn down the house. You plug them in, the current flows, and they get hot. Done.

If you stick with the hobby for a while, these eventually get replaced with something like the venerable HAKKO FX-888D or that one Weller everyone likes with the analog knob. These are much improved; having temperature control leads to a more consistently heated tip and much improved soldering experience.

Entering the electronics workplace one comes across the next level of quality soldering iron: high end HAKKOs, Metcals, JBCs, and the like. Using one of these irons is practically a religious experience; they heat in a flash and solder melts while you blink. They even turn off when you put the handpiece down! But they’re expensive to buy (hint: think used). What’s a hobbyist to do?

[SergeyMax] seems to have had this problem. He bit the bullet, figured out how the Metcal works, and made his own base. This is no mean feat as a Metcal might look like a regular iron but it’s significantly more complex than ye olde firestarter. The Metcal magic is based on a oscillating magnetic fields (notice the handpiece is connected via BNC?) interacting with a tip bearing a special coating. In the presence of the changing field the tip heats up until it hits its Curie temperature, at which point it stops interacting with the magnetic field and thus stops heating.

When the user solders, the tip cools by sinking its heat into the part and drops below the Curie temperature again, which starts the heating again. It’s like temperature control with the sensor placed absolutely as close to the part as possible and a nearly instant response time, without even a control loop! [SergeyMax] has a much more thorough description of how these irons work, which we definitely recommend reading.

So what’s the hack? Based on old schematics and some clever reverse engineering from photos [SergeyMax] built a new base station! The published schematic is as rich with capacitors and inductors as one could hope. He didn’t post source or fab files but we suspect the schematic and photos of the bare board combined with some tinkering are enough for the enterprising hacker to replicate.

The post contains a very thorough description of the reverse engineering process and related concerns in designing a cost efficient version of the RF circuitry. Hopefully this isn’t the last Metcal replacement build we see! Video “walkthrough” after the break.

Edit: I may have missed it, but eagle eyed commentor [Florian Maunier] noticed that [SergeyMax] posted the sources to this hack on GitHub!

Continue reading “Homemade Magic Makes The Metcal Go” →

Reverse Engineering WyzeSense Hardware

June 11, 2019 by Lewin Day 6 Comments

Wyze are a company that produces a variety of home automation products. Their Wyze Sense package is a system of contact and PIR home security sensors, that piggy backs off their Wyze Cam product. In the interests of being able to use this hardware outside the prescribed corporate ecosystem, [Xuan Xing] got down to hacking.

The project starts by tearing down the Wyze Cam, and getting serial console access. This was made easier by an existing Github project, which develops custom firmwares for smart cameras. With that in place he was able to see what was going on under the hood, and read the camera’s system logs.

By poring over these logs, and examining the disassembled Wyze Sense dongle, he’s well on the way to discovering how the sensors communicate with the Wyze Cam. The end goal is to enable the Wyze security sensors to be used with the Raspberry Pi platform, and to share the code on Github for other makers to experiment with.

Home automation platforms come and go quicker than the seasons change. This makes the hardware a popular target for hackers trying to get things running independently of any one company’s servers.

Hail To The King, Baby: Reverse Engineering Duke

June 8, 2019 by Tom Nardi 15 Comments

If you’re a fan of DOS games from the 1990s, you’ve almost certainly used DOSBox to replay them on a modern computer. It allows you to run software in a virtual environment that replicates an era-appropriate computer. That’s great for historical accuracy, but doesn’t do you much good if you’re trying to leverage modern computing power to breathe some new life into those classic titles. For that, you need to dig in a little deeper.

For the last two and a half years, [Nikolai Wuttke] has been doing exactly that for 1993’s Duke Nukem II. The end result is RigelEngine, an open source drop-in replacement for the original game binary that not only runs on a modern Windows, Linux, or Mac OS machine, but manages to improve on the original in a number of ways. An accomplishment made even more impressive once you learn that the original source code for the game has been lost to time, and that he had to do everything blind.

In a blog post chronicling his progress so far, [Nikolai] explains the arduous process he used to make sure his re-implementation was as accurate as possible to the original game. He spent untold hours studying the original game’s disassembled code in Ida Pro, handwriting out pages of notes and pseudocode as he tried to understand what was happening behind the scenes. Once a particular enemy or element of the game was implemented in RigelEngine, he’d record the gameplay from his version and compare it to the original frame by frame so he could fine tune the experience.

So what’s the end result of more than two years of work and over 25K lines of code? Thanks to the incredible advancements in computing power since the game’s release nearly 30 years ago, [Nikolai] has managed to remove the need for loading screens. His engine is also capable of displaying an unlimited number of particle effects on the screen at once, and multiple sound effects can now be played simultaneously. In the future he’s looking to implement smooth character movement (in the original game, movement was in 8 pixel increments) and adaptive volume for sound effects based on their distance from Duke. Ultimately, RigelEngine should be able to replace the original graphics with new high resolution textures once some issues with the rendering buffer gets sorted out.

It’s hard to overstate how important some of these classic games are to those who grew up playing them. With John Romero still releasing DLC for the original DOOM and hackers disassembling nearly 40 year old games to fix bugs, it doesn’t seem like they’re in any danger of being forgotten.

Continue reading “Hail To The King, Baby: Reverse Engineering Duke” →

Your Table Is Ready, Courtesy Of HackRF

June 4, 2019 by Tom Nardi 28 Comments

Have you ever found yourself in a crowded restaurant on a Saturday night, holding onto one of those little gadgets that blinks and vibrates when it’s your turn to be seated? Next time, bust out the HackRF and follow along with [Tony Tiger] as he shows how it can be used to easily fire them off. Of course, there won’t actually be a table ready when you triumphantly show your blinking pager to the staff; but there’s only so much an SDR can do.

Even if you aren’t looking to jump the line at your favorite dining establishment, the video that [Tony] has put together serves as an excellent practical example of using software defined radio (SDR) to examine and ultimately replicate a wireless communications protocol. The same techniques demonstrated here could be applied to any number of devices out in the wild with little to no modification. Granted these “restaurant pagers” aren’t exactly high security devices to begin with, but you’d be ~~horrified~~ surprised how many other devices out there take a similarly cavalier attitude towards security.

[Tony] starts by using inspectrum to examine the Frequency-shift keying (FSK) modulation used by the 467.750 Mhz devices, and from there, uses Universal Radio Hacker to capture the actual binary data being sent over the air. Between studying the transmissions and the information he found online, he was eventually able to piece together the packet structure used by the restaurant’s base station.

Finally, he wrote a Python script which generates packets based on which pager he wants to set off. If he’s feeling particularly mischievous, he can even set them all off at once. The script outputs a binary file which is then loaded into GNU Radio for transmission via the HackRF. [Tony] says he’s not quite ready to release his script yet, but he gives enough information in the video that the intrepid hacker could probably get their own version up and running by the time he gets it posted up to GitHub anyway.

We saw some very similar techniques demonstrated at the recent WOPR Summit security conference, so once you’re done hacking the local restaurants, you can take these same lessons and apply them to the rest of the Internet of Things. If you’re wondering, it’s even easier to eavesdrop on the non-restaurant pagers.

Continue reading “Your Table Is Ready, Courtesy Of HackRF” →

Solving The Final Part Of The IClicker Puzzle

May 21, 2019 by Tom Nardi 9 Comments

The regular Hackaday reader might remember the iClicker from our previous coverage of the classroom quiz device, or perhaps you even had some first hand experience with it during your university days. A number of hackers have worked to reverse engineer the devices over the years, and on the whole, it’s a fairly well understood system. But there are still a few gaps in the hacker’s map of the iClicker, and for some folks, that just won’t do.

[Ammar Askar] took it upon himself to further the state of the art for iClicker hacking, and has put together a very detailed account on his blog. While most efforts have focused on documenting and eventually recreating how the student remotes send their responses to the teacher’s base station, he was curious about looking at the system from the other side. Specifically, he wanted to know how the base station was able to push teacher-supplied welcome messages to the student units, and how it informed the clients that their answers had been acknowledged.

He started by looking through the base station’s software update tool to find out where it was downloading the firmware files from, a trick we’ve seen used to great effect in the past. With the firmware in hand, [Ammar] disassembled the AVR code in IDA and got to work piecing together how the hardware works. He knew from previous group’s exploration of the hardware that the base station’s Semtech XE1203F radio is connected to the processor via SPI, so he started searching for code which was interacting with the SPI control registers.

This line of logic uncovered how the radio is configured over SPI, and ultimately where the data intended for transmission is stored in memory. He then moved over to running the firmware image in simavr. Just like Firmadyne allows you to run ARM or MIPS firmware with an attached debugger, this tool allowed [Ammar] to poke around in memory and do things such as simulate when student responses were coming in over the radio link.

At that point, all he had to do was capture the bytes being sent out and decode what they actually meant. This process was complicated slightly by the fact the system uses to use its own custom encoding rather than ASCII for the messages, but by that point, [Ammar] was too close to let something like that deter him. Nearly a decade after first hearing that hackers had started poking around inside of them, it looks like we can finally close the case on the iClicker.