Skip to main content
The Binarly Transparency Platform (BTP) statically analyzes binary images to detect cryptographic materials - algorithms, protocols, certificates, and keys - without requiring source code or debug information. Detected properties appear in the Cryptographic Materials tab and are exported in the CBOM and PQC Compliance Report.

Detection by Binary Type

Native Binaries

For native compiled binaries - UEFI firmware modules or ELF executables and libraries - detection is code-based. BTP identifies cryptographic algorithm implementations by matching known algorithm-specific constants in code and data sections, tracing cross-references to those constants, and - for select algorithms - applying partial emulation to resolve indirect calls. Detection does not rely on symbol names, function names, or debug information:
  • Custom implementations of well-known algorithms are still detected if the underlying code patterns are present.
  • Stripped binaries are fully supported.
  • Obfuscated or heavily modified implementations may reduce detection confidence or prevent detection entirely.

Managed Runtimes

For binaries targeting managed runtimes - Java bytecode and Python packages - detection is API-based. BTP identifies cryptographic usage by recognizing calls to supported cryptographic library APIs: Java: Apache Commons Codec, Bouncy Castle, Google Guava, Google Tink, JDK (javax.crypto, java.security) Python: cryptography, M2Crypto, Pooch, PyCryptodome, PyNaCl, pyOpenSSL, stdlib (hashlib, hmac) Custom algorithm implementations that bypass supported APIs will not be detected.

Coverage by binary type

The set of detectable algorithms differs between binary types. Native code-based detection has the broadest coverage. API-based detection for managed runtimes is constrained to what the supported libraries expose. Signature algorithms are additionally identified from the signature algorithm field of every parsed X.509 certificate, regardless of binary type. PQC algorithms (ML-KEM, ML-DSA, SLH-DSA, LMS) and the PRNG are detected via code analysis in native binaries. These algorithms have no equivalent API surface in the supported Java or Python libraries.

What Is Detected

Algorithms and Protocols

Algorithm findings record the algorithm class, the binary component and offset where the implementation was found, and reachability information. Protocol findings record SSL/TLS client versions. In ELF binaries, BTP identifies calls to OpenSSL client method functions (for example TLSv1_2_client_method) and maps version-flexible methods to the highest version supported by the linked OpenSSL release. Algorithm classes follow the crypto/algorithm/* and crypto/protocol/* naming scheme. Detection coverage varies by binary type: native binaries use code-based detection, while managed runtimes (Java, Python) use API-based detection against supported libraries. See Finding Classes Reference for the full list.

Certificates

Certificate findings record the full set of X.509 parameters: issuer, subject, validity period (not-before and not-after dates), expiration status, signature algorithm, public key algorithm and size, and whether the certificate is self-signed. Certificate issue classes follow the crypto/certificate/* naming scheme. Every parsed certificate is recorded as an artefact/crypto-certificate-material property; certificate issues are reported as additional findings.

Keys

Key material records key type (RSA or EC, including the Ed25519, Ed448, X25519 and X448 curves), key size and curve, public vs. private classification, and location within the image. Keys are parsed from PEM, DER, SSH, PGP and TSS2 (TPM 2.0) containers, and private keys additionally from PKCS #12 containers. Key material is recorded under artefact/crypto-key-material. Private keys exposed within firmware are additionally flagged under secret/private-key or secret/encryption-key. For RSA keys (standalone public and private keys, and public keys extracted from certificates), BTP runs additional security checks and factorization attacks to identify weak or compromised keys. Each triggered check is reported as a crypto/rsa/weak-key-parameters finding with the severity listed below:

Confidence

Each cryptographic finding carries a confidence score reflecting how well the detected code pattern matched the algorithm. Confidence applies to algorithms, protocols, and assets (certificates and keys). See Accuracy & Confidence in Findings for the full confidence model.

Reachability

Reachability analysis determines whether a cryptographic implementation is accessible from a public entry point in the binary. A reachable finding indicates the implementation can be reached through an execution path, increasing the practical risk of weak or deprecated algorithm usage. See Reachability Analysis.

Algorithm Compliance

Detected algorithms are evaluated against published security standards to identify weak, deprecated, or quantum-vulnerable implementations. See Algorithm Compliance Reference for the full classification table.

Limitations

Java and Python binaries using custom cryptographic implementations that bypass supported APIs will not be detected.
For obfuscated components, the analysis may be inaccurate and provide incorrect results or no results.