Static Detection of Post-Quantum Cryptographic Algorithms in Stripped Binaries for Digital Forensic Examination and Migration Assurance

Muhammad Shaheer Bin Junaid

Source-linked AI summary

Static Detection of Post-Quantum Cryptographic Algorithms in Stripped Binaries for Digital Forensic Examination and Migration Assurance

Muhammad Shaheer Bin Junaid

arXiv:2608.25122v1Aug 25, 2026cs.CR

TL;DR

Existing scanners cannot verify post-quantum replacements in stripped binaries. Kestrel detects ML-KEM and ML-DSA from transform constant tables, achieving full table matches across four toolchains and ordinary build transformations with no false positives.

Problem
Existing binary scanners identify vulnerable cryptography but cannot verify whether ML-KEM or ML-DSA has replaced it in stripped binaries.
Method
Kestrel derives scheme fingerprints from public parameters and detects normalized, reordered transform constant tables in binary read-only data.
Results
Kestrel achieved full table matches across four toolchains and ordinary build transformations, with no false positives, while discovering twelve uncatalogued programs containing post-quantum cryptography.
Takeaways & Limitations
The method provides visibility into post-quantum cryptography entering production through language runtimes, supporting cryptographic inventory of deployed software.
Takeaways & Limitations
Kestrel does not detect implementations that generate transform constants at runtime instead of storing them in binary data.

Abstract

from arXiv · show

Currently, there is no method to verify from compiled binary code whether a quantum-vulnerable algorithm has been replaced by an approved post-quantum algorithm. Cryptographic discovery tools identify algorithms by symbols, library dependencies, and runtime behaviour; however, all these signals are destroyed by stripping, statically linking, and optimising a binary. This paper presents Kestrel, a static analysis method for identifying the standardised lattice-based schemes ML-KEM and ML-DSA in stripped binary code. Kestrel identifies ML-KEM and ML-DSA by detecting the number-theoretic transform constant tables that form the read-only data upon which the arithmetic depends. The fingerprints Kestrel derives from public scheme parameters are localised by means of a normalisation-and-multiset-matching procedure; the false-positive probability is established analytically. In experiments on four independent implementation lineages and all build transformations, including compiler-level obfuscation, Kestrel achieved recall of 128 of 128 with zero false positives. Applying Kestrel to 6,224 binaries on a production Linux system disclosed twelve uncatalogued programs containing ML-KEM; these included the OpenSSH key-exchange program and the container-management stack. In several of these programs, post-quantum code entered production through the language runtime without the awareness of the projects distributing them. Kestrel distinguishes genuine post-quantum implementations from advertised claims not backed by the underlying code, attributes each detection to its originating codebase, and, in a forensic disk-image trial, recovered a detection from unallocated space after the deleted binary could no longer be reconstructed. Thus, Kestrel provides a practical basis for cryptographic migration assurance, software supply-chain inspection, and post-quantum forensic examination.

I. Introduction · II. Background · B. Module lattices and the number-theoretic transform

Kestrel addresses the difficulty of verifying post-quantum cryptography in stripped binaries by detecting ML-KEM and ML-DSA through their number-theoretic-transform constant tables. The method derives representation-complete fingerprints from public parameters and matches them despite implementation and build variation.

II. Background: Migration requires locating every deployed instance of quantum-vulnerable cryptography before replacement, but existing discovery tools generally identify only RSA, elliptic-curve schemes, and Diffie-Hellman.These public-key schemes are threatened by Shor’s algorithm, whereas AES-256 retains an adequate security margin under Grover’s algorithm.
I. Introduction: Kestrel identifies ML-KEM and ML-DSA in stripped binaries by detecting their number-theoretic-transform constant tables, which remain essential to polynomial arithmetic.The paper frames this as the first fingerprint set and detector for post-quantum primitives in stripped binaries, rather than a new constant-matching technique.
I. Introduction: Kestrel derives complete fingerprint sets from public scheme parameters and uses normalisation plus multiset scoring to accommodate reordered and differently represented constants.This avoids dependence on manually enumerating implementation-specific fingerprints.
I. Introduction: 128 of 128 detections succeeded with zero false positives across four independent toolchains and all ordinary build transformations, including stripping, static linking, and obfuscation.A production sweep of 6,224 binaries additionally disclosed twelve uncatalogued programs containing post-quantum cryptography.
B. Module lattices and the number-theoretic transform: ML-KEM and ML-DSA perform polynomial multiplication over degree-255 module-lattice polynomials, and the number-theoretic transform makes this practical instead of requiring O(n^2) coefficient multiplications.The transform is a finite-field analogue of the discrete Fourier transform.
B. Module lattices and the number-theoretic transform: ML-KEM uses q = 3329 and zeta = 17, while ML-DSA uses q = 8380417; implementations store successive root powers in a fixed bit-reversed order.These precomputed powers are the read-only data targeted by Kestrel’s fingerprints.
B. Module lattices and the number-theoretic transform: Implementations may store the same transform table in Montgomery form, multiplying residues by R = 2^16 mod q, so identical mathematics produces different binary byte sequences.For ML-KEM, q inverse modulo 2^16 is 62209 and is embedded as an instruction immediate rather than stored in data.

