Click here to Skip to main content
15,867,594 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Self-explanatory. How does this work?

I have a piece of assembly code, which I derived from another C code, using the MinGW compiler, and CMD. (Please do not ask why I derived it.)

My goal is to convert this assembly code to C/C++ code, with the use of any application, like a decompiler?

What I have tried:

CMD code for that program:

gcc -s -o main.s main.c


I have the .s file (assembly file), currently, which seems to be quite useless, unless convertible.


BTW, I know that decompliers aren't the most accurate, but it's a start, and yes, Assembly to C converters seem to be useless, I know.
I hope, you could provide me some viable solutions, for my goal. Forgive me if I have made any errors in my question or the logic in this program.
Posted
Updated 27-Feb-23 14:25pm
Comments
Richard MacCutchan 12-Aug-19 3:42am    
Why did you decompile it?
Daniel Pfeffer 25-Dec-22 13:14pm    
There is a publicly available program, ghidra, produced by the NSA (of all places!) that can do a fairly decent job of converting an object (.o) file to C. To download it, you need to use a VPN that identifies you as being in the US, but there are no other restrictions on the download.

Decompilation is an iterative process - you identify parts of the code / data, and then modify a configuration file so the program will take your identification into account, and repeat.

The problem is that when you use any form of automatic conversion, the resulting code cannot be magically more readable than before. 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. Armed with that knowledge, you can create reasonable C/C++ data structures, and maybe even write a script to automate that task.

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. 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.

Large chunks of the actual code can probably be translated one-to-one, and at least that could be automated with a little scipting. But there will remain parts that can't be translated easily. You'll probably have to examine each of those individually.

However, the big question is what you want to do with it after conversion, and whether this is worth all the effort:

1. 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.

2. 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.

3. If you want to port it to another platform, then consider rewriting it from scratch instead - that would likely be much easier.
 
Share this answer
 
 
Share this answer
 
Of course the best solution would be accessing the original C code form which the assembly was 'derived'.
You could also use your assembly code together with other (C) source files, gcc handles both types.
The last option is the most difficult, you have to understand what the assembly code does and the reproduce such functionality with a C program.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900