Chapter 1.
Prologue - Who is this book for? The flow of hacking

Chapter 2.
Hacking Flow

2.1 Target Selection
2.2 Equipment Analysis
2.3 Obtaining the firmware
2.3.1 Using 1-Day Attack Code
2.3.2 Hardware Hacking - Using Debugging Ports
2.3.3 Flash Memory Dump
2.4 Firmware Analysis
2.4.1 System Configuration Analysis
2.4.2 Analyzing the Firmware Image
2.4.3 Dynamic Analysis
2.5 Modifying the firmware image
2.6 Exploiting Vulnerabilities
2.7 ARM Exploitation

Chapter 3.
Selecting hacking targets

3.1 Between Legal and Illegal
3.2 Selecting an attack point
3.3 Attack Surface
3.4 Attack Models and Attack Vectors
3.5 Threat Model and Security Assets
3.6 Thinking like a hacker
3.7 Bug Bounty
3.8 Conclusion

Chapter 4.
Components of embedded devices

4.1 Embedded Hardware
4.1.1 Embedded Board Components
4.1.2 Chips on embedded boards
4.1.3 Current Test
4.1.4 UART
4.1.5 JTAG
4.1.6 Peripheral Devices
4.2 Embedded Software
4.2.1 Boot flow of embedded devices
4.2.2 Bootloader
4.2.3 PBL (Primary Boot Loader or Rom Boot Loader
4.2.4 SBL(Secondary Boot Loader)
4.2.5 UBoot
4.2.6 Operating System
4.2.7 Device Drivers
4.2.8 Filesystem
4.2.9 Services and Processes
4.2.10 RTOS
4.3 Firmware Integrity Verification and Encryption
4.4 Conclusion

Chapter 5.
Hardware serial communication

5.1 Synchronous and Asynchronous Serial Communication
5.2 Serial Communication Practice
5.3 Atmega128 Development Equipment
5.4 LED Control Practice with Atmega128
5.5 Implementing UART serial with Atmega128
5.6 Using the USB Serial Converter
5.7 SPI Communication
5.8 The Birth of SPI Communication
5.9 Understanding SPI Communication
5.10 Final

Chapter 6.
Obtaining firmware through the debugging port

6.1 UART Hacking
6.1.1 Utilizing UART Debugging
6.1.2 Finding UART Pins
6.1.3 UART Pin Finding Practice
6.1.4 Checking UART using a multimeter
6.1.5 Connecting UART Serial
6.1.6 Analyzing UART signals using a logic analyzer
6.1.7 Analyzing UART Debugging Messages
6.1.8 Getting a boot shell via UART
6.1.9 Dumping firmware using the boot shell SPI command
6.1.10 Checking Firmware Configuration with Binwalk
6.1.11 Boot Shell - Dumping the Firmware with the md (memory display) Command
6.2 JTAG Hacking
6.2.1 What is JTAG?
6.2.2 JTAG Connection
6.2.3 Finding JTAG Pins
6.2.4 Defining JTAG Pins Using JTAGulator
6.2.5 Finding the Raspberry Pi TJAG Pins Using JTAGulator
6.2.6 Various JTAG debugger equipment
6.3 JTAG Security

Chapter 7.
flash memory

7.1 Flash Memory Types
7.2 Why do we need to dump flash memory?
7.3 Finding NAND Flash on an Embedded Board
7.4 Memory Package Types
7.5 Protocol-Specific Packaging Features
7.6 Finding Memory Chip Candidates on the Board
7.7 Reading the serial number of flash memory
7.8 Data Sheet
7.8.1 Obtaining a Data Sheet
7.8.2 Obtaining Chip Information
7.8.3 Understanding the Data Sheet - SPI
7.8.4 Understanding the Data Sheet - SPI (Read)
7.8.5 Understanding the Data Sheet - SPI (REMS)
7.8.6 Understanding Data Sheets - MMC
7.8.7 Understanding the Data Sheet - UFS
7.8.8 Security of Data Sheets
7.9 Connecting Flash Memory
7.9.1 Connecting to Memory Chip Pins - Direct Soldering and Jumper Connections
7.9.2 Connecting to Memory Chip Pins - Using Memory Clips (Pin Clamps)
7.9.3 Connecting to Memory Chip Pins - Hook Grabber Clip
7.9.4 Connecting to Memory Chip Pins - BGA Desoldering
7.9.5 Connecting to Memory Chip Pins - BGA Resoldering

Chapter 8.
Flash memory dump

8.1 Memory Dump - Atmega128
8.1.1 SPI Communication Settings
8.1.2 Reading the Manufacturer ID
8.1.3 Reading Flash Memory Data
8.2 Memory Dump - Raspberry Pi
8.2.1 Raspberry Pi
8.2.2 Flash ROM Project
8.2.3 Installing the Raspberry Pi Operating System
8.2.4 Burning the Raspberry Pi Image
8.2.5 Installing SSH on the Raspberry Pi
8.2.6 Writing Images
8.2.7 Raspberry Pi SSH Connection
8.2.8 Enabling Raspberry Pi SPI
8.2.9 Installing Flash ROM
8.2.10 Dumping ROM Memory with Flash ROM
8.2.11 Unsupported chipset dump in flashrom
8.2.12 Working with the SPIdev Python Package
8.3 Memory Dump - beeprog3
8.3.1 Beeprog
8.3.2 Memory Desoldering
8.3.3 Connecting Memory Sockets
8.3.4 Installing Befrog Software
8.3.5 Non-Prog Connection
8.3.6 Memory Chip Dump
8.4 Memory Dump - Allsocket
8.4.1 Purchasing All-Socket Equipment
8.4.2 FTK Imager Dump
8.5 Conclusion

Chapter 9.
Analyzing the firmware

9.1 Firmware structural analysis sequence
9.2 Binwork
9.2.1 Installing and Running Binwork
9.2.2 Extracting a Filesystem from an Image
9.3 Carving
9.3.1 LZMA Carving
9.3.2 Squashfs Carving
9.4 Static Analysis
9.4.1 Static Analysis Tools - IDA vs. Ghidra
9.4.2 IDA vs. Ghidra
9.4.3 Building an RTOS Image Static Analysis Environment
9.4.4 Finding the base address
9.4.5 Identifying Hardware Variables
9.5 Dynamic Analysis
9.5.1 Emulating the Firmware Executable - 1
9.5.2 Emulating the Extracted Firmware Binary - 2
9.5.3 Tracing the execution flow of firmware - strace
9.5.4 Dynamically Analyzing Firmware Executables - gdb
9.5.5 Setting up the QEMU system environment
9.5.6 Building qemu-system-arm32
9.5.7 Building qemu-system-aarch64
9.5.8 UNICORN Emulator
9.6 Bootloader Analysis
9.6.1 Bootloading Method
9.6.2 Bootloader Reversing
9.6.3 Utilizing Open Source
9.7 Kernel Analysis
9.7.1 Kernel Image Analysis Methodology
9.7.2 Kernel Driver Analysis
9.7.3 Structure of Kernel Drivers
9.7.4 Embedded Device Driver Analysis
9.8 Filesystem Analysis
9.8.1 Why study file system structure?
9.8.2 Working with File Systems
9.8.3 Squashfs
9.8.4 CPIO
9.8.5 EXT4
9.8.6 JFFS and JFFS2
9.8.7 CRAMFS
9.8.8 UBIFS
9.9 Analyzing Custom Firmware
9.9.1 Starting the Analysis of Modified Firmware
9.9.2 Analyzing Modified UBIFS Images
9.9.3 010 Editor Analysis
9.9.4 Revised UBI Data Analysis
9.9.5 Extracting Data from Modified UBI
9.10 Final

Chapter 10.
Modify the firmware to obtain an analysis shell

10.1 Determine where to edit
10.2 Planting a Backdoor
10.3 Attempting to connect with modified firmware
10.4 How to open various backdoors
10.4.1 Opening a backdoor using a command that allows remote access
10.4.2 Opening a backdoor via the download command
10.4.3 Opening a backdoor through program creation
10.5 Configuring the Debugging Environment

Chapter 11.
Creating an Analysis Tool

11.1 Creating an Analysis Tool
11.1.1 Cross Compilation
11.1.2 Setting up the cross-compilation environment
11.1.3 Installing the Cross Compiler
11.1.4 Cross Compiling
11.1.5 Static Cross-Compiling the Strace Analysis Tool
11.1.6 Verifying strace operation
11.2 Creating an Embedded Analysis Tool Through Hooking
11.2.1 Preloading Linux Libraries
11.2.2 Hooking a Library Using a Preloader
11.2.3 OpenSSL Hooking Practice
11.2.4 Global Hooking
11.2.5 Creating a tool to monitor file creation and deletion using hooking
11.2.6 Disabling Hooking Mode
11.3 Conclusion

Chapter 12.
Exploiting vulnerabilities

12.1 Various Permissions in Embedded Systems
12.1.1 DAC
12.1.2 Immutable sticky bit
12.1.3 MAC
12.1.4 Linux capabilities
12.1.5 RBAC
12.2 Logic Bugs
12.3 Logic Bug Vulnerability Cases
12.3.1 Characteristics of USB Ext4 Format
12.3.2 USB mount permission setting issue
12.3.3 Symbolic links within USB
12.3.4 Custom Shell Bypass
12.3.5 Firmware Update
12.3.6 Absence of authentication
12.4 Write what where?
12.4.1 Uevent helper
12.4.2 Multifunction Printer Vulnerability Case
12.4.3 Conclusion

Chapter 13. ARM Exploitation

13.1 Memory Corruption Attacks
13.2 About ARM
13.3 ARM Assembly Code
13.4 What is ARM Thumb mode?
13.5 ARM Calling Conventions
13.6 Creating ARM Shellcode
13.7 Writing thumb mode code
13.8 Pipelining
13.9 Hello world shell coding
13.10 Creating an execve shellcode
13.11 Creating a Reverse Connection Shellcode
13.12 ARM Memory Corruption Attack Techniques
13.13 ARM Stack Overflow
13.14 ARM ROP
13.15 Real-World ARM Exploit Techniques
13.16 Final

◈ What this book covers ◈

◆ Hardware Basics for Hardware Hacking Beginners
◆ Embedded system configuration
◆ Firmware extraction methodology for embedded devices
◆ Serial analysis methodology using UART and JTAG debugging ports
◆ Basic knowledge for hacking embedded systems
◆ Various emulating techniques
◆ Embedded Hacking Know-How
ARM architecture binary attack technique

◈ Target audience of this book ◈

◆ Readers who want to build basic knowledge about hacking embedded systems such as multi-function printers, wall pads, routers, and NAS
◆ Readers who want to build basic knowledge about hardware hacking
◆ Readers who want to study various embedded attack methodologies

◈ Author's Note ◈

Sometime around 2010, the embedded hacking craze began to take hold in South Korea.
Embedded hacking became a new toy for hackers who were bored with hacking familiar systems, and it was the ultimate game for hackers who could see the results of their hacking directly with their own eyes if they succeeded.
And I was one of those hackers who enjoyed this game.
At that time, securing embedded devices was much easier than finding vulnerabilities in other servers.
However, as time passed, the security of embedded devices gradually improved, and I also grew along with them by studying techniques to bypass this strengthened security.
And this became an opportunity to explain the process through an embedded lecture.
The lecture materials, updated annually, piled up steadily, and at some point, I realized that it was necessary to highlight all the material I had accumulated over the years.
I tried to cover as much as possible the process of how I started studying hacking embedded devices, how it developed, and what can be done.
- ahrik

There was a reason I first started hacking cars.
This whole journey began in 2010, with a BBC article I saw on the bus on my way back from a job interview at a company.
The title is 「Hack attacks mounted on car control systems」.
It said that cars could be hacked.
If the article was true, it was about bringing threats that had previously existed only in the digital world into the real world, and this was enough to instill a romantic feeling in me.
I ignored the news of my acceptance from the company and went to a university research lab to find a place where I could study car hacking.
Life after that was not easy.
In my head, the low level of the target was up to assembly language, but when the scope expanded to automobiles, things arose that required understanding the hardware characteristics.
At the time, I was very disappointed that there was no domestic material that looked at hardware from a security perspective, but I am glad that I was able to make a small contribution through this book.

In fact, when I participated in writing the book, much of its content and direction were already set.
However, due to my shortcomings and worries, it was not easy to write each and every word.
When I first got involved, I started out with big dreams and excitement, but the longer I struggled, the more my will seemed to wane.
The biggest concern was probably the ability to communicate.
I was wondering if I could effectively convey what I had in mind, and at the same time, if I could match the tone of the sentences I'd already written.
It would have been nice if things had gone as planned, but looking back on the past to write the 'Author's Note', it seems inevitable that there will be great regret.

Hardware security is still a developing field. Even amidst the significant changes brought about by the LLM program, hardware security still has a long way to go before it can be automated.
But I don't think it's impossible.
Recently, theories such as digital twins and automata learning are gradually emerging to bring real-world hardware into the digital world and verify it.
In this trend, I hope this book, which describes embedded hacking, will be of great help to readers.

Finally, I would like to express my gratitude to the many people I have met while studying security and working in related fields.
My HSD brothers, sisters, and siblings, who first introduced me to the joy of studying together when I was studying alone, and the Physical Lab kids, who are currently the most precious to me.
These two groups are where I started and where I am now in security.
And in the meantime, I would like to take this opportunity to express my gratitude to the many people I met and got to know through security over a not-so-short period of time, even though I was unable to express it due to my lack of social skills.
- seeh0