Introduction Welcome back to our series on an introduction to hardware hacking! In this post we will be covering the Serial Peripheral Interface (SPI) protocol, a commonly used serial bus protocol which allows hardware components to communicate with each other. The goal of this post is to serve as a guide for security researchers and hardware hackers to easily interface with target devices. Many embedded devices use SPI to access persistent data stored on flash memory.
Welcome to an introduction to hardware hacking! This series will discuss the basics of interacting with an embedded device though various hardware interfaces. Our team performs penetration testing on IoT / embedded devices every day, and we’re excited to share some of our knowledge and experiences to help those getting started with hardware security learn the ropes. This is a multi-part series which discusses the fundamental concepts, useful tools, and practical techniques which you can use to approach a basic hardware assessment.
For our first blog post in this series, we will focus on a very common type of debug serial communication protocol that can be used to obtain low-level access to a wide range of devices.
In our previous blog, we described some examples of where binary hashing can help solve problems and compared a number of algorithms for both basic block and graph aware hashing. Today we are releasing a tool, Hashashin, which combines some of these algorithms to allow security researchers to port Binary Ninja annotations from one binary to another.
As security researchers, we often spend a lot of time looking into the internals of libraries in products we are assessing. With this come some common time sinks, such as identifying library versions. While library version identification is relatively straightforward on the surface, other tasks are clearly more challenging – such as applying signatures to stripped binaries, porting defined types across libraries, and similar codebases.
In this post, we continue our series on RF4CE by discussing the mechanisms the protocol uses for security. We encourage you to read the first post for background on the purpose of this post and discussion of security levels and keying techniques. This post will explain how RF4CE devices pair and how payloads are encrypted and protected. Additionally, we’ll explain some of the problems with RF4CE security, and discuss potential remediations.
My team talks a lot about “proactive security” – the concept of baking cybersecurity measures into architecture and design as opposed to responding to vulnerabilities and breaches when they occur. However, I lacked a quantitative answer when recently asked: “how do you convince businesses to start being proactive?”
In the course of security assessments we often come across protocols and communication methods that are not widely known outside of specific industry use. This article is the first in a series of deep dives on one such protocol, RF4CE. In this article, we talk about the background of RF4CE and its use cases, as well as providing an introduction to the basics of RF4CE.
This year at INFILTRATE 2019, I got together with fellow RPISEC alumnus and Boston Cybernetics Institute co-founder Jeremy Blackthorne to present “Three Heads Are Better Than One: Mastering NSA’s Ghidra Reverse Engineering Tool”. Around 50 minutes into that presentation, I presented a demo of a proof of concept script I built to trace out how inputs to malloc are derived. In this blog post, we’ll take a deeper look at that script.
Windows developers may be familiar with “banned.h” or “strsafe” libraries. Introducing safe libraries to development is nothing new, as was covered in the 2007 presentation on SDL for Windows Vista (slide 7). While basic, these basic libraries have been shown to provide significant value - as discussed later in the deck, 41% of bugs that Microsoft removed in Vista early on were due to removal of ‘banned’ API function calls.
This is the first of a multi-part series where we will share some of our methodology for supply chain verification in situations where there is very limited information. This content was previously shared by Sophia d’Antoine at Square’s r00ted1 Conference on November 14th, 2018 in NYC. We have previously shared our thoughts on the importance of supply chain validation with regard to hardware attacks, but this blog series will delve deeper into the specifics related to case alleged in Bloomberg Businessweek’s “The Big Hack” article.