A frontier agent rebuilds your license check in under a minute. VeilCC protects the functions worth stealing, so the code you ship can't be read.
uint32_t check_license(const char *key) {
uint32_t h = 2166136261u; // FNV-1a basis
for (int i = 0; key[i]; i++) {
h ^= (uint8_t)key[i];
h *= 16777619u; // FNV prime
}
return h == 0xB7A4E39Cu; // the accept constant, in the clear
}It slows a human. It does nothing to an agent that just runs your binary and reads the input-to-output map. The only logic an executing attacker can't read is logic that isn't in the file yet.
< 60s
for an agent + Ghidra to reconstruct a typical license check and name the algorithm.
0
static transforms, MBA, flattening, virtualization, survive an attacker who simply executes the code.
1
thing that holds: the code the attacker needs isn't present until the moment it runs.
Drag through the four stages. You build as normal; the crown jewel leaves the file; a decompiler finds data; it decrypts for one call.
Stage 1 of 4
$ clang -O2 -fpass-plugin=veil app.c -o app → found crown jewel: check_license [veil:seal] → hot paths left native
One annotation, three levels. Each is an honest tradeoff, what a running AI still gets, what it costs you, and whether a crack travels to the next machine.
The crown jewel leaves the file.
Right for license checks, attestation, proprietary kernels, DRM.
Drop a binary you own, choose a level, and get a protected one back. Signed in, it runs the real pass server-side; otherwise it hands you a labelled demo of the output. No install.
Drop a binary to protect it
.o · .exe · .dylib · .so · .wasm, or pick a file
Add two lines to your build. Protection runs server-side with a fresh seed every build, your protection IP never ships in the binary.
- uses: veilcc/protect@v1
with:
level: seal # obfuscate | seal | device-bound
api-key: ${{ secrets.VEILCC_KEY }} Every protected build comes with a receipt: what was sealed, the seed it used, and a cost-to-break estimate against current frontier models. Anyone can check it, which is exactly why we publish it instead of a slogan.
sealed check_license, attest_device
level seal (moving-target seed 0x9f3a…c1)
hot paths left native (0 FPS impact)
plaintext in file none
cost to break static / sandbox: no recovery
determined local: ~days, measured
receipt hash b7a4…e39c · verify at veilcc.com/r Start free on a binary you own. Payment and keys arrive as you move up a level.
$0
Try it on your own binary
Level: Obfuscate
$199/mo
Indie & startup teams
Level: Seal
Let's talk
Fintech · firmware · on-prem · games
Level: Device-bound
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.
Only where you ask it to. Obfuscation leaves hot paths native. Sealing runs on cold, high-value functions, a license check or attestation costs microseconds per call, not per frame. The build refuses to seal anything it classifies as hot.
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.
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.
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.
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.)