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.
Non-cryptographic hashes, PRNG, and PQC signing are detected via code patterns 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. Algorithm classes follow thecrypto/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 thecrypto/certificate/* naming scheme. Certificates without issues are recorded as artefact/crypto-certificate-material properties.
Keys
Key material records key type (RSA, EC, Ed25519, post-quantum), key size or parameter set, public vs. private classification, and location within the image. Key material is recorded underartefact/crypto-key-material. Private keys exposed within firmware are additionally flagged under secret/private-key or secret/encryption-key.
For public RSA keys, BTP runs additional security checks and factorization attacks to identify weak or compromised keys:
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
For obfuscated components, the analysis may be inaccurate and provide incorrect results or no results.