blint - blint is a Binary Linter that checks the security

项目说明

blint

<img src="./blint.png" width="200" height="auto" />


blint is a Binary Linter that checks the security properties and capabilities of your executables. It is powered by lief and can generate a Software Bill-of-Materials (SBOM) for supported binaries.

What is blint?

blint is a tool for reverse engineers, security analysts, and de to quickly assess the security posture and composition of a binary file. In an age of statically-linked Golang, Rust, and .NET applications, understanding what's inside a binary is more important than ever. blint automates this initial triage process.

The default scan flows like this:

Supported Binary Formats:

ELF (for GNU and musl libc)

PE (Windows executables and DLLs), including .NET assemblies: metadata tables, strong-name facts, and publish shape (ReadyToRun, NativeAOT, single-file bundles)

Mach-O (macOS and iOS, x64 and arm64), including Objective-C and Swift metadata

iOS/macOS apps (.ipa, and on macOS also .app, .framework, and .dSYM bundles): the main executable, embedded frameworks, dylibs, and app extensions are all analyzed, and embedded pro profiles are decoded for the entitlements they grant

Windows packages and documents: .msi/.msp databases, .cab archives, .msix/.appx packages and bundles, ClickOnce deployments, .nupkg archives, and Office documents (including analysis)

Android (APK, APKM, AAB, including DEX files in deep mode)

WASM (WebAssembly modules)

Disassembler: AArch64, x86/x86-64, i386, ARM and Thumb (armeabi-v7a), Mips, MicroMips (native), and Dalvik (DEX).

Key Features & Use Cases

Comprehensi Audits: Automatically checks for common security mitigations like PIE, ASLR, NX, Stack Canaries, and RELRO. Ideal for ensuring your CI/CD pipeline produces hardened binaries.

Software Bill-of-Materials (SBOM) Generation: Creates CycloneDX SBOMs for binaries built with Go, Rust, .NET, and Android toolchains, pro a clear in of third-party components for management.

Deep Binary Inspection: Disassembles, extracts, and analyzes a wealth of information including symbols, functions, dependencies, and build toolchains. This raw data is saved as a detailed JSON file.

- For a complete guide to all attributes in this file, see the Technical Metadata Documentation.
- For the custom CycloneDX properties blint adds to the BOM, see the Custom Properties Documentation.
- Na to the disassembly guide.
- For callgraph internals and analyst-facing interpretation, see the callgraph guide.

