Features
Every capability is built on a real in-memory loader from the ground up — there is no throwaway temp-unpack step hiding underneath.
Your whole app collapses into one executable.
ExeWrap embeds the main EXE, every DLL it imports and any data files you add into one output. It walks the import closure of the binaries sitting beside your app and bundles them automatically, so there is no dependency list to keep in sync. Ship one file; the user double-clicks it.
Nothing is ever written to disk.
A reflective PE loader maps each bundled module into memory directly — applying relocations, resolving imports against the in-memory bundle first, running TLS callbacks and registering x64 exception-unwind tables so exceptions and stack unwinding work exactly as on a normal load. Unlike a temp-extraction packer, the payload never lands in %TEMP% or the app folder — only the container itself is read from disk.
Bundled data behaves like real files — in RAM.
Data files you embed are served through a virtual file system. The boxed app can open, read, get sizes, seek, enumerate directories and even memory-map them, through the normal Windows file APIs. Writes are captured copy-on-write into a RAM overlay and discarded on exit, so the app folder stays clean — or optionally persisted to an encrypted cache file so edits to bundled files survive across runs. .ini reads and Nt-level file calls are covered too.
Ship the keys your app expects to find.
Export the registry keys your application reads, bundle them with the box, and they are served straight from memory — on a machine where they were never installed, with no setup step and no administrator rights. Both the ordinary registry API and direct native calls are covered. Keys you did not bundle still come from the real registry, so the rest of the system behaves normally, and values the app writes stay in RAM — the user’s registry is never touched. That is also what makes an <strong>in-process COM server</strong> work straight out of the box: bundle its CLSID registration and <code>CoCreateInstance</code> finds it, with the server DLL served from memory and nothing installed on the machine.
Names and contents, hidden by default.
Every box is AES-256 encrypted out of the box — and not just 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 and it is not shipped in readable form: it is derived from the container's own code, so every box has its own, and editing the loader — to strip a check, to hook it — leaves an archive that no longer decrypts. That stops extraction tools and casual tampering; it is not a secret from someone willing to reimplement the loader. When it has to be a real secret, password-protect it: the key is derived with PBKDF2 from a password that is never stored anywhere in the file, so the box only runs for someone who supplies it at launch (a prompt or an environment variable).
Update a shipped box without rebuilding.
Drop a small .xupd patch package beside the container and it is mounted at runtime, overriding bundled files by name. Data and registry entries apply from any patch; replacing a DLL means shipping code, so it takes a signed one. Embed a public key in the box and every patch must carry a valid RSA signature — forged or tampered patches are rejected, and a package the box cannot authenticate never contributes code.
Two switches when an app resists.
Virtualization leans on techniques some applications notice. Compatibility mode drops the cosmetic and aggressive parts of the loader, and minimal-hooks mode limits interception to the boxed application’s own imports — no system-wide detours at all, which is markedly less packer-like for security software, at the cost of some coverage. Neither changes how your app is packaged; both are one flag.
If it’s a native PE, it boxes.
ExeWrap is a PE loader, not a language runtime — it has been proven boxing Microsoft’s own MSVC-built system tools as well as Delphi GUI apps. C, C++, Rust, Go and Delphi native executables are all in scope, on both Win32 and Win64. (.NET / CLR and drivers stay out of scope; so do out-of-process COM servers, because another process cannot see this one’s virtual registry.)
Compare plans or talk to us about an Enterprise site license with AV-whitelisting help & unlimited seats.
View pricing Contact sales