Compile C and C++ to the browser without publishing your engine.
Emscripten puts decades of native work one download away. TrustSig Protect obfuscates that module and virtualizes the functions you pick.
Solver::Optimizef_4a10Licensing::Checkf_ce83Pricing::Evaluatef_17b5KeyStore::Unsealf_92da
app.wasmSaved and read by anyone
Years of native work, one download away.
A WebAssembly module reaches the browser as a file like any other.
Anyone can save the module your page loads and open it in tools that cost nothing.
Names, imports and strings survive the compile and describe what each part of it does.
The structure of code that took years to write is there to read.
- Licence checkProtected
- Paywall logicProtected
- Key handlingProtected
- Page layoutUntouched
- AnalyticsUntouched
You choose what disappears.
Protection lands on the functions you pick, not on the whole module.
You mark the parts worth hiding: solvers, pricing, licence checks, anything you would not publish.
The rest of the module stays as your build produced it.
That keeps the output close to the size you ship today.
LICENSE_EXPIREDenc:8f2c…api.internal.keyenc:41ab…solver_v7_seedenc:d073…
Nothing readable stays in the binary.
Names go, the order goes, and the strings stop being strings.
Every meaningful function, import and export name is stripped or randomised.
Control flow is flattened, so the order your code runs in is no longer visible in the file.
Sensitive values sit encrypted and are decrypted only for the instant they are used.
Porting to the browser stops meaning handing over the source.
A native binary took real work to reverse. A WebAssembly module used to take an afternoon. After a protected build there are no names to search, no order to follow, and the parts that matter are not WebAssembly any more.
Instructions only our engine runs
The functions that matter stop being WebAssembly at all.
Obfuscation hides how your code reads. Virtualization changes what it is.
Protect compiles the functions you picked into bytecode for an instruction set that exists only in your build.
A small engine ships with your module and runs that bytecode.
The next build gets a different instruction set, so nothing learned from this one carries over.
- Public decompilerNo match
- De-obfuscatorNo match
- Symbol recoveryNo match
Nothing to unwrap
No off-the-shelf tool recognises the output.
Public de-obfuscators look for patterns our engine never leaves.
The obfuscation engine is ours, not a wrapper around a public one.
Off-the-shelf de-obfuscators have nothing to unwrap, because the output matches nothing they know.
Every build is laid out differently, so anything learned from one file is worthless against the next.
What a protected module carries.
- Virtualization
- The functions you pick run as bytecode on an engine that only your build has.
- Control-flow flattening
- The order your code runs in stops being visible in the file.
- Symbol scrubbing
- Function, import and export names are stripped or randomised.
- String vault
- Sensitive values stay encrypted and are decrypted only for the instant they are used.
- Compact output
- Virtualization lands only on the functions you pick, so the module stays close to its original size.
- Polymorphic builds
- Every build differs byte for byte, down to the layout of the bytecode.
Emscripten builds, answered
Protect works on WebAssembly, which is what an Emscripten build produces.
No. You choose which functions to protect, and nothing about the way they are written changes.
Virtualization lands only on the functions you pick, so the rest of the module is unchanged.
Code running inside the engine is slower than plain WebAssembly, which is why it belongs on the logic worth hiding rather than on an inner loop.
Get in touch.
Tell us what your module does, what needs protecting, or whatever you want to ask.