e-m-b-a/emba

Describe the bug With PR #2151 we introduced new tests to verify the working of all binary detection rules that are located here https://github.com/e-m-b-a/emba/tree/master/config/bin_version_identifiers To ensure the tests are as good as possible we are trying to build this test-corpus from real-world binary data. To be able to do this we need to find the original firmware with the original binaries to create the corpus data. Currently we already re-created around 300 testfiles for 300 rules. Nevetheless, many tests are currently missing: To make the creation process as easy as possible, EMBA is now automatically creating the identified corpus file on every testrun in the log directory s09_firmware_base_version_check/binary_corpus_tmp. If you are running a firmware scan with the latest EMBA version and you get files in this directory you can directly initiate a PR here How to help? Use the following steps: EMBA installation (default mode) Run a EMBA test with your firmware and the f

Describe the bug EMBA is using multiple sources and multiple modules to create a as complete as possible SBOM or software inventory. For example she is using package managers like opkg, dep, rpm, python, ... Additionally, she uses the information of packages that are available (dep, rpm, ipk, ...) Finally, she is analysing binaries statically and dynamically As an addon EMBA can also emulate the complete system and extracts further details More and more firmware that we can see has some kind of package manager included. Nevertheless, the majority does not. For these cases EMBA has a quite huge arsenal of version identifiers. You can find them here These identifiers are hand crafted and every component needs a dedicated configuration for detection. This is exactly the area that everyone who is using EMBA can support us to stay competitive. Without your help the detection rate will get less accurate over time and we will miss components and vulnerabilities. Describe the solution you'd

Is your feature request related to a problem? Please describe. Please expand the options in your LocalAI calls to allow us to configure more elements of the URL. Currently, the Scheme, Port and API_endpoint are hardcoded in the /modules/Q03_localai_connector.sh file: line 292: http://"${LOCAL_AI_IP}":8080/v1/chat/completions line 419: http://"${LOCAL_AI_IP}":8080/v1/models Describe the solution you'd like It would be nice if the AI_OPTION=3 parameter could be set as a command line option and/or fixed in the /config/ai_config.env file. In the /config/ai_config.env file contains the Schema (HTTP/HTTPS) -> LOCAL_AI_SCHEME="HTTPS" Port (0-65535) -> LOCAL_AI_PORT="8080" Path to API endpoint: -> LOCAL_AI_API_ENDPOINT="/v1" https://HOSTNAME/v1 - works with the OpenAI libraries and any OpenAI-compatible tool https://HOSTNAME/llm - works with Claude Code and other Anthropic tools Describe alternatives you've considered Instead, we could use an HTTP proxy. Priority issue Are you al

Is your feature request related to a problem? Please describe. This request is directly relevant to the ongoing Podman migration issue in #1845. Both that effort and the deployment failures documented here share the same root constraint: EMBA's current architecture is tightly coupled to a specific Docker daemon workflow, which blocks alternative container runtimes and native execution paths alike. The findings below may provide useful ground-level diagnostic context for that migration. On CachyOS (Arch-based), deploying EMBA fails across all tested methods due to hardcoded environmental assumptions: Strict Docker Gatekeeping: The emba wrapper enforces a strict check_docker_dependencies check, halting execution even when all necessary tools (radare2, binwalk, unblob) are installed natively. Absolute Pathing: Even when the local ./external/ directory is successfully populated with dependencies, internal scripts appear to rely on absolute root paths (e.g., /external/cve-bin-tool/...) exp

Is your feature request related to a problem? Please describe. The development of the rust port of binwalk looks stuck. Describe the solution you'd like There is a maintained fork over here https://github.com/binwalk-ng/binwalk-ng We need to test the fork and integrate it into the installer of EMBA. Describe alternatives you've considered Stay on the original, unmaintained base is not a good alternative