The source is clean. What did the binary actually ship?

Source review tells you about code you can read. It says nothing about the compiled artifact that actually goes out: the vendored dependency you never built, the release executable a partner sent, the DLL sitting next to your app. Point the Binary Inspector at any .exe, .dll, .so or .dylib and read what it really contains.

What it actually does

It parses the binary itself, not a description of it, and turns the result into a report you can read at a glance: how hardened the file is, what it has baked into it, what it pulls in, and whether it has been packed to hide its contents. Then, if you want, it checks the file's hash against the wider world.

Exploit mitigations Embedded secrets & strings Imported functions Packer detection Hash reputation (70+ engines) .exe · .dll · .so · .dylib

Why source-only misses it

The binary is the thing that runs. Between your source and that binary sit a compiler, a linker, a packager, and sometimes a third party you never see. Three ways that gap bites:

1. Secrets compiled into the artifact

A key or token that was inlined at build time does not live in a file you can grep after the fact. It lives in the binary, as a string sitting in the data section, downloadable by anyone who has the executable. Reading the compiled artifact is the only way to see it.

2. A binary you did not build

You vendored a prebuilt dependency, inherited a release from a contractor, or shipped alongside a partner's DLL. You trust it because it works, but you have never actually looked inside it. The inspector tells you what it imports, whether it is packed, and what strings it carries, before you ship it inside your product.

3. Hardening you assumed was on

Modern exploit mitigations (things like address-space layout randomization, non-executable data, and stack protection) are compile and link settings that are easy to lose in a custom build. A binary with them turned off is meaningfully softer to attack. Whether they are present is a property of the file, readable from the file.

The trap

"We reviewed the code" is not the same as "we looked at what shipped." A packed executable, an inlined credential, or a build with mitigations stripped out all pass a source review cleanly, because none of them are visible in source. They are only visible in the artifact.

What the inspector reports

Hardening report. Which standard exploit-mitigation flags the binary was built with, so a release compiled without them stands out instead of shipping quietly.
Embedded secrets and strings. The same secret detection IOnclad runs over source, pointed at the binary's contents, so an inlined key in the data section surfaces with its value redacted.
Imports. The functions and libraries the binary pulls in, which tells you what it is actually capable of touching.
Packer detection. Whether the file has been packed or obfuscated, the classic sign that the contents are not meant to be read.
Hash reputation. Optionally check the file's hash against 70+ engines through your own free VirusTotal key. The key is yours, the lookup is opt-in, and only the hash is sent, never the file.

When you reach for it

Before shipping a release, to confirm the executable you are about to hand users has mitigations on and no secret baked in.
When you inherit a build from a contractor or an old CI pipeline and want to know what is actually inside it.
When you vendor a prebuilt binary and would rather look than assume.
When a file looks off and you want a fast read on whether it is packed and what its hash reputation is.

IOnclad reports what it can read from the artifact and known-bad hash matches from VirusTotal. It is not antivirus, not a malware sandbox, and a clean report is not proof a file is safe.

Look inside what you ship.

Scan your source and git history in under a minute, then inspect the compiled artifacts too. Nothing leaves your machine unless you opt in.

Try the Browser Scanner → Download for Windows