01
Identified by bytes, not by filename
Extraction is driven by what a file actually is. A firmware image with no extension and an APK renamed to .zip are unpacked the same way, because nothing here is trusted on the strength of its name.
Binary security review
Review the artifact you actually ship.
Source review stops at the repository. ZeroQuarry takes the built artifact instead - an APK, a jar from your release, a firmware image pulled from a device - and works from the bytes: deterministic component discovery first, then agents reading decompiler output, strings, manifests, and native libraries.
APK, JAR, AAR, WAR, EARFirmware imagesDeterministic version discovery
binary://carrier-resolutionprocessing
Upload
portal.war
identified by bytes, not by name
Extract
portal.war
WEB-INF/lib
service.jar
Carriers
- pom.propertiesmaven
- gradle .modulemaven
- dpkg statusfirmware
- apk installed-dbfirmware
- MANIFEST.MFnot parsed
Resolved
log4j-core 2.14.1
metadata/pom.properties
a version you can check beats a version you can only argue about
Capabilities
How a binary is identified when there is no source
A source review reads files someone wrote. A binary review has to recover identity from the artifact itself, and most of the available ways of doing that are guesses. ZeroQuarry separates the part that can be determined from the part that has to be reasoned about.
02
Deterministic dependency analysis first
Component identity is resolved before any model runs, and the result is handed to the agents as context. The investigation starts from real components instead of versions guessed out of strings.
03
Nested archives read in place
Binary uploads are not unpacked to disk the way a source tree is. A WAR keeps its entries inside the archive, so ZeroQuarry reads carriers straight out of the zip and recurses into the jars under WEB-INF/lib.
04
Version carriers that mean something
Maven coordinates from pom.properties, pom.xml and Gradle Module Metadata; firmware package databases from dpkg status and the Alpine apk installed-db. These are identity records, not inference.
05
MANIFEST.MF is deliberately not used
Every jar ships a MANIFEST.MF and the naming is inconsistent between projects. That is exactly where wrong version matches come from, so ZeroQuarry does not read those headers as carriers.
06
Agents work the extracted evidence
binwalk for firmware and embedded filesystems, jadx for reviewable Java, alongside file, strings and apktool. Agents are pointed at manifests, decompiler output, native libraries, bundled dependencies, and update or authentication flows.
How it runs
From shipped artifact to evidence
The same pipeline as every other surface, starting from bytes rather than a repository.
Upload
Bring the built artifact rather than the repository: the APK from the store build, the jar a customer downloads, the firmware image pulled off a device.
Extract
Content-based unpacking, firmware carving and Java decompilation produce a tree that can actually be read, including the archives nested inside the outer one.
Resolve
Deterministic analysis records exact components and versions from high-precision carriers, and materialises them where a finding's source resolves to a real file.
Investigate
Agents pursue attack paths across the resolved components, decompiled classes and update flows. Triage, adversarial challenge, confidence scoring and reporting then run as they do for source and live targets.
Outcomes
Why review the build, not only the repository
Source review has a floor: it can only speak about the code you have. The artifact is a separate question.
Coverage of what ships
The build you publish is a different object from the repository you review, and it is the one your customer downloads.
Versions that can be checked
A finding points at an identity record rather than a string match, so an engineer disputing a version can open the file and settle it instead of arguing about it.
One evidence trail
Binary findings share the same validation, retest and report path as every other surface, so a release decision is not assembled out of two separate systems.
Evaluation FAQ
Before you upload something
Accepted formats, how versions are identified, and what a finding looks like afterwards.
What can I upload?
Compiled application packages and firmware: APK, JAR, AAR, WAR and EAR archives, plain archives, and firmware images. Binary review currently takes uploaded files rather than a repository clone, and it is a licensed tier capability.
How do you know which versions are inside it?
From carriers that are identity records: Maven coordinates in pom.properties, pom.xml and Gradle Module Metadata, and firmware package databases such as dpkg status and the Alpine apk installed-db. MANIFEST.MF headers are deliberately not parsed, because every jar ships one and the naming is where wrong version matches come from.
Do binary findings get the same validation and proofs?
Yes. Binary findings move through the same triage, adversarial challenge, confidence scoring, proof generation and evidence packaging as any other scan mode, and can be retested against a rebuild.
Related workflows
Where binary review sits
Upload the artifact you actually ship
Start with the build from your last release and check whether the components inside it are the ones you think are there.