Hacking the Internet of Things: Decoding LoRa

Getting software-defined radio (SDR) tools into the hands of the community has been great for the development and decoding of previously-cryptic, if not encrypted, radio signals the world over. As soon as there’s a new protocol or modulation method, it’s in everyone’s sights. A lot of people have been working on LoRa, and [bertrik] at RevSpace in The Hague has done some work of his own, and put together an amazing summary of the state of the art.

LoRa is a new(ish) modulation scheme for low-power radios. It’s patented, so there’s some information about it available. But it’s also proprietary, meaning that you need a license to produce a radio that uses the encoding. In keeping with today’s buzzwords, LoRa is marketed as a wide area network for the internet of things. HopeRF makes a LoRa module that’s fairly affordable, and naturally [bertrik] has already written an Arduino library for using it.

So with a LoRa radio in hand, and a $15 RTL-SDR dongle connected to a laptop, [bertrik] got some captures, converted the FM-modulated chirps down to audio, and did a bunch of hand analysis. He confirmed that an existing plugins for sdrangelove did (mostly) what they should, and he wrote it all up, complete with a fantastic set of links.

There’s more work to be done, so if you’re interested in hacking on LoRa, or just having a look under the hood of this new modulation scheme, you’ve now got a great starting place.

“Hello Barbie” Not an IoT Nightmare After All

Security researchers can be a grim crowd. Everything, when looked at closely enough, is insecure at some level, and this leads to a lot of pessimism in the industry. So it’s a bit of a shock to see a security report that’s filled with neither doom nor gloom.

We’d previously covered Somerset Recon’s initial teardown of “Hello Barbie” and were waiting with bated breath for the firmware dump and some real reverse engineering. Well, it happened and basically everything looks alright (PDF report). The Somerset folks desoldered the chip, dumped the flash ROM, and when the IDA-dust settled, Mattel used firmware that’s similar to what everyone else uses to run Amazon cloud service agents, but aimed at the “toytalk.com” network instead. In short, it uses a tested and basically sound firmware.

The web services that the creepy talking doll connected to were another story, and were full of holes that were being actively patched throughout Somerset’s investigation, but we were only really interested in the firmware anyway, and that looked OK. Not everything is horror stories in IoT security. Some stories do have a happy ending. Barbie can sleep well tonight.

Reverse Engineering The iPhone’s Ancestor

By all accounts, the ARM architecture should be a forgotten footnote in the history of computing. What began as a custom coprocessor for a computer developed for the BBC could have easily found the same fate as National Semiconductor’s NS32000 series, HP’s PA-RISC series, or Intel’s iAPX series of microprocessors. Despite these humble beginnings, the first ARM processor has found its way into nearly every cell phone on the planet, as well as tablets, set-top boxes, and routers. What made the first ARM processor special? [Ken Shirriff] potsed a bit on the ancestor to the iPhone.

The first ARM processor was inspired by a few research papers at Berkeley and Stanford on Reduced Instruction Set Computing, or RISC. Unlike the Intel 80386 that came out the same year as the ARM1, the ARM would only have a tenth of the number of transistors, used one-twentieth of the power, and only use a handful of instructions. The idea was using a smaller number of instructions would lead to a faster overall processor.

This doesn’t mean that there still isn’t interesting hardware on the first ARM processor; for that you only need to look at this ARM visualization. In terms of silicon area, the largest parts of the ARM1 are the register file and the barrel shifter, each of which have two very important functions in this CPU.

The first ARM chip makes heavy use of registers – all 25 of them, holding 32 bits each. Each bit in a single register consists of two read transistors, one write transistor, and two inverters. This memory cell is repeated 32 times vertically and 25 times horizontally.

The next-largest component of the ARM1 is the barrel shifter. This is just a device that allows binary arguments to be shifted to the left and right, or rotated any amount, up to 31 bits. This barrel shifter is constructed from a 32 by 32 grid of transistors. The gates of these transistors are connected by diagonal control lines, and by activating the right transistor, any argument can be shifted or rotated.

In modern terms, the ARM1 is a fantastically simple chip. For one reason or another, though, this chip would become the grandparent of billions of devices manufactured this year.

32C3: Dieselgate — Inside the VW’s ECU

