Release shielding

Add format-aware analysis decoys after your existing protection stages. VeilCC includes the MIT-licensed BLA engine, pinned to a reviewed revision. Its structural scores and cost estimates are heuristics; they do not prove runtime equivalence or immunity to reverse engineering.

Stacking layers

Compile-level obfuscation, selected-function sealing, object metadata hardening, and release shielding can be stacked. Keep this order:

veil protect crown.c --obfuscate --seal --post-obfuscate -o crown.protected.o
# Compile/link the application with your normal build system.
# On macOS, shield the unsigned output before applying your normal signature.
veil release protect app -o app.shielded --receipt release.json
# Run application tests, then sign/package the shielded release.

The object path still produces a linkable object. Release shielding takes the final unsigned executable or a supported release asset. Linked binaries with signatures or EOF-sensitive bundles are rejected. Thin 64-bit little-endian Mach-O metadata layout is extended so the result can be signed normally. Universal Mach-O requires a platform-aware local pipeline.

The release receipt contains a full SHA-256 of the returned artifact. Signing changes that artifact: verify the receipt before signing, and record a separate signed manifest for your final distribution. Existing native receipts continue to use their current shortened artifact hash.

Console & API

In the console, choose Release shielding, select a file and audit it for free. Shielding uses one build from the same allowance as native protection. Invalid or incompatible jobs release their quota reservation. Audit and structural inspection stay available after the allowance is exhausted.

veil release audit app.wasm
veil release protect app.wasm -o app.shielded.wasm --intensity balanced
veil release verify app.shielded.wasm

curl https://veilcc.com/api/release \
  -H "Authorization: Bearer $VEILCC_KEY" \
  -F binary=@app.wasm -F action=protect \
  -F 'options={"intensity":"balanced","honey_maps":true}'

Actions are audit, verify, and protect. Options are intensity (stealth, balanced, maximum, bankrupt), seed, honey_maps, and llm_directives. Public WASM export names, imports and executable sections are preserved at every setting. Model tensor definitions and weight bytes stay unchanged; decoys are confined to string metadata.

Higher settings increase output size and may add initialization work. LLM-facing directive decoys are off by default and may be ignored by agents. Upload limit: 24 MB; protected output limit: 16 MB. Use local project tools for larger releases. This service never executes the uploaded application. Its checks cannot replace your runtime tests.

Local project tools

Project discovery, source weaving, integrity binding, bundler plugins and platform-specific protection need your project context. Build the companion from the VeilCC source repository with Node 24 or newer:

npm --prefix release-tools run build
export VEIL_RELEASE_TOOL="$PWD/protect-runner/release-cli.mjs"

veil release local project inspect-release ./dist
veil release local project lint ./dist --sarif
veil release local project weave-plan ./src --json
veil release local project verify-weave ./src --json
veil release local project harden ./dist --dry-run
# Review the plan and preserve any public WASM exports explicitly before:
veil release local project harden ./dist --intensity balanced

veil release local project emit-headers --lang c -o shield.h
veil release local project mcp

Local project commands retain BLA's original names, configuration and tool schemas. They can modify runtime behavior: self-integrity checks, sibling hashes and domain/time scope binding must be enabled deliberately and tested with your build. Local maximum/bankrupt WASM protection can rename exports; pass --wasm-preserve-exports with your public names. Hosted shielding preserves them automatically.

The full JavaScript API is exported from release-tools/index.mjs, including AST string encoding, scope binding, source weave planning/verification, artifact comparison, format shields, exposure inspection, SARIF, Ed25519 manifests, integrity coverage and MCP tools. String encoding reconstructs plaintext at runtime; it is not a substitute for server-held secrets.

# JSON options use the upstream API's property names.
veil release local source encrypt-strings encrypt-options.json
veil release local source bind-scope scope-options.json
veil release local source polymorph compare-options.json

veil release local keygen --private manifest.pem --public manifest.pub.pem
veil release local manifest ./release/app.cjs --private manifest.pem \
  -o ./release/app.cjs.bla-manifest.json
veil release local project verify-manifest ./release/app.cjs.bla-manifest.json \
  --public-key manifest.pub.pem --artifact ./release/app.cjs

Keep private signing keys in your CI secret store. MCP configuration is available through veil release local project setup --dry-run; registration only occurs when you explicitly run setup.

// vite.config.mjs; Rollup, Webpack and esbuild adapters are also exported.
import { veilVitePlugin } from './release-tools/bundler.mjs';
export default { plugins: [veilVitePlugin({ intensity: 'balanced' })] };

Bundler adapters fail the build on protection errors. Keep original source maps privately, and test the generated bundles. Agent tooling is provided for local analysis and planning; VeilCC does not silently rewrite business logic.

Compatibility

Feature / formatWhere it runsBoundary
JS / TS decoys, opaque predicates, shadow logic, source-map decoysConsole, CLI, local bundlerRun module and browser tests; check CSP and source-map workflows.
WASM custom sections and export decoysConsole and CLIHosted mode preserves public ABI and executable sections.
Python source decoysConsole and CLIOriginal prologue preserved; test your Python runtime.
Unsigned ELF / Mach-O / PE releasesConsole and CLIPreserve executable bytes; reject unsafe signatures, carriers and layouts. Mach-O metadata bounds are extended for signing.
SafetensorsConsole and CLIOnly string metadata changes; tensors and weights stay identical.
ASAR, Electron fuses and runtime signalsLocal project toolsRequire explicit Electron context, integrity handling and application tests. Runtime signals do not prevent debugger attachment.
SQLite, GGUF, plist, ZIP, bytecode, IL2CPP, BEAM, PTXLocal project toolsMay change schemas, packaging or observable metadata; require the matching runtime and build pipeline.
UF2, EVM, PCAPLocal project toolsDevice-specific behavior, code-size semantics or capture contents can change. Not automatically applied by hosted shielding.
Native C / Rust / Go compile-time decoy headersLocal project toolsInclude in a separate compilation unit when using crown-only sealing; check linker retention and size.
String encoding, scope / integrity binding, self-seal, sibling entanglementLocal API, CLI and MCPExplicit source/build integration; never enabled globally by the console.
Audit, release exposure, packaging lints, source weave plans, polymorph reports, signed manifests, SARIFLocal API, CLI and MCPStructural evidence and application-specific policies, with separate runtime testing.