C. Why the constants survive · III. Related Work and the Gap

Kestrel exploits the persistence of read-only numeric constants despite transformations that rewrite instructions and erase symbols. Existing approaches do not identify post-quantum primitives from static constants in stripped binaries, leaving the gap that Figure 2 situates.

C. Why the constants survive: Compiled binaries separate executable instructions in the text section from read-only constants in the read-only data section.
C. Why the constants survive: Compiler optimisation can reorder, inline, and rewrite instructions while preserving the program’s constant values.
C. Why the constants survive: The numeric values of constant tables cannot change without changing the program’s output.
C. Why the constants survive: Optimisation and obfuscation rewrite .text, while stripping erases .symtab.
III. Related Work and the Gap: Prior work comprises three categories, but none identifies a post-quantum primitive from static constants in a stripped binary.
III. Related Work and the Gap: Figure 2 summarises the comparison with existing approaches and situates the present method within this gap.

A. Cryptographic identification in binaries · B. Post-quantum-specific discovery · C. Cryptographic bill of materials tooling

Prior binary-cryptography identification progressed from constant matching to semantic analysis but remained focused on classical primitives, while post-quantum discovery relies mainly on names, dependencies, or runtime signals that disappear in stripped, statically linked binaries. Commercial tooling emphasizes finding vulnerable assets, leaving static identification of quantum-safe algorithms under these conditions as the central gap addressed by Kestrel.

A. Cryptographic identification in binaries: Existing binary-cryptography tools evolved from fixed-constant matching toward data-flow, symbolic-execution, and bit-precise semantic analysis, but target classical primitives rather than lattice schemes.FindCrypt, Signsrch, and findcrypt-yara match constants; later methods identify primitives through program behavior and structure.
A. Cryptographic identification in binaries: Kiona targets stripped, statically linked, and proprietary binaries with constant and instruction signatures, but supports only classical algorithms such as AES, SHA, and RC4.Its documented coverage includes ChaCha20, RC4, AES, DES, MD5, SHA-1, SHA-2, SHA-3, and Base64.
B. Post-quantum-specific discovery: QED detects quantum-vulnerable cryptography through library API names because compiler optimization may disturb static look-up tables, and explicitly does not address staticIts name-based strategy motivates a different approach for binaries whose identifying names are unavailable.
B. Post-quantum-specific discovery: Post-quantum discovery successors remain based on function symbols, library dependencies, and binary attributes, while Mallick and colleagues classify implementations using runtime footprints, network-observable key sizes, and post-quantum TLS behavior.These approaches depend on information absent from stripped, statically linked binaries or require executing the process and observing traffic.
C. Cryptographic bill of materials tooling: Commercial platforms now scan binaries, but their stated purpose is to locate quantum-vulnerable algorithms, hard-coded keys, and other assets for migration discovery rather than verify quantum-safe implementations.The market is characterized as discovery-first, while Binarly is associated with generating a cryptographic bill of materials from binary executables.
C. Cryptographic bill of materials tooling: A migration-planning framework identifies static linking, stripped binaries, and proprietary implementations as barriers, then reduces post-stripping identification to matching known cryptographic constants before setting that approach aside.This frames the unresolved problem as assurance of cryptographic migration under conditions that remove name-based signals.
C. Cryptographic bill of materials tooling: Kestrel is presented as the only method that statically detects quantum-safe algorithms while surviving stripping and static linking that erase name-based signals.Figure 2 summarizes the distinction between Kestrel and existing approaches.

