Is it as difficult as reverse engineering Desktop software ?
(And if there are compiler flags which make reverse engineering more difficult, what flags are those ?)
1 Like
Wasm is a significantly smaller instruction set than x64, for example. This might have effects in both directions: a smaller instruction set is easier to keep in one's head and understand in itself, although the generated code may be longer than identically-working code generated for a CISC ISA.
In practice, people don't reverse engineer stuff by going over every single instruction manually. Instead, they use tools like IDA Pro that perform most of the tedious, repetitive work automatically, such as detecting loops and if/else branches, or identifying local variables.
I thus think that there's no significant difference between trying to RE WebAssembly vs x64 assembly, as long as there is such a tool for WASM (I don't know if IDA supports it, but there's likely something equivalent even if not). So, I'd say it's not any simpler or more difficult.
I don't think there is such a flag. Stripping debug symbols obviously makes dynamic debugging more difficult, but you already mentioned that one. There are obfuscators that make the code jump around more than necessary, but you can't realistically stop a skilled and determined reverse engineer. In particular, if you are thinking about embedding a private key in your binary, then simply don't do that.
5 Likes
I am embedding a WebGL 2.0 vertex/fragment shader (that I have spent tens of hours on) in plain text. But there's really nothing I can do about this right? (Besides renaming the variables to voldemort, optimus_prime, darth_vader, ...) An attacker can always hook the browser, hook the WebGL::shader_source(...) calls, and intercept the code.
1 Like
Yes, that's probably right.
Worse yet, they could even write a custom WASM runtime, specifically tailored for reverse engineering.
Variable names aren't reflected in the generated code, so definitely don't waste time on that.
If you have such IP, I would advise protecting yourself legally instead, for example by including in your license that reversing and creating derivative works is expressly forbidden.
2 Likes
I was referring to the GLSL shaders. Might as well as have fun with potential reverse engineers.
1 Like
That's still probably a waste of time. It used to be somewhat common for some misdirected programmers to obfuscate variables in there production enterprise code (like Cobol) in order to maintain job-security because then no-one else could make sense of their code. This didn't really work, because once you follow what the code is doing, it's easy enough to assign the variable a meaningful name and rename all instances of it. Doing this, it doesn't take long to assign meaningful names to all the variables.
3 Likes
I think webassembly is significantly easier to reverse-engineer than obfuscated x86 assembly as wasm enforces control flow integrity and makes it impossible to manipulate locals outside of the frame they are from, while x86 allows you to clobber the return stack, all locals on the stack and allows you to jump into the middle of an instruction, making is significantly harder for tools to decompile in a way that is guaranteed to preserve semantics even in the face of heavy obfuscation. Wasm code also can't detect debuggers unlike x86 code which can detect them if the debugger doesn't deliberately prevent this. For example segments are reset whenever there is an interrupt like a debug interrupt. Or you can read the actual code to check if it hasn't been replaced with a software breakpoint. Various OSes also have api's that detect debuggers. Wasm doesn't have any of this. If the x86 assembly is not obfuscated using any tricks, there isn't much difference with wasm though when using tools like a decompiler.
5 Likes
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.