# Emba | An Analyzer For Linux-based Firmware Of Embedded Devices **URL:** \ **Category:** Tools & Scripts\ **Tags:** tools, business, pc-optimization\ **Created:** [January 28, 2021, 1:06pm UTC](https://onehack.st/t/emba-an-analyzer-for-linux-based-firmware-of-embedded-devices/171169 "2021-01-28T13:06:24Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Prometheus](https://onehack.st/user_avatar/onehack.st/prometheus/32/34950_2.png) [@Prometheus](https://onehack.st/u/Prometheus)\ **Post date:** [January 28, 2021, 1:06pm UTC](https://onehack.st/t/emba-an-analyzer-for-linux-based-firmware-of-embedded-devices/171169/1 "2021-01-28T13:06:24Z")
![image](https://onehack.st/uploads/default/original/3X/7/8/785cf59fced388f44200d960f497fea3ffda0495.jpeg) _emba_ is being developed as a firmware scanner that analyses already-extracted Linux-based firmware images. It should help you to identify and focus on the interesting areas of a huge firmware image. Although _emba_ is optimized for offline firmware images, it can test both, live systems and extracted images. Additionally, it can also analyze kernel configurations. _emba_ is designed to assist a penetration tester. It is not designed as a standalone tool without human interaction. _emba_ is designed to give as much information as possible about the firmware. The tester can decide on the areas to focus on and is always responsible for verifying and interpreting the results. ### How to use it? **Before starting, check that all dependencies are met and use the installer.sh script: `./emba.sh -d` or `./emba.sh -d -F`** ##### Arguments: ```auto Test firmware / live system -a [MIPS] Architecture of the linux firmware [MIPS, ARM, x86, x64, PPC] -A [MIPS] Force Architecture of the linux firmware [MIPS, ARM, x86, x64, PPC] (disable architecture check) -l [./path] Log path -f [./path] Firmware path -e [./path] Exclude paths from testing (multiple usage possible) -m [MODULE_NO.] Test only with set modules [e.g. -m p05 -m s10 ...]] (multiple usage possible, case insensitive, final modules aren't selectable, if firmware isn't a binary, the p modules won't run) -c Enable cwe-checker -g Create grep-able log file in [log_path]/fw_grep.log Schematic: MESSAGE_TYPE;MODULE_NUMBER;SUB_MODULE_NUMBER;MESSAGE -E Enable automated qemu emulation tests (WARNING this module could harm your host!) -D Run emba in docker container -i Ignore log path check Dependency check -d Only check dependencies -F Check dependencies but ignore errors Special tests -k [./config] Kernel config path Modify output -s Print only relative paths -z Add ANSI color codes to log Firmware details -X [version] Firmware version (double quote your input) -Y [vendor] Firmware vendor (double quote your input) -Z [device] Device (double quote your input) -N [notes] Testing notes (double quote your input) Help -h Print this help message ``` #### Docker Container There is a simple docker-compose setup added which allows you to use emba in a docker container - [see the wiki for more details](https://github.com/e-m-b-a/emba/wiki/Docker-Container) #### Examples ##### Static firmware testing: - Extract the firmware from an update file or from flash storage with [binwalk](https://github.com/ReFirmLabs/binwalk) or something else - Execute _emba_ with set parameters, e.g. `sudo ./emba.sh -l ./logs/arm_test -f ./firmware/arm_firmware/` [![emba example startup](https://github.com/e-m-b-a/emba/raw/master/documentation/emba_01.png)](https://github.com/e-m-b-a/emba/blob/master/documentation/emba_01.png) - Path for logs and firmware path are necessary for testing successfully ( **WARNING:** emba needs some free disk space for logging) - Architecture will be detected automatically; you can overwrite it with `-a [ARCH]` - Use `-A [ARCH]` if you don’t want to use auto detection for architecture - _emba_ currently supports the following architectures: MIPS, ARM, PPC, x86 and x64 ##### Live testing: For testing live system with _emba_ run it as if you were testing static firmware, but with `/` as firmware path: `sudo ./emba.sh -l ./logs/local_test -f /` - Path for logs and firmware path are necessary for testing successfully - Architecture will be detected automatically; you can overwrite it with `-a [ARCH]` - Use `-A [ARCH]` if you don’t want to use auto detection for architecture - The paths `/proc` and `/sys` will be automatically excluded - It improves output and performance, if you exclude docker `-e /var/lib/docker` ##### Test kernel config: Test only a kernel configuration with the kernel checker of [checksec](https://github.com/slimm609/checksec.sh): `sudo ./emba.sh -l ./logs/kernel_conf -k ./kernel.config` - If you add `-f ./firmware/x86_firmware/`, it will ignore `-k` and search for a kernel config inside the firmware **Good to know:** - `sudo` is necessary for some modules to run properly - Currently only tested on [Kali Linux](https://kali.org/downloads)(2020.4) - _emba_ needs some free disk space for logging - _emba_ uses well known tools like objdump, [LinEnum](https://github.com/rebootuser/LinEnum), [checksec](https://github.com/slimm609/checksec.sh), [linux-exploit-suggester.sh](https://github.com/mzet-/linux-exploit-suggester), [cwe-checker](https://github.com/fkie-cad/cwe_checker) - _emba_ includes multiple modules of the well known Linux analyser [Lynis](https://cisofy.com/lynis/) ### Dependencies _emba_ uses multiple other tools and components - [see the wiki for more details](https://github.com/e-m-b-a/emba/wiki/Dependencies) ### Structure [See the wiki for more details](https://github.com/e-m-b-a/emba/wiki/Structure-of-the-emba-directory) ### How to write own modules? [See the wiki for more details](https://github.com/e-m-b-a/emba/wiki/How-to-write-own-modules) ## GitHub: > **[GitHub - e-m-b-a/emba: EMBA - The firmware security analyzer](https://github.com/e-m-b-a/emba)** > > EMBA - The firmware security analyzer