IV. Threat Model and Problem Definition … V. Fingerprint Derivation

Kestrel targets static identification of ML-KEM and ML-DSA in compiled binaries when source, execution, and network observation are unavailable, supporting forensic examination and migration assurance. Its fingerprints are deterministically derived from public scheme parameters and cover implementation-specific transform-table representations.

IV. Threat Model and Problem Definition: The threat model assumes an analyst must identify cryptographic primitives from a compiled binary without source code, execution, or network observation.The setting covers both forensic examination and migration assurance, with false positives carrying the principal operational cost.
A. Forensic examination: Forensic examination requires distinguishing a genuine ML-KEM-1024 implementation from a binary that merely claims post-quantum protection by inspecting implementation evidence.The genuine variant carries the zeta table, whereas the fraudulent variant cannot.
B. Migration assurance: Migration assurance verifies vendor compliance against the delivered binary, because a false positive could certify a non-compliant artefact as migrated.The resulting security failure bears the auditor’s signature.
B. Migration assurance: The method is limited to transform-table lattice schemes ML-KEM and ML-DSA, excluding SLH-DSA, FFT-based signatures, and code-based schemes.SLH-DSA is hash-based and stores no such table, while the other excluded families present distinct fingerprinting problems or were selected for later standardisation.
V. Fingerprint Derivation: Kestrel generates fingerprints deterministically from public parameters rather than manually enumerating implementations, allowing coverage of implementations not yet written and extension to new schemes.The procedure is presented as the first contribution of the fingerprint-derivation stage.
V. Fingerprint Derivation: The generator takes q, zeta, transform length n, and bit-reversal width w, then emits forward-twiddle, inverse-transform, and base-case exponent families.Implementations may store these tables separately, so fingerprints must cover all three families.
V. Fingerprint Derivation: Forward and inverse ML-KEM tables share exactly one member out of 128, while forward and mod-root families overlap by approximately half, motivating multitable detection.Scoring only the forward table would miss binaries storing the inverse table separately.
V. Fingerprint Derivation: The generator emits signed, unsigned, plain-residue, reordered, and lane-duplicated byte representations, which normalisation later converges into one target set.The ML-DSA generator uses q = 8380417, an eight-bit reversal, and 256 signed thirty-two-bit entries; its unused zeroth entry may be 0.

VI. Detector Design · A. Normalisation

Kestrel replaces brittle byte-string searching with a unified normalisation-and-scoring mechanism that handles representation differences. Its windowed detector canonicalises candidate residues while testing raw and Montgomery-converted interpretations.

VI. Detector Design: Byte-level searching fails because the same table appears in at least four forms and vectorised builds can reorder it.The reference implementation also diverges from a first-principles table on one entry, requiring special cases for a byte matcher.
VI. Detector Design: The detector uses normalisation and scoring instead of byte matching, converting representation differences into parameters of one mechanism.Byte-level forms vary across implementations, vectorised builds reorder tables, and the reference table differs on one entry; Figure 4 presents the pipeline.
VI. Detector Design: Figure 4 sets out the detector pipeline that consolidates these obstacles into a single mechanism.The design replaces separate byte-matching exceptions with parameterised normalisation and scoring.
A. Normalisation: The detector advances a window across read-only data, reading sixteen-bit values for ML-KEM and thirtytwo-bit values for ML-DSA.This windowed scan operates directly on candidate values in the read-only data section.
A. Normalisation: Each candidate is normalised to a canonical residue modulo q, with signed values folded to their unsigned equivalents.The procedure therefore compares values in a common residue representation despite signedness differences.
A. Normalisation: Montgomery-form candidates are converted to plain residues using the inverse Montgomery factor, R inverse modulo q.For ML-KEM, R inverse modulo q equals 169, and the converted result is evaluated as a second hypothesis alongside the raw residue.

B. Multiset scoring … VII. Methodology and Implementation

Kestrel scores order-independent residue multisets against analytically justified thresholds, while treating Keccak constants and code-section values as corroborating or rejected signals rather than primary fingerprints. The methodology fixes this construction and evaluation corpus before empirical testing.

