Binary artifact scans

Binary scans inspect shipped artifacts rather than source repositories. Use them for mobile apps, firmware, Java packages, installers, release archives, and other packaged software.

Binary scans answer a different question than source scans: what did we actually ship?

Binary scans start from the shipped artifact itself so the review matches what customers, attackers, or downstream operators actually receive.

They are useful when build steps, packaging, signing, dependency bundling, minification, generated code, or vendor components can change the security profile between repository and release artifact.

When binary scans are the right tool

Use binary scans for:

• mobile app release candidates
• firmware images and update packages
• installer bundles and desktop releases
• JARs or JVM services distributed outside your build system
• third-party packages you are allowed to inspect
• source-unavailable artifacts from suppliers or acquired products

Pair binary scans with source scans when you need to connect artifact evidence back to code ownership.

Inputs

Upload one or more binary files or archives. Typical inputs include:

• APKs and Android app archives
• JARs and JVM packages
• firmware images
• installer packages
• compressed release bundles

ZeroQuarry prepares an analysis workspace from the upload. Where possible, it extracts archives, records metadata, collects strings, and uses available decompilation or inspection outputs for the agents.

Upload the artifact that matches the release or environment you care about. A debug APK, unsigned firmware image, or locally rebuilt archive may produce a different finding set than the artifact customers receive.

What agents inspect

Binary-focused workers review the prepared workspace for:

• mobile manifests and exported components
• hardcoded secrets, API keys, and embedded credentials
• insecure update channels or signature checks
• weak cryptography and key storage
• native library and parser attack surface
• embedded endpoints and service URLs
• bundled dependencies with known CVEs
• risky permissions or entitlement choices

The evidence for a binary finding may be a manifest entry, string hit, decompiled source location, extracted filesystem path, or disassembly reference.

Review strategy

Start review with findings that indicate the artifact differs from your expectations:

• production artifacts containing staging endpoints
• secrets, keys, or tokens embedded in the package
• exported mobile components that were expected to be private
• update or signature behavior that does not match release policy
• bundled libraries that differ from the approved dependency set

Then compare against related source and remote scans in the same project. A binary finding becomes more actionable when you can identify the owning repository, build step, or deployed service.

Notes and focus

Binary scans benefit from precise context. Useful notes include:

This is the Android release candidate. Focus on exported activities, deep links,
and token storage.

Review firmware update verification and any bundled private keys.

Prioritize auth flows and embedded backend endpoints.

Report outputs

Binary scan reports use the same finding model as source and remote scans: severity, confidence, description, evidence, PoC material where possible, and optional disclosure artifacts.

Not every binary issue can produce a runnable exploit. When that happens, the PoC should still explain the reproduction path and the artifact evidence.

Common next steps

• Use Release security review when the binary is a release candidate.
• Use Remote target scans when the artifact exposes endpoints or deep links.
• Use Triage to remediation to turn artifact evidence into engineering work.