back

An introduction to Firmware Analysis

Techniques - Tools - Tricks

If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!

Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.

Video duration
00:40:11
Language
English
Abstract
This talk gives an introduction to firmware analysis: It starts with how to retrieve the binary, e.g. get a plain file from manufacturer, extract it from an executable or memory device, or even sniff it out of an update process or internal CPU memory, which can be really tricky. After that it introduces the necessary tools, gives tips on how to detect the processor architecture, and explains some more advanced analysis techniques, including how to figure out the offsets where the firmware is loaded to, and how to start the investigation.

The talk focuses on the different steps to be taken to acquire and analyze the firmware of an embedded device, especially without knowing anything about the processor architecture in use. Frequently datasheets are not available or do not name any details about the used processor or System on Chip (SoC).

First the prerequisites, like knowledge about the device under investigation, the ability to read assembly language, and the tools of the trade for acquisition and analysis, are shown.

The question "How do I get the firmware out of device X?" makes the next big chapter: From easy to hard we pass through the different kinds of storage systems and locations a firmware can be stored to, the different ways the firmware gets transferred onto the device, and which tools we can use to retrieve the firmware from where it resides.

The next step is to analyze the gathered data. Is it compressed in any way? For which of the various different processor architectures out there was it compiled for? Once we successfully figured out the CPU type and we've found a matching disassembler, where do we start to analyze the code? Often we have to find out the offset where the firmware is loaded to, to get an easy-to-analyze disassembler output. A technique to identify these offsets will be shown.

The last chapter covers the modifications we can apply to the firmware, and what types of checksum mechanisms are known to be used by the device or the firmware itself to check the integrity of the code.

Talk ID
5477
Event:
30C3
Day
1
Room
Saal 1
Start
12:45 p.m.
Duration
01:00:00
Track
Security & Safety
Type of
lecture
Speaker
Stefan Widmann
Talk Slug & media link
30C3_-_5477_-_en_-_saal_1_-_201312271245_-_an_introduction_to_firmware_analysis_-_stefan_widmann

Talk & Speaker speed statistics

Very rough underestimation:
98.6 wpm
548.5 spm
112.3 wpm
630.6 spm
100.0% Checking done100.0%
0.0% Syncing done0.0%
0.0% Transcribing done0.0%
0.0% Nothing done yet0.0%
  
100.0% Checking done100.0%
0.0% Nothing done yet0.0%
  

Work on this video on Amara!

Talk & Speaker speed statistics with word clouds

Whole talk:
98.6 wpm
548.5 spm
firmwaredevicesearchproblemexampletalkcodeimageupdatergoodfilesdevicessubroutineoffsetaddressarchitecturebinarymemorytimeslidesfilefindstartwindowsangelusbsubroutinessystemlaughterdisassemblerlinuxdumpupxserialcallmanufacturerhandbuiltsecondinternalperfectleftapplausespecialexternalmodifyworkchipflasharchitectures
Stefan Widmann:
112.3 wpm
630.6 spm
devicefirmwaresearchexampleimagecodeupdaterfilesproblemsubroutineoffsetaddressfilememoryfindbinarydevicesarchitecturesubroutinesusbupxserialdisassemblerstartcallmanufacturerwindowsdumptalkflashchipinternalarchitectureshandadressingperfectlinuxbuiltdownloadingbitmodifygoodcommunicationjtaglinkexternaltimeprocessorcorrectvalid