This document introduces EMBA, a free and open-source firmware analysis tool. It describes EMBA's extraction and analysis modules that can extract firmware components like Linux filesystems, decrypt images, and analyze the firmware using tools like binwalk and Yara rules. EMBA aims to automate common firmware analysis tasks and identify security issues like outdated components, weak configurations, and potential 0-day vulnerabilities through static and dynamic analysis techniques.

1. EMBA
Firmware
security
analyzer
@securefirmware
https://github.com/e-m-b-a
Michael Messner, Pascal Eckmann

2. # whoami
Michael Messner
Penetration tester
Firmware analysis
Hardware analysis
Siemens Energy AG
@s3cur1ty_de
https://github.com/m-1-k-3
@ michael.messner@siemens-energy.com

3. # whoami
Pascal Eckmann
Cybersecurity Engineer
Security Research
Siemens AG
@_p4cx
https://github.com/p4cx
@ pascal.eckmann@siemens.com

4. The landscape

5. What the firmware analysis
• Firmware is the operating system
• Linux analysis techniques can be used quite often and are well known
• Commercial tools are available, but they are expensive and limited
• EMBA has no limits, costs no money and gives the best results

6. The typical workflow
• Do some strings
• Do some binwalk
• Do some find
• Do some regex
• Do a lot google
• Load something into IDA/Ghidra
• Do something

7. EMBA to the rescue
Get the firmware (vendor, hardware)
Extract the firmware (e.g., Linux filesystem, Kernel)
Analyze the firmware
Report all the things
Firmware
binary file
EMBA
extractor
modules
EMBA
analyzer
modules
EMBA live
tester
modules
EMBA final
aggregator
Web
report
generator
Access the
firmware

8. Get the firmware
• Updates from vendor / web site
• Shell access – copy the filesystem via scp, ftp, tftp, nc or to storage device
• Other vulnerabilities e.g., command injection
• JTAG / SWD
• Communication sniffing (e.g., SPI)
• Desolder Flash memory and extract the content

9. The easiest way
Binwalk all the things

10. The EMBA extraction process
EMBA
extraction
modules
Identify Linux
root
filesystem
Ext/UFS
filesystems
VMWare
images
Encrypted
images
Special
images
Other
systems
Mount &
copy
Mount &
copy
Decrypt
(leaked keys)
Custom
tool
Binwalk
EMBA
analyzer
Deep
extraction
Ext/UFS filesystems
VMWare images
Encrypted images
Special images
Other systems
Mount & copy
Mount & copy
Decrypt (leaked keys)
Custom
tool (e.g. Freetz NG)
Binwalk
Identify Linux
root
filesystem
OK
Not OK
Always
Basic
compression
Extract
(patool)

11. Finally, we have something extracted
Which files and directories are there?
Which binaries, configuration files, …
Which architecture are we dealing with?
Which binary protections are in use?
Which Software versions in use?
Is some outdated software in use?
Which areas are from the vendor, which are open source?
Where are possible weak spots or interesting functions used?
Which kernel?
Are there hard-coded passwords?
Scripting issues (shell, python, php, …)?
Insecure permissions?
Weak configurations?
Public exploits?
Dynamic analysis?
Reporting
EMBA
analyzer
modules

12. Don’t reinvent the wheel
Multiple Linux tools
binwalk
Freetz-NG
Checksec.sh
CVE and CVSS databases
CVE-Search
CVE-Searchsploit
cwe-checker
GHIDRA
Docker
Radare2
fdtdump
linux-exploit-suggester
OpenSSL
uboot mkimage
objdump
pixd
bandit
progpilot
Qemu
shellcheck
sshdcc
tree
unzip
sudo parser
sshdc
Yara
and others …
See also: https://github.com/e-m-b-a/emba/wiki/Installation#dependencies

13. Hunting 0days
Identify interesting spots

14. What the 0day?
• 0day – unknown vulnerability (There is no patch available)
• You have to find the vulnerability by yourself
• The goal of every penetration tester is to find 0days
• 1day – already known vulnerability (Patches are in theory available)
• You have to identify the components with exact version details (SBOM) and
match it against a vulnerability database
• The goal of every penetration tester is to do this automagically and do not
waste time with it
• It is also an interesting thing for developers, security teams and the
purchasing department

15. Weak binary functions
When using legacy C functions such as strcpy, it’s up
to the developer to make sure the size of the buffer
to be written to is large enough to avoid buffer
overruns. If this is not done properly, it can result in
a buffer overflow, causing the program to crash at a
minimum. At worst, a carefully crafted overflow can
cause malicious code to be executed.
Source: https://rules.sonarsource.com/c/RSPEC-1081

16. Identify interesting spots
Create disassembly
objdump radare2
Check binary protection mechanisms
Weak fct counter
Check network functionality
Common Linux file

17. Identify interesting spots
See also: https://flattsecurity.medium.com/finding-bugs-to-trigger-unauthenticated-command-injection-in-a-netgear-router-psv-2022-0044-2b394fb9edc by @stereotype32

18. The 1day issue

19. What the 1day?
• 0day – unknown vulnerability (There is no patch available)
• You have to find the vulnerability by yourself
• The goal of every penetration tester is to find 0days
• 1day – already known vulnerability (Patches are in theory available)
• You have to identify the components with exact version details (SBOM) and
match it against a vulnerability database
• The goal of every penetration tester is to do this automagically and do not
waste time with it

20. What’s the problem?!?
• We are working on the compiled/packed firmware
• Mostly no source code with component versions available
• No standardised format of version details
• No standardised mechanism/parameter on how to get version details

21. Hybrid version detection in EMBA
Static analysis Dynamic analysis
EMBA database with version identifiers
Output generation with Qemu
Output generation with string
analysis, kernel modules, path
details

22. Version detection in EMBA
Match the output against a version dictionary:

23. We love exploits

24. Version detection in EMBA

25. @ pascal.eckmann@siemens.com @ michael.messner@siemens-energy.com
EMBA
Firmware
security
analyzer
@securefirmware
https://github.com/e-m-b-a
Michael Messner, Pascal Eckmann