B. Multiset scoring: Kestrel scores windows by counting expected canonical residues as an order-independent multiset, allowing reordered vectorised tables without exact byte matching.Threshold scoring accommodates vectorised layouts because reordered tables contain the same residues.
C. False-positive bound: The chance that unrelated data contains at least 100 distinct members of a specific 128-element subset of a 3329-element space is exceedingly small and explicitly computable.This probability motivates setting the detection threshold analytically rather than relying on qualitative reassurance.
D. A negative filter, and a rejected signal: Keccak’s 24-entry round-constant table corroborates detections because ML-KEM and ML-DSA use SHAKE, but it cannot discriminate them alone because SHA-3 is ubiquitous.The Keccak check is attached as a reported condition rather than used as a gate that discards matches.
E. Candidate signals evaluated and rejected: The reduction constant and public-key or ciphertext sizes are rejected as primary fingerprints because they reside in optimisable, obfuscation-targeted code sections rather than persistent read-only data.They remain corroborating signals, whereas the zeta table embodies the method’s data-survives-code argument.
E. Candidate signals evaluated and rejected: The detection pipeline normalises and scores candidate data instead of matching bytes, with the Keccak check reported alongside the result.This design separates the primary multiset match from corroborating evidence.
VII. Methodology and Implementation: The artefact construction and evaluation corpus were fixed before empirical work, and Section VIII reports outcomes under the stated protocol without modification.This pre-specification keeps the design independent of measured results.

A. Order of construction … D. Environment and provenance

Kestrel is built from a verified constant-table foundation, evaluated on implementations spanning distinguishable code lineages and realistic distribution transformations. The reproducible evaluation records language-specific build equivalences, complete tooling provenance, and corpus lineage on commodity hardware.

A. Order of construction: The generator is verified against known table heads before a ground-truth binary confirms that source-predicted constants occur in compiled read-only data.This observation-to-binary confirmation precedes construction of the detector, scoring harness, and evaluation matrix.
B. Ground-truth corpus: The corpus spans reference C, liboqs, PQClean, vectorised, Go, RustCrypto, and Chrome implementations, covering lineage cells distinguished by the generator.Chrome is highlighted as the most consequential target because it is widely deployed and carries the three-table layout.
C. Transformation matrix: Each source is compiled into unoptimised, optimised, stripped, statically linked, and obfuscated variants to test detection as distribution transformations accumulate.The transformation matrix serves as detector validation rather than the principal claim of the work.
C. Transformation matrix: Transformation equivalence is reported per language rather than as one implied grid, reflecting differences among toolchains.This avoids treating unavailable or default behaviors as equivalent operations across languages.
C. Transformation matrix: The C build uses optimisation, separate stripping, explicit static linking, and source-to-source obfuscation actions.These concrete actions define the C column of the per-language matrix.
D. Environment and provenance: The evaluation runs on a commodity virtual server without specialised hardware, with tooling versions, compiler flags, and library commits recorded for exact regeneration.The corpus and variants are therefore reproducible within the resources of an independent researcher.
D. Environment and provenance: Table II records every compiled implementation, its toolchain, and its lineage cell, establishing corpus provenance for reproducibility.The provenance metadata identifies where each corpus entry belongs within the evaluation design.

VIII. Evaluation · A. Recall across the transformation matrix · B. A false-positive sweep that became a discovery

Kestrel achieved near-perfect recall across applicable build transformations and perfect precision, with its only consistent shortfall being the ML-DSA reference’s 255-of-256 result. A production sweep of 6,224 binaries produced no false positives but uncovered twelve uncatalogued programs containing ML-KEM, including active OpenSSH and container-runtime deployments.

VIII. Evaluation: The evaluation paired a labelled corpus, where binary ground truth was known from direct compilation, with a stock-system sweep whose result was initially unknown.The stock-system sweep produced the paper’s central finding.
A. Recall across the transformation matrix: 128 of 128 labelled binaries were recovered across four implementation lineages and applicable transformations, with 100 per cent precision; only the ML-DSA reference read 255 of 256 entries.The ML-DSA shortfall was identical in every transformation column and resulted from its zeroed first table entry, not transformation degradation.
B. A false-positive sweep that became a discovery: 6,224 stock-system binaries produced no false positives, with noise capped at 27 below the threshold of 32 and genuine detections scoring 128.The score distribution was distinctly bimodal, separating noise from signal.
B. A false-positive sweep that became a discovery: Twenty-four scanned paths contained ML-KEM, resolving through /bin symlinks to twelve distinct uncatalogued programs across two implementation lineages.The false-positive sweep therefore became a production discovery and attribution exercise.
B. A false-positive sweep that became a discovery: OpenSSH actively offered mlkem768x25519-sha256 as a hybrid post-quantum key exchange, and it was the default key-agreement algorithm in OpenSSH 10.0.Direct interrogation confirmed an active capability rather than an incidental linked-library table.
B. A false-positive sweep that became a discovery: Containerd, Docker, runc, and ctr shared the Go standard library’s ML-KEM fingerprint, showing post-quantum code entering production through the toolchain without distributors’ awareness.The fingerprint comprised two plain-residue tables in Go’s .noptrdata section.
B. A false-positive sweep that became a discovery: Table configuration distinguished OpenSSL-linked C-reference code from Go-runtime code in previously unseen production binaries, attributing their lineages without symbols.The SSH binary used Montgomery form and one .rodata table, whereas container binaries used plain form and two .noptrdata tables.

