There are levels to obfuscation.
Inspecting some of my own WASM files, I can see that internal names from
source code appear even in release builds. However, to compilers and
interpreters (and even decompilers) it shouldn't matter what exactly those
names are - "getNumberOfSkinCareEligibleItemsWithinTransaction()" provides
the same information as "foo123()". This is different from obfuscation by
changing the data flow. Informative strings in binary are low-hanging fruit
and the most common way to leak info. Isn't there a flag to
minify/obfuscate them when making the WASM binary?
On Wednesday, 3 June 2026 at 18:52:30 UTC+2 jj wrote:
> 1. If you are shipping the code for a web browser to execute, _and_
> the code footprint is large, it is definitely recommended to ship a
> separate .wasm file. That enables streaming WebAssembly compilation
> (Wasm is already being compiled while the file is being downloaded),
> which improves site loading times by a great deal, compared to a
> SINGLE_FILE build.
>
> 2. The SINGLE_FILE encoding makes it very easy to examine function
> names and C strings in the code in a text editor. That was one of the
> design goals. See the attached screenshot. If you want to detect
> whether debug symbols were present in a SINGLE_FILE output, you can
> search for the bare C strings directly in the file.
>
> 3. Reconstructing the original .wasm code from a SINGLE_FILE output is
> also very easy, it is effectively a text string snipping job, like
> extracting a base64 string in a text file would be. In the attached
> screenshot, take the string inside the call to binaryDecode('...'),
> that is the Wasm module.
>
> 4. WebAssembly is a high-level structured virtual ISA, so it does not
> allow unstructuring tricks like omitting frame pointers. Functions,
> loops and branches are always explicitly encoded and there are no
> spaghetti like with gotos/jumps. This allows easier decompilation back
> to high level C, compared to native assembly code, even if debug
> symbols were not present.
>
> This might be a scenario to look into some code JS obfuscation strategies.
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/emscripten-discuss/23c1ff46-984f-4924-986b-85358c39be25n%40googlegroups.com.
