Quote:
[Originally Posted by DENiSON;81909]i also note most tutorials dont mention needing symbol loader. they simply suggest loading up your program and then pressing CTRL + D ? |
That's because they assume you know how to use softice, or are at least basically acquainted with it. Aimless claims softice is dead but he's being biased.
If you use XP, sice is as good or better than Olly, depending on what you are trying to accomplish. If you're going to use it, however, you need to spend a lot of time learning it. You don't need symbol loader, I seldom use it. If I want to break in on an app I'm debugging, I set BPX _baseprocessstart in kernel32 and the app stops there. That's because _baseprocessstart shows up in k32 just before an app loads. It's simply a matter of stepping over a couple of functions and tracing into one of them. Then you're right at the start of code for the app.
One of the keys in using softice is learning how to make nms files using IDA. The nms file are symbols that help you indentify key locations in the app. Using IDA, you can even write in your own landmarks for your own benefit. It's not as good as source code, of course, but it sure helps. Learning to use the 'addr' and 'table' command is vital in softice, but once you've mastered that stuff, the rest is a piece of cake.
Symbol loader is a convenience for editing the winice.dat config file. You can do all that by hand. It also helps you load modules if you want them but you can do that by hand as well.
Once you break on _baseprocessstart, and trace to start of code, it's simply a matter of setting whatever BP you need and hitting F5. Or type G <address>. When you first use sice on an app, it can take a while to determine what's going on. For example, an app I am debugging loads a ROM module. On the first load, I have to set a BMSG hwnd 111, which catches a WM_COMMAND message on the top window.
I find the hwnd using SPYXX. When it breaks, I can trace to the dialog box that loads the module, or I can BPX on GetOpenFilename. Either way, I end up at the dialog box. From there I write down the address where GetOpenFilename is found, so next time I don't have to mess with tracing. I just use BMSG hwnd 111, set G <address>, set a BP with the mouse on the other side of GetOpenFilename, hit F5, the dialog box appears, I load my module and hit OK. The BP I set with the mouse picks up GetOpenFilename returning from the call, and I'm off to the races.
Softice is very intuitive and easy to use. It's also very stable and you can trace through any ring 0 code you want, as long as you don't try anything stupid.
I am not going to mouth off about Olly because I don't know how to use it. By the same token, I don't think anyone should try to discourage you using softice. Both debuggers have their pluses and it never hurts to learn anything related to RE for future reference.
The advantage of Olly, as far as I can see, is that a lot of people are writing plugins for it. On the negative side, what I'm seeing is tutorials written for Olly that are recipe cracks. They tell you how to get to a point in the code without explaining what is going on. Most of what I have learned, which ain't a lot, has been from breaking on the start of code (not winmain) and tracing through the app to see what's happening. That way, I've learned about how windows initializes an app, how winmain is called, the message loop, and how winmain is one long function that loops till an exit message appears. I have also watched windows being initialized and opened.
I think you should carry on with softice and try tracing into some ring 0 code. Sometimes you'll find that a call into ring 0 calls back into the app you are debugging. How Olly handles that is not clear to me. While in ring 0, however, you must be aware that your app in not all that's going on. If you're not aware, you can be tracing through the code for another app. You can tell that immediately in softice by looking at the bar near the bottom of the screen. It tells you exactly what module you're in.
One last thing. I recently came across utilities that are written in DOS. For example, a FLASH utility for flashing your ROM. Without the older version of softice you're essentially dead. I don't know of any other debugger that can debug a DOS app. I've used softice to debug DOS, DOS4G, windows, directX and python. Not bad for a dead debugger.