C. The analytical bound · D. Genuine versus bluff · E. Rejected signals, and why

Kestrel’s zero measured false positives are bounded analytically, distinguish genuine ML-KEM from deceptive advertisements, and reject code-section or coincidental constants as unreliable fingerprints. The evidence supports ordered zeta tables as the decisive signal for stripped-binary identification.

C. The analytical bound: The false-positive bound models each window’s matches to the 128-member target set with a binomial upper tail, using an approximately 0.0385 per-value match probability among 3,329 residues.This explains the measured zero rather than merely reporting it.
C. The analytical bound: Approximately four false positives at threshold 32 were predicted for 6,224 binaries, yet the measured count was zero; for an 8 GB image, approximately twenty-seven were predicted versus zero measured.The uniform-random model is a conservative ceiling because it omits the requirement that matched residues be distinct.
D. Genuine versus bluff: A binary can advertise post-quantum cryptography without containing it, whereas the detector reports implemented code rather than claims that a never-run file makes available.This capability is unavailable to dynamic or network methods when the file is never executed.
D. Genuine versus bluff: The bluff binary advertised “ML-KEM-1024 post-quantum encryption” in strings, performed classical cryptography, and scored zero because no target table was present.A string- or name-based scanner would accept the advertised label, while the table detector rejects it.
E. Rejected signals, and why: QINV and fixed public-key size were relegated to corroborating roles because they reside in code rather than data and can occur by chance across transformations.The zeta table survives the transformations that eliminate or weaken these candidate signals.
E. Rejected signals, and why: QINV never appeared in the data section, while the static build produced ten coincidental data-section matches for key size within statically linked libc.These observations support rejecting both signals as primary fingerprints.
E. Rejected signals, and why: Two-byte constants and modulus 3329 can collide by chance, so only the ordered zeta table provides evidential weight.The coincidental key-size matches support this conclusion rather than undermining it.

F. Adversarial evasion and the method's boundary · G. Performance

Kestrel resists low-cost evasions because its multiset matching detects residues regardless of arrangement, but stored-byte transformation and runtime-generated constants define its boundary. Its measured performance supports practical large-scale forensic and audit scanning, completing 6,224 binaries in approximately ten minutes.

F. Adversarial evasion and the method's boundary: 128, 86, and 64 were the scores under three low-cost evasions, which all failed because genuine residues remained detectable despite reordered, spaced, or relocated data.The multiset scorer identifies residues irrespective of order, spacing, or section boundary.
F. Adversarial evasion and the method's boundary: Only XOR transformation defeated detection by altering stored bytes so residues disappeared, requiring substantive modification of the cryptographic code.The experiment recorded evasion cost because successful evasion must be distinguished from cheap evasions that fail.
F. Adversarial evasion and the method's boundary: 8 of 128 was the score for a correct runtime-generated ML-KEM key exchange that stored no data-section constants, so static constant fingerprinting missed it.The implementation computed the twiddle table at load time, establishing the method's genuine boundary.
G. Performance: The performance measurements used four processor cores and 8 GB of memory, with each scan reported as the median of five post-warm-up runs.Tests ran on an Intel Core i9-14900HX Linux virtual machine using the unmodified evaluation tool.
G. Performance: 10.5 MB/s on a 41 MB Go binary exceeded the 1.1 MB/s measured for the smallest binary as fixed initialization costs amortized with size.Throughput increased with binary size because the fixed per-invocation cost became less significant.
G. Performance: 583.6 seconds for 6,224 binaries yielded a complete-system sweep in approximately ten minutes, supporting practical forensic and fleet-audit use.The scan averaged 93.8 ms per binary across 2,704 MB of code.
G. Performance: 395 MB peak resident memory for the 41 MB binary reflected memory use that scales with the largest scanned file rather than remaining constant.Kestrel reads each file and its sections into memory.

