Describe the bug
While running some moderately large files (~100MB) through EMBA I caught a glimpse of a log entry that seemed noteworthy.
The log line in question:
./modules/S16_ghidra_decompile_checks.sh: line 214: /external/emba_venv/bin/semgrep: Argument list too long
Looking at the line in question:
semgrep --disable-version-check --metrics=off --severity ERROR --severity WARNING --json --config "${EXT_DIR}"/semgrep-rules-0xdea/rules /tmp/haruspex_"${lNAME}"/* >>"${lSEMGREPLOG}" || print_error "[-] Semgrep error detected on testing ${lNAME}"Interestingly enough, this does not seem to terminate the scan.
I was also unable to find any mention of the (expected?) error message in the logs.
So from my (naive) point of view, this is likely one of two things, making this a bug:
- a silent error leading to incomplete results
- an error condition that should lead to scan termination but does not
Analysis was run through the EMBArk interface using dockerized EMBA version 2.0.1a.
The firmware file in question can unfortunately not be provided.
Expected behavior
Binaries of "arbitrary" size/complexity can be analyzed.
Screenshots
/
Desktop (please complete the following information):
- OS: EMBA Docker container as used with EMBArk
- EMBA version:
2.0.1a
- Installation method: default with up to date docker image
Priority issue
Are you already a Sponsor? - N
Additional context
Inspecting the scanned paths in the container yielded the following results:
└─# ls -1 /tmp/haruspex__******740DF22C991D3E74/ | wc -l
11686
└─# ls -1 /tmp/haruspex__******38586DF5ABA441F8/ | wc -l
24002
└─# ls -1 /tmp/haruspex__******83E4DCAF24C0193F/ | wc -l
4353
└─# ls -1 /tmp/haruspex__******984A34E6647DF3F9/ | wc -l
3736
└─# ls -1 /tmp/haruspex__******778F3D02E26D79C0/ | wc -l
2890
└─# ls -1 /tmp/haruspex__******BD12642F46A46D3D/ | wc -l
2678
It therefore seems likely the issue is caused by usage of the wildcard expansion /* on too many files at once.
Describe the bug
While running some moderately large files (~100MB) through EMBA I caught a glimpse of a log entry that seemed noteworthy.
The log line in question:
Looking at the line in question:
Interestingly enough, this does not seem to terminate the scan.
I was also unable to find any mention of the (expected?) error message in the logs.
So from my (naive) point of view, this is likely one of two things, making this a bug:
Analysis was run through the EMBArk interface using dockerized EMBA version
2.0.1a.The firmware file in question can unfortunately not be provided.
Expected behavior
Binaries of "arbitrary" size/complexity can be analyzed.
Screenshots
/
Desktop (please complete the following information):
2.0.1aPriority issue
Are you already a Sponsor? - N
Additional context
Inspecting the scanned paths in the container yielded the following results:
It therefore seems likely the issue is caused by usage of the wildcard expansion
/*on too many files at once.