Plans that scale with your product

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. Framework-dependent .NET Core apps are also supported: the box hosts the runtime and serves the app plus its dependency assemblies from memory, so the target only needs the .NET runtime installed. Inside such a box Assembly.Location is empty and any strong-name or self-Authenticode check in the app will fail. .NET Framework, drivers/services and out-of-process COM servers stay out of scope — 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 under your own key, password protection, update packages and code-signing) are disabled. A Demo box is still sealed to its own loader — that is what makes the watermark part of the binary rather than a flag someone can clear — but the seal is derived from the box, so it is not encryption you control and does not keep your files from being read.

Per developer, offline. One license covers a single developer on up to three of their own machines — a workstation plus, say, a laptop and a build or CI server. It is an RSA-signed license file: the builder verifies it locally and never phones home, so it runs on air-gapped or proxied build machines without a licence server. Moving to a new machine is fine within the three-device limit; more developers, or more machines, need more licenses or an Enterprise site license, which lifts the seat cap. The license gates the builder only — boxes you have already produced carry their loader baked in and never check it. Sharing one license across a team beyond those devices is what the revocation list is for.

Nothing stops working. The ExeWrap build you installed keeps running every feature of your tier — permanently, version-gated perpetual licensing: your licence stays valid for every build released on or before your renewal date, and it is checked against the build's release date, not your system clock, so turning the clock back changes nothing. What a lapsed subscription costs you is the future: newer ExeWrap versions, updates and support. Renew to get those again (and the renewed window covers builds released up to the new date). Boxes you have already produced of course keep working regardless — the loader is baked into the output and never calls home.

If all you need is to merge a couple of DLLs into an executable with no protection, a free bundler may well be enough, and we would rather you knew that than felt misled. What a paid, actively developed tool buys you is everything around that. Coverage: both 32-bit and 64-bit, native code from any compiler (C, C++, Rust, Go, Delphi) and framework-dependent .NET Core served from memory, verified to run across Windows builds from Server 2016 through the current previews — not a tool that was last updated years ago and may or may not survive the next Windows release. Real protection, not just packaging: AES-256 encryption on by default covering the file names and directory as well as the payload, password protection with the key stored nowhere, and signed update packages so a dropped-in file cannot change what your customers run. Depth: a virtual registry, in-process COM, in-memory writes, memory-mapped files and child-process coverage, so real applications actually work rather than only trivial ones. And evidence: "nothing is unpacked to disk" is something we measure with Process Monitor, antivirus behaviour is measured against the major engines rather than assumed, and each release is re-checked. On top of that you get code-signing integration, support, and a named EU vendor to submit false-positive whitelisting through. Free is the right tool for a throwaway; this is for software you ship, maintain and stand behind.

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. The key is not a constant hidden somewhere in the file: it is derived from the container's own code and flags, so every box has a different one and a patched loader derives the wrong key and decrypts nothing. Be clear about what that is worth — it defeats extraction tools, generic unpackers and casual tampering, but the loader has to decrypt unaided, so someone who reimplements the derivation can still recover the files. When it has to be a real secret, Professional adds password protection: the key is derived with PBKDF2 and stored nowhere at all, 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 produces extractable boxes.)

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 by name. Data files and registry entries apply from any patch. Replacing a DLL means shipping code, so that requires a signed patch: embed a public key in the box and every patch must carry a valid RSA signature. A patch the box cannot authenticate is never allowed to contribute code — otherwise dropping a file next to a signed container would be enough to run your customers' software differently.

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). We measure this rather than guess. As of October 2026 we have tested six major engines on current Windows 11 — Microsoft Defender, ESET, Bitdefender, AVG/Avast, Norton and Kaspersky — each installed and active with real-time protection on, against boxes of a native console app, a VCL GUI app and a .NET app, both unsigned and signed. None of them detected, blocked or quarantined any box. Most were completely silent; Norton showed a reputation prompt that scanned the file and resolved to safe (an unsigned, never-before-seen build has no hash reputation yet, and a signing certificate quiets that prompt). Because the Bitdefender and Avast engines also power several other products, the reach is wider than six names. This is real measurement, not a promise: we have measured the real-time (on-access) layer and have not exhaustively tested every engine, every scan mode or every build, a brand-new build always starts without reputation, and a later signature update can always change a verdict — so Authenticode signing plus reputation help, and Enterprise includes getting your boxes whitelisted with the AV vendors. We are upfront about this rather than promising a clean slate.

To distribute it, yes — and signing works. This is measured on a clean Windows 11 25H2 with Smart App Control enforcing: an UNSIGNED box is blocked outright (no “run anyway”), while the SAME box signed with an ordinary OV certificate ran with no block and no prompt. So code-signing cleared the Smart App Control gate, and even an OV certificate was enough in that test — but Smart App Control is reputation- and hash-based, so treat this as a measured result rather than a guarantee for every build. An EV certificate builds SmartScreen reputation across downloads fastest. Every paid tier (Standard and up) can sign: point ExeWrap at your own signtool command or a .bat, so your certificate, password and timestamp stay in one place. The free Demo cannot sign and is watermarked, so a Demo box is for evaluating on your own machine, not for shipping.

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.