If you want to adjust the behaviour in some manner, then you're better off modifying the assembly code: at least you won't have to understand the entire code, only the parts you're changing.ģ. If you want to simply understand what the code does, it's probably better to stick with the assembly, find out what it does, and add some documentation.Ģ. However, the big question is what you want to do with it after conversion, and whether this is worth all the effort:ġ. You'll probably have to examine each of those individually. But there will remain parts that can't be translated easily. Large chunks of the actual code can probably be translated one-to-one, and at least that could be automated with a little scipting.
It shouldn't be hard to identify the constuction and destruction of the call stack at the start and end of the functions - do that next. Then you can go on to identify functions, give them a proper name, according to what you've learned, or a temporary name if you're unsure. Armed with that knowledge, you can create reasonable C/C++ data structures, and maybe even write a script to automate that task. It requires hard work and good analysis to understand what the data structures are, recognize patterns in the algorithms and subroutines, and derive the general data and program structure. The problem is that when you use any form of automatic conversion, the resulting code cannot be magically more readable than before.
