When to use Windbg and Ollydbg?

Question

According to what I know :WinDbg uses debugging information (pdb/symbol files) for debugging.So ,for example say I get a unknown exe (malicious) can I debug it since I'll not be having its .pdb. Is WinDbg best suited to analyze memory dumps and crash issues only?

Ollydbg being a ring 3 debugger is good to analyze/debug malicious exe's but doens't support unknown dlls(there is loaddll but you have to know which function the dll exports and there parameters) and rootkits(sys files).

So If I have a dll and a .sys file how can I debug it using olly or winDbg?

Note:I am a noob I may be wrong in what I know.I don't have the resources to buy IDAPro :-).

Answer 1

Even the free version of IDA Pro is worth having. Finding the general structure of an unknown binary is much easier with it than with anything else. If you have an unknown DLL, it will show you which exports it has, and looking at the assembly code helps you guess the parameters.

In most cases, to debug a .dll, you'll want to write a small program to call several of its exports one after another anyway. You can use ollydbg or windbg to load your .exe and trace through the .dll code.

My personal experience is that in many cases, the best approach would be using IDA first to get an overview over the unknown binary, then use ollydbg or the IDA debugger to trace on the processor instruction level, and only use a high level debugger when i have some symbols to trace on the source code level.

I have bought IDA and i think the current version of the debugger is much better than the free 5.0 one, so you might want to skip the IDA debugger entirely, but you'll still use it for static analysis. And i tend to use Linux much more than Windows (and if on windows, use IDA or Ollydbg), so i have a lot more experience with gdb than with windbg.

Still, each of these tools has its strenghs and weaknesses, and if you seriously want to go into binary analysis, you'll need each of them in the long run. If i were you, i'd invest a day or two into each of them. Once you're comfortable with them, you'll find you'll use each of them depending depending on your specific situation.

Answer 2

WinDbg uses debugging information (pdb/symbol files) for debugging. So ,for example say I get a unknown exe (malicious) can I debug it since I'll not be having its .pdb

Yes. Symbols are one of Windbg's main strength, but it can also debug anything without symbolic information.

Is WinDbg best suited to analyze memory dumps and crash issues only?

Once again, it can do that, but that's not its sole use.

Ollydbg being a ring 3 debugger is good to analyze/debug malicious exe's but doens't support unknown dlls(there is loaddll but you have to know which function the dll exports and there parameters)

If you need to analyse a DLL, you'll need a program to load it and then debug this program, thus you can't debug a DLL by itself (DLLs, as their name imply are dynamic libraries used by a main program). That's a system requirement.

and rootkits(sys files).

Yes, you'll need a ring0 debugger.

You can also mix static (disassembler) and runtime (debugger) analysis for your DLL and driver (*.sys) file. Hex rays has a free version of IDA.

---

Both debuggers can be used for Ring3 (user-land) debugging, and only Windbg can do Ring0 (kernel-land) but they have their own strengths and weaknesses.

From my point of view (I'm using both a lot):

• OllyDbg:
  • Pros: great for displaying information to the end-user; Color schemes, Well organised displaying windows.
  • Cons: symbolic information is minimal; no command line; GUI only
• Windbg:
  • Pros: extremely powerful with symbolic information; Ring0 debugging; windows internals; bare metal stuffs
  • Cons: not really user-friendly; steep learning curve

They both have a native plugin system (C / C++); windbg have a scripting language which is a real PITA (but pykd [Windbg scripting in python] can alleviate this problem).

Note that windbg can't do in-place live ring0 debugging (à la Softice or Syser) except with "livekd" (but this works on a system snpashot, not live): you need a host system (the debugger) and another machine which will be the debuggee (either a virtual machine or another physical machine).