> So I went back to the debugger and placed some breakpoints around where the WebAssembly module is loaded, realizing that its only purpose is to deobfuscate the JavaScript that eventually makes it into that "SOURCE" pseudo-file I saw earlier. [...]
> So… the WebAssembly is essentially generating JavaScript on-the-fly. Of course, all renditions of the code do the same thing, but the variable names are changing. [...]
> So it seems the WebAssembly module is doing some sort of tampering checking, [...]
I remember various discussions when WASM was specced about the danger of WASM blobs being used for code obfuscation.
The fears were dismissed with the argument that WASM is easy to decompile and that there is a textual representation to preserve "view source" functionality.
And yet, as soon as WASM is practically usable, we get this - an application that uses WASM solely because it is hard to inspect in the browser.
> So… the WebAssembly is essentially generating JavaScript on-the-fly. Of course, all renditions of the code do the same thing, but the variable names are changing. [...]
> So it seems the WebAssembly module is doing some sort of tampering checking, [...]
I remember various discussions when WASM was specced about the danger of WASM blobs being used for code obfuscation.
The fears were dismissed with the argument that WASM is easy to decompile and that there is a textual representation to preserve "view source" functionality.
And yet, as soon as WASM is practically usable, we get this - an application that uses WASM solely because it is hard to inspect in the browser.