Android Deep Analysis: In deep mode blint parses the dex classes, detects bundled service and tracker SDKs, and runs a Dal review that decodes the bytecode and flags risky beha such as dynamic code loading, reflection, nati execution, weak cryptography, and cleartext networking. The findings are attached to the BOM as custom properties. When disassembly is enabled, blint also writes a Dal sidecar next to the BOM. Native code (lib/<abi>/*.so of an APK/AAB or a standalone .so) gets its own analysis path: per-ABI bionic ELF facts and loader/hardening checks, framework identification in the SBOM, and a dex↔native JNI join that binds declared natives to their implementations (see the Android nati).

iOS/macOS App Analysis: Point blint at an .ipa and it unpacks the app bundle, reads the Info.plist context (bundle id, , minimum OS, FairPlay encryption status), and analyzes the main executable along with every embedded framework, dylib, and app extension. For Mach-O binaries, blint recovers Objective-C metadata (classes, superclasses, methods, protocols, and referenced selectors) and demangles Swift symbols, then surfaces iOS privacy capabilities such as location, camera, microphone, contacts, photos, telephony, motion, biometrics, and device fingerprinting. It also reports privacy and fingerprinting beha: passi fingerprinting, installed-app probing, local-network scanning, cross-app tracking, and the app's Pri.xcprivacy posture including undeclared "required reason" API usage.

Capability Analysis: Identifies potentially sensiti by re imported functions and symbols, such as network access, filesystem operations, or cryptographic API usage.

- Includes cluster-style beha reviews for low-le patterns (for example eBPF sock_ops usage, TUN interception stacks, raw packet injection primitives, and local DoH redirection indicators).

Windows Depth: Windows inputs get a structured Authenticode walk (signers, timestamps, chains, signing class), kernel-dri (frameworks, IOCTL surfaces, H, known dri against a shipped loldrivers.io and Microsoft blocklist snapshot), installer and container unpacking (MSI, CAB, MSIX, 7z SFX, ClickOnce), and a .NET metadata reader that recovers assembly references, P/Invoke surfaces, and publish shape without executing anything.

Binary Diffing: blint diff compares two of one binary (or two *-metadata.json exports) and reports metadata deltas, hardening regressions with per-property polarity, finding deltas paired across rebuilds, and, with --disassemble, a function-le keyed on content hashes.

Performance: --jobs N analyzes binaries in parallel worker processes with byte-identical output, and --cache turns on a content-addressed parse cache so unchanged binaries are parsed once. blint capabilities prints the full catalog of checks and reviews the engine will run, in text or JSON.

CI/CD Integration: Can be added to build pipelines to enforce security policies, such as requiring code signing on all release artifacts.

Fuzzing Target Identification: Suggests interesting functions to target for fuzzing based on common patterns in function names (e.g., parse, decode, copy).

Extensible with Custom Rules: Define your own capabilities and checks using simple YAML rule files.

Installation

blint requires Python >= 3.10.

For disassembly support, which enables instruction-le of functions, install the extended . This includes the nyxstone disassembler.

Image

You can also run blint using the official container image a on GitHub Container Registry. This is a con way to run blint without installing Python or any dependencies on your host machine.

Quick Start

Analyze a binary and save the reports to the /tmp/blint directory:

Analyze a Go or Rust binary and get suggestions for fuzzing targets:

Analyze an iOS/macOS app (.ipa). blint unpacks the bundle and writes a separate
*-metadata.json for the main executable and each embedded framework, dylib, and
app extension. Add --disassemble for instruction-le (Objective-C and
Swift call sites are resolved to imported APIs):

Generate a CycloneDX SBOM for an Android application:

For Android deep analysis, enable deep mode so the dex classes are parsed. This is what makes service and tracker detection and the Dal review possible. Deep mode also enables disassembly, which writes the Dal sidecar next to the BOM. Both .apk single files and .apkm split bundles are supported.

Attribute Mach-O imports against an Xcode SDK's .tbd stubs, so each imported symbol is confirmed against, and attributed to, the system library that actually exports it (see .tbd SDK index in the metadata guide):

The same flag exists on blint sbom, where it attributes and confirms the Mach-O dependency edges in the BOM.

Understanding the Output

blint produces several JSON artifacts in the specified reports directory.

| Filename | Purpose | Details |
| --------------------------- | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| exename-metadata.json | Raw, detailed metadata extracted from the binary. This is the source for all other reports. | Contains e: headers, symbols, functions, dependencies, signature info, and more. See the Technical Metadata Documentation for a full breakdown. |
| exename-wasm-report.json | Raw WASM parser report for WebAssembly inputs. | Generated for .wasm files and contains the full wasm_tools parser output, including section/function/instruction detail, extracted strings with secret/IoC screening, the labeled call graph, toolchain fingerprint, and the component interface in for Component Model binaries. |
| findings.json | A summary of the security properties audit. Designed for CI/CD integration. | Lists security mitigations like PIE, NX, and Stack Canaries and whether they are present. For WASM inputs, the wasm_tools analysis findings (WASM-*) are passed through as findings. |
| analysis-co.json | A run-le of what was actually analyzed. | Counts units attempted, succeeded, failed, and skipped (per role), and records every failure and skip with a reason, so a clean result can never be mistaken for a blind one. |
| reviews.json | A summary of the capability review. | Lists detected capabilities (e.g., "networking", "file-read", "crypto") based on the symbols and functions found. |
| fuzzables.json | A list of suggested functions to fuzz, generated when using the --suggest-fuzzable flag. | Identifies functions with names that suggest data parsing or manipulation, which are often good candidates for fuzzing. |
| exename-callgraph.mmd | Mermaid callgraph export generated with --export-callgraph-mermaid. | Includes internal and unresol; also embedded into blint-output.html. |
| exename-callgraph.graphml | GraphML callgraph export generated with --export-callgraph-graphml. | Useful for Gephi, Cytoscape, and NetworkX workflows. |
| exename-callgraph.gexf | GEXF callgraph export generated with --export-callgraph-gexf. | Useful for Gephi-centric large graph exploration. |
| sbom-*.cdx.json | The Software Bill-of-Materials (SBOM), generated by the sbom sub-command. | A CycloneDX-formatted JSON file detailing the binary's components and dependencies. |

Ad Usage: SBOM Generation with blintdb

For C and C++ binaries, identifying components from symbols alone can be imprecise. blint can use blintdb, a pre-compiled database built from real project outputs, to impro identification with:

project-le matching

binary-name hints

optional disassembly hash matching when deep mode is enabled

similarity-hash matching (function fuzzy hashes, and the binary import-set digest) when the database carries those columns, so a compiler-drifted recompile degrades to fuzzy matching instead of missing

banner detection: strings a statically-linked copy leaves in the binary, which attribute members of a static archive to the project they were compiled from

Databases with schema 2 and 3 are both supported; the similarity-hash columns are detected per database, so a v2 database (or one whose hash columns are unpopulated) keeps working with exact matching only. Matched components record this as an internal:blintdb_fuzzy_layer property (active, or a named una*/inactive_* state such as unasent or inacti) so "the fuzzy layer found nothing" is ne with "the fuzzy layer could not run".

