Hello. I am working with a 16-bit Windows app in Softice. I wish to make a log entry every time a CALL instruction is executed. My only problem is that I cannot figure out how to automate testing an instruction on every program step. It would be easy if there was some way to set a breakpoint on a dynamic value (such as the current CS:IP). Using Macro recurssion doesn't seem to work either.
I would greatly appreciate any ideas you might have.

Thanks,

Eric

I'm not sure what you mean by making a log entry, but you could simply do a Backtrace on the code region you're interested in and look at the results later, use the HEAP command for the 16bit segments.

If you're trying to log API calls, even the 16bit ones, you should be able to set a BPR R(ead) on the import table address range and SI will break on every access.

Either
BPR ds:importStart ds:importEnd R


Or, you could use the EADDR qualifier to specify the address range to break on, (if you are on an import call, ? EADDR or D EADDR returns the import table jump address hidden under the Softice generated name), i.e.
BPRW <taskname> if (EADDR >= ds:ITStart <= ds:ITEnd)


Or similarly with EVALUE to specify only Kernel32 addresses (example),
BPRW <taskname> if (EVALUE >= ds:BFF70000 <= ds:BFFC0000)

Not sure what else you're trying to accomplish.

Kayaker

Thanks Kayaker. I'm sorry for being unclear. When I said that I wanted to "log" every CALL instruction I meant that every time CS:IP pointed to the instruction CALL (less interested in external CALLs) I wanted SI to write this to the history buffer, or to macro an icedump. Basicly I want an overview of this programs branchings during a certain period of its execution.
One way which I know will work is to BPX the 107 functions I was interested in, but I really didn't feel like doing all that typing. BPRing CS:<segstart> CS<segend> is ok, except that it would limit me to only four segments. Even then, and this REALLY bothers me, I cannot seem to access the indirect value of CS:IP. [@CS:IP],[*CS:IP],[CS:IP.0], and [CS:IP->0] only return "Invalid Indirection". EADDR does not seem to be helpful in this, but I am still looking at it. This problem bothers me more than anything!

Thanks,

Eric

Hi

>BPRing CS:<segstart> CS<segend> is ok, except that it would limit me to only four segments.
BPR breakpoints don't fall into the maximum-of-4 limitation of BPM bps if that's what you mean. You should be able to BPR the entire module by specifying the taskname, if you then type BL you should see breakpoints set up for every segment. You can also include or exclude specific segments from breakpoint activation with the CSIP command, this is an old holdout of early Softice that only works on 16bit apps.

I just did a backtrace of a 16bit app with several segments with
BPRW taskname T
and displayed it with SHOW. This may not be your ideal solution, but at least you get a record of the exact code execution, /screendumps of the backtrace will give you output, (if you were to do backtracing on 32bit PE files in Win98, TraceDump is the ultimate tool of choice of course...


Indirection with 16bit apps does seem difficult because of the segment/selector information built into address type values. I tried several combinations of indirection operators and couldn't get the contents of cs:ip returned either, presumably you want to test the opcodes for a call function. I don't know how else you could test for a CALL, the only thing you might be able to test for is a segment change using the underscore "_" directive to evaluate CS as a constant at the time the breakpoint is set, a Call to another segment should be picked up this way
BPRW taskname R if (cs != _cs)

Kayaker

Thanks again for the info. I ended up importing my IDA listing into MS Access, and using a recurssive query I got a list of all of the function calls I wanted. I then wrote a query that wrote out a SI Macro BPXing each function I was interested in, as well as DOing cls; stack; screendump.

It might have been the long way around, but it worked!

Eric

Nice solution! The query and macro you wrote out might be a good reference for those wanting to do the same thing, if you would like to post it.

Regards,
Kayaker

Nice idea! I've never seen MSAccess used in this way before - just goes to show really that some of Microsoft's software is useful for hacking after all...