Hacker News Reader

Comment by maeln | Hacker News Reader

Please, can we stop having this argument every time there is an article about webassembly ? WASM not any more obfuscated than any minified JS. Being a bytecode doesn't make you "unfree". You have access to the same tool to debug JS and WASM. And the WASM specification is open. There is literally no difference between running JS or running WASM.

View on HN

A binary format is no more obfuscated than minified JS? What now?

Going to need some clarification on how that's the case.

I mean... come on:

https://medium.com/@pnfsoftware/reverse-engineering-webassem...

I guess he's saying that an unminifier tool is effectively no different than a decompiler, and both are basically unreadable without it.

That said, I don't know of any webassembly decompilers, although I guess they must exist by this point. But also historically decompilers have been imperfect as some of the structure of the code is lost in the compilation process and has to be inferred, sometimes incorrectly, by the decompiler. Compare to a minifier where all you lose is the variable names, comments, and possibly helpful whitespace. All of the structure of the code is still there and there are no heuristics necessary to recreate something that resembles the original source.

That is correct, a minified JS will preserve most of the semantics of the original program. And since the original source can come from any language, how would one know which decompiler to use.

You could already compile programs from other languages to javascript.

https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

Wasm was effectively an extension of asm.js. It makes the experience of compile-to-web better, but it isn't much more opaque than other projects.

There are certainly wasm decompilers -- wasm2c, wasm2js, etc. You also have access to the browser's JS debugger for breakpoints, line by line execution control, dumping wasm's linear memory.

I haven't written any productive WebAssembly but I play Capture The Flag competitions, and it's become frequent for a wasm reverse engineering challenge to be thrown in. The tools are good enough to make that tractable, even for non-experts in wasm like me.

It helps a little that it's a stack-based rather than register-based VM. Usually more of the intent of code is preserved that way. It's like reversing a JVM class, rather than like reversing a native binary.

What are these Capture The Flag competitions? Do you mind posting a link?

Sure. My favorite explanation's a short video:

https://youtu.be/8ev9ZX9J45A

WASM is a binary and a text format. You can turn any WASM binary to the text format and have a readable version of the blob. Firefox can automatically show you the text version of a WASM blob. So no, there is no difference with a minified JS. Just because there are in a text format don't make them any more easy to reverse engineer.

Unless I'm completely missing something the "text version" you're talking about is just WASM and there's quite a difference between that and minified JS.

ex:

   end $label121
   get_local $var7
   get_local $var9
   call $func3444
   get_local $var7
   call $func1500

Yes this is what I am talking about. Once you know the instruction, I fail to see how it is more difficult to understand than javascript.

That certainly is a take.

That's like saying x86_64 assembly is as easy to understand as C. High level languages exist to make code easier to understand.

wasm is higher-level than x86 (or any other native) assembly.

How is that any more readable than deobfuscated js?

    func1500(func3444(var7, var9), var7)

or more likely:

    gw(kl(s,i),s)

There is a difference in degree, though. Unminified JS is usually easier to read than wasm text, in general.

One practical factor: I often debug wasm files by compiling them to JS first.

At least wasm has structured control flow, which helps a lot. I wish wasm had even more readability features, personally.

It's a binary format originally based on minified JS, with a standard textual form, and which can be viewed and debugged with exactly the same tools (and ease) as minified JS.

Can you point me to an example of this?

Thanks for the downvote whoever. Honestly, I want an example of how it "can be viewed and debugged with exactly the same tools (and ease) as minified JS".

I see nothing that states that is the case.

WASM is essentially a more efficient version of Asm.js, which is just Javascript. WASM is a binary format. Asm.js is Javascript. They're equally obfuscated.

Maybe I’m misunderstanding something but WASM is meant to be compiled from other languages and that source is lost, unlike minified javascript, isn’t it?

Would you consider the source lost if the (minified) javascript was compiled from TypeScript?

I would. And fair enough, I think the web closed around me and I didn't even realize it. But we are all doing ok so far, so I supose wasm won't be that bad either.

Yes, but you'd see similar issues (to a different degree) with languages like Typescript and JSX as well.

Cross-compilation has been a thing for a while now -- WASM is the followup to ASM.js, which was already being used as a compile target for languages like C.

Now, reverse engineering ASM.js is easier than reverse engineering WASM (although ASM.js is still a giant pain). And reverse engineering minified Javascript is even easier -- most competent JS engineers could debug a React project without source maps, even if it took them longer.

But it's not clear to me that WASM makes the process meaningfully harder. As in, you're still going to want to use source maps like you use today, and it'll still be totally possible to figure out what a program is doing without the original source. It'll just be a pain.

And the benefits to the web as an open, language-agnostic platform that can be used for memory-intensive tasks outweigh the downsides of needing to work harder to reverse engineer software.

Minifying JavaScript is as destructive as compiling from any language to WASM. The original source are also lost when minifying JS. The fact that the transpilation/compilation target is the same langage doesn't mean its any less destructive.

> can we stop having this argument every time there is an article about webassembly

No, we can't, it's a valid criticism, it's not going to go away. Minified JS is bad, webassmbly is worse.

What is the criticism exactly? Saying WASM is worse than minified JS is factually wrong.

We can debate about minified JS if you so desire but its a different debate.

This is a valid concern. Among many things it is much easier to audit higher level code than bytecode.

What can't you do? How is it any easier to audit minified JS than a WASM blob ? Everytime this argument is raised there is no valid argument to explain why WASM would be much worse than the current state of JS.

Two wrongs don’t make a right.

Then please enlighten us and share with us what is wrong.

Minified JS (even with single letter variables and all) is still a high level language which is much easier for humans to follow than bytecode. That was only an example of it being a valid concern. I actually love WASM (specially the s-exp representation) and have implemented a compiler that compiles to it, but it's important to listen to valid concerns even if we really like a technology.

"RISC-V is open, you can't compile proprietary binaries for RISC-V."

That is not what I said, don't try to create a fake argument.

You real sentence should be "RISC-V instruction set is open, therefor I can see whatever a binaries is doing via the instruction it is executing." Doesn't mean its free, doesn't mean its easy to reverse engineer whatever the binary is doing, but you have everything to do it.

Reply on news.ycombinator.com