Improve our interesting firmware collection

[m-1-k-3]

Is your feature request related to a problem? Please describe.

We are always looking for interesting firmware for testing and improving EMBA. This could be:

• Special architecture firmware that is currently not fully supported by EMBA
• Non Linux systems
• BIOS/UEFI firmware
• Firmware that EMBA is running into issues during analysis
• something else we can use for EMBA training

[brainstorm]

What about VxWorks on SuperH4? How much does EMBA unfold vs manual analysis?:

https://blogs.nopcode.org/brainstorm/anritsu-ms2721b-spectrum-analyzer/

;)

[m-1-k-3]

@brainstorm do you have already some experience and results of binaryanalysis-ng

[brainstorm]

@m-1-k-3 Back then BANG did not find much, so I resorted to manual analysis in the second part of that article:

https://blogs.nopcode.org/brainstorm/anritsu-ms2721b-spectrum-analyzer-repair-part-2/

I doubt binaryanalysis-ng would find much nowadays either... VxHunter on the other hand found a boatload of very useful stuff (resolving functions and offsets) and nowadays it is integrated in Ghidra as "VxWorks" plugin, which I assume is based on VxHunter.

[github-actions]

This issue is stale because it has been open for 28 days with no activity.

[floyd-fuh]

It would be very nice if EMBA would support so-called bare-metal firmware, see https://www.youtube.com/watch?v=q4CxE5P6RUE for an explanation. At least in a first iteration it would be nice if the code detects bare-metal firmware and then activates/deactivates certain modules, informs the user, etc.

E.g. hardware running https://www.zephyrproject.org/

[m-1-k-3]

Could you give me some more details on what you would expect from this identfication. Probably S03 is already doing parts of your needs.

See

emba/modules/S03_firmware_bin_base_analyzer.sh

Line 80 in 7d00a37

OS_SEARCHER=("Linux" "FreeBSD" "VxWorks\|Wind" "FreeRTOS" "ADONIS" "eCos" "uC/OS" "SIPROTEC" "QNX" "CPU\ [34][12][0-9]-[0-9]" "CP443" "Sinamics" "UEFI" "HelenOS" "Windows\ CE")

and

emba/modules/S03_firmware_bin_base_analyzer.sh

Line 49 in 7d00a37

if [[ ${RTOS} -eq 1 ]] ; then

Is this already the identification you are expecting. Additionally, EMBA tries to identify UEFI firmware in module P35 which gets further analysed in module s02

Further details are also available in the wiki https://github.com/e-m-b-a/emba/wiki/OS-support#vxworks-based-firmware / https://github.com/e-m-b-a/emba/wiki/OS-support#uefi-firmware

[floyd-fuh]

Maybe it's just that Zephyr (strings like "Booting Zephyr OS build v3.2.99") is not in that list?

I just think that it very much depends on the chip on those systems on how the firmware would need to be analysed but I also understand that emulating and supporting all the chips out here is a hard task (but maybe worth a try)

[m-1-k-3]

If you have already automated some tasks that we can start including into EMBA it would be great.

The Zephyr strings can be introduced into the S03 module and in the version detection configuration file here. Could you provided a testing firmware and a PR with the updates on the basic Zephyr integration?

[floyd-fuh]

While EMBA detects that a large VMDK file is scanned, it would be nice if it could also do some optimisations to make the scan end. At least for my configuration the scan of the following VMDK image lead to 2 OOM-kill (killing the entire Kali VM) after ~ 10 hours each when it had only 8GB of RAM, and a complete Kali VM freeze when it had 16GB memory (and more CPU) after ~15 hours:

https://www.infoblox.com/product-evaluation-portal-ddi/

Maybe something to add to your list of interesting firmwares, would be interesting to know if you were able to scan it successfully with a more powerful machine.

[m-1-k-3]

Big images could cause issues if your host does not have enough power. What you could do is

• putting more RAM in the box ;)
• limit the threading as this will probably kill your box (parameters -P and -T)
• find the module that is probably causing this issue and we can try to find a way to fix it

[m-1-k-3]

@floyd-fuh 16cores and 32gig of RAM finished the infoblox in 5h 35mins with the default profile.

[github-actions]

This issue is stale because it has been open for 28 days with no activity.