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.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.
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.| Category | Native | Java | Python |
|---|---|---|---|
| Encryption | Full | Most ciphers | Common ciphers |
| Hashing — cryptographic | Full | Full | Full |
| Hashing — non-cryptographic | DJB2, FNV, MurmurHash3 | — | — |
| MAC | Full | Full | Full |
| Signing | Full | All except PQC | Common variants; no PQC, Ed25519, Ed448, SM2 |
| PQC signing (ML-DSA, SLH-DSA, LMS) | ✓ | — | — |
| PRNG (Mersenne Twister) | ✓ | — | — |
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:
| Check / Attack | Description | Kind |
|---|---|---|
| SizeCheck | Key is smaller than 2048 bits | Check |
| ExponentCheck | Public exponent is non-standard | Check |
| RocaCheck | Key is affected by the ROCA vulnerability | Check |
| RocaVariantCheck | Key is affected by a ROCA variant (any base) | Check |
| KeypairCheck | Key is affected by CVE-2021-41117 (Keypair factorization) | Check |
| FermatCheck | Key is factorable via Fermat’s method | Attack |
| PollardPm1Check | Key may be vulnerable to Pollard’s p−1 method | Attack |
| ContinuedFractionsCheck | Key has a large coefficient in its continued fraction expansion | Attack |
| BitPatternsCheck | Key contains a repeating bit pattern | Attack |
| PermutedBitPatternsCheck | Key contains a repeating permuted bit pattern | Attack |
| HighAndLowBitsEqualCheck | Enough bits in p and q coincide to allow factorization | Attack |
| LowHammingWeightCheck | Key is a product of low Hamming weight primes | Attack |
| SmallUpperDifferencesCheck | abs(p − q) has a special form enabling factorization | Attack |
| UnseededRandCheck | Key was generated from an unseeded random number generator | Attack |
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.