An Introduction to Hardware Hacking

I’m currently writing up a series on hardware hacking fundamentals, and before I get into the specifics – I thought it sensible to add a piece on why hardware security is important and to lay out the major themes of what I’ll be discussing.

Firstly, with physical devices, threat actors have more options when it comes to attacking the devices and it should be noted that breaking a specific device might not be the final aim. As an attacker over the internet, I only have exposed network services to “play” with, but if I’m testing a physical device the attack surface can be much wider. With options including network services, radio frequency input/output, on-chip debugging, exposed serial ports, memory extraction, etc, etc.

Additionally, once I’ve broken the device I have physical access to I may be able to use the discovered vulnerabilities (or extracted access keys) to compromise other devices. In fact, that’s kind of the point.

Pulling apart each device to gain root access to it is not really a viable plan, but compromising one device and using the information gained the compromise all the devices, is well…a lot better for the threat actor.

But I mentioned lots of things a second ago and then walked on past them, so let’s take a quick look at terminology, and a little bit of the attack surface:

Attack Surface

Network Services

Exposed services on the device can of course be compromised, and there’s not really a lot to add here other than we consider all of the issues discussed under the categories of Web Application and Infrastructure vulnerabilities.

This could be something as simple as outdated software, or as complicated as blind command injection.

However it’s worth pointing out that one (hardware hacking) can inform the other (web app hacking). For example, a command injection vulnerability in the administrative interface of a device is a great thing, and having access to the source code of an application can make it easier to find those, and hardware hacking techniques can lead to source code extraction from a device.

Radio Frequency Input/Output

Devices don’t only communicate over cables, or common communication protocols like WiFi, there are other things to play with! I’m reminded of a great talk by Natalie “Natashenka” Silvanovich back in around 2013 where she discussed hardware hacking Tamagotchi. If you haven’t seen that talk, I recommend it as a fun way into the major themes of hardware hacking. She mentions that Tamagotchi also have Infrared (IR) communications and that it is a possible attack vector.

In the context of hardware hacking you might come across BLE (Bluetooth Low Energy), ZigBee, FM RDS. Attacking RF communications can be achieved with an SDR – a Software-defined Radio.

You might also see the term USRP™ (Universal Software Radio Peripheral), which in short, is what Ettus call their SDR.

These transceivers aren’t necassarily as large as you might expect; for example here’s a Ettus b200mini USRP (70MHz – 6GHz), minus its antennas:

On-Chip Debugging

Many devices have on-board methods of testing them. I often hear people laugh at manufacturers for having these, especially where hackers have leveraged them to compromise a device – but they’re there for an important reason.

If you’re manufacturing devices, which can be a fairly expensive process, it’d be great to have a method of testing these when they pop-off the far end of the assembly line. Was the complete manufacturing process successful or is this a batch of duds? What about if a customer returns some devices to you saying they’re broken – are they broken? how are they broken?

On-board, or on-chip, interfaces that allow you to interact with the system can make those problems easier to deal with. But yes, they can make messing around with the systems internals and breaking security easier too.

In this context we’re talking about things like “JTAGing”. JTAG (Joint Test Action Group) refers to a standard for verifying and testing devices; usually when it’s used in the context of hardware hacking you’ll hear things like “JTAG port”, which can be a little misleading.

The JTAG standard (IEEE 1149.x) doesn’t define any kind of connector, it’s simply a standard that defines a serial protocol for interacting with chips. It can often be found internally as a group of pins set off to one side, but it could just as easily be exposed only by clipping into pins on the controller.

Here’s an example of a JTAG, neatly exposed on a board as a set of connectors:

Exposed Serial Ports (UART)

Serial connections or UART (Universal Asynchronous Receiver/Transmitter) are connections on-board which can allow you to see what the device is up to and sometimes supply it input. There term is generic for serial input-output, but often refers to a connection on a device which supplies text-based output.

You can often hook into the device with a USB-to-UART and use a terminal emulator like PuTTY to interact with the running operating system or receive debugging output.

Memory Extraction

Many devices have storage chips on-board, which you may be able to extract the contents from. That doesn’t necessarily mean those contents will be not be enciphered – so there may be additional work to do, such as extracting the encryption key.

However sometimes you can access the storage chip, interact with it to dump its contents and then be able to look at the software the system runs – you might even be able to modify it directly – allowing you to change access key, expose services such as telnet/ssh, or disable firewalls such as iptables on embedded Linux systems.