Sometimes, security mechanisms can be bypassed if you just do things slightly out of the ordinary. For instance, readout protection on microcontrollers is a given nowadays, to the point where it’s intentionally enabled and relied upon as a major technical measure to protect intellectual property. The gist is — when you connect to a microcontroller over its debug interface and then ask to read its flash memory, it will politely refuse. However, [Racerxdl] shows us that in practice, it’s not flawless protection – for certain chips, you just need to be a little quicker than usual.
Usually, flashing and debugging software will chat with the microcontroller for a bit, and probe parameters before going for any direct requests. However, if you skip the courtesy and bluntly get to the point immediately right after power is applied to the microcontroller, you can intimidate them just enough to give you one byte of its memory before it refuses to cooperate further. Since that can be any byte you wish, you can read the entire flash — one byte at a time.
You need to power cycle the chip before you can progress, so the hardware does involve a bit more than just an SWD interface, and it will take a fair bit more time than reading out a non-protected chip the usual way; plus, of course, the debugging interface needs to be active for this in the first place, which isn’t always the case. However, it still beats paying a few thousand dollars for a factory in China to decap your chip and read it out using a fancy machine.
[Racerxdl] didn’t just write a proof-of-concept for this attack – they implemented it for one of our favourite chips, the RP2040. As such, you no longer need an unobtainium STM32 to dump an unobtainium STM32.
To be clear, [Racerxdl] didn’t design this attack — it’s been around for some time now. Credit for that goes to Johanes Obermaier. All in all, this is a wonderful reminder that seemingly reliable security mechanisms can be foiled by the simplest tricks. For instance, if your chip erases the flash when you unlock its protection, you can just tell it not to.
Here on Hackaday, we routinely cover wonderful informative writeups on different areas of hardware hacking, and we even have our own university with courses that delve into topics one by one. I’ve had my own fair share of materials I’ve learned theory and practical aspects from over the years I’ve been hacking – as it stands, for over thirteen years. When such materials weren’t available on any particular topic, I’d go through hundreds of forum pages trawling for details on a specific topic, or spend hours fighting with an intricacy that everyone else considered obvious.
Today, I’d like to highlight one of the most complete introductions to hardware hacking I’ve seen so far – from overall principles to technical details, spanning all levels of complexity, uniting theory and practice. This is The Hardware Hacking Handbook, by Jasper van Woudenberg and Colin O’Flynn. Across four hundred pages, you will find as complete of an introduction to subverting hardware as there is. None of the nuances are considered to be self-evident; instead, this book works to fill any gaps you might have, finding words to explain every relevant concept on levels from high to low.
Apart from the overall hardware hacking principles and examples, this book focuses on the areas of fault injection and power analysis – underappreciated areas of hardware security that you’d stand to learn, given that these two practices give you superpowers when it comes to taking control of hardware. It makes sense, since these areas are the focus of [Colin]’s and [Jasper]’s research, and they’re able to provide you something you wouldn’t learn elsewhere. You’d do well with a ChipWhisperer in hand if you wanted to repeat some of the things this book shows, but it’s not a requirement. For a start, the book’s theory of hardware hacking is something you would benefit from either way. Continue reading “Books You Should Read: The Hardware Hacker’s Handbook”→
One doesn’t always have the luxury of sipping tea comfortably while hacking a piece of hardware at a fully-equipped workbench, where every tool is within reach. To address this, [Zokol] shares an early look at a hardware hacking toolkit-in-progress, whose purpose is to make hacking sessions as productive as possible while keeping size and weight within reasonable limits. There isn’t a part list yet, but there are some good tips on creating your own.
To put together an effective hardware hacking toolkit, one must carefully consider what kinds of tasks need to be performed, and in what order. Once a basic workflow is identified, one can put together a set of complementary hardware tools and resources to meet the expected needs. The goal is to have the tools to go as far as one can in a single session, and identify any specialized equipment that will be needed later. That way, follow-up sessions can be as effective as possible.
Since hardware hacking is all about inspecting (and possibly modifying the behavior of) electronic devices, [Zokol] observes that step one is always to begin with external interfaces. That means common cables and adapters should all be part of a hardware hacking toolkit, otherwise the session might end awfully early. The next step is to open the device, so common tools and ways to deal with things like adhesives are needed. After that, diagnostic tools like multimeters come into play, with tools becoming more specialized as investigation proceeds. It’s a very sensible way to approach the problem of what to bring (and not bring) in a hardware hacking toolkit, and we can’t wait to see what the final version looks like.
Back at the 2017 Superconference, Hackaday Managing Editor Elliot Williams started his talk about the so-called “Internet of Things” by explaining the only part he doesn’t like about the idea is the Internet… and the things. It’s a statement that most of us would still agree with today. If anything, the situation has gotten worse in the intervening years. Commercial smart gadgets are now cheaper and more plentiful than they’ve ever been, but it seems like precious little has been done to improve their inherent privacy and security issues.
But his talk doesn’t serve to bash the companies producing these devices or even the services that ultimately folded and left their customers with neigh useless gadgets. That’s not his style. The central theme of “Nexus Technologies: Or How I Learned to Love WiFi”is that a smart home can be wonderful thing, assuming it works the way you want it to. Elliot argues that between low-cost modular hardware and open source software, the average hacker has everything they need to build their own self-contained home automation ecosystem. One that’s not only cheaper than what they’re selling at the Big Box electronics store, but also doesn’t invite any of the corporate giants to the party.
Of course, it wasn’t always so. A decade ago it would have been all but impossible, and five years ago it would have been too expensive to be practical. As Elliot details his journey towards a truly personal smart home, he explains the advances in hardware and software that have made it not just possible on the DIY level, but approachable. The real takeaway is that once more people realize how cheap and easy it is to roll your own smart home gadgets, they may end up more than willing to kick Big Brother to the curb and do IoT on their own terms.
This previously unpublished recording somehow slipped between the cracks of the editing room floor but upon recent discovery, it’s still just as relevant today. Take a look at Elliot’s view on Nexus Technologies, then join us after the break for a deeper dive. Make sure to subscribe to Hackaday’s YouTube channel to get in on the 2019 Hackaday Superconference live stream starting Saturday, November 16th.
The millennium: a term that few had any use for before 1999, yet seemingly overnight it was everywhere. The turning of the millenium permeated every facet of pop culture. Unconventional popstars like Moby supplied electronica to the mainstream airwaves while audiences contemplated whether computers were the true enemy after seeing The Matrix. We were torn between anxiety — the impending Y2K bug bringing the end of civilization that Prince prophesied — and anticipation: the forthcoming release of the PlayStation 2.
Sony was poised to take control of the videogame console market once again. They had already sold more units of the original PlayStation than all of their competition combined. Their heavy cloud of influence over gamers meant that the next generation of games wasn’t going to start in until the PS2 was on store shelves. On the tail of Sony announcing the technical specs on their machine, rumors of a new competitor entering the “console wars” began to spread. That new competitor was Microsoft, an American company playing in a Japanese company’s game. Continue reading “How The Xbox Was Hacked”→
The problem in the Pwn2Win CTF came in the form of the design files for a hypothetical rocket launch code. The custom IC takes an ASCII string as input, and flips a pin high if it matches. Probably the simplest way to do this in logic is to implement a shift register that’s long enough for the code string’s bits, and then hard-wire some combinatorial logic that only reads true when all of the individual bits are correct.
Anyway, back to our story. After reversing the netlist, [q3k] located 320 flip-flops in a chain, suggesting a 40-byte ASCII code string. Working backward in the circuit from the “unlocked” pin to the flip-flops, he found a network of NOR and NAND gates, which were converted into a logic notation and then tossed into Z3 to solve. Some cycles later, he had pulled the password straight out of the silicon!
This looks like a really fun challenge if you’re into logic design or hardware reverse engineering. You don’t have to write your own tools to do this, of course, but [q3k] would say that it was worth it.
Thanks [Victor] for the great tip!
Featured image by David Carron, via Wikipedia.
[Films By Kris Hardware] has started quite an interesting YouTube series on hacking and owning a PogoPlug Mobile v4. While this has been done many times in the past, he gives a great step by step tutorial. The series so far is quite impressive, going into great detail on how to gain root access to the device through serial a serial connection.
PogoPlugs are remote-access devices sporting ARM processor running at 800 MHz, which is supported by the Linux Kernel. The version in question (PogoPlug Mobile v4) have been re-purposed in the past for things like an inexpensive PBX, an OpenWrt router and even a squeezebox replacement. Even if you don’t have a PogoPlug, this could be a great introduction to hacking any Linux-based consumer device.
So far, we’re at part three of what will be an eight-part series, so there’s going to be more to learn if you follow along. His videos have already covered how to connect via a serial port to the device, how to send commands, set the device up, and stop it calling home. This will enable the budding hacker to make the PogoPlug do their bidding. In this age of the cheap single-board Linux computer, hacking this type of device may be going out of style, but the skills you learn here probably won’t any time soon.