This repository contains a collection of reference data that can be used with the MinHash-based Code Relationship & Investigation Toolkit (MCRIT).
The scope is to cover popular, typically statically linked code that is commonly encountered during binary / malware analysis.
This includes both artefacts introduced by compilers themselves as well as (precompiled) third party libraries that provide access to common algorithms and data structures.
The data found in this repository has been processed with the following tool chain:
- Starting with raw data, typically containing
.LIB(.A) or.OBJ(.O), optionally 7z was used to extract the contents, then lib2smda has been used to instrument IDA Pro to parse these files, extract their code and symbols and finally export them into individual SMDA disassembly files. - These files are then merged into a single SMDA report, performing deduplication per PicHash and Function Symbol if appropriate.
- Alternatively,
.DLLand.EXEfiles have been directly processed using SMDA or optionally IDA Pro if*.PDBfiles are available. - Finally, the SMDA reports have been submitted once into a vanilla installation of MCRIT and the MCRIT export functionality has been used to convert to an immediately usable format.
This repository contains both the final SMDA files and the ready-to-import MCRIT files, which can be imported using Data/Import in MCRITweb or using the CLI.
Entries marked Generated with scripts/build_corpus.py came a second way, which needs neither IDA Pro nor a prebuilt binary to start from: unmodified upstream source is fetched against a pinned tag or digest, built with mingw-w64 and with MSVC v143 on a Windows runner, and disassembled with SMDA directly. Most families carry both, from the same upstream tag, because a MinGW reference matches a MinGW-built binary well and an MSVC-built one only weakly; three of them are MSVC-only, because ATL, the DIA SDK and MASM have no GCC equivalent. What it produces is byte-compatible with the rest of the corpus — the minhash and shingler configuration hashes are checked against the existing exports on every run — and every artefact records its source URL and digest, compiler, build flags and dependency versions in data/<family>/provenance.json. Compiler runtime that every binary links in is measured against a project-free probe and removed, so it stays attributed to the toolchain rather than to the library. See scripts/corpus/README.md.
This repository is intended to grow over time, as we find time to process more of the scattered artefacts from several previous endeavors.
If you feel that something especially relevant is missing, please open an issue and/or provide input data and we will see what we can do.
Compilers
Libraries
- aPLib
- libzlib
- bzip2
- cJSON
- libcurl
- libevent
- liblzma
- libsodium
- libtomcrypt
- libuv
- libxml2
- lz4
- mbedTLS
- pcre2
- sqlite3
- libpng
- libtiff
- wolfSSL
- OpenSSL
- Crypto++
- 7-Zip
- PCRE
- abseil
- re2
- protobuf
- nlohmann/json
- jemalloc
- libstdc++
Runtimes
Loaders and shellcode
Heaven's Gate and WOW64 transitions
WinAPI obfuscation
Offensive tooling
String obfuscation
Reference code extracted from all files containing precompiled code found in installations for various compiler toolchains.
Many thanks to Daniel Enders for creating these reference binaries during his Master thesis in 2022!
Also many thanks to Max Ufer for providing the first builds of Go versions 1.19-1.22!
The source file used to compile these included as many Golang standard library files as possible to create coverage for common functions.
Starting with 1.19, the references are built reproducibly from the latest patch release of each version with scripts/golang: the source is generated from go list std and references every exported, non-generic function and method of every importable standard library package (CGO_ENABLED=0 go build -trimpath, not stripped), and function names are taken from the pclntab by SMDA.
Note that for x64 builds of Go 1.22+, SMDA currently over-approximates type switch jump tables for about 20 functions per file (smda#363), so these files will be regenerated once that is fixed.
When using these with MCRIT, you probably want to have as few as possible / the most fitting version only as you may otherwise run into performance issues. We noticed that the similarity in Golang library functions can lead to huge candidate clusters for which all functions will have to be matched.
| Name | Date | Version | MCRIT | SMDA |
|---|---|---|---|---|
| Golang | 2014-05-05 | 1.2.2 | x86 / x64 | x86 / x64 |
| Golang | 2014-06-18 | 1.3 | x86 / x64 | x86 / x64 |
| Golang | 2014-12-10 | 1.4 | x86 / x64 | x86 / x64 |
| Golang | 2015-08-19 | 1.5 | x86 / x64 | x86 / x64 |
| Golang | 2016-02-17 | 1.6 | x86 / x64 | x86 / x64 |
| Golang | 2016-08-15 | 1.7 | x86 / x64 | x86 / x64 |
| Golang | 2017-02-16 | 1.8 | x86 / x64 | x86 / x64 |
| Golang | 2017-08-24 | 1.9 | x86 / x64 | x86 / x64 |
| Golang | 2018-02-16 | 1.10 | x86 / x64 | x86 / x64 |
| Golang | 2018-08-24 | 1.11 | x86 / x64 | x86 / x64 |
| Golang | 2019-02-25 | 1.12 | x86 / x64 | x86 / x64 |
| Golang | 2019-09-03 | 1.13 | x86 / x64 | x86 / x64 |
| Golang | 2020-02-25 | 1.14 | x86 / x64 | x86 / x64 |
| Golang | 2020-08-11 | 1.15 | x86 / x64 | x86 / x64 |
| Golang | 2021-02-16 | 1.16 | x86 / x64 | x86 / x64 |
| Golang | 2021-08-16 | 1.17 | x86 / x64 | x86 / x64 |
| Golang | 2022-03-15 | 1.18 | x86 / x64 | x86 / x64 |
| Golang | 2023-09-06 | 1.19.13 | x86 / x64 | x86 / x64 |
| Golang | 2024-02-06 | 1.20.14 | x86 / x64 | x86 / x64 |
| Golang | 2024-08-06 | 1.21.13 | x86 / x64 | x86 / x64 |
| Golang | 2025-02-04 | 1.22.12 | x86 / x64 | x86 / x64 |
| Golang | 2025-08-06 | 1.23.12 | x86 / x64 | x86 / x64 |
| Golang | 2026-02-04 | 1.24.13 | x86 / x64 | x86 / x64 |
| Golang | 2026-08-19 | 1.25.14 | x86 / x64 | x86 / x64 |
| Golang | 2026-09-01 | 1.26.8 | x86 / x64 | x86 / x64 |
Having used an installer for the respective version of VS, we crawl its directory structure to discover and process all *.LIB and *.OBJ, sort them by bitness, and merge the code found into a single file.
Thanks to Check Point Research for processing VS 2015, 2017, 2019, and 2022.
| Name | Version | MCRIT | SMDA |
|---|---|---|---|
| VS 6 Express | 8168 | x86 | x86 |
| VS 2003 Express | 3077 | x86 | x86 |
| VS 2005 Express | 50727 | x86 | x86 |
| VS 2008 Express | ----- | x86 | x86 |
| VS 2010 Express | 30319 | x86 | x86 |
| VS 2012 Express | ----- | x86 / x64 | x86 / x64 |
| VS 2013 Express | ----- | x86 / x64 | x86 / x64 |
| VS 2015 Pro | ----- | x86 / x64 | x86 / x64 |
| VS 2017 Pro | ----- | x86 / x86-MFC / x64 / x64-MFC | x86 / x86-MFC / x64 / x64-MFC |
| VS 2019 Pro | ----- | x86 / x86-MFC / x64 / x64-MFC | x86 / x86-MFC / x64 / x64-MFC |
| VS 2022 Pro | ----- | x86 / x86-MFC / x64 / x64-MFC | x86 / x86-MFC / x64 / x64-MFC |
Having used an installer for the Windows version of a MinGW release, we crawl its directory structure to discover and process all *.A and *.O, sort them by bitness, and merge the code found into a single file.
| Name | Date | Version | MCRIT | SMDA |
|---|---|---|---|---|
| MinGW r1 | XXXX-XX-XX | - | x86 / x64 | x86 / x64 |
| MinGW r2 | XXXX-XX-XX | - | x86 / x64 | x86 / x64 |
| MinGW r3 | 2012-07-14 | trunk_r5214 gcc4.7.1 binutils cvs-20120714 | x86 / x64 | x86 / x64 |
| MinGW r4 | 2012-10-27 | v2.0.7 gcc4.7.2 binutils2.23 | x86 / x64 | x86 / x64 |
| MinGW r5 | 2012-11-04 | v2.0.7 gcc4.7.2 binutils2.23 | x86 / x64 | x86 / x64 |
| MinGW r6 | 2013-04-13 | v2.0.8 gcc4.7.3 binutils2.23.2 | x86 / x64 | x86 / x64 |
| MinGW r7 | 2013-04-13 | trunk_r5784 gcc4.8.0 binutils2.23.2 | x86 / x64 | x86 / x64 |
| MinGW r8 | 2013-06-01 | trunk_r5876 gcc4.8.1 binutils2.23.2 | x86 / x64 | x86 / x64 |
| MinGW r9 | - | - | x86 / x64 | x86 / x64 |
| MinGW r10 | 2013-11-17 | v3.0.0 gcc4.8.2 binutils2.23.2 | x86 / x64 | x86 / x64 |
| MinGW r11 | 2014-05-22 | v3.1.0 gcc4.8.3 binutils2.24 | x86 / x64 | x86 / x64 |
| MinGW r12 | 2014-07-30 | v3.1.0 gcc4.9.1 binutils2.24 | x86 / x64 | x86 / x64 |
| MinGW r13 | 2014-11-10 | v3.3.0 gcc4.9.2 binutils2.24 | x86 / x64 | x86 / x64 |
| MinGW r14 | 2015-06-30 | v4.0.2 gcc4.9.3 binutils2.25 | x86 / x64 | x86 / x64 |
| MinGW r15 | 2015-07-10 | v4.0.2 gcc5.1 binutils2.25 | x86 / x64 | x86 / x64 |
| MinGW r16 | 2015-07-21 | v4.0.2 gcc5.2 binutils2.25 | x86 / x64 | x86 / x64 |
| MinGW r17 | 2015-12-01 | v4.0.4+ gcc5.2 binutils2.25.1 | x86 / x64 | x86 / x64 |
| MinGW r18 | 2015-12-05 | v4.0.4+ gcc5.3 binutils2.25.1 | x86 / x64 | x86 / x64 |
| MinGW r19 | 2016-06-14 | v4.0.6 gcc5.4 binutils2.25.1 | x86 / x64 | x86 / x64 |
| MinGW r20 | 2016-06-14 | v4.0.6 gcc6.1 binutils2.25.1 | x86 / x64 | x86 / x64 |
| MinGW r21 | 2016-09-27 | v4.0.6 gcc6.2 binutils2.27 | x86 / x64 | x86 / x64 |
| MinGW r22 | 2016-12-29 | v4.0.6 gcc6.3 binutils2.27 | x86 / x64 | x86 / x64 |
| MinGW r23 | - | - | x86 / x64 | x86 / x64 |
| MinGW r24 | - | - | x86 / x64 | x86 / x64 |
| MinGW r25 | 2017-02-20 | v5.0.1+1 gcc6.3 binutils2.27 | x86 / x64 | x86 / x64 |
| MinGW r26 | 2017-06-02 | v5.0.2 gcc7.1 binutils2.28 | x86 / x64 | x86 / x64 |
| MinGW r27 | 2017-08-16 | v5.0.2 gcc7.2 binutils2.29 | x86 / x64 | x86 / x64 |
| MinGW r28 | 2018-02-07 | v5.0.3 gcc7.3 binutils2.29.1 | x86 / x64 | x86 / x64 |
| MinGW r29 | 2018-11-01 | v5.0.4 gcc8.2 binutils2.31.1 | x86 / x64 | x86 / x64 |
| MinGW r30 | 2019-02-27 | v6.0.0 gcc8.3 binutils2.31.1 | x86 / x64 | x86 / x64 |
| MinGW r31 | 2019-10-14 | v6.0.0 gcc9.2 binutils2.32 | x86 / x64 | x86 / x64 |
| MinGW r32 | 2020-04-30 | v7.0.0 gcc9.3 binutils2.34 | x86 / x64 | x86 / x64 |
| MinGW r33 | 2021-02-27 | v8.0.0 gcc10.2 binutils2.36.1 | x86 / x64 | x86 / x64 |
| MinGW r34 | 2021-07-13 | v8.0.2 gcc10.3 binutils2.36.1 | x86 / x64 | x86 / x64 |
| MinGW r35 | 2021-08-15 | v9.0.0 gcc11.2 binutils2.36.1 | x86 / x64 | x86 / x64 |
| MinGW r36 | - | - | x86 / x64 | x86 / x64 |
| MinGW r37 | 2022-04-26 | v10.0.0 gcc11.3 binutils2.38 | x86 / x64 | x86 / x64 |
| MinGW r38 | 2022-08-23 | v10.0.0 gcc12.2 binutils2.39 | x86 / x64 | x86 / x64 |
Thanks to Nim-IDA-FLIRT-Generator by @hunterbr72, we were able to produce object files for Nim, which we could then turn into MCRIT symbols.
| Name | Version | MCRIT | SMDA |
|---|---|---|---|
| Nim | 1.2.10 | x86 / x64 | x86 / x64 |
| Nim | 1.4.8 | x86 / x64 | x86 / x64 |
| Nim | 1.6.14 | x86 / x64 | x86 / x64 |
Ben Herzog wrote a great reverser's guide to Rust and provided some example binaries with full symbols (PDB) and covering different standard library functions.
| Name | Date | Version | MCRIT | SMDA |
|---|---|---|---|---|
| Rust RE-Tour | 2023-06-01 | Rosetta | x86 / x64 | x86 / x64 |
Reference code for the Rust standard library and commonly used crates.io crates, built with matchplate at the exact rustc version, target and release profile of real samples. Each crate is built through its own test suite, which instantiates its generics over concrete types — an .rlib retains only non-generic code. Every function is deduplicated on (pic_hash, name) and ingested per binary, so each crate keeps its own lib.rust.<crate> family and lib.rust.std is split out via a std donor.
Names: family=lib.rust.<crate>, version=<semver>, component=<rustc>-<triple>-<profile>.
Pick the point that matches your sample — rustc version first, then the lto axis. Exact-version reference data identified 43.9% more library code than one version off, while further distance costs under a point per version; the lto setting separates cleanly while opt-level barely does. As with Golang, loading many points at once inflates candidate clusters. A Rust binary usually names its compiler: panic paths embed /rustc/<commit-hash>/library/..., and the hash maps to a release in Rust's own channel manifests.
Built with no Microsoft-licensed material (rust-lld, mingw-w64 import libraries, own CRT stubs).
| Name | Date | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|---|
| Rust crates | 2023-04-20 | rustc 1.69.0 | x86_64-pc-windows-msvc, opt3-ltofat | 47 MB | 18 MB |
| Rust crates | 2023-11-16 | rustc 1.74.0 | x86_64-unknown-linux-gnu, optz-ltofat | 18 MB | 7 MB |
| Rust crates | 2024-06-13 | rustc 1.79.0 | x86_64-pc-windows-gnu, opt3-ltooff | 23 MB | 10 MB |
| Rust crates | 2024-11-28 | rustc 1.83.0 | x86_64-pc-windows-msvc, opt3-ltooff | 39 MB | 14 MB |
| Rust crates | 2025-05-15 | rustc 1.87.0 | x86_64-pc-windows-msvc, opts-ltooff | 53 MB | 20 MB |
| Rust crates | 2026-03-05 | rustc 1.94.0 | i686-pc-windows-msvc, optz-ltofat | 39 MB | 13 MB |
| Rust crates | 2026-04-16 | rustc 1.95.0 | x86_64-pc-windows-msvc, optz-ltooff | 95 MB | 35 MB |
Depending on how the library code is distributed, we extract and convert code similar to the above outlined methodology. In some cases, we also processed code found "as-is".
aPLib is a popular compression library implementing LZ.
Dates are estimates based on file timestamps found in distributed files.
| Name | Date | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|---|
| aPLib | 1998-05-03 | 0.12b | as distributed | x86 PE | x86 PE |
| aPLib | 1998-09-23 | 0.17b | as distributed | x86 PE | x86 PE |
| aPLib | 1998-10-03 | 0.18b | as distributed | x86 PE | x86 PE |
| aPLib | 1998-11-05 | 0.19b | as distributed | x86 PE | x86 PE |
| aPLib | 1999-01-14 | 0.20b | as distributed | x86 PE | x86 PE |
| aPLib | 1999-05-26 | 0.22 | as distributed | x86 PE | x86 PE |
| aPLib | 2001-01-24 | 0.26 | as distributed | x86 PE | x86 PE |
| aPLib | 2002-04-18 | 0.36 | as distributed | x86 PE / x86 ELF | x86 PE / x86 ELF |
| aPLib | 2004-10-16 | 0.42 | as distributed | x86 PE / x86 ELF | x86 PE / x86 ELF |
| aPLib | 2005-10-08 | 0.43 | as distributed | x86 PE / x86 ELF | x86 PE / x86 ELF |
| aPLib | 2008-06-22 | 0.44 | as distributed | x86 PE / x86 ELF | x86 PE / x86 ELF |
| aPLib | 2009-07-29 | 1.01 | as distributed | x86 PE / x86 ELF / x64 PE / x64 ELF | x86 PE / x86 ELF / x64 PE / x64 ELF |
| aPLib | 2014-01-20 | 1.10 | as distributed | x86 PE / x86 ELF / x64 PE / x64 ELF | x86 PE / x86 ELF / x64 PE / x64 ELF |
| aPLib | 2014-07-21 | 1.11 | as distributed | x86 PE / x86 ELF / x64 PE / x64 ELF | x86 PE / x86 ELF / x64 PE / x64 ELF |
zlib is a popular compression library implementing the Deflate algorithm.
Dates taken from Changelog file / release notes.
Source lib files taken from the Shiftmedia project.
The MinGW-w64 rows were built from unmodified upstream release tarballs with scripts/build_corpus.py, using upstream's own win32/Makefile.gcc; they cover zlib1.dll rather than a static lib, and MinGW C runtime functions were excluded so they stay attributed to MinGW. See data/libzlib/provenance.json for source URLs, digests, compiler and flags.
| Name | Date | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|---|
| libzlib | 2013-04-28 | 1.2.8 | MSVC12 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2013-04-28 | 1.2.8 | MSVC14 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2016-12-31 | 1.2.9 | MSVC12 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2016-12-31 | 1.2.9 | MSVC14 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2017-01-02 | 1.2.10 | MSVC12 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2017-01-02 | 1.2.10 | MSVC14 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2017-01-15 | 1.2.11 | MSVC12 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2017-01-15 | 1.2.11 | MSVC14 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2017-01-15 | 1.2.11 | MSVC15 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2013-04-28 | 1.2.8 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2017-01-15 | 1.2.11 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2022-10-13 | 1.2.13 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libzlib | 2024-01-22 | 1.3.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
bzip2 is a Burrows-Wheeler compressor found in installers and archivers for over two decades.
Generated with scripts/build_corpus.py; see data/bzip2/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| bzip2 | 1.0.8 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| bzip2 | 1.0.8 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
cJSON is a minimal JSON parser very widely vendored into C tooling.
Generated with scripts/build_corpus.py; see data/cJSON/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| cJSON | 1.6.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| cJSON | 1.6.0 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| cJSON | 1.7.15 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| cJSON | 1.7.19 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| cJSON | 1.7.19 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
libcurl is commonly statically linked into downloaders and droppers. Built against the Schannel TLS backend, which shapes the emitted code more than the version does.
Generated with scripts/build_corpus.py; see data/libcurl/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| libcurl | 8.4.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libcurl | 8.4.0 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| libcurl | 8.15.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libcurl | 8.15.0 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
libevent is an event notification library linked into a lot of older tooling.
Generated with scripts/build_corpus.py; see data/libevent/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| libevent | 2.1.12 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libevent | 2.1.12 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libevent | 2.1.12 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| libevent | 2.1.12 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
liblzma provides LZMA/LZMA2, ubiquitous in installers. Built from signed git tags rather than release tarballs, because the 2024 backdoor (CVE-2024-3094) was present only in the tarballs.
Generated with scripts/build_corpus.py; see data/liblzma/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| liblzma | 5.4.7 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| liblzma | 5.4.7 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| liblzma | 5.8.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| liblzma | 5.8.1 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
libsodium provides X25519 and XSalsa20 and is linked by several ransomware families.
Generated with scripts/build_corpus.py; see data/libsodium/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| libsodium | 1.0.18 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libsodium | 1.0.18 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| libsodium | 1.0.20 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libsodium | 1.0.20 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
LibTomCrypt is a crypto toolkit with a long history of reuse in malware. Built against LibTomMath for its bignum backend.
Generated with scripts/build_corpus.py; see data/libtomcrypt/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| libtomcrypt | 1.18.2 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libtomcrypt | 1.18.2 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
libuv is the event loop behind Node.js and a good deal of C tooling.
Generated with scripts/build_corpus.py; see data/libuv/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| libuv | 1.44.2 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libuv | 1.44.2 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| libuv | 1.52.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libuv | 1.52.1 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
libxml2 is vendored into an enormous amount of software. ShiftMediaProject additionally publishes MSVC builds with PDBs, which would complement these.
Generated with scripts/build_corpus.py; see data/libxml2/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| libxml2 | 2.9.14 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libxml2 | 2.9.14 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| libxml2 | 2.14.3 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libxml2 | 2.14.3 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
lz4 is a fast compressor common in modern loaders, packers and Electron-derived software.
Generated with scripts/build_corpus.py; see data/lz4/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| lz4 | 1.9.4 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| lz4 | 1.10.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| lz4 | 1.10.0 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
mbedTLS is the TLS and crypto stack of the embedded and IoT world. One build per code generation rather than per release.
Generated with scripts/build_corpus.py; see data/mbedTLS/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| mbedTLS | 2.16.12 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 2.16.12 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 2.16.12 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 2.28.10 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 2.28.10 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 2.28.10 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 3.0.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 3.0.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 3.0.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 3.6.7 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 3.6.7 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 3.6.7 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| mbedTLS | 3.6.7 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
PCRE2 is the regular expression engine used by anything current. JIT is enabled, as it is in most distributions.
Generated with scripts/build_corpus.py; see data/pcre2/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| pcre2 | 10.39 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| pcre2 | 10.39 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| pcre2 | 10.45 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| pcre2 | 10.45 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
SQLite is almost certainly the most widely embedded database on Windows. Built from the official amalgamation, which is how applications consume it.
Generated with scripts/build_corpus.py; see data/sqlite3/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| sqlite3 | 3.8.11.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| sqlite3 | 3.31.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| sqlite3 | 3.31.1 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| sqlite3 | 3.50.4 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| sqlite3 | 3.50.4 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
libpng is found in old packers, installers and image-handling tooling. Built against a zlib staged into the source tree, so the build needs nothing preinstalled.
Generated with scripts/build_corpus.py; see data/libpng/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| libpng | 1.6.50 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libpng | 1.6.50 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
libtiff has a long CVE history and is embedded widely. Codecs that would pull external dependencies are disabled; the core reader and writer is what matters for recognising reuse.
Generated with scripts/build_corpus.py; see data/libtiff/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| libtiff | 4.0.10 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libtiff | 4.7.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| libtiff | 4.7.0 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
wolfSSL is an embedded TLS stack. One version only: it is genuinely uncommon in Windows malware compared with OpenSSL and mbedTLS.
Generated with scripts/build_corpus.py; see data/wolfSSL/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| wolfSSL | 5.9.2 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| wolfSSL | 5.9.2 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
OpenSSL is the largest body of crypto code in this corpus. The three versions are chosen for architecture rather than recency: 1.1.1 has no provider layer at all and is still by far the most encountered OpenSSL, 3.0 introduced the provider architecture, and 3.5 is the current LTS.
OpenSSL in the wild is overwhelmingly MSVC-built, so a MinGW reference matches those only weakly; its strength here is matching MinGW/GCC-built Windows binaries, and by proxy ELF builds.
Generated with scripts/build_corpus.py; see data/OpenSSL/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| OpenSSL | 1.1.1w | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| OpenSSL | 1.1.1w | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| OpenSSL | 1.1.1w | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| OpenSSL | 1.1.1w | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| OpenSSL | 3.0.15 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| OpenSSL | 3.0.15 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| OpenSSL | 3.5.8 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| OpenSSL | 3.5.8 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
Crypto++ is a C++ crypto toolkit and a regular guest in malware. The three releases are picked where the library was restructured: 5.6.5 is the last of the 5.6 line and predates the C++11 move of 6.0, 7.0.0 follows the split of the SIMD implementations into their own translation units, and 8.9.0 is current. Any two of them overlap far less than their version numbers suggest.
The compilation is under the Boost Software License 1.0 while the individual files are in the public domain, which is the arrangement described in upstream's License.txt.
Generated with scripts/build_corpus.py; see data/cryptopp/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| cryptopp | 5.6.5 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| cryptopp | 7.0.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| cryptopp | 8.9.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| cryptopp | 8.9.0 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
7z.dll carries the archiver and every codec, including the LZMA implementation that is among the most copy-pasted compression code in Windows malware.
7-Zip publishes no checksums of its own; the digests recorded here were taken from the fetched archives over HTTPS.
Generated with scripts/build_corpus.py; see data/7-Zip/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| 7-Zip | 23.01 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| 7-Zip | 23.01 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| 7-Zip | 26.03 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| 7-Zip | 26.03 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
PCRE1 ended at 8.45 but is still linked into a great deal of legacy Windows software, and it shares almost no code with PCRE2. JIT and UTF are enabled explicitly, because PCRE1's CMake build defaults both off where a distribution or a vendored copy ships them on.
Generated with scripts/build_corpus.py; see data/pcre/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| pcre | 8.45 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| pcre | 8.45 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
Abseil also covers CCTZ, which is vendored inside it as absl/time/internal/cctz, so google/cctz is not processed separately. Abseil builds as a pile of static archives, which SMDA cannot read, so they are linked into one DLL with --whole-archive to force every object in rather than only what an anchor references.
Generated with scripts/build_corpus.py; see data/abseil/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| abseil | 20220623.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| abseil | 20250127.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| abseil | 20250127.1 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
The two versions bracket the largest code-level split in this part of the corpus: 2022-06-01 is the last release before RE2 took a dependency on Abseil, and the current one is built on Abseil throughout. A matcher that knows only one of them recognises very little of the other.
For the Abseil-based version, Abseil is built alongside as DLLs and only imported, so none of its object code is attributed to re2 - the import table shows libabsl_hash, libabsl_strings, libabsl_synchronization and the rest. What is present is the Abseil inline and template code RE2 instantiates, which any RE2 binary carries.
Generated with scripts/build_corpus.py; see data/re2/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| re2 | 2022-06-01 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| re2 | 2022-06-01 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| re2 | 2025-11-05 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| re2 | 2025-11-05 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
nlohmann/json is header-only, so none of it exists in a binary until a translation unit uses it and there is no upstream artefact to disassemble. The reference data comes from compiling a unit that instantiates the templates (scripts/corpus/exercisers/nlohmann_json.cpp); the functions in the binary are nlohmann's, the exerciser only selects which.
Generated with scripts/build_corpus.py; see data/nlohmann_json/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| nlohmann_json | 3.10.5 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| nlohmann_json | 3.11.3 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| nlohmann_json | 3.11.3 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| nlohmann_json | 3.12.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| nlohmann_json | 3.12.0 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
Protocol Buffers, in three generations chosen where the library was rebuilt rather than by recency: 3.6.1 still parses the wire format down the old recursive path (EpsCopyInputStream arrives in 3.11, the table-driven parser in 3.19), 21.12 is the last release before the hard Abseil dependency and the generation embedded nearly everywhere, and 31.1 is current and Abseil-based throughout.
31.1 is built shared so Abseil and utf8_range are imported rather than linked in; about 15% of its functions still demangle to absl:: names, which are instantiations over protobuf's own types and are in any real protobuf binary.
Generated with scripts/build_corpus.py; see data/protobuf/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| protobuf | 3.6.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| protobuf | 21.12 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| protobuf | 21.12 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| protobuf | 31.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| protobuf | 31.1 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
jemalloc has a real, if niche, Windows presence: Firefox-derived code, and some game and anti-cheat stacks. The C++ wrapper is disabled, because it adds libstdc++ surface without adding allocator code.
Generated with scripts/build_corpus.py; see data/jemalloc/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| jemalloc | 5.3.0 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
data/MinGW carries libstdc++ and libsupc++ on x64 but not on x86: the r38 x86 report is mostly Win32 import thunks, with no _ZN/_ZSt symbols and no libgcc helpers at all, so 32-bit libstdc++ is covered nowhere else in the corpus. This recipe is x86 only for that reason - an x64 build would duplicate what r38 already has.
Reprocessing the MinGW x86 inputs is the real fix and is a question for the maintainer; this fills the gap in the meantime.
Generated with scripts/build_corpus.py; see data/libstdc++/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| libstdc++ | 13.2-mingw-w64 | MinGW-w64 GCC 13 | x86 PE | x86 PE |
Interpreters and virtual machines that are commonly statically linked into tooling.
Lua is the reference implementation of the language, embedded in a great deal of tooling.
Generated with scripts/build_corpus.py; see data/Lua/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| Lua | 5.1.5 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| Lua | 5.1.5 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| Lua | 5.3.6 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| Lua | 5.4.8 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| Lua | 5.4.8 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
LuaJIT is the runtime behind the toolkit named in issue #1; the reusable machine code an analyst meets is this interpreter and JIT core, statically linked in. Upstream carries no git tags, so versions are pinned to the commit that set the version string.
Generated with scripts/build_corpus.py; see data/LuaJIT/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| LuaJIT | 2.0.5 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| LuaJIT | 2.0.5 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| LuaJIT | 2.1.0-beta3 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| LuaJIT | 2.1.0-beta3 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| LuaJIT | 2.1-rolling-2026-09-08 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
q3vm is a standalone Quake 3 QVM interpreter. Its vm.c is written to be dropped into other projects, so the same shape appears in Quake3-engine derivatives and anything embedding a QVM sandbox.
Generated with scripts/build_corpus.py; see data/q3vm/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| q3vm | 1.3.1 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| q3vm | 1.3.1 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
| q3vm | 2026-03-06 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| q3vm | 2026-03-06 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
Position-independent loaders and the projects that generate them. Entries marked as compiled by MSVC are blobs committed upstream and disassembled as buffers, not rebuilt here.
donut generates position-independent loaders. What is covered here is the loader, not the generator: the loader is the code donut embeds in whatever it packages, so it is what turns up in samples, and upstream commits it MSVC-compiled in loader_exe_x86.h and loader_exe_x64.h - the same bytes that ship in the release binaries and the PyPI package.
The generator is deliberately not built. It statically links the vendored lib/aplib64.lib, and aPLib is already a family here, so building it would duplicate aPLib under donut's name. Note that the loader blobs contain aPLib's depacker (loader/depack.c) for the same reason - that much is unavoidable, since it is part of the shipped loader.
Generated with scripts/build_corpus.py; see data/donut/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| donut | 1.1 | MSVC (as committed upstream) | x86 code / x64 code | x86 code / x64 code |
MemoryModule is the canonical in-memory PE loader, reused verbatim by a long tail of packers and loaders, almost always as a vendored copy frozen at some old commit.
Generated with scripts/build_corpus.py; see data/MemoryModule/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| MemoryModule | 0.0.4 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| MemoryModule | 2019-02-24 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
| MemoryModule | 2019-02-24 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
pe_to_shellcode converts PE files to shellcode. The stub2 loaders committed upstream are covered; they are MSVC-built and cannot be reproduced without Visual Studio.
Generated with scripts/build_corpus.py; see data/pe_to_shellcode/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| pe_to_shellcode | 1.0 | MSVC (as committed upstream) | x86 code / x64 code | x86 code / x64 code |
| pe_to_shellcode | 1.2 | MSVC (as committed upstream) | x86 code / x64 code | x86 code / x64 code |
sRDI implements reflective DLL injection. The compiled MSVC blobs committed upstream are covered rather than a rebuild, since those are what is encountered in the wild.
Generated with scripts/build_corpus.py; see data/sRDI/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| sRDI | 2018-05-27 | MSVC (as committed upstream) | x86 code / x64 code | x86 code / x64 code |
| sRDI | 2020-04-15 | MSVC (as committed upstream) | x86 code / x64 code | x86 code / x64 code |
| sRDI | 2022-06-17 | MSVC (as committed upstream) | x86 code / x64 code | x86 code / x64 code |
Implementations of the WOW64 transition: reaching 64-bit code, and the 64-bit ntdll, from a 32-bit process. Every one of them is x86 by construction rather than by choice - they truncate pointers to uint32_t, read CONTEXT.Ebx, or use inline assembly that x64 MSVC does not implement - so each is built for x86 only.
A header-only Heaven's Gate implementation whose gate is a constexpr byte array copied into RWX memory rather than assembly, which is what lets it build with GCC as well as MSVC. Nothing of it exists in a binary until a translation unit uses it, so the reference data comes from an exerciser that instantiates the public surface and the detail:: layer behind it, including both call_function arities - the four-argument-or-fewer and the more-than-four paths are different code. Every function in the header is inline, so the exerciser takes each one's address as well as calling it.
Generated with scripts/build_corpus.py; see data/wow64pp/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| wow64pp | 2020-09-19 | MinGW-w64 GCC 13 | x86 PE | x86 PE |
| wow64pp | 2020-09-19 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE | x86 PE |
A WOW64 transition library that exposes the 64-bit ntdll to 32-bit code, through RtlInvokeX64 and a family of RtlGetProcAddressWow64 helpers. Unlike most Heaven's Gate code it ships as a DLL with an eleven-symbol export table, so it is linked rather than copied and the same names appear wherever it is used. 26 functions, 17 of them the library's own.
Generated with scripts/build_corpus.py; see data/RtlWow64/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| RtlWow64 | 2021-02-12 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE | x86 PE |
Issues 32-bit direct syscalls by walking the WOW64 ntdll and calling Wow64SystemServiceEx, rather than by the usual far-return gate. It is a proof-of-concept executable rather than a library, so what is recorded is the tool itself. Built Release|Win32 specifically, which upstream requires because Debug instrumentation moves the memory layout the technique depends on. Of its 41 functions only 9 are wowGrail's own; the rest is the std::string and std::wstring machinery its get64b_CSTR and get64b_WSTR helpers instantiate.
Generated with scripts/build_corpus.py; see data/wowGrail/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| wowGrail | 2021-05-27 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE | x86 PE |
A compact Heaven's Gate implementation reaching 64-bit code from a 32-bit process by far-returning through selector 0x33. The gate is a patched byte array rather than assembly, which is what lets it carry no MSVC-only assembly syntax at all. Built with optimization and inlining disabled as its project file specifies, and with no C runtime in the image - it links IgnoreAllDefaultLibraries with main as the entry point, which is why the runtime filter is turned off for it. 15 functions, 12 of them its own.
Generated with scripts/build_corpus.py; see data/HeavensGate2/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| HeavensGate2 | 2017-07-23 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE | x86 PE |
A second Heaven's Gate demonstration, and a useful contrast to the others: it implements the gate in __declspec(naked) functions with full inline assembly rather than in patched byte arrays, so its emitted shape differs even though the technique is the same. Only the Heavens Gate subdirectory of its repository is compiled - one named translation unit, nothing globbed - and nothing else in that tree is built, referenced or recorded. The repository ships no build system, so the compile and link lines come from the recipe. 26 functions, 20 of them its own.
Generated with scripts/build_corpus.py; see data/NTTITONHeavensGate/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| NTTITONHeavensGate | 2017-06-16 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE | x86 PE |
Projects that hide which Windows APIs a binary calls - by resolving imports from hashes at run time, or by rewriting the import table so a call appears to target something else.
Resolves imports at run time by hashing export names with MurmurHash2A, so the import table carries no recognisable API names. The hash and the export-table walk are ordinary out-of-line functions; the rest is a template wrapper instantiated once per resolved function type, which is why the artefact is almost entirely the library's own code - 170 of 180 functions on x64 and 194 of 204 on x86. Built at /Od: the level was chosen cautiously rather than measured, because at /O2 much of the wrapper collapses into its callers.
Generated with scripts/build_corpus.py; see data/WinApiObfuscator/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| WinApiObfuscator | 2.0.0.0 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
A header-only C++20 wrapper over the native NT API, built against a pinned copy of phnt rather than a vcpkg-resolved one. Built at /Od, and not as a preference: NTW_INLINE is __forceinline and appears 958 times across 56 headers, so at /O2 cl folds essentially the whole library into its caller and there is nothing left to record - upstream's own test CMakeLists forces /Od even in Release for the same reason. The consequence is worth stating rather than leaving to be discovered: this sample describes an unoptimised consumer, and an /O2 consumer has hardly any nt_wrapper functions left to match.
The exerciser is five translation units rather than one, each compiled with failure tolerated and the link taking whatever objects were produced, so one bad spelling costs one slice of coverage instead of the family. That is safe here only because every function the library provides is inline. 140 functions on each architecture, 126 of them the library's own.
Generated with scripts/build_corpus.py; see data/nt_wrapper/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| nt_wrapper | 2021-02-02 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
Proxies Win32 calls through a kernel driver, so the work a process appears to do in user mode is performed by APICallProxy.sys on its behalf via IOCTLs. The driver is the only part worth recording - the seven user-mode executables beside it hold one to four functions each and cannot clear the eight-function floor. Built Release|x64 only, which is the single project configuration carrying the link libraries. This is the corpus's first kernel-mode artefact: the runner's WDK was confirmed present by probe rather than assumed, and the recipe records that a .sys links runtime the msvcrt/ucrt baseline cannot recognise, so some kernel glue stays under this family's name.
It also vendors two third parties without reproducing their terms: DisableDSE/hde64.h is Vyacheslav Patkov's Hacker Disassembler Engine, carrying a copyright line and no grant of permission, and roughly 25 of its functions are wbenny/KSOCKET's Ks* socket layer renamed to APIProxy* - that one is MIT, so what is missing is the attribution rather than the permission.
Generated with scripts/build_corpus.py; see data/APICallProxy/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| APICallProxy | 2022-12-09 | MSVC 19.44 (Visual Studio 2022, v143) | x64 PE | x64 PE |
Rewrites a PE's import table so calls to one API appear to target another. What is recorded is the tool, not its output - a patched binary is somebody else's code with this project's edits applied. Its injected shellcode is worth knowing about: it is not a byte blob but ordinary C++ static member functions, each __declspec(noinline) and address-taken in a static table, so the linker can neither discard nor fold them. The x86 artefact carries 89 unnamed functions against x64's none; those are the __ehhandler$ and __unwindfunclet$ fragments that 32-bit C++ exception handling emits and the PDB records no symbol for, which is why the symbol gate ignores functions below three instructions.
Generated with scripts/build_corpus.py; see data/CallObfuscator/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| CallObfuscator | 2.0 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
Public offensive-tooling code bases that are copied into implants more or less verbatim. Every one of them needs Visual Studio - ATL, the DIA SDK, MASM, or in the two kernel drivers' case a WDK - and they are built on a windows-2022 runner by .github/workflows/windows-reference-data.yml rather than approximated with GCC.
A collection of Win32 API-abuse routines. Upstream ships no static-library or DLL configuration, so the sources are compiled into one and linked with /OPT:NOREF, which keeps routines nothing calls - the point here is coverage, not a minimal binary. A small number of sources need ATL or __try/__except and are skipped.
Generated with scripts/build_corpus.py; see data/VX-API/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| VX-API | 2.01.015 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
A Windows memory-hacking library: process and module management, manual PE mapping, local and remote hooking, pattern search. Built in its Release(DLL) configuration, which statically compiles the vendored AsmJit and rewolf-wow64ext sources into the same image - so functions from those projects are present here under the BlackBone family, as they are in any real BlackBone DLL. BeaEngine is imported from its own DLL and is not. The kernel driver is a separate family, BlackBoneDrv, because it shares no code with this image.
Generated with scripts/build_corpus.py; see data/BlackBone/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| BlackBone | 2023-07-17 | MSVC 19.44 (Visual Studio 2022, v143) | x86 PE / x64 PE | x86 PE / x64 PE |
BlackBone's kernel driver, from the same commit as the library above and in its own solution. It does from ring 0 what the library cannot do from ring 3: manually maps images into other processes, injects and queues APCs, remaps one process's memory into another, edits VAD nodes and PTEs to hide or reprotect regions, hooks the SSDT and patches handle-table entries - all reached from user mode through a single DeviceIoControl switch. A separate family rather than a second component of BlackBone, because the two images have not one function in common: that one is C++ linked against the ucrt, this is C compiled against ntifs.h. Built Win10Release|x64, which is upstream's own CI configuration and the only one of the four whose undocumented structure layouts describe a kernel anyone still runs; all eight of the project's configurations are x64 and it refuses to compile for x86 at all.
Read its 321 functions with two subtractions in mind. 58 of them are not code at all: they are MSVC string-literal COMDAT symbols (??_C@_...), which sit in the driver's code sections and are disassembled as one- to six-instruction fragments. A further 112 reach three instructions or fewer, almost all of them import thunks into ntoskrnl. What is left is 144 functions of ten instructions or more, which is the driver's own code and lines up with the 139 functions counted in its source - the small excess being static helpers and AVL callbacks the file-by-file count does not reach. Match quality should be judged on those 144, not on 321.
Eight of them are not this project's code, and a match on those eight is a match on Windows kernel source: ldrreloc.c's four Ldr* relocation routines say in the file that they are Windows Research Kernel source, usable only under a licence agreement the repository does not carry, and VadHelpers.c's four Mi* AVL routines are the same kernel's code carried in without a copyright header at all.
Generated with scripts/build_corpus.py; see data/BlackBoneDrv/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| BlackBoneDrv | 2023-07-17 | MSVC 19.44 (Visual Studio 2022, v143) | x64 PE | x64 PE |
The v1 generator, whose stubs resolve their own syscall number inline: each loads the PEB from gs:[60h] and walks major version, minor version and build number down a chain of comparisons before issuing the syscall. That ladder is the recognisable part, and it is what an implant carries when it copies this generator's output. SysWhispers2 and 3 emit 2- to 15-instruction stubs that differ only by one immediate and would form a large, low-value cluster, so they are not covered.
The DLL holds the generated stubs and nothing else - no C runtime, no entry point - and exports them so each carries its name.
Generated with scripts/build_corpus.py; see data/SysWhispers/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| SysWhispers | 2021-07-06 | MSVC 19.44 (Visual Studio 2022, v143) | x64 PE | x64 PE |
Hidden
A WDM filter driver that hides and protects filesystem objects, registry keys and processes, together with the user-mode client that drives it. The driver registers a filesystem minifilter and a registry callback, watches process creation against a rule set it keeps in memory, reads its configuration from the registry, and exposes the whole surface through a single DeviceIoControl switch. Two artefacts come out of the one solution: Hidden.sys, and HiddenCLI.exe with the HiddenLib static library linked into it - the .lib is an archive rather than a PE and is not collected on its own, so a match on the client may be a match on the library.
Neither reported function count is the project's own code, and both were counted rather than estimated. Hidden.sys reports 507 functions: 150 are MSVC string-literal COMDATs that are not code at all, 90 are import thunks of three instructions or fewer, 101 are Zydis or Zycore, and 4 are compiler runtime - leaving 134 that are the driver's own. HiddenCLI.exe reports 525: 223 thunks, 83 short bodies, 72 CRT or STL the runtime filter did not reach, and 147 that belong to the client and HiddenLib. Judge coverage on 134 and 147.
A fifth of Hidden.sys is therefore not this project's code: Hidden/Disasm carries a vendored Zydis 3.1.0 and Zycore 1.0.0 compiled into the driver, so a match landing in the instruction decoder is a match on Zydis. It is built with ZYAN_NO_LIBC, which changes what Zydis compiles, so those functions will not necessarily agree with a Zydis built the ordinary way.
The user-mode half is built /MD. Upstream builds it /MT, which linked the CRT and the STL statically and put 952 functions in the image of which only about 130 were the project's; /MD leaves that code in ucrtbase and vcruntime140, where data/MSVC already covers it. The driver keeps its own runtime, having no ucrt to move out.
The project carries no licence of any kind - no LICENSE or COPYING file and no copyright line in any of its own sources. The only licence text in the repository is the MIT header on the vendored Zydis and Zycore files. The Hidden Package project, which runs Inf2Cat over the driver's .inf to emit a catalogue and produces no code, is not built; the binaries are linked and disassembled, never packaged, signed, installed or loaded.
Generated with scripts/build_corpus.py; see data/Hidden/provenance.json for source digests, compiler and flags.
Four compile-time string obfuscators, which hide literals by encrypting them during compilation and decrypting on first use, and one post-build patcher that does the same job from outside the compiler. None of the four exists in a binary until something uses it - the C++ ones are header-only and almost entirely constexpr, and the Rust one encodes in const context - so the reference data comes from an exerciser or driver that uses the library; the functions recorded are the library's own.
These are the one group here where the optimization level is not a free choice, and it differs per project - the level each was built at is recorded in build_flags and argued in notes, because it decides what survives into the binary at all. Reference data built at one level will not match a consumer built at another.
All four of the compile-time obfuscators are portable, and all four are also built for Linux: these are the corpus's only ELF artefacts, and every one of them is an ELF row beside the PE row in the same table. Same pinned commit, same exerciser or driver, same optimization level - only the container differs, so the two are directly comparable. They are shared objects rather than executables on purpose: a -shared ELF links glibc, libstdc++ and libm dynamically, so none of their code enters the sample under a library's name, and they are built -fvisibility=hidden so that only the exerciser's entry point is exported and the library's own calls stay direct, which is what the PE builds get for free from __declspec(dllexport).
adamyaxley/Obfuscate encrypts each literal with a key derived from its source line and decrypts it on first use. It instantiates per (length, line), so a binary carries one small cluster of functions per obfuscated string rather than one shared routine. Built at -O0: at -O2 every instantiation collapses to a five-byte endbr64; ret stub, because the destructor's zeroing loop is dead-store eliminated and the function survives only because thread_local takes its address.
Generated with scripts/build_corpus.py; see data/Obfuscate/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| Obfuscate | 2026-06-03 | GCC 13 (Linux, glibc) | x86 ELF / x64 ELF | x86 ELF / x64 ELF |
| Obfuscate | 2026-06-03 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
Snowapril's compile-time obfuscator, instantiated per call site through __COUNTER__, so even identical strings at different sites emit different functions. Built at -O0, which is the only level that emits anything: there is no constexpr variable forcing compile-time evaluation, so at -O0 the encryption is emitted as real runtime code and at -O1 and above it inlines into the caller and disappears entirely.
Built with SOURCE_DATE_EPOCH pinned, because upstream seeds its generator from __TIME__ and without that the cipher constants and the mangled symbol names change on every rebuild.
Generated with scripts/build_corpus.py; see data/StringObfuscatorCT/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| StringObfuscatorCT | 2019-12-11 | GCC 13 (Linux, glibc) | x86 ELF / x64 ELF | x86 ELF / x64 ELF |
| StringObfuscatorCT | 2019-12-11 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
katursis/StringObfuscator templates on string length alone, so a binary using it carries one decrypt routine per distinct length rather than one per string - adding more strings of a length already present adds no new code. Built at -O2, which upstream requires and which this corpus confirmed the reason for: at -O0 the obfuscation does not happen and the exerciser's literals were recoverable from the binary with strings, where at -O1 and -O2 none were. Its decrypt() survives -O2 because it carries __attribute__((noinline)), guarded by #ifdef __GNUC__ - which is why there is no MSVC build of it here.
Generated with scripts/build_corpus.py; see data/StringObfuscator/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| StringObfuscator | 2021-08-07 | GCC 13 (Linux, glibc) | x86 ELF / x64 ELF | x86 ELF / x64 ELF |
| StringObfuscator | 2021-08-07 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
CasualX/obfstr is the Rust entry in this group, and the first Rust family this tooling generates rather than inherits. Its decoder, obfstr::xref::inner, is #[inline(never)] and generic over const SEED: u64, so it emits exactly one monomorphization per obfuscated item and each one is a different shape: the seed selects the arithmetic and drives a control-flow flattening pass around it. The seed derives from the file, line, column and the string itself, so identical strings at different call sites still emit distinct functions; measured here, 46 strings gave 46 obfstr:: functions on each architecture. Unlike the C++ obfuscators above, it emits that same one-per-string shape in debug and in release alike, so the optimization level is not the provenance hazard here; release is what is recorded.
The driver crate is #![no_std] with panic = "abort", because a stock Rust cdylib would pull thousands of Rust std and core functions into the sample under this family's name - the same trap -static-libstdc++ is for the C++ families. OBFSTR_SEED is left unset, which is upstream's own reproducible default and makes release builds byte-identical across rebuilds.
Generated with scripts/build_corpus.py; see data/obfstr/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| obfstr | 0.4.6 | GCC 13 (Linux, glibc) | x86 ELF / x64 ELF | x86 ELF / x64 ELF |
| obfstr | 0.4.6 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |
4g3nt47/Obfuscator is not a compile-time obfuscator at all, and is here for contrast as much as for coverage: it is a standalone command-line tool that opens an already-built binary, finds every string prefixed with the marker [OBFS_ENC], XORs it with a rolling key and writes a new file. Nothing of it is ever linked into the program it protects. The only part that propagates downstream is a copy-pasted ten-line obfs_decode(), which the upstream README asks you to paste into your own source, so it appears in whatever shape your own compiler gives it rather than in the shape recorded here. What this family identifies is the tool binary itself.
Seven functions is the whole project - obfs_encode, obfs_decode, obfs_find_offset, obfs_filecpy, obfs_read_until_null, obfs_run and main - so the recipe sets min_functions=7 against the corpus-wide floor of eight, and the runtime residue it used to clear that floor on is now measured by a baseline probe instead. Built at -O0, not upstream's -Os: obfs_decode is byte-identical to obfs_encode, so identical-code folding reduces it to a one-instruction tail jump at -Os and -O2. Compiled directly rather than through upstream's Makefile, which hardcodes -s on the link line, never creates the bin/ directory it writes objects to, and installs a bin/main that no rule builds.
Generated with scripts/build_corpus.py; see data/Obfuscator4g3nt47/provenance.json for source digests, compiler and flags.
| Name | Version | Compiler | MCRIT | SMDA |
|---|---|---|---|---|
| Obfuscator4g3nt47 | 2023-02-26 | MinGW-w64 GCC 13 | x86 PE / x64 PE | x86 PE / x64 PE |