[Daniel Lange] and [Felix Domke] gave a great talk about the Volkswagen emissions scandal at this year’s Chaos Communication Congress (32C3). [Lange] previously worked as Chief architect of process chain electronics for BMW, so he certainly knows the car industry, and [Domke] did a superb job reverse-engineering his own VW car. Combining these two in one talk definitely helps clear some of the smog around the VW affair.

[Lange]’s portion of the talk basically concerns the competitive and regulatory environments that could have influenced the decisions behind the folks at VW who made the wrong choices. [Lange] demonstrates how “cheating” Europe’s lax testing regime is fairly widespread, mostly because the tests don’t mimic real driving conditions. But we’re not sure who’s to blame here. If the tests better reflected reality, gaming the tests would be the same as improving emissions in the real world.

As interesting as the politics is, we’re here for the technical details, and the reverse-engineering portion of the talk begins around 40 minutes in but you’ll definitely want to hear [Lange]’s summary of the engine control unit (ECU) starting around the 38 minute mark.

[Domke] starts off with a recurring theme in our lives, and the 32C3 talks: when you want to reverse-engineer some hardware, you don’t just pull the ECU out of your own car — you go buy another one for cheap online! [Domke] then plugged the ECU up to a 12V power supply on his bench, hooked it up, presumably to JTAG, and found a bug in the firmware that enabled him to dump the entire 2MB of flash ROM into a disassembler. Respect! His discussion of how the ECU works is a must. (Did you know that the ECU reports a constant 780 RPM on the tacho when the engine’s idling, regardless of the actual engine speed? [Domke] has proof in the reverse-engineered code!)

The ECU basically takes in data from all of the car’s sensors, and based on a number of fixed data parameters that physically model the engine, decides on outputs for all of the car’s controls. Different car manufacturers don’t have to re-write the ECU code, but simply change the engine model. So [Domke] took off digging through the engine model’s data.

Long story short, the driving parameters that trigger an emissions reduction exactly match those that result from the EU’s standardized driving schedule that they use during testing — they’re gaming the emissions tests something fierce. You’ve really got to watch the presentation, though. It’s great, and we just scratched the surface.

And if you’re interested in our other coverage of the Congress, we have quite a collection going already.

Reverse Engineering the ARM ALU

[Dave] wanted to learn more about the ARM architecture, so he started with an image of the ARMV1 die. If you’ve had some experience looking at CPU die, you can make some pretty good guesses at what parts of the chip have certain functions. [Dave], however, went further. He reverse engineered the entire ALU–about 2,200 transistors worth.

Continue reading “Reverse Engineering the ARM ALU”

Hacking a KVM: Teach a Keyboard Switch to Spy

When it comes to large systems, there are a lot more computers than there are people maintaining them. That’s not a big deal since you can simply use a KVM to connect one Keyboard/Video/Mouse terminal up to all of them, switching between each box simply and seamlessly. The side effect is that now the KVM has just as much access to all of those systems as the human who caresses the keyboard. [Yaniv Balmas] and [Lior Oppenheim] spent some time reverse engineering the firmware for one of these devices and demonstrated how shady firmware can pwn these systems, even when some of the systems themselves are air-gapped from the Internet. This was their first DEF CON talk and they did a great job of explaining what it took to hack these devices.

Continue reading “Hacking a KVM: Teach a Keyboard Switch to Spy”

Hacking a $100 Signal Generator

Signal generators are a useful piece of kit to have on your electronics bench. The downside is that they tend to be rather expensive. If you have $100 to drop on a new toy, the MHS-5200A is a low cost, two channel, 25 MHz generator that can be found on eBay.

The downside is the software. It’s an ugly Windows interface that’s a pain to use. The good news is that [wd5gnr] reverse engineered the protocol so you don’t have to. This means other software can be developed to control the device.

When connected to a computer, this function generator shows up as a virtual USB serial port. The documentation that [wd5gnr] assembled lists all the serial commands you can send, and what they do. If you aren’t into manually setting waveforms from a serial terminal (who is?) there’s a tool for doing that automatically on Github. This takes in a CSV file describing a waveform, and programs the generator to make it for you.

The software is also compatible with Waveform Manager Plus, a free GUI tool for defining waveforms. Putting this all together, you can have a pretty capable waveform generator for less than $100.