views:

17027

answers:

11

A friend of mine downloaded some malware from Facebook, and I'm curious to see what it does without infecting myself. I know that you can't really decompile an .exe, but can I at least view it in Assembly or attach a debugger?

Edit to say it is not a .NET executable, no CLI header.

+1  A: 

You may get some information viewing it in assembly, but I think the easiest thing to do is fire up a virtual machine and see what it does. Make sure you have no open shares or anything like that that it can jump through though ;)

Rob Prouse
Yeah, I thought about that, but I'd rather not go through the hassle of setting up a VM just to kill it :)
swilliams
True, it is a hassle for this one case, but I always find it is useful to keep a VM around for testing new software or stuff like this. I can then do what I please and just choose not to save state at the end and go back to the clean VM for the next run.
Rob Prouse
+2  A: 

Sure, have a look at IDA Pro. They offer an eval version so you can try it out.

Douglas Mayle
That looks cool, I'll try it out. Thank you.
swilliams
+7  A: 

Any decent debugger can do this. Try OllyDbg. (edit: which has a great disassembler that even decodes the parameters to WinAPI calls!)

utku_karatas
+2  A: 

What you want is a type of software called a "Disassembler".

Quick google yields this: http://www.geocities.com/~sangcho/disasm.html

Corey Trager
+1  A: 

If you are just trying to figure out what a malware does, it might be much easier to run it under something like the free tool Process Monitor which will report whenever it tries to access the filesystem, registry, ports, etc...

Also, using a virtual machine like the free VMWare server is very helpful for this kind of work. You can make a "clean" image, and then just go back to that every time you run the malware.

+29  A: 

With a debugger you can step through the program assembly interactively.
With a disassembler, you can view the program assembly in more detail.
With a decompiler, you can turn a program back into partial source code, assuming you know what it was written in (which you can find out with free tools such as PEiD - if the program is packed, you'll have to unpack it first).

  • Debuggers:
    • OllyDbg, free, a fine debugger, for which you can find numerous user-made plugins and scripts to make it all the more useful.
    • WinDbg, free, a quite capable debugger by Microsoft. WinDbg is especially useful for looking at the Windows internals, since it knows more about the data structures than other debuggers.
    • SoftICE, SICE to friends. Commercial and development stopped in 2006. SoftICE is kind of a hardcore tool that runs beneath the operating system (and halts the whole system when invoked). SoftICE is still used by many professionals, although might be hard to obtain and might not work on some hardware (or software - namely, it will not work on Vista or NVIDIA gfx cards).
  • Disassemblers:
    • IDA Pro, commercial, top of the line disassembler/debugger. Used by most professionals, like malware analysts etc. Costs quite a few bucks though.
    • W32Dasm, free, a bit dated but gets the job done. I believe W32Dasm is abandonware these days, and there are numerous user-created hacks to add some very useful functionality. You'll have to look around to find the best version.
  • Decompilers:
    • Visual Basic: VB Decompiler, commercial, produces somewhat identifiable bytecode.
    • Delphi: DeDe, free, produces good quality source code.
    • C: HexRays, commercial, a plugin for IDA Pro by the same company. Produces great results but costs a big buck, and won't be sold to just anyone (or so I hear).

Some related tools that might come handy in whatever it is you're doing are resource editors such as ResourceHacker (free) and a good hex editor such as Hex Workshop (commercial).

Additionally, if you are doing malware analysis (or use SICE), I wholeheartedly suggest running everything inside a virtual machine, namely VMware Workstation. In the case of SICE, it will protect your actual system from BSODs, and in the case of malware, it will protect your actual system from the target program. You can read about malware analysis with VMware here.

Personally, I roll with Olly, WinDbg & W32Dasm, and some smaller utility tools.

Also, just a friendly reminder to all of you! Remember that disassembling or even debugging other people's software is usually against the EULA at the very least ;) If you (hypothetically speaking) do, though, a good first indicator of "this is probably illegal" is if the program or module you're touching is packed with something other than UPX.

psoul
Fantastic, thanks!
swilliams
SoftICE and W32Dasm are what I was going to recommend too.
rally25rs
Excellent answer.
Chris Marasti-Georg
I appreciate the last paragraph in its generality, good advice, but it is amusing in the context of the question: I doubt a virus comes with an EULA! ;-)
PhiLho
Actually, some malware and even trojans of late have had EULAs in them (oh, those russians..) Of course, they can be (and are) ignored by researches, because it can be assumed that nobody will come forward to sue them... Also, they're usually too badly written to mean anything in court in any case.
psoul
Note that IDA Pro's previous version is free for non-commercial use.
Simon Buchan
Note that most malware these days (at least compiled malware) can easily detect if it is running in VMWare, Virtual PC, WINE, VirtualBox, etc.
Mick
If you're running in a VM, watch out for the Blue Pill attack.
Exception
+2  A: 

Good news. IDA Pro is actually free for its older versions now: http://www.hex-rays.com/idapro/idadownfreeware.htm

Matthew
A: 

If you want to run the program to see what it does without infecting your computer, use with a virtual machine like VMWare or Microsoft VPC, or a program that can sandbox the program like SandboxIE

Joel Lucsy
+4  A: 

psoul's excellent post answers to your question so I won't replicate his good work, but I feel it'd help to explain why this is at once a perfectly valid but also terribly silly question. After all, this is a place to learn, right?

Modern computer programs are produced through a series of conversions, starting with the input of a human-readable body of text instructions (called "source code") and ending with a computer-readable body of instructions (called alternatively "binary" or "machine code").

The way that a computer runs a set of machine code instructions is ultimately very simple. Each action a processor can take (e.g., read from memory, add two values) is represented by a numeric code. If I told you that the number 1 meant scream and the number 2 meant giggle, and then held up cards with either 1 or 2 on them expecting you to scream or giggle accordingly, I would be using what is essentially the same system a computer uses to operate.

A binary file is just a set of those codes (usually call "op codes") and the information ("arguments") that the op codes act on.

Now, assembly language is a computer language where each command word in the language represents exactly one op-code on the processor. There is a direct 1:1 translation between an assembly language command and a processor op-code. This is why coding assembly for an x386 processor is different than coding assembly for an ARM processor.

Disassembly is simply this: a program reads through the binary (the machine code), replacing the op-codes with their equivalent assembly language commands, and outputs the result as a text file. It's important to understand this; if your computer can read the binary, then you can read the binary too, either manually with an op-code table in your hand (ick) or through a disassembler.

Disassemblers have some new tricks and all, but it's important to understand that a disassembler is ultimately a search and replace mechanism. Which is why any EULA which forbids it is ultimately blowing hot air. You can't at once permit the computer reading the program data and also forbid the computer reading the program data.

(Don't get me wrong, there have been attempts to do so. They work as well as DRM on song files.)

However, there are caveats to the disassembly approach. Variable names are non-existent; such a thing doesn't exist to your CPU. Library calls are confusing as hell and often require disassembling further binaries. And assembly is hard as hell to read in the best of conditions.

Most professional programmers can't sit and read assembly language without getting a headache. For an amateur it's just not going to happen.

Anyway, this is a somewhat glossed-over explanation, but I hope it helps. Everyone can feel free to correct any misstatements on my part; it's been a while. ;)

Jason L
A: 

Boomerang may also be worth checking out.

Glomek
Not really. it crashes and burns for anything more complicated than the most trivial executables.
shoosh
A: 

If you have no time, submit the malware to cwsandbox:

http://www.cwsandbox.org/

http://jon.oberheide.org/blog/2008/01/15/detecting-and-evading-cwsandbox/

HTH

plan9assembler