Firmware files not always processed when firmware is a single archive

[gluesmith2021]

Describe the bug

This occurs at least on some instances of "partial firmwares" (i.e. small parts of a Linux file system), but I can't tell in general what kind of input trigger the bug.

When the partial firmware is provided to EMBA as a .tar.gz, none of the binary files are analyzed (the don't even appear in p99_prepare_analyzer.csv). But if the archive is manually extracted before running emba (then giving it the unpacked folder instead as the source), all files are properly analyzed.

I can't share the very interesting case I had, but I made a trivial one from 2 libraries below.

To Reproduce
Steps to reproduce the behavior:

1. EMBA installation: default mode
2. Use the firmware available here (link valid until March 14): https://1drv.ms/u/c/6832161d9629c783/EZ37i9kSzC9Iv2DHiXgUtAcBqfzvDJH6xMliUd7_uTh9Sg?e=LeJw3s
3. Start EMBA with the following parameters:

sudo ./emba -p ./scan-profiles/default-sbom.emba -l <output_folder> -f /path/to/lib64.tar.gz

There are no report about files in the archive. Furthermore, P99 csv log contains only a single line, for /firmware, the tar archive itself, but nothing about files within.

Extract the archive and try again on the unpacked folder:
4. tar -xf lib64.tar.gz
5. sudo ./emba -p ./scan-profiles/default-sbom.emba -l <output_folder> -f /path/to/lib64

There should be reports on .so files, and P99 csv log should list them (at least unique ones)

Note: there might be missing reports because of another issue: #1464 . Therefore checking P99 csv log for presence of extracted files (or lack thereof in this case) is more reliable than the final report to validate the unexpected behavior.

Expected behavior

Files inside the archive should be analyzed, not the /firmware file itself (at least, not only that file, but I don't expect that file to be analyzed at all)

Screenshots

Desktop (please complete the following information):

• OS: Ubuntu 22.04 VM, 32 cores
• EMBA version: master branch as of 2025-02-10, commit 15e67eb
• Installation method: default with up to date docker image (1.5.1b)

Priority issue

Are you already a [Sponsor]? - No

Additional context

[m-1-k-3]

On a first check with your testing file i got the following entries:

└─$ NO_UPDATE_CHECK=1 sudo -E ./emba -f ~/Downloads/lib64.tar.gz -l ~/firmware-analysis/emba_logs_test -y -S -m s199 -m f199 -y

└─$ cat /home/m1k3/firmware-analysis/emba_logs_test/csv_logs/p99_prepare_analyzer.csv                                          
/logs/firmware/unblob_extracted/firmware_extract/lib64/libjson-c.so.4;ELF64;2's complement, little endian;AdvancedMicroDevicesX86-64;;;ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=6c879f21c380efc32c264def15ee6b860c74b8d5, stripped;0ea304346edc653ab0a1cd3df38e8335;
/logs/firmware/unblob_extracted/firmware_extract/lib64/libjitterentropy.so.2.1.2;ELF64;2's complement, little endian;AdvancedMicroDevicesX86-64;;;ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8d1524820e3be0bf80bc111baec4329988c19054, stripped;d5ebb335b01804237703c40093f497a6;

The firmware by itself is probably in the csv cause it is not detected as a Linux system (check prepare_all_file_arrays) and it somehow was running into this condition.

[gluesmith2021]

I'll then assume that the workaround is to unpack everything before launching emba.

[m-1-k-3]

I'll then assume that the workaround is to unpack everything before launching emba.

If you can tear it down further we are glad to fix. In the mean time we need to unpack it before.