Strange behavior when running out of space

[qequ]

Describe the bug

running emba with a quick scan profile in a VM the logs consumed the entire free space of the disk (approximately 30-35 GB) and it seems like emba entered in a deadlock; can't finish but also doesn't timeout in any other way.
Also starts running the blacklisted modules (?

To Reproduce
Steps to reproduce the behavior:

1. EMBA installation default
2. Use the firmware available here: https://www.supermicro.com/support/resources/getfile.php?SoftwareItemID=12192
3. Start EMBA with the following parameters: s

sudo ./emba -f /path/to/SMT_X11_AST2500_64M_374_18_V/SMT_X11_AST2500_64M_374_18_V.bin -l /tmp/logs/ -p ./scan-profiles/quick-scan.emba

5. additional steps

6. See error

Expected behavior
finish the analysis even with errors

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: e.g. ubuntu 22.04
• EMBA version: master branch
• Installation method: default with up to date docker image

Priority issue
Are you already a Sponsor? - n

Additional context
Add any other context about the problem here.

[m-1-k-3]

On my first test it looks as the BMC decryptor is not able to fully decrypt this image:

We are using this one: https://github.com/c0d3z3r0/smcbmc
Next step would be a try to decrypt it manually with smcbmc and identify the issue.

[qequ]

I'm trying to understand how emba behaves after failing the decryption stage. will it start restarting the s09, s02, s03, s14, ... processes in a deadlock until it consumes the entire memory? that's whats the logs show in my case

[m-1-k-3]

I think the failed extraction process produced a huge number of garbage files (check /logs/firmware) and EMBA is now trying to execute all her modules on these garbage files which will take a lot time and disk space.

[qequ]

so emba doesn't interrupt the pipeline if one of the main scans fails ? if one just let it run will continue until its stopped manually

[m-1-k-3]

How to identify a failed extraction process? The extractor is happy if something falls out of the extraction process. In our case the decryption failed but probably unblob or binwalk could extract something (and I bet something was extracted). With this in mind we need to keep on going.

[dgutson]

Maybe the extractor tools produce a log emba could parse to distinguish garbage vs correctly extracted file?

[m-1-k-3]

I am sure we can improve this behaviour massively. Just give it a try. PR are welcome.