Hacker News Reader

Comment by gmiller123456 | Hacker News Reader

I'm not expecting too much, as it's going to be hard to monetize something people get the source code to. So I think it's going to be limited to small projects, or sub projects that don't cost a lot to develop.

View on HN

That problem has been solved by F2P client/server games a long time ago. The important stuff happens on the server, and the client is "only" a dumb renderer. You'll need to assume that the client is compromised anyway, whether that also means that the client source code "leaks" is irrelevant for monetization (via in-app-purchases, which again is controlled by the server while the client only renders the "shop UI").

I imagine any serious project won't be written in JavaScript, and WASM code with symbols stripped out is about as opaque as x86 or ARM assembly, especially when you start getting into the code sizes you expect for a full game engine or productivity suite.

When you minify js don’t you end up with the same kind of thing? You can “decompile” both and neither give you any symbols. Just a bunch of random letters calling other random letters, etc. Maybe I need an example to understand.

Not quite, minify JS can be "beautified" to get pretty reasonable JS back, sans variables and functions having letters for names as you noted. But this is because obfuscated JS is still valid JS, it's just made ugly.

Obfuscated assembly is often changed in such a way that there are no corresponding language constructs to "reverse" back to, if it originally came from a language like C++. Sure you can see the actual assembly code, but you can't recreate the higher level C++ constructs in a sane way, because the obfuscation technique scrambles things too much.

I think you're missing a good amount of nuance here

minified JS can be turned into reasonable JS, yes, but you're probably not going to get TypeScript code back, so the same sort of challenge exists there.

Assembly -> high-level language is harder, but there are absolutely binary -> C decompilers that are very popular/used in the RE community to make changes to existing programs.

But that doesn't even matter, WASM is much higher level than assembly, it's a stack machine, there is no arbitrary control flow / labels / `goto`, there are pre-defined data types, etc. all of this means it's easier to convert WASM -> high-level language than it is with a generic x86/arm binary.

There are WASM decompilers[0][1] which can convert WASM binaries into C code and back.

In both cases (minified JS and WASM), you're not going to get out exactly what you put in, but WASM doesn't really change the situation very much given the widespread adoption of 'compile to JS' languages like TypeScript these days.

[0] https://chromium.googlesource.com/external/github.com/WebAss...

[1] https://github.com/wwwg/wasmdec

Except WASM isn't as low level as machine code proper, and also needs to obey certain rules due to code verification, thus it is as easy as any other bytecode format.

You might not get the original C++ code back, but it is relatively easy to get an alternative version in C code back, which is already good enough as starting point.

If you're so worried about people getting the source code to it, you can just compile to WebAssembly.

Reply on news.ycombinator.com