VeilCC Open console

Ship code AI can't
reverse-engineer.

Your binary is an open book to AI. VeilCC hardens it with AI-resistant obfuscation and seals your key logic, so attackers can't crack, clone, or cheat your game or app.

Protect a binary Add to CI in two lines →
veil / release build macOS arm64

# Obfuscate. Seal. Harden. Then ship.

veil protect crown.c --obfuscate --seal --post-obfuscate -o crown.protected.o
veilcc: protected crown.c → crown.protected.o (11528 bytes, obfuscate + seal + post-compile hardening)
        quota: 1 of 500 used this month
        receipt: 18a0…ef1f
clang main.c crown.protected.o -o demo
./demo
license check: passed
Sealed function. Same behavior. Source Driver
Recorded CLI run

The packer you ship
is already beaten.

VMProtect, Themida, Denuvo, an in-house obfuscator, they buy you days against a human with a disassembler and nothing against an agent that just runs your build and reads the input-to-output map. That's how your license check lands on a keygen forum, and how your matchmaking becomes a private server. The only logic an attacker running your code can't read is logic that isn't in the file yet.

< 60s

for an agent + Ghidra to lift a license check or a cheat-detection routine and name the exact algorithm.

0

static transforms, MBA, control-flow flattening, VM-packing, survive an attacker who simply runs the binary.

1

thing that holds: the bytes the attacker needs aren't in the shipped file until the instant they run.

What happens to the code you seal.

Drag through the four stages. You build as normal; the sealed function — license gate, cheat check, pricing model — leaves the file; a decompiler finds only ciphertext; it decrypts for one call, then scrubs.

You build as you always have.

compile
$ clang -O2 -fpass-plugin=veil app.c -o app
  → found crown jewel: check_license  [veil:seal]
  → hot paths left native

Set your protection.

Stack it: obfuscate the whole module, seal the crown jewel, or both, with sealing's key embedded or device-bound. Each combination is an honest tradeoff, what a running AI still gets, what it costs you, and whether a crack travels to the next machine.

protection
Seal key

The crown jewel leaves the file.

What an executing AI still recovers
Nothing at rest. The sealed function ships as ciphertext, decrypted only at the instant it runs.
Runtime cost
Per-call, on cold paths only
A crack survives…
Static analysis, sandboxes and off-device dumps get ciphertext
cost to break

Right for license checks, attestation, proprietary kernels, DRM.

Three ways in. All take a minute.

Drag & drop

Drop a binary you own and VeilCC scans the real bytes — every readable string, named algorithm and exposed symbol an attacker reads first — then loads the hardened build with all of it gone. No install. Download the hardened file on Pro.

Scan your file, then protect it

Scanning is free. Protection uses your workspace’s build allowance.

From the CLI

Install once, then protect any object in a single command. Your link step is unchanged.

terminal
$ brew install --cask almata-ai/tap/veil
$ veil login
$ veil protect --seal crown.o \
  --proto "uint32_t check_license(const char*)" \
  -o crown.protected.o --receipt receipt.json
Read the CLI docs →

In your pipeline

Add two lines to your build. Protection runs server-side with a fresh seed every build, your protection IP never ships in the binary.

.github/workflows/release.yml
- uses: almata-ai/veilcc-protect@v1
  with:
    level: seal            # obfuscate | seal | device-bound
    api-key: ${{ secrets.VEILCC_KEY }}
Read the CI docs →

Security you can
put a number on.

Every protected build ships with a receipt: exactly what was sealed, the moving-target seed, the applied protection layers, and the artifact hash.

Protect a binary free See what's in the receipt →
receipt.json · recorded demo
sealed function    check_license
protection         IR obfuscation + sealing
                   + post-compile hardening
plaintext in file  none
local names        25 anonymized
code / data        unchanged (verified)
exports / imports  preserved (verified)
receipt hash       18a0…ef1f

From the CLI run above. Metadata checks describe this build, not a guarantee against runtime extraction.

Pricing that maps to the dial.

Start free on a binary you own. Payment and keys arrive as you move up a level.

Free

$0

Try it on your own binary

Level: Obfuscate + seal

  • Always-free, unlimited exposure scanning
  • 1 protected build / month (obfuscate + seal)
  • Build receipt with artifact hash
  • CLI + console
Start free

Pro

$199/mo

Indie & startup teams

Level: Obfuscate + seal

  • Everything in Free
  • 500 protected builds / month
  • Obfuscate the module + seal the crown jewel
  • Moving-target seed every build
  • Hosted Protection API + GitHub Action
Start with Pro

Enterprise

Let's talk

Fintech · firmware · on-prem · games

Level: + Device-bound keys

  • Everything in Pro
  • Device-bound seal keys (secure enclave / TPM)
  • On-prem Protection API, code never leaves
  • License & activation API, attestation
  • SOC2 roadmap, SLA, support
Book a call

Straight answers.

Is it unbreakable?

No, and we'll never say it is. An attacker who runs your binary on their own machine and dumps RAM during a call can still recover a sealed function. We sell cost, delay, and a measured number, the only claims that survive a public crack-me. Device-bound keys get a copied binary to near-zero, which is a different and honest claim.

How is this different from Denuvo, VMProtect or a packer?

Those are static transforms, they rearrange and hide code that is still, in the end, present in the file, so a human with time or an agent that runs your build gets through. Sealing doesn't rearrange the logic, it removes it: the function ships as ciphertext and only exists in cleartext for the microseconds it runs, then it's scrubbed. You can run VeilCC on top of a packer, it protects the one function the packer can't.

Does this actually stop cheaters and private servers?

It raises the cost sharply. Seal the routines cheats and emulators depend on reading, anti-cheat checks, server-authority logic, entitlement gates, and there's no logic in the shipped client to lift or reimplement until the moment it runs. For a client the attacker fully controls, device-bound keys mean a copied build never decrypts at all, the honest bar for stopping redistribution and emulated servers.

Won't this slow my game or app down?

Only where you ask it to. Obfuscation leaves hot paths native. Sealing runs on cold, high-value functions, a license check or an anti-cheat probe costs microseconds per call, not per frame. The build refuses to seal anything it classifies as hot, so your frame budget is untouched.

Do you see my source code?

The passes run on compiled objects, not source, and on the hosted API they run in memory with zero retention. Regulated and air-gapped teams run the same API on-prem, so nothing leaves your network.

Which languages and targets?

Anything that compiles through LLVM. Verified end-to-end today: C, C++, Rust, Swift, on macOS/Linux/Windows across arm64 and x86-64. Zig, TinyGo and Unity IL2CPP use the same object path and are expected to work, we list them as shipped only once our suite proves them.

Can a frontier AI still reverse it?

A pure-software obfuscator can't stop an agent that executes your code, so we don't pretend to. Sealing changes the game: there is no logic in the file to read until it runs, and device-bound keys mean a copied file never runs at all. That's the part that doesn't decay as the models get better.

Ship the next build sealed.

Sign in, drop a binary, and ship it protected. Or create an API key and wire VeilCC into your pipeline in two lines. (Payment goes live soon; early access is free.)

Open the console Read the docs →