Protection report

Since 2.2.0, every protected build writes a Protection Report next to the output:

protected/
  MyApp.dll
  MyApp.symbols.json
  MyApp.protection-report.json   ← machine-readable (stable, versioned schema)
  MyApp.protection-report.html   ← shareable summary you can open in a browser

It answers the question every obfuscator leaves unanswered: what did it actually protect, and how do I know? The report contains counts and ratios only — never your source identifiers — so it is safe to share with a customer or a security reviewer. The only names it lists are ones already public in the output (the residual surface a decompiler can still read).

Turn it off with "generateProtectionReport": false in your config.

What’s in it

• Identifier coverage — how many types, methods and fields were renamed out of the total renameable, with ratios and an overall coverage score.
• Advanced protections — strings and resources encrypted, methods virtualized (Pro), methods given control-flow obfuscation, references proxied.
• Protections applied — the transforms that actually ran on this edition, and any requested but unavailable on your edition.
• Residual public surface — every public type/member left in the clear, and why (public API preserved, a keep rule, or reflection-detected). This is the measurable gap to review.
• Per-type coverage (Pro) — the same counts broken down per output type.
• Build identity — the output assembly’s name, target framework and MVID, so a report is tied to one exact build.

The JSON validates against the published schema (schemaVersion 1.0); gate consumers on the major version.

Read or gate it from the CLI

# Print a build's coverage summary.
nebula verify --assembly protected/MyApp.dll

# CI gate: fail the build (exit 5) if identifier coverage is below 80%.
nebula verify --report protected/MyApp.protection-report.json --min-coverage 0.80

verify resolves the report automatically when you pass --assembly (it reads <name>.protection-report.json beside it). Add --json for the raw report.

Verify it independently in Glass.NET

The whole point is that you don’t have to take our word for it. Open the protected assembly in the free Glass.NET decompiler — its Obfuscation Inspector reports the same residual public surface from the assembly itself. The counts should match within rounding; if they don’t, that’s a finding worth raising.

Free vs Pro

	Free	Pro
Coverage counts + score	✓	✓
Residual public surface	first 25	full list
Per-type coverage detail	—	✓

Agents and automation

nebula mcp exposes a verify tool that returns the same summary, so a coding agent can check a build’s coverage as part of a CI or review flow. See the CLI reference.