Within the filesystem, device-specific code resides, written in C, C++, or other programming languages, such as Lua. Device-specific code, or even all of the firmware itself, can be a mix of third-party developers contracted out, known as Original Design Manufacturers (ODM), or in-house developers working with the Original Equipment Manufacturer (OEM). ODMs are an important piece of the embedded device development supply chain. They are often small companies in Asia and are a dime a dozen. Some OEMs have trusted ODMs they work with on product lines, while others will do business with ODMs that have the lowest fees for only one product. Depending on the industry, an ODM can also be referred to as a supplier. It is important to note that ODMs are free to work with a number of different OEMs and can even distribute the same code base. You may be familiar with this notion or even wondered why a critical public advisory affects ten plus device manufactures for a software bug. This occurs due to a lack of secure development life cycles processes by the ODM and verification by the OEM. Once an ODM completes their application deliverables, which may be an SDK or firmware to the OEM, the OEM will merge its code base(s) into the firmware, which may be as small as OEM logos on web interfaces. The implementation varies depending on how the ODM and OEM merge their code; however, it is not uncommon for an ODM to provide a binary file to the OEM. OEMs are responsible for distributing the firmware, managing firmware, and supporting the device itself. This includes firmware security issues reported by third-party researchers, which puts a strain on OEMs if ODMs retain the source code and the OEM only has access to a binary image.

In Chapter 3, Analyzing and Exploiting Firmware we will learn how to reverse engineer firmware binary images by recognizing the filesystem, identifying compression, and emulating binaries for testing, to take advantage of common firmware issues.