Quote:
|
Originally Posted by br00t_4_c
...by making statistical comparisons of a given disassembly...
...a "genetic" decompiler...
...some form of "learning"...
|
It can be a good approach, but there are some uncertain points. It is hard to measure the result, and it is hard to code those heuristics that recreates the original code.
What I imagine is a tool that at first determines the compiler as precisely as it is possible, and then knowing the compilation 'habits' of that compiler configuration it looks for some information that can be retrieved in a reliable way. Otherwise we would just see fail imaginations of our software, I mean it would very easily mislead itself.
It is simply a false goal to get back the original source code.
What we can reach is a level between C and C++ from where we can see such correspondences that were otherwise unvisible. Having had this information we can reproduce additional C++ parts, moving that level more and more towards C++, but I think it cannot be automized.
The best would be a disassembled C++ source code explorer tool that would enable the user to reorganize the source code.
The problem is that a simple function can be either:
* a global function
* a static function
* a class level function (static member function)
* a member function
In the asm code there is no difference.
Exploring the already visible C++ parts an experienced coder who knows the software very well may be able to make such decisions and may be able to give reasonable names for the entities.