Book Image

Practical Hardware Pentesting

By : Jean-Georges Valle
Book Image

Practical Hardware Pentesting

By: Jean-Georges Valle

Overview of this book

If you’re looking for hands-on introduction to pentesting that delivers, then Practical Hardware Pentesting is for you. This book will help you plan attacks, hack your embedded devices, and secure the hardware infrastructure. Throughout the book, you will see how a specific device works, explore the functional and security aspects, and learn how a system senses and communicates with the outside world. You’ll set up a lab from scratch and then gradually work towards an advanced hardware lab—but you’ll still be able to follow along with a basic setup. As you progress, you’ll get to grips with the global architecture of an embedded system and sniff on-board traffic, learn how to identify and formalize threats to the embedded system, and understand its relationship with its ecosystem. You’ll discover how to analyze your hardware and locate its possible system vulnerabilities before going on to explore firmware dumping, analysis, and exploitation. The reverse engineering chapter will get you thinking from an attacker point of view; you’ll understand how devices are attacked, how they are compromised, and how you can harden a device against the most common hardware attack vectors. By the end of this book, you will be well-versed with security best practices and understand how they can be implemented to secure your hardware.
Table of Contents (20 chapters)
1
Section 1: Getting to Know the Hardware
6
Section 2: Attacking the Hardware
12
Section 3: Attacking the Software

Chapter 10

  1. It is a test interface and protocol that allows us to talk with an internal test engine. The behavior of the test engine is not defined in JTAG itself but is engine-specific.
  2. TCLK, TDI, TDO, and TMS. They respectively are Test Clock, Test Data In, Test Data Out, and Test Mode Select. TCLK clocks the debug engine; the data comes in from TDI, out from TDO, and TMS manages the state transition of the debug engine.
  3. No, it was made to test the soldering of chips and PCBs; chip debugging was added later as an afterthought.
  4. Since IDCODE is present on the DR by default, the JTAGulator doesn't have to send data to the chip to receive an IDCODE! A BYPASS scan finds it since it puts the chip in BYPASS mode and sends a test pattern through it.
  5. http://openocd.org/doc/html/General-Commands.html: mwd, mww, mwh, and mwb. For example, it can be used to stop a watchdog. Look at the stm32f1x.cfg file in OpenOCD!
  6. Yes it is! Now you can execute your own TCL and...