Each section will start by a quick theoretical introduction, then attendees will practice a lot through guided
examples or real hands-on. The number of exercises done will depend of the workshop duration.

Extraction is the acquisition of the filesystem contained in the firmware. Classically, two types of
techniques could be employed, either using hardware access to dump its content or directly having the
firmware accessible as an archive file. This workshop will only discuss the second one. Firmware files
could have various formats, from the most classical ones which can be easily mount or extracted to the
undocumented handmade ones. In this case, a format reverse-engineering should be done to create the
appropriated unpacker. The following tools will be presented:
- binwalk [3] or unblob [4] for extraction, signature recognition and entropy computation;
- ImHex [5] and katai [6] for defining file formats, navigating on the hexadecimal view of the given file and creating associated parsers.

Potential hands-on and/or guided examples:
- Extraction of a router firmware using binwalk or unblob, discussion of the limits of these tools.
- Reverse of a simple file format.

Cartography consists in gathering any information about the firmware and to identify points of interest
which will require deeper analysis to potentially find a vulnerability or assess the correct security of it.
First, we will introduce what we are usually looking for in a firmware:
- boot process and initialization system;
- attack surface;
- classic weaknesses like SSL NO_VERIFY_PEER option;
- deprecated OpenSSL options;
- strcpy calls;
- etc.

Potential hands-on and/or guided examples:
- Navigation into the firmware executables and their imports with Pyrrha. Manipulation of the different views proposed by the UI to identify potential entrypoints that will lead to a given binary (identified as the "vulnerable" one). The router firmware extracted at the previous step will be used as an example.
- Various diffing technics to identify differences between two versions of the same firmware (scripting of the JSON Pyrrha output, potentially one or two binary diffs done with BinDiff [7, 8], . . . ).
- Interaction with other tools to precise this analysis like hashlookup1 [9].

Develop your own tools As seen in the previous sections, some steps of the analysis could be supported by some tools/scripts. This last part of the workshop tends to offer attendees tools to help this development. Two main ideas will be introduced: first, integrate a new mapper in Pyrrha based on a new heuristic or to handle a specific need. The second relies on Numbat, the API used by Pyrrha to create a
graph that could be rendered and looked in, in a user-friendly UI. The idea is to quickly develop a UI for
already existing tools

[1] Quarkslab. Pyrrha. 2023. url: https://github.com/quarkslab/pyrrha.
[2] Quarkslab. Numbat. 2024. url: https://github.com/quarkslab/numbat.
[3] ReFirm Labs. Binwalk. 2010. url: https://github.com/ReFirmLabs/binwalk.
[4] Onekey. Unblob. 2021. url: https://github.com/onekey-sec/unblob.
[5] WerWolv. ImHex. 2020. url: https://github.com/WerWolv/ImHex.
[6] Katai Struct. 2015. url: https://github.com/kaitai-io/kaitai_struct.
[7] Halvar Flake. “Structural comparison of executable objects”. In: DIMVA 2004, July 6-7, Dortmund,Germany (2004).
[8] Thomas Dullien and Rolf Rolles. “Graph-based comparison of executable objects (english version)”. In: Sstic 5.1 (2005), p. 3.