H. Detection on recovered evidence · IX. Implementation-Lineage Attribution · X. Limitations

Kestrel detects ML-KEM directly in recovered or unrecovered disk-image bytes and attributes detections to implementation lineages, while its scope is limited by runtime-generated constants, scheme structure, runtime representation, and dependency boundaries.

H. Detection on recovered evidence: Two successfully recovered files matched their live originals byte-for-byte and produced identical verdicts, scores, and lineage assignments.Recovery altered none of the bytes read by Kestrel.
H. Detection on recovered evidence: Conventional recovery failed for the deleted file because ext4 destroyed inode block pointers and the ELF structure needed by signature carving.Sleuth Kit returned zero bytes, while foremost found no file to reconstruct.
H. Detection on recovered evidence: 128 of 128: scanning unallocated disk-image bytes located the ML-KEM table after file recovery failed, demonstrating resilience to file-level destruction.The detector found the table at offset 0x8c6420 by scanning the raw 200 MB image as a flat byte stream.
IX. Implementation-Lineage Attribution: Kestrel attributes detections to source lineages because implementation-selected constant inventories support provenance and are difficult to change without rewriting the transform.Direct inspection identifies lineage markers such as the reference C implementation’s Montgomery-form table and zeroed ML-DSA entry.
IX. Implementation-Lineage Attribution: Attribution stops at lineage: Go standard library and RustCrypto implementations share identical from-specification tables, so distinguishing them requires language-level metadata.The constants are indistinguishable despite storage in .noptrdata for Go and .rodata for Rust.
X. Limitations: Runtime-generated transform constants evade detection because no stored table exists, although this behavior appeared in none of the examined implementations or observed malware.The method therefore targets cryptography obscured by ordinary build transformations rather than deliberate table generation.
X. Limitations: Scheme coverage is limited to lattice schemes storing transform tables; SLH-DSA, FFT-based signatures, and code-based schemes require different detection structures.Detectability depends on algebraic structure, and hash-based constructions lie outside the method’s scope.
X. Limitations: Managed-runtime targets may emit constants through store instructions rather than contiguous data tables, while Keccak corroboration applies only within a file’s static dependency closure.Bytecode-aware extraction is future work, and dynamically linked SHA-3 code can separate Keccak constants from the zeta table.

XI. Discussion · XII. Conclusion

Kestrel addresses the previously unaddressed confirmation of genuinely present quantum-safe algorithms in compiled binaries by detecting ML-KEM and ML-DSA through indispensable number-theoretic transform constants. Its broader applicability is governed by whether a scheme’s correctness depends on stored invariant constants, and its reported results are openly reproducible.

XI. Discussion: The method emerged amid a 2026 forensic need to distinguish genuine from fraudulent post-quantum implementations and an assurance need driven by legally binding migration deadlines.These developments made verification a concrete examination and compliance requirement rather than a hypothetical concern.
XI. Discussion: Fixed-constant matching is an established but evadable signature-matching technique that remains useful because most software has no reason to evade detection.The discussion identifies this tradition as both the method’s foundation and a potential line of criticism.
XI. Discussion: Detectability depends on the underlying mathematics: lattice schemes expose fixed transform tables, whereas hash-based schemes lack distinctive constants of their own.The method detects a scheme to the degree that its correctness depends on stored, invariant constants.
XII. Conclusion: Kestrel addresses confirmation, from compiled binaries, that quantum-safe ML-KEM and ML-DSA implementations are genuinely present by detecting their indispensable number-theoretic transform constants.This reverses the usual focus of cryptographic discovery, which targets quantum-vulnerable algorithms for removal.
XII. Conclusion: The author declares no competing financial interests or personal relationships that could have influenced the work and reports no specific grant funding.This disclosure covers financial, personal, and funding conflicts.
XII. Conclusion: Kestrel’s fingerprint generator, detector, corpus scripts, LLVM obfuscation pass, benchmark logs, and detector outputs are openly available for independent reproduction.The public repository also includes a build script for regenerating the large BoringSSL and obfuscated binaries.