Strings definitely show up in the wasm binary, like they do in normal binaries. But function names are minified by default in optimized builds, and do not appear. Even imports and exports are minified in -O3 and above, which is recommended.
So if you see something like "getNumberOfSkinCareEligibleItemsWithinTransaction()" in the binary, either it is a string, or it isn't an optimized build, or something is going wrong and please file a bug with a testcase. On Thu, Jun 4, 2026 at 2:00 AM Xellos <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/emscripten-discuss/23c1ff46-984f-4924-986b-85358c39be25n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEX4NpSetR0HuSfvF7%2BVeZqEpWoi2WPxzhav3kD-nMr4%2BmGcoA%40mail.gmail.com.
