Skip to main content

​
Black-box unpacking

The platform unpacks uploaded binaries using an engine based on unblob, extended with Binarly-specific handlers for UEFI firmware images and Docker container images. The engine detects container types automatically, unpacks contents recursively, and preserves metadata (timestamps, permissions) where the format allows.
7-Zip, AR, ARC, ARJ, Autel ECC, CAB, CPIO (binary, portable ASCII, portable ASCII CRC, portable old ASCII), D-Link (encrypted image, FPKG, SHRS), DMG, Engenius (partial), HP (BDL, IPKG), Instar (BNEG, HD), LZH, MSI (partial), multi-sevenzip, Netgear (CHK, TRX v1/v2), Partclone, QNAP NAS, RAR (partial), StuffIt (SIT, SIT v5), TAR (Unix, USTAR), Xiaomi (HDR1, HDR2), ZIP (partial)Partial support: RAR and ZIP cover non-encrypted archives only. MSI uses CFB-based extraction only, so extracted filenames reflect CFB internal names rather than on-disk installer paths. Engenius does not support all firmware versions.
Android EROFS, Android Sparse, CramFS, ExtFS (ext2/ext3/ext4), FAT (FAT12/FAT16/FAT32), ISO 9660, JFFS2 (new and old), NTFS, RomFS, SquashFS (v1, v2, v3, v4, including Broadcom, DD-WRT, and big-endian variants), UBI, UBIFS, YAFFS
bzip2, compress, GZIP (standard and multi-volume), LZ4 (standard, legacy, and skippable frames), Lzip, LZMA, LZO, UZIP, XZ, zlib, ZSTD
QCOW2, Raw disk image, VHD, VHDX, VMDK
ELF (32-bit and 64-bit)Binarly extensions:
  • UEFI firmware images (PI firmware volumes, FFS file systems, PE32/PE32+ sections)
  • Vendor UEFI/BIOS update packages: Acer, Asus, Dell, Fujitsu, Gigabyte, HP, HPE, Intel, Lenovo, MSI, Samsung, Supermicro, and LVFS
  • BMC firmware: AMI MegaRAC SPX, Supermicro, Nuvoton NPCM8XX
  • FIT (Flattened Image Tree) images
  • NVIDIA SoC firmware capsules (Spark, Grace, Tegra)
  • U-Boot bootloader images
  • Docker container images (OCI and Docker-format layer tarballs)

​
Supported environments

What you can submit for static binary analysis.
  • X86
  • ARM32/64 (and variants)
  • XTensa
  • UEFI firmware and update packages
  • BMC firmware
  • Microcode (Intel and AMD)
  • U-Boot bootloader
  • Zephyr RTOS firmware
  • OP-TEE kernel
  • QNX
  • OpenWRT
  • Android Open Source Project (AOSP)
  • Yocto Linux
  • Buildroot Linux
  • Linux distributions (Rocky, Ubuntu, Red Hat, etc.)
  • HPE Aruba OS
  • Cisco IOS/NX
  • Linux kernel images (uImage and zImage)
  • Java (JARs, WAR/EAR archives, JVM bytecode)
  • Linux ELF binaries
  • Android packages (APK)
  • Lua bytecode
  • Python packages, source code, and bytecode
  • Docker container images

​
Detection coverage

What the analysis engine identifies within submitted binaries.
The platform identifies weak, vulnerable, or potentially compromised cryptographic assets (crypto/*):
  • Weak private and public keys
  • x509 expired certificates
  • PKCS7 bundles
  • Leaked or compromised keys
  • Cryptographic protocols
  • Cryptographic algorithms
Intel BootGuard manifests and UEFI Secure Boot policy are inventoried as UEFI artefacts (artefact/uefi/boot-policy-manifest, artefact/uefi/key-manifest) alongside cryptographic material. Boot Guard integrity failures and leaked Boot Guard keys are reported as supply-chain failures.
Embedded secrets in files within analyzed binaries (secret/*):
  • API credentials
  • OAuth credentials
  • Encryption keys
  • JWT tokens
  • Webhook URLs (e.g. Slack webhooks)
  • Generic credentials (e.g. URLs with Basic Auth)
Secrets can be validated against external services. Each secret carries a validity status: Valid, Invalid, Undetermined, or Unspecified.See Secrets Detection for full input scope and component class coverage.
Zero-day vulnerabilities discovered through semantic code analysis (vulnerability/uefi/*). The Binarly Analysis Engine decompiles binaries, constructs call graphs, and performs data-flow analysis to identify vulnerability classes independent of any CVE assignment.UEFI-specific classes include:
  • SMM callouts via NVRAM variables, CommBuffer, Boot Services, Runtime Services, protocols, and save state
  • SMRAM corruption via pointers, CommBuffer, global buffers, protocols, and save state
  • DXE and PEI memory corruption and code execution via NVRAM variable function pointers
  • Buffer overflows via shared DataSize between GetVariable calls (double-get pattern)
  • SMRAM information disclosure via shared DataSize
  • Microcode vulnerabilities in UEFI-based firmware
Publicly documented vulnerabilities with assigned CVEs (vulnerability/known-vulnerability). Findings include CVSS, EPSS, and Exploitation Maturity Score (EMS), reachability analysis, and decompiled pseudocode evidence.Also covers UEFI-specific known vulnerabilities:
  • PKfail: untrusted or non-production Platform Key enabling Secure Boot reconfiguration (vulnerability/uefi/pkfail)
  • Secure Boot bypass: signature databases permitting execution of known applications with code execution primitives (vulnerability/uefi/secure-boot-bypass)
CISA Known Exploited Vulnerabilities (KEV) catalog status and ransomware campaign association are shown on individual finding detail pages.
Known vulnerabilities in external dependencies detected through dependency analysis (vulnerability/known-vulnerability). Findings are organized by dependency in the Dependencies tab, showing affected components, version ranges, and earliest safe versions where a fix is available.
Known supply chain integrity issues (supply-chain/known-supply-chain-issue). These surface deviations from expected supply chain integrity, for example components built from tampered sources or known compromised toolchains.Also covers Intel Boot Guard integrity issues:
  • Boot Guard verification could not be confirmed
  • Leaked Boot Guard Key Manifest private key
  • Leaked Boot Guard Boot Policy Manifest private key
Missing security mitigations and code quality issues that increase exploitability or indicate insecure development practices.Linux / ELF mitigation failures (mitigation/*):
  • Missing stack canaries
  • Missing Control Flow Integrity (CFI, IBT, BTI)
  • NX/DEP disabled
  • RELRO disabled or partially enabled
  • PIE disabled
  • Fortify Source disabled
Linux / ELF weaknesses (weakness/*):
  • Unstripped binaries containing symbol information
  • RPATH or RUNPATH set (potential for arbitrary code execution via library hijacking)
  • Use of unsafe C/C++ functions
  • Linux kernel hardening configuration gaps
UEFI firmware mitigations (mitigation/uefi/*):
  • Memory protection policy misconfiguration
  • PEI and DXE StackGuard misconfiguration
  • Incomplete RSB stuffing
  • Outdated or vulnerable Intel and AMD microcode
  • Outdated Secure Boot forbidden signature database (dbx)
  • Secure Boot Setup Mode enabled
  • Non-production test keys (AMI, Insyde, Phoenix)
  • Leaked AMI platform key (PKfail)
  • Writable Intel Flash Descriptor regions
  • Weak UEFI platform configuration
See Hardening Analysis for analysis depth and per-platform check details.
Potential tampering or obfuscation patterns (suspicious/*). Flags anomalous PE parsing behavior in UEFI modules, including unusual import resolution and relocation handling, that may indicate a modified or implanted binary.
Confirmed malicious behavior (malware/*). The platform identifies malicious implants, hooks, embedded executables, and firmware backdoors. Findings include the module name and type, detected capabilities, virtual addresses, and industry references using ATT&CK and Malware Behavior Catalog (MBC) classifications.

​
Analysis capability matrix

This matrix maps each analyzable target to the finding classes the platform can produce for it. Rows are the component types that analysis binds to; columns link to the corresponding section of the Finding Classes reference. Column key:
Recursive unpacking. Composite inputs (UEFI firmware and update packages, BMC firmware, disk images, archives, Docker images, APKs) are unpacked into their constituent components, and each extracted component is analyzed according to its own row. For example, ELF binaries inside a Docker image or firmware image receive the full Linux / POSIX coverage, and native libraries inside an APK are analyzed as ELF.
How known vulnerabilities are detected. Known (code) findings come from code and semantic analysis of the component itself. Known (version) findings come from package, version, and ecosystem matching, and are also surfaced as dependency vulnerabilities. Malware and supply-chain findings are produced by signature and rule engines and apply broadly to the targets above.
Managed runtimes. Cryptographic detection for Java and Python is API-based and does not cover post-quantum algorithms. See Detection Methods and Cryptographic Detection.
Alongside these findings, the platform also emits informative artefacts (embedded executables, certificates, keys, Boot Guard manifests) and metadata (symbols, hardening summaries, entropy, component relationships) for the relevant targets.