Click here to Skip to main content
14,740,774 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi guys. I started practicing reverse engineering some time ago. I read a lot about physics of the process as well as different tools but still a bit confused. Correct me if I am wrong.

My understanding: let’s say I have a basic program which is .exe for example (I am on Windows). It is entirely in machine code, which is just a bunch of 1’s and 0’s just literally. It is clearly unreadable and the first thing I do is run a disassembler on my .exe which turns it into assembly language which hardly human readable. The last step is to run a decompiler of my choice that turns the assembly language into a resemblance of the source code in a chosen programming language.

Problems: theory isn’t very difficult, nonetheless when I started trying to reverse some basic .exe’s I ran into a lot of issues in both dissembling and decompiling. In the earlier, most tools always say my programs are of some unacceptable type and not CLR whatever that means. In the latter, in case I get lucky and produce some assembly code, none of the decompilers want to accept it since it is missing metadata or some. I

Question: If you know the situation I am in, please give me your advice about which software combination is best to use for reverse. Maybe any great books that are ultimate guides on reverse. Any, any kind of help will be much appreciated.

Thanks very much in advance.

What I have tried:

Decompilers: JustDecompile, Snowman
Updated 23-Apr-19 1:20am

1 solution

In Windows there are two forms of EXE file: Native and CLR.
Native are just that: native to Windows and the x86 architecture.
CLR are different: they use the Common Language Runtime which is a "pseudo machine code" that is compiled to Native code by the JIT engine as the app is running, and only apply to .NET based applications (mostly but not exclusively written in C# or VB).

CLR apps can be reversed engineered to produce C# or VB code (with varying effectiveness depending on the levels of obfuscation and optimisation applied when it was created).
Native apps? Not so much. Native apps could have been written in anything: machine code, C, C++, or a combination of then, and using one of many, many different compilers. THis means that Native apps are not a good "reverse engineering" prospect, as they may well have not been written in the high level language you expect, and may have had more extreme optimisations applied - both of which means that any C++ code you might create from the exe automatically may bear little or no resemblance to the original source code.

There are reasons for code to be difficult to reverse engineer: and they mostly concern Intellectual Property - you don't own the source code and the original authors don't want to give it to you; they invested a lot f work and money in getting it right in the first place and see no reason why you should be able to copy it...
Grigorii Mordkovich 23-Apr-19 8:40am
Thank you so much. This is a lot of info that definitely clears things up. As a follow up on your point about IP, I absolutely realize it and wasn’t trying to break into somebody else's software without their permission by any means. However, I’d like to know about the physics of this process and maybe in the future participate in a CTF competition. For the sake of training, I wrote a very simple C++ code of my own (was like one function that compared an input to some passcode and the main) and it cause all the above issues when I tried to reverse the compiled version of it to see smth similar to original.
OriginalGriff 23-Apr-19 8:43am
You're welcome!

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