The Demystifying Tech Podcast invited me back as a guest, and during the conversation the security of elections was discussed. It was given only a few minutes between other items which is a real shame, so I thought I’d expand on some of the points I made here and give a little bit of an introduction to the prior art of election hacking.
I wanted to talk a little bit about the British Airways breach; I won’t be focusing on the intention to fine from the ICO. I’ll just be talking a little about vulnerabilities, how they can be addressed, and the issues mitigations may bright. I’ll also be talking about a security incident that hit the ICO and how it was potentially very similar to what happened to British Airways.
I previously mentioned dumping memory contents using SPI, with a BusPirate. Sometimes that’s not feasible – such as if the flash memory module is a little inaccessible and you’re not feeling like deconstructing the board just yet.
An alternative is to pull memory over JTAG. I talked about accessing JTAG and interacting with a chip using OpenOCD previously, however this time around I’d like to go a step further.
The board I’m using in this example is a Netgear DG834Gv1, which has an exposed JTAG, shown below on the bottom right of the board (in red):
So I’m playing around with a device right now and I’m currently pulling out the contents of its flash memory over SPI – so I figured I’d write a few notes about how to do just that!
Here’s what I’m playing with, in case you’re curious:
Cloning basic Keyfobs using GNURadio and an SDR!
In my introduction to hardware hacking, I mention that radio systems may be part of the attack surface for a hardware device penetration test. So I thought I’d give a gentle introduction to hacking with an SDR here!
Firstly, what’s an SDR? It stands for software-defined radio, and refers to a category of devices which allow you to interface with radio. There are a lot of SDR devices on the market to choose from when you first get started – a RTL-SDR can be picked up for £15 and devices from Ettus Research go well into the thousands of pounds.
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.
Getting up and running with PulseView and reading pin output with an Analyzer!
Logic Analyzers are inexpensive devices that allow you to just take a look at what a small number of pins on a chip are up to. They can be hooked into software like PulseView to read pin output and decode it into something more useful. Many decoders are available, but in this introduction we’ll have a quick look at PulseView and reading (decoding) UART data.
I’ve previously written about UART and how to find them with a JTAGulator, but here’s a different approach.
Discovering UART with the JTAGulator and connecting to it with UART PassThrough and a USB-to-UART!
UART stands for Universal Asynchronous Receiver/Transmitter, however in the context of Hardware Hacking we’re generally looking for an serial interface which will give us text output from the system and possibly allow for command input. The general intention from the manufacturers point of view – is to allow easy debugging, both out of the factor (to check the system is working as intended) and if a device is returned as broken.
Discovering JTAG ports with the JTAGulator, and connecting to them with UM232H!
What is JTAG?
JTAG is short for Joint Test Action Group and generally refers to on-chip debugging interfaces that follow the IEEE 1149.x standard. The standard doesn’t mandate a certain connection – it just dictates a standard for communicating with chips in a device. It uses 5 pins: TCK, TMS, TDI, TDO and (options) TRST; which are (Test) Clock, Mode Select, Data In, Data Out, and Reset.
It can be useful to hardware hackers in various ways, such as extracting device IDs, extracting firmware, overwriting memory.
This week I was asked some specific questions about the security of iframes. The questions came about from a PCI standpoint, for stores that use fully outsourced iframes for taking payment.
Short answer: The attacks are very limited.