Pricing

Plans that scale with your product

Evaluate free, go Standard or Professional when you ship, and move to a site license when your team grows.

Demo

Prove ExeWrap boxes your real binary — Win32 or Win64; output is watermarked.

€0
forever
  • In-memory boxing (Win32 & Win64)
  • Auto dependency detection
  • Virtual data files
  • GUI & CLI for evaluation
  • Payload encryption
  • Update packages
  • Un-watermarked output
Download
Most popular

Standard

Ship hardened, un-watermarked single-file builds.

€249
per year
then €175/yr to renew*
  • Everything in Demo, un-watermarked
  • AES-256 encryption by default (payload + directory)
  • Authenticode code-signing
  • CLI automation (CI-ready)
  • Persistent encrypted cache
  • External file override for field updates
  • 1 developer seat
  • Password protection (PBKDF2)
  • Signed update packages
  • Virtual registry & in-process COM
  • Virtual writes
Buy Standard

Professional

Ship software that installs nothing at all — registry, COM and file writes included.

€699
per year
then €489/yr to renew*
  • Everything in Standard
  • Password-protected payloads (PBKDF2)
  • Signed update packages (.xupd)
  • DLL patching via signed patches
  • Virtual registry (bundle a .reg export or a live key)
  • In-process COM servers without installation
  • Virtual writes - app output stays in RAM
  • Up to 3 developer seats
Buy Professional

Enterprise

For teams shipping at scale, with AV-whitelisting help and unlimited seats.

On request
site license, priced per team
  • Everything in Professional
  • Priority AV-whitelisting support
  • Volume & site-wide licensing terms
  • Onboarding & priority support
  • Unlimited seats / site license
Contact sales

Prices exclude VAT. Licenses are per developer seat unless noted. Need a custom arrangement? Talk to us.

* Renewals are discounted about 30% off the regular price; the actual amount may differ slightly due to rounding.

Boxes you have already produced keep working after your subscription ends — only building new boxes requires an active license.

No software protection is 100% secure

ExeWrap raises the bar — your app, DLLs and data run from memory and never land on disk, the payload can be encrypted or password-protected, and updates are signed. But like every packer, virtualizer or DRM tool, it is not unbreakable: a determined expert with enough time and the right tools can analyse any binary. ExeWrap changes the economics of attack; it does not promise invulnerability. For high-value targets, layer it with your own server-side checks and per-customer licensing.

FAQ

Common questions

No. ExeWrap operates on your compiled .exe and its DLLs. Point it at the binary and it produces a single boxed executable — no source changes, no recompile, no library to link.

ExeWrap is a native PE loader, not a language runtime, so it works on executables from any native compiler — C, C++, Rust, Go and Delphi — on both Win32 (PE32) and Win64 (PE32+). It has been verified boxing Microsoft’s own MSVC system tools. .NET / CLR apps and drivers/services are out of scope, as are out-of-process COM servers — a second process cannot see this one’s virtual registry.

Often not cleanly. Storefront DRM (for example Steam’s steam_api) and self-checking anti-tamper expect the original, unmodified executable; when the app is virtualised they may refuse to run, fail an integrity check, or go unrecognised by the client. Large games also run into the memory and start-up costs described below. ExeWrap targets self-contained native applications with a manageable payload — gigabyte-scale DRM games are a poor fit.

No. The bundled app, its DLLs and its data files are mapped and served straight from memory — they never land in %TEMP% or the app folder. Only the container executable itself is read from disk, which you can confirm with Process Monitor filtered on file writes.

There is no hard limit in the format, but the in-memory design has practical ones. At launch the loader reads the whole container into RAM and serves the bundled files from memory, so a multi-gigabyte box needs a matching amount of RAM and starts more slowly. Build large boxes with the 64-bit builder — the 32-bit builder can exhaust its address space and fail with an “out of memory” error while packing — and note that a 32-bit target application cannot hold a multi-gigabyte bundle at all. For apps with very large asset trees (gigabytes of textures, audio or video), box the executable and its DLLs and leave the bulky data folder on disk rather than embedding all of it.

The Demo runs the full workflow on both Win32 and Win64, so any prospect can verify ExeWrap boxes their real binary regardless of architecture. The output is watermarked and the paid capabilities (encryption, password protection, update packages and code-signing) are disabled.

Boxes you have already built keep working unchanged — the loader is baked into the output and never calls home. You only lose the ability to produce new fully-featured boxes: the builder reverts to Demo mode (watermarked, no encryption or patches). Renew at any time to re-enable your tier.

From Standard up, boxes are AES-256 encrypted by default — and not only the payload: the file directory is encrypted too, so bundled file names, sizes and contents are all hidden. A box is never a plain, unzippable archive. That default is obfuscation-grade (the key travels with the box, so a determined reverser can still recover it). Professional adds password protection: the key is derived with PBKDF2 and never stored, so the box only runs for someone who supplies the password at launch (a prompt or an environment variable). You can also turn encryption off for a deliberately plain build. (The free Demo has no encryption, so its boxes are extractable.)

Optionally. By default writes to bundled files go to an in-RAM copy-on-write overlay and vanish on exit, so nothing is left on disk. Turn on the persistent cache (Professional) and those edits are saved to an encrypted cache file beside the box (bound to that box, tamper-checked) and mounted first on the next run, so newer versions survive across runs — still without ever writing the originals to disk.

Professional lets you build a small .xupd patch package and ship it beside the box; at runtime it overrides bundled files — data or even DLLs — by name. Embed a public key in the box and patches must carry a valid RSA signature, so forged or tampered patches are rejected.

Yes. The command-line interface takes the same options as the GUI and returns proper exit codes, so it drops into any build pipeline — including the free Demo, so you can wire it into CI before you buy.

No — and we would distrust any tool that claims it. No software protection on earth is unbreakable: a determined expert with enough time and the right tools can eventually analyse any binary, ExeWrap included. What ExeWrap does is change the economics — the app, its DLLs and its data run from memory and never sit on disk as loose files, the payload can be encrypted or password-protected, and updates are signed, so casual extraction, copy-paste reuse and trivial tampering stop being worth the effort. Think strong lock, not bank vault. For the highest-value targets, layer it with your own server-side checks and per-customer licensing so even a single cracked copy can be contained.

Possibly — in-memory loaders share behaviour with packers, so some engines flag any boxed output (this is inherent to the whole product class, ours included). Authenticode signing plus reputation help, and Enterprise includes help getting your boxes whitelisted with AV vendors. We are upfront about this rather than promising a clean slate.

Antivirus engines use behavioural heuristics, and an in-memory loader does the same things a malware packer does — read its own overlay, allocate executable memory, hook system calls — so a boxed EXE can be flagged as a false positive. Whitelisting means getting the AV vendors to recognise your build as clean so it stops being flagged. There are two layers. First, reputation: Authenticode signing (ideally an EV certificate) plus download volume builds trust with Microsoft SmartScreen and Defender. Second, vendor submissions: we submit your binary (and our loader signature) to each AV vendor’s false-positive portal — Microsoft, and the major engines like Kaspersky, ESET, Avast and Bitdefender — so they mark it clean in their next definition update, and we re-submit when you ship a new build or rotate your certificate. It is ongoing service work, not a feature inside the builder, which is why it sits in Enterprise. Important: it lowers false positives but cannot guarantee zero — a brand-new build can be flagged again until it is re-cleared.
Site under construction: This website is still under construction — content and prices are subject to change.