reverse engineer .exe

[echy]

how do you reverse engineer a .exe

reason why is because i want to learn

 

ive tried looking at videos, ive gotten somewhat close but i still have no clue

maybe someone here has done it or has an idea..

anything would be of help

 

[zMeul]

decompiling binary executable will not give you the exact source code but a approximation of the binary form

it will be especially hard to do it when the binary was encrypted

[echy]

Just now, zMeul said:

decompiling binary executable will not give you the exact source code but a approximation of the binary form

it will be especially hard to do it when the binary was encrypted

so my chances of getting the prettying looking source code are slim? but i can get to the binary and change a few things is what your saying?

[FAQBytes]

Look for open source code, most won't be obfuscated. Try looking for really bad code on github, and see if you can find a better way to do it.

[echy]

1 minute ago, FAQBytes said:

Look for open source code, most won't be obfuscated. Try looking for really bad code on github, and see if you can find a better way to do it.

its cuz i know people know how to do it, they just the share the information or the inforamtion is really scarce

[LAwLz]

You will never get the original source code back if it was written in a compiled language.

What you can do however, is use a program like OllyDbg or IDA to analyze the compiled code (only for 32bit programs as far as I know though).

 

Just be prepared to read a lot of assembly...

[DevBlox]

Decompiling might give you some use if that application is written on .NET, with languages like C# or VB, and that is assuming it is not purposely obfuscated with special tools that will make that difficult or impossible. EXE Explorer has some of that capability, but to really browse code you can use Visual Studio + ReSharper with it's decompiler, that's your best bet.

 

Otherwise, if a program is compiled to machine code. Assembly. No other way around. Decompilers for C and C++ produce much more crooked results than those before mentioned, they're not really that useful. EXE Explorer still might give you an idea of what resources are present in the executable, but code is all up to you to read and interpret. Your best bet is to attach a debugger and go through the program step by step, tediously checking what each program part is doing. You will encounter a lot of external/system calls, you will need to recognize which is which, best have some table/list of them so you could do that.

 

With enough time you can definitely reverse engineer important portions of it. That's how people who pirate software get past security measures, how some modders have to mod their games out (that is very hard to do for big games though). You will learn a lot, if you're willing, go for it!

[Unimportant]

7 hours ago, echy said:

how do you reverse engineer a .exe

reason why is because i want to learn

 

ive tried looking at videos, ive gotten somewhat close but i still have no clue

maybe someone here has done it or has an idea..

anything would be of help

 

One uses a disassembler to convert the exe, which in essence just contains the raw binary assembler opcodes, into human readable assembler. If you know assembly (expert level) you can then see what the program does. Not my idea of fun tough.

 

On top of that you'll have to be very versed in understanding calling conventions and stack layout of compiled languages like C and C++ on top of the plain assembly.

 

[straight_stewie]

21 hours ago, echy said:

so my chances of getting the prettying looking source code are slim?

Those chances are impossible. When you compile, either to an intermediate language or to an assembly/machine language, you lose all of the things like variable names and such. In this way, compilation is largely one way, in the sense that alot of "human readable" information will be lost.

 

All is not lost, however. The real difficulty lies in determining what language the program was written in, as this will largely determine what your approach will be.

If the source language was any fully precompiled language, such as C, compiled BASIC, Compiled COBOL, compiled FORTRAN, or what have you, then the solution is really rather simple. You can use a disassembler to generate assembly from a binary, then you can use a decompiler to go from assembly to C (or any other turing complete fully compiled language). You will still have to do TONS of work to refactor the source to include variable names and formatting that are useful to any normal human being.

If the source language employs a JIT strategy or otherwise runs inside of a runtime, then it is largely more complicated. You will first need to determine the exact source language, and possibly the source language version. You will also likely need to do the same for any libraries that are used. Then what you will need to do is take either one of two strategies:

The first, and probably easiest if you have the necessary information is to decompile the binaries into the appropriate intermediary language, and then decompile those into the appropriate source language(s). That's about all I can tell you about that method.

 

I can tell you even less about the second method. You can use something like PyDBG to "debug" the instructions that an application is running, as well as register values and such, and reverse engineer from that point forward. Just about the only thing I know about this technique is that it is most commonly used not to RE full applications, but more usually to snoop specific portions of applications to find security holes.

[stmfd sp!, {lr}]

On 15/03/2017 at 8:22 AM, LAwLz said:

You will never get the original source code back if it was written in a compiled language.

What you can do however, is use a program like OllyDbg or IDA to analyze the compiled code (only for 32bit programs as far as I know though).

 

Just be prepared to read a lot of assembly...

You should clarify a few things:

1) Just because it's compiled doesn't mean you can't create a pretty good source-code decompilation. For example, Java and C# and both compiled to CIL which provides quite a lot of information; enough information to recreate a pretty good source code representation. Of course, the code might have been optimised so certain operations aren't as they were defined the actual source code and there's also a chance it's obfuscated which could hinder attempts to get anything useful from a disassembly (with ease, anyway). I assume you were talking about native languages where the majority of the high level abstractions are compiled away, just make that more obvious since PE files (from the ".exe" in the title) can have several targets (not just native).

2) IDA Pro supports both architectures. Of course though, you'll need the 64 bit version to work with 64 bit executables.

 

OP:

Of course it all depends on the executable and the extent of what you want to reverse engineer. A lot of the time, you don't need to reverse engineer a lot to get what you want. I've seen people throw away executables after running a quick "strings" on it and checking the IAT for WinAPI usages. If it's malware you're trying to reverse engineer, you should consider the scope of your reverse engineering - like, it's often more useful to throw the executable into some sandboxed environment and monitor its network usage and syscalls. As someone else mentioned, if the software is already open source, there's no need to reverse engineer it that much (it really depends what you're doing). For example, Chrome keeps getting hit with formgrabbers that hook SSL_Write to intercept POST information from user's requests. It's easy to find the function because you can just pattern match against memory to find it (Chrome no longer exports the function from BoringSSL - if I recall correctly - but that hasn't stopped people, lol).