The workflow is a two-step process:

1. Download the blintdb database:

This downloads the database to the directory specified by the BLINTDB_HOME en .

2. Generate the SBOM with blintdb enabled:

3. For higher-confidence nati, enable deep mode:

When --use-blintdb and --deep are set together, blint enables disassembly automatically and searches the database with function hashes before falling back to symbol e.

The generated SBOM keeps the inferred package purl and also records internal:blintdb_* e properties on matched components so you can review why a component was selected.

For repeatable end-to-end of local blint-db changes, use the integration script in tests/scripts/orpus.py. It builds and a 15-case corpus split across Meson, vcpkg, and Homebrew, using the manifest stored in tests/data/blintdb-small-corpus.json.

The generated summary.json includes per-ecosystem pro copied from the linked blint-db run metadata under ecosystems.<name>.pro. That block mirrors projects.selected_count, attempted_count, success_count, failure_count, status_counts, and build_failures. Each projects.build_failures[] entry is a flattened per-project failure record with stable keys such as selector, project_name, ecosystem, build_system, status, stage, and message, plus optional details like returncode or exception_type when they are a.

WebAssembly Component Model SBOM

blint sbom skips .wasm inputs by default. Pass --wasm-sbom to include Component Model binaries: their imported WIT interface packages (for example wasi:cli at 0.2.0) are emitted as required library components, and the wasm binary itself becomes the application parent.

The purls are built from exact import e only (pkg:generic/wasi/cli@0.2.0?type=wasm maps the WIT namespace/package identity; the type=wasm qualifier follows the format proposed in the wasm-tools dependency research notes). Exported interfaces are recorded as a property on the parent rather than as dependencies, because they are capabilities the binary provides. Core modules are skipped: their imports carry no package identity, so no or fuzzy guesses are emitted.

En

BLINTDB_HOME, BLINTDB_IMAGE_URL, BLINTDB_REFRESH: Control blintdb download location, source image, and refresh behavior.

BLINT_GLIBC_BASELINE: Oldest glibc your deployment target ships (for example 2.28 for RHEL 8), used by the CHECK_ABI_FLOOR security check. A binary whose GLIBC symbol- floor exceeds a baseline set here is a medium finding; without it the check compares against its built-in default (2.28 in rules.yml) and reports at info, saying the default was used. musl and bionic binaries never fire the check. The --glibc-baseline CLI option is the same setting and wins when both are given. A value that is not a dotted is ignored with a warning.

BLINT_CACHE_DIR: Where the content-addressed parse cache (enabled with --cache) stores its database. Defaults to the per-user cache directory.

BLINT_CACHE_MAX_BYTES: Size bound for the parse cache. Default is 1 GiB; 0 disables e.

BLINT_MAX_HEX_BYTES: Maximum number of raw bytes con to hex when metadata contains undecodable byte sequences. Default is 4096.

- 0 disables truncation.
- When truncation happens, blint appends ...<truncated:N_bytes> to preser without producing huge JSON fields.

