blint is an OWASP binary linter that statically assesses executables, mobile apps and container images for hardening gaps, capabilities and composition, aimed at defensive analysts and authorized assessment teams.
| Tool | owasp-dep-scan/blint — binary linter for security properties, capabilities and SBOM generation |
| Category | Binary static analysis and supply-chain tooling |
| Primary Use | Auditing hardening flags (PIE, NX, RELRO), reviewing capabilities, and generating CycloneDX SBOMs from binaries in authorized pipelines |
| Safe Use | Educational and documentary analysis for security professionals auditing binaries they own or are authorized to assess; CI/CD hardening enforcement and defensive research |
| Telemetry Note | Purely static local analysis — nothing is executed or transmitted; defenders observe only local file reads and JSON/HTML report writes in the output directory |
blint, hosted under the owasp-dep-scan organization on GitHub, is a binary linter that checks the security properties and capabilities of executables without ever running them. It is built on top of lief, the well-known library for instrumenting executable formats, and positions itself squarely for reverse engineers, security analysts, and developers who need to triage what lives inside a compiled artifact. The project carries an OWASP affiliation, an MIT license, a Python codebase requiring 3.10 or newer, and a healthy topic spread covering sbom, cyclonedx, supply-chain-security, and fuzzing. At roughly 456 stars it is a credible, actively maintained community tool rather than a weekend experiment.
The core problem blint addresses is the opacity of modern statically-linked binaries. With Golang, Rust, and .NET applications shipping as self-contained blobs, the traditional technique of listing shared library dependencies tells you almost nothing about composition or hardening. blint automates that initial triage: it parses the binary, evaluates a rule set, extracts capabilities, and emits structured reports. The README's flow diagram describes inputs of binaries, directories, container images, and app or package archives, which are decomposed into per-binary analysis units, parsed by format-specific readers, and then fed through security checks driven by a rules.yml rule engine plus capability annotation rules.
Format coverage is unusually broad for a single tool. On the native side it handles ELF for both GNU and musl libc, PE including Windows executables and DLLs, Mach-O for macOS and iOS on x64 and arm64, and WASM modules. Beyond raw executables it understands packaging layers: iOS and macOS .ipa and .app bundles, Android APK, APKM, and AAB inputs including DEX files in deep mode, Windows .msi/.msp databases, .cab, .msix/.appx, ClickOnce deployments, .nupkg archives, and even Office documents with VBA macro analysis. This turns blint into a one-stop front end where an analyst can point it at almost any artifact type that crosses a desk during an authorized review.
The default security audit checks the classic hardening mitigations: PIE, ASLR, NX, stack canaries, and RELRO. This is the same checklist manual reviewers extract with checksec-style tooling, but blint operationalizes it for pipelines, where the README explicitly suggests enforcing policies such as requiring code signing on all release artifacts. Complementing the checks, capability analysis reviews imported functions and symbols to flag potentially sensitive behaviors such as network access, filesystem operations, or cryptographic API usage — a signal that works both for hardening audits and for malware triage-style capability reviews in defensive research contexts.
The SBOM story is where blint connects to the wider supply-chain ecosystem. The blint sbom subcommand generates CycloneDX 1.7 documents (with 1.6 selectable) for binaries built with Go, Rust, .NET, and Android toolchains, giving vulnerability-management teams a component inventory from artifacts that would otherwise be black boxes. Optional blintdb deep matching improves component attribution, and the tool attaches its findings as custom CycloneDX properties, documented in a dedicated CUSTOM_PROPERTIES.md guide. For organizations already consuming SBOMs in dependency scanning, this closes the gap where statically-linked builds silently escape traditional package-level SBOM generation.
Mobile analysis is a standout depth area. For Android, deep mode (--deep) parses dex classes, detects bundled service and tracker SDKs, and runs a Dalvik behavioural review flagging risky patterns like dynamic code loading, reflection, native command execution, weak cryptography, and cleartext networking. Native libraries get their own path with per-ABI bionic ELF facts, loader hardening checks, and a dex-to-native JNI join that binds declared natives to their implementations. On the iOS side, blint unpacks .ipa bundles, reads Info.plist context, recovers Objective-C metadata and demangled Swift symbols, decodes embedded provisioning profiles for granted entitlements, and surfaces privacy capabilities spanning location, camera, contacts, biometrics, and fingerprinting — including checks on the PrivacyInfo.xcprivacy posture and undeclared required-reason API usage.
Windows inputs receive comparable depth. There is a structured Authenticode walk covering signers, timestamps, chains, and signing class; a kernel-driver posture review including frameworks, IOCTL surfaces, HVCI compatibility, and matching against a shipped loldrivers.io and Microsoft blocklist snapshot; installer and container unpacking for MSI, CAB, MSIX, 7z SFX, and ClickOnce; and a Plug and Play driver package review that shows what a pluggable device causes Windows to install and run as SYSTEM. The .NET metadata reader recovers assembly references, P/Invoke surfaces, and publish shape — ReadyToRun, NativeAOT, single-file bundles — all without executing anything, which keeps the tool firmly on the static side of the safety line.
Two features deserve special attention from a workflow perspective. First, blint diff compares two versions of a binary or two *-metadata.json exports, reporting metadata deltas, hardening regressions with per-property polarity, and, with --disassemble, a function-level delta keyed on content hashes — essentially a lightweight binary diffing capability for tracking vendor patch changes or verifying your own rebuilds did not regress protections. Second, the opt-in --disassemble mode, powered by nyxstone in the extended install, enables instruction-level analysis and callgraph exports in .mmd, .graphml, and .gexf formats, covering AArch64, x86-64, ARM and Thumb, MIPS, and Dalvik instruction sets.
Installation is straightforward and non-weaponized: pip install blint for the base tool, or pip install blint[extended] if you need the disassembler. Invocation follows the same simple pattern — blint -i /path/to/binary -o /tmp/blint produces the reports, and blint sbom -i app.apk -o sbom.cdx.json --deep handles Android deep SBOM generation. A Homebrew tap and an official container image at ghcr.io/owasp-dep-scan/blint round out the deployment options for analysts who prefer isolated execution environments. Performance knobs include --jobs N for parallel worker processes with byte-identical output and --cache for a content-addressed parse cache so unchanged binaries parse once.
Output is spread across several JSON artifacts plus an HTML report. The *-metadata.json file is the canonical source, containing headers, symbols, functions, dependencies, and signature information in full detail, documented exhaustively in METADATA.md. Findings, capability reviews, and blint-output.html sit on top of that raw layer. The blint capabilities command prints the full catalog of checks the engine will run in text or JSON, which is a nice transparency touch for auditors who need to justify coverage claims. Extensibility comes via simple YAML rule files documented in RULES.md, letting teams encode organization-specific capability checks.
For defensive professionals, the telemetry footprint is minimal by design: blint reads files and writes reports locally, executing nothing, which makes it a safe fit for triaging unknown samples in a lab as a first-pass capability annotator before heavier dynamic analysis. Its fuzzing-target suggestion feature, which flags functions whose names match patterns like parse, decode, or copy via --suggest-fuzzable, further reinforces the tool's orientation toward hardening and quality workflows rather than offense. In an authorized context — your own builds, your clients' artifacts under contract, or public samples in a research setting — blint is a legitimate and unusually comprehensive first-stage binary analyst.
owasp-dep-scan/blint.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.