Launching today
VeilCC
Ship code AI can't reverse engineer
24 followers
Ship code AI can't reverse engineer
24 followers
Ship code AI can't reverse-engineer. VeilCC hardens it with AI-resistant obfuscation and seals your key logic, so attackers can't crack, clone, or cheat your game or app.
Free Options
Launch Team / Built With
Render Sandboxes: a computer for every agentRun untrusted code safely. Idle sandboxes cost nothing
Promoted
Hey Product Hunt 👋
I'm Ameer, I built VeilCC.
Short version of why: AI got good enough this year that reverse engineering a shipped binary stopped being a multi-year, team-of-humans kind of project. You've probably seen some version of this already, whole games getting decompiled and ported in days, software getting cloned function by function. The usual protections (control-flow flattening, VM-packing, that whole playbook) were built to slow down a person with a disassembler open at 2am. They don't do much against something that can read the entire binary at once and just explain back what it does.
So instead of trying to hide the logic better, VeilCC pulls it out of the binary entirely. Whatever actually matters in your build, license checks, anti-cheat, pricing gates, your core algorithm, only comes back together in memory for the instant it's called, then it's gone again.
I want to be upfront about what this is and isn't. It's not unbreakable, someone determined enough to catch it mid-call with a debugger can still get there, but it'll probably take them a VERY long time. When I tried it, it completely depleted my tokens for Codex and GLM. Even if someone tries hard to decompile it, they will come out with a version that completely breaks 5 hours in. Meaning, they'd have to test every portion of the game/software (wasting their token budget) as they decompile and even then it's not guaranteed. This is especially a death sentence for longer games.
The way this works, it incentivizes designers to make longer, meatier games that are hard to decompile and not economically worth it
Three ways to use it: drag a binary into the console and go, run it through the CLI if you want it scripted, or drop two lines into a GitHub Action if you want it in CI. Every protected build comes with a receipt, what got sealed, the build seed, the artifact hash, so it's not just "trust us."
Free tier gives you one protected build a month to kick the tires. Pro and Enterprise are for teams that need volume or device-bound keys.
Would love for people to actually try to break it and tell me where it falls over, that feedback is worth more to me than anything nice anyone says in the comments. Thanks for checking it out 🙏
Congrats Ameer! Pulling the logic out of the binary instead of hiding it better is a sharp answer to AI decompilers. One question from a Mac app maker: if a licence check moves out of the build, how does the app behave offline? Mine has to keep working for weeks without a connection.
@mr_pft Thanks! Yes, your Mac app can keep working offline for weeks. With Veil’s default sealing mode, the app ships with an encrypted copy of the licence check. It decrypts and runs the check locally, with no connection to Veil required.
Your app’s licensing policy still determines how long it can work offline. If it verifies a signed licence locally and that licence is valid for the full offline window, the app can keep working the whole time.
@ameerarsala Thanks Ameer, that's clear. A sealed local check that works without calling home fits well with signed licences that stay valid offline. Good luck with the launch!
As someone shipping native apps, this hits a real worry for me — AI has made tearing apart a shipped binary a lot faster than it used to be, and it's not just the code, it's the logic inside it. I like that you're upfront it's not unbreakable, and that I can just drag a binary in and try it rather than reworking my build. Curious how a protected build holds up in practice — does it add much binary size or startup time?
@jcbuilds Thanks! For function sealing, the size overhead comes from the loader and the data it needs to run the encrypted functions. The exact increase depends on what you protect, so I’d compare the two builds before quoting a percentage.
Sealing adds work when a protected function is called. If you seal a licence check that runs at launch, launch pays that cost. If the first call happens later, the cost shows up there instead. By default, Veil decrypts the function on each call, so I’d start with a few sensitive routines that run infrequently and leave frame loops and other hot paths alone.