I am aware of existing decompilation tools like Ghidra which give you close-to-original pseudocode.
But I think reverse engineering might be a place for ML to shine… After all, you got an empty source file, and a target binary to reach. You can automatically check everything by doing test compilations and comparing with the target binary.
ML is really good for pattern recognition, which is a huge part of reverse engineering. Though at the same time, I experienced firsthand how bad LLMs are in assembly since they don’t “think” or have a hard time tracking state machines.
I am aware that a big part of reverse engineering is not getting something that compiles, but rather, figuring out variable names, function definitions and how a piece of software works in general. But I think, with human help, it could help decompilations drastically. What do you think?
The advantage of decompilation as a task is that you have a reference output you can validate against.
I would assume the approach, mechanisms, and quality of produced code is similar to general/prompted code generating.
I assume the produced code (and its quality) depends on the compiled code; how much was stripped or obfuscated, and what runtime are we talking about which may or may not have language constructs that guide structure. With little metadata or code structure left AI would shift more into it’s general patterns than if there is more metadata available that already defines structures or names.
The thought of integrating a deterministic decompiler and then use AI to structure it and make it more readable while verifying the output remains the same seems like an interesting extension or alternative workflow and toolchain.
I have not used these kinds of AI decompilation tools or workflows, but thinking purely from my background and general experience.