BLINT_MAX_WASM_INSTRUCTIONS: Total instruction-stream budget for each *-wasm-report.json. Instruction streams are the only unbounded part of the wasm parser output and dominate the report size for large modules. Default is 50000; 0 disables the cap.

- The budget is divided max-min fair across every function in the report, so short functions keep their whole body and the remainder goes to the long ones, rather than the first functions in section order consuming e.
- Trimmed functions keep their truthful instruction_count and gain an instructions_truncated count, and the report gains a top-level blint_truncation block recording the budget, the instructions dropped, and how many functions were affected.

BLINT_RESOL: Set to 1 to resolve each ELF binary's dynamic dependency closure the way the loader would, reporting libraries that cannot be found, imported symbols nothing in the closure defines, and search paths that let an untrusted directory answer first. Off by default, because resolution reads the filesystem the scan runs on and is only meaningful when that filesystem is the binary's intended runtime. Results land in the link_closure metadata block.

- BLINT_LINK_ROOT: Filesystem root to resol. Point this at an unpacked container image or sysroot rather than at the scanning host. Default is /.
- BLINT_LINK_SEARCH_PATH: Extra directories treated as if they were in LD_LIBRARY_PATH, separated by the platform path separator.

Command-Line Reference

Every block below is the output of <command> --help on this
(default paths shown as <user data dir> are platform dependent).

<details>
<summary><strong>Main Command Help</strong></summary>

</details>

<details>
<summary><strong>SBOM Sub-command Help</strong></summary>

</details>

<details>
<summary><strong>Callgraph-Match Sub-command Help</strong></summary>

Matches a callgraph recovered from a compiled binary against one produced from
source code, so binary functions can be identified even when the binary is
stripped. Give it a source side (<code>--source</code> JSON or <code>--source-dir</code>,
analyzed for you when it is a Rust crate) and a binary side (<code>--binary</code>, or
<code>--binary-metadata</code> from a previous blint run). The primary quality knob is
<code>--profile</code>; the <code>--min-votes</code>/<code>--margin</code>/<code>--khop</code>/<code>--fp-*</code>
flags are expert o of that preset. The full guide covers layers, defaults, and
honest accuracy results: Callgraph matching.

</details>

<details>
<summary><strong>Canonicalize Sub-command Help</strong></summary>

</details>

<details>
<summary><strong>Capabilities Sub-command Help</strong></summary>

</details>

<details>
<summary><strong>Diff Sub-command Help</strong></summary>

Compare two of one binary. Inputs may be binaries or exported
<code>*-metadata.json</code> files. The report covers metadata deltas
(imports, exports, dependencies, entitlements, sections, identity),
hardening regressions with an explicit per-property polarity, finding and
capability-review deltas paired across rebuilds, and, with
<code>--disassemble</code>, a function-le keyed on content hashes,
so a recompile is not reported as rewritten code.

</details>

<details>
<summary><strong>DB Sub-command Help</strong></summary>

The default --image-url is platform dependent (the dump above was captured on macOS arm64, hence the darwin-arm64 image); pick the image matching your platform and architecture from the listed choices.

</details>

<details>
<summary><strong>Cache Sub-command Help</strong></summary>

</details>

Python API

Analyze a single binary in process, with the same engine the CLI uses:

analyze() writes no report files. A missing path raises FileNotFoundError, a file blint cannot parse raises NotABinaryError, and a failed analysis raises AnalysisFailedError with the structured failure record attached, so a clean result can never be mistaken for a blind one. Calls are serialized by an internal lock (the engine's rule state is module-global); sequential calls with different options each see their own rules.

Every finding carries a finding_id: a content hash over (rule id, binary sha256, e locator), deliberately not o, descriptions, paths or the blint , so findings can be tracked, suppressed and diffed across runs on the same bytes.

References

Lessons from building blint v4

lief examples

checksec.py

Sponsorship

If you love blint, please consider donating to our project. In addition, blint is made possible by the incredible work of the LIEF project. Please consider sponsoring them as well.

LIEF Project

项目信息

开发语言：Python

Star 数：458

技术要点

该项目属于病毒分析方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕blint is a Binary Linter that checks the security properties and capabilities of your executables. It can also generate a Software Bill-of-Materials (SBOM) for supported binaries.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。