Hacking Secure Software Update Systems at the DEF CON 32 Car Hacking Village
Read about Red Balloon's CTF at DEF CON 32's Car Hacking Village, highlighting secure software updates.
Device recovery and reverse engineering often requires dumping a flash chip directly. At Red Balloon Security, we may solder to exposed pins on the chip or contacts on the PCB, or desolder the chip completely to read it.
A common issue with this process is separating the interleaved metadata from the “useful” data. Generally, out-of-bounds (OOB) data includes error correction codes (ECC), which are tagged onto the end of each memory page to maintain data integrity. Often, it is left to the flash reader or controller to deal with the OOB data.
RBS’s Open Firmware Reverse Analysis Konsole (OFRAK) gives reverse engineers the same functionality as the methods described above without requiring a hunt for the exact tool or writing a custom implementation. The ability to then analyze and modify the data, and use OFRAK to repack it into the same format, is another huge benefit.
NAND flash consists of many small pages combined into blocks. Often, each page has OOB data, but it is sometimes combined and stored together after a block of data pages. Below is an example of a NAND flash chip layout:
A common flash chip layout.
While we may know the layout of any one flash chip, it is challenging to apply a universal solution for all chips. As with all file formats, many fields must be considered, and when the goal is to modify the contents and repack them into the same format, the challenge becomes even more complex.
Historically, the solution for separating the data has been for engineers to commit time and energy to writing their own scripts, or searching the Internet for a tool that supports that specific flash chip or manufacturer.
While there are many similarities in the layouts between manufacturers and specific models, the tools are often not compatible with each other. We encounter this issue across so many devices and NAND flash chips that we find it useful to include a component in OFRAK for easy processing of the unpacked outputs. Doing this allows us to also use other components to encode and decode using the applicable ECC algorithm and compute checksums, and further modify the dump without having to manually update all of the fields when repacking.
With the flash components, a user can unpack a raw flash dump and receive the corrected data back, and then use other OFRAK functionality to recursively unpack any files, data, or kernels within that dump into more granular ResourceViews. We use these components to make changes to the dump, repack it, and flash it back onto the chip to be run on a device directly. They could also be used for transferring data from one flash chip to another model with a different flash format.
Our solution aims to be universal by allowing researchers and software developers to create their own attributes without having to write any logic. In a situation where the flash dump is not handled properly with the existing implementation, it is possible to modify the existing component, or create a new component without reinventing the wheel. When a datasheet is available, this process is even simpler.
The first step is to install OFRAK. You can then go through an example to get you started with the flash components specifically. Here, our goal is to provide a quick technical overview of the components.
The attributes are the most essential part of the flash components. It has five different types of block formats:
The most important of these is the data block format, which repeats until the end of data is reached. By default, the end of the resource provided is expected to end the flash dump. However, once an indicator of the end of the file (magic bytes, data size, or total size) is provided in the header or tail block, then the component will use the position of the field to read in the value and automatically set the end of the resource.
There are some cases where not all of the flash dump includes OOB data. These are commonly indicated by magic bytes at the start of an offset and possibly delimiters between pages. OFRAK supports these formats as well. Each format is just a list of fields that specify their type and size.
The types:
class FlashFieldType(Enum):
DATA = 0
ECC = 1
ALIGNMENT = 2
MAGIC = 3
DATA_SIZE = 4
ECC_SIZE = 5
CHECKSUM = 6
DELIMITER = 7
TOTAL_SIZE = 8
There are separate properties for the ECC and checksum, which allow flexibility in implementing your own algorithms. We have split ECC handling into its own component, which provides an abstract implementation that can be inherited for your own custom ECC algorithms.
The attributes can be updated before repacking the resource if a different repacked format is desired. This may be particularly useful for device recovery or increasing storage capacity on devices that support different models of flash chips.
To demonstrate how we use the OFRAK flash unpacker component, we have pulled the NAND flash off a Cisco Voice-over-IP Phone and read the data directly. Once we have this data, we can refer to the datasheet or inspect the dump for patterns. The datasheet shows this layout:
Flash Layout for Micron flash chip.
While it’s always tricky to confirm that the datasheet is for our exact model, we can inspect the data itself and confirm that there are 64 bytes of OOB data between pages of 2048 bytes containing the interesting data:
OOB data in a raw flash dump.
For this NAND flash format, we can see that it is not just ECC, and could dissect our dump further if we wished to repackage it; instead we’ll stick to unpacking for now. To get the flash unpacker to ignore the OOB data, we can mark it as an alignment of 64 bytes. OFRAK interprets the layout using the attributes of a flash resource:
FlashAttributes(
[
FlashField(field_type=FlashFieldType.DATA, size=2048),
FlashField(field_type=FlashFieldType.ALIGNMENT, size=64),
],
)
Unpacked data from flash dump. Look familiar?
We would need to populate the OOB data correctly to repack the flash dump with modifications. It remains an exercise for the reader to determine the appropriate ECC algorithm, but a fully implemented example is available in the OFRAK documentation.
For updated, in-depth comments and explanations, you can always check the OFRAK documentation or the source code directly. If you have never used OFRAK before, you may want to check the other examples and documentation to learn more about how you can further utilize the platform with your unpacked flash dump or any other files.
If there are any issues with the flash components specifically or with OFRAK in general, please submit an issue on Github to let us know: Red Balloon encourages and appreciates all contributions!
Learn more about OFRAK
© 2024 Red Balloon Security.
All Rights Reserved.
Sal Stolfo was an original founding member of Red Balloon Security, Inc.
Contact us now to discover more about Red Balloon Security’s range of solutions and services or to arrange a demonstration.
Reach out to learn more about our embedded security offering and to schedule a demo.
Reach out to learn more about our embedded security offering and to schedule a demo.
Reach out to learn more about our embedded security offering and to schedule a demo.
Reach out to learn more about our embedded security offering and to schedule a demo.
