anyone good at reverse engineering an exe file?

[jhu]

i just came upon a phishing website that wants me to download an "e-greeting." instead, the program is an .exe file that i suspect contains some sort of malware. since i'm using linux, it doesn't affect me. anyone good at interpreting decompiled code willing to see what this thing does?

 

[Descartes]

Depending on the compiler used to create this app, decompilation may or may not even be possible. Some compilers obfuscate to a degree significant enough to make the endeavor very difficult.

Standard COFF exes are easy enough to determine where executable code exists (on Windows, the PE format is widely known and there are plenty of tools available to capture it), but you're likely only going to get the assembly instructions (or worse, just the opcodes; you can see that in a standard hex editor), but to isolate this little section of malware you're suspecting would be a large effort unless it's an extremely simple app.

So, I doubt you're going to get anyone willing to invest the time required to do it. You're better off just not running such applications... ever.

 

[Modelworks]

Just for kicks ,open it in a hex editor.
Sometimes you can decipher what an exe is intending to do from ascii text decoded in the hex editor.

 

[hans007]

i used to do this as a contractor for symantec's virus / spyware analysis lab..


you will probably want to use a hex editor to search for hard coded strings. most of the urls and such will show up.

if you want to know like the exact calls it will make and that sort of thing... you might be able to look at it in say... IDA pro disassembler. if its made with win32 mfc libraries (instead of say borland) i think ida can try to pick up the symbol table and convert them to actual function names in win32 libraries. you can actually sort of step through the disassembled stuff and see what is being pushed into the stack before function calls..


so if you see the symbol for something you can see what parameters the call is taking.

 

[exdeath]

Requires knowledge of the target OS. You can learn about 90% of a executables intended purpose by looking at the import tables. This is where you see the ASCII naming DLLs and Win32 functions. It's defined in the PE format. It's questionable when you have a very small executable with no version information with the bulk of its imports having to do with registry, file, keyboard, and network functions and little else.

I tend to start from a system or API call performing a specific suspicious act I'm interested in, such as sending data via a winsock call, and work backwards to see where the parameters came from and how the data is formed. If you start top down at the executables entry point you could waste hours stepping your way through the C runtime stub and WinMain and get lost quickly when staring at raw assembly doing mundane and routine stuff like setting up the heap, etc.

Don't try to decode the assembly top to bottom and fully reverse engineer the program to C source. It's not going to happen. Instead look at API calls and determine what the program is trying to do at the highest level. You don't need to reverse engineer 1000 prologues/epilogues and determine function names, most of which will be standard C runtime functions anyway and a waste of time, just to see that a program is hooking the keyboard, creating a file, and dumping its contents to a network socket.

They key is to start in the middle and follow and back trace from places where well known and defined API calls are being made. With a quality debugger you can associate jumps into the import table with ASCII Win32 API function labels to make it easier on your eyes. The language of reverse engineering is not assembly language, it's API, because ultimately in order to do anything outside it's own virtual sand box, every program will have to call API functions to interact with the outside world. Flow charting the API calls will be 1000 times more productive than staring at x86 opcodes. After you've learned the general framework based on the API calls and have an idea what the program is doing and what you are looking for, you can be more specific and start sifting in between the API calls to the assembly and see how parameter data is formed, what data is being passed and where its coming from or how its being calculated, etc.

It's the same idea as writing a good console emulator. Why bother with thousands upon thousands of instructions emulating the hardware when all you have to do is write a wrapper for "draw_triangle" that passes it along to Direct3d?

You already have the leg up by suspecting that it's malicious. You already know what to look for and what to expect to see.