Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.binarly.io/llms.txt

Use this file to discover all available pages before exploring further.

​
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_img, SHRS), DMG, Engenius†, HP (BDL, IPKG), Instar (BNEG, HD), LZH, MSI†, multi-sevenzip, Netgear (CHK, TRX v1/v2), Partclone, QNAP NAS, RAR†, StuffIt (SIT, SIT v5), TAR (Unix, USTAR), Xiaomi (HDR1, HDR2), ZIP†† Partial support: RAR and ZIP — non-encrypted only. MSI — CFB-based extraction only; extracted filenames reflect CFB internal names, not on-disk installer paths. Engenius — not all firmware versions are supported.
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), 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
  • Unified Extensible Firmware Interface (UEFI)
  • BMC firmware (OpenBMC, AMI MegaRAC)
  • Microcode
  • OP-TEE kernel (ARM TrustZone)
  • QNX
  • OpenWRT
  • Android Open Source Project (AOSP)
  • Yocto Linux
  • Buildroot Linux
  • Rocky Linux
  • Any Linux distro (Ubuntu, Red Hat, etc.)
  • HPE Aruba OS
  • Cisco IOS/NX
  • Java (JARs, WAR/EAR archives, JVM bytecode)
  • Linux ELF binaries
  • Android packages (APK)†
  • Lua bytecode
  • Python packages, source code, and bytecode
  • Docker container images
† Partial support: Android packages (APK) — native libraries (.so files) only; Dalvik/ART bytecode is not analyzed. Keys and certificates may also be extracted.

​
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. Confirmed active secrets are reported as secret/leaked.
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.Mitigation failures (mitigation/*):
  • Missing stack canaries
  • Missing Control Flow Integrity (CFI/BTI/IBT)
  • NX/DEP disabled
  • RELRO disabled or partially enabled
  • PIE disabled
  • Fortify Source disabled
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
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.