If we would write some code in rust, compile it to, for example, x86_64. And then de-compile it to C. It would be perfectly memory-safe C code, right?
Yes, but it wouldn't necessarily be readable. And it definitely wouldn't be portable!
Snowman native code to C/C++ decompiler for x86/x86_64/ARM
11–20 of 40 posts
Re: Snowman native code to C/C++ decompiler for x86/x86_64/ARM
#12The main website seems to be dead, and there are no examples of its output.
A shame. My understanding is this was state of the art, for a free and open source decompiler.
Of course, times change and AFAICT Ghidra has taken up that mantle.
Re: Snowman native code to C/C++ decompiler for x86/x86_64/ARM
#13If we would write some code in rust, compile it to, for example, x86_64. And then de-compile it to C. It would be perfectly memory-safe C code, right?
Isn't Mozilla doing that? Rust to WASM to C.
Edit: Sorry I misremembered, they seem to compile C/C++ code to WASM then back to C: https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
Although technically the plugins could be written in Rust.
Re: Snowman native code to C/C++ decompiler for x86/x86_64/ARM
#14If we would write some code in rust, compile it to, for example, x86_64. And then de-compile it to C. It would be perfectly memory-safe C code, right?
Isn't Mozilla doing that? Rust to WASM to C. Edit: Sorry I misremembered, they seem to compile C/C++ code to WASM then back to C: https://hacks.mozilla.org/2021/12/webassembly-and-back-again... Although technically the plugins could be written in Rust.
Link?
Re: Snowman native code to C/C++ decompiler for x86/x86_64/ARM
#15How about this for an idea: a decompiler that uses Machine Learning to name the decompiled variables and functions. Would be nice even if it worked only sometimes.
For an AI-less solution there is IDA's Lumina which works pretty well. There's also a reverse engineered server for it [0] so you could build plugins for other disasemblers/decompilers to use with non-official servers.
It basically hashes machine code (with address parts removed) [1], then when reverse engineers label and push symbols to the server (or get them from some debug build), others can pull and see what the functions are called in completely unrelated projects, that use the same libraries / have the same functions.
[0] https://abda.nl/lumen/ [1] https://github.com/naim94a/lumen/issues/2
Re: Snowman native code to C/C++ decompiler for x86/x86_64/ARM
#16No post body was provided.
Re: Snowman native code to C/C++ decompiler for x86/x86_64/ARM
#17No post body was provided.
Re: Snowman native code to C/C++ decompiler for x86/x86_64/ARM
#18If we would write some code in rust, compile it to, for example, x86_64. And then de-compile it to C. It would be perfectly memory-safe C code, right?
It wouldn't look much like what you'd expect C to look like. If it did decompile back to idiomatic C it could introduce some kind of aliasing bug along the way that'd make it not so memory safe.
Re: Snowman native code to C/C++ decompiler for x86/x86_64/ARM
#19If we would write some code in rust, compile it to, for example, x86_64. And then de-compile it to C. It would be perfectly memory-safe C code, right?
The simpler way to obtain C from Rust would be to use mrustc https://github.com/thepowersgang/mrustc
Not that the C will be much more readable than the dissassembly, but there's a chance less information will be lost.
Re: Snowman native code to C/C++ decompiler for x86/x86_64/ARM
#20If we would write some code in rust, compile it to, for example, x86_64. And then de-compile it to C. It would be perfectly memory-safe C code, right?
Nothing is perfectly memory-safe. Also, not sure I would see the point of this translation?