Log in

View Full Version : DriverStudio 3.0 BreakPoints


naides
October 10th, 2003, 23:01
More than a question,
I wish to share the experiences I have had with DS 3.0 and see if other ppl have had the same problems and perhaps provide suggestions.

I was working on an app in which the status 'registered' versus 'demo' is stored in a global dword flag in in memory so that:

cmp dword ptr [00543221], 00
jz good guy, full capabilities
. . . Else Nag Screen: program in demo mode

Nothing out of the ordinary.
I was using DS 2.7 (I had no reason to update to 3.0 if it did the job)

So the logical next step was to catch the code when it sets the flag at [00543221] to something different than 00. No problem, I placed a memory access breakpoint: bpmd 00543221 w.

No rocket science here.

Now, the bloody bp did not break. I was double, triple sure that the flag had been modified: I manually changed to 00000000 at the program entry point, and later when Sice broke in a bpx point I had placed somewhere later in the code, the contents at 00543221 would be changed to 00000001 (demo mode) at some point, but SoftIce did not catch it. ???

It happened in two different computers, an Athlon and a Pentium 4, both running WinXP.
It was puzzling. I tested similar bpm with notepad, for instance, and it did break, so this phenomenon appeared to be an idiosincrasy of the particular app I was debugging.

I remembered that DS2.7 had bad reputation with WinXP. We had to apply Kayaker's patch to allow apps to break at WinMain etc.

Looking in the Numega website they claimed that DS3.0 was fully compatible with WinXP so I decided to give it a try.

After a somwhat rocky installation (It kept detecting DS2.7 despite I had already uninstalled, so I had to manually remove all registry traces) DS 3.0 was up and running.

The new version appeared to behave better than 2.7: If one loads a module onto the Symbol Loader it indeed stops at the entry point without need for a patch (I guess they copied it from Kayaker ). Also the memory breakpoints behaved as expected.

BUT small problem: breakpoints to system DLL API ie: BPX messageboxA worked very erratically. Even when I know for a fact that the API is called by the app, Sice refuses to break. I have noticed that if I manually traced in the code near the vicinity where the API is called, then it suddenly 'sticks' and starts working from that moment on.

Anybody with similar experiences?
Is this a bug?
Is this intended?
Is this Documented? (Yes, I RTFM and found no references to the issue, but I know dick about memory mapping and other obscure lingo, so I may have been looking in the wrong places)

Ideas?

Add on:
I do set the bpm while I am in the memory space of the debugee, more specifically when the program breaks at entry point. For extra caution I also set the API bpxS while in the memory context of the debugee at entry point.

dELTA
October 11th, 2003, 15:10
And there's no possibility that the program has anti-bp tricks? Asprotect for example has both anti-bpx and anti-bpm tricks, and other programmers might very well use them too. This sounds especially probable when you say that the breakpoints works when you set them while tracing just before the code that accesses the breakpoint location (because then it is a low probability that any anti-bp code will be execute between the two points).

Maybe you can try out the anti-anti-BPM tool and DRX operation detector from Yates (http://www.woodmann.net/yates/syscode.htm)?

naides
October 11th, 2003, 15:58
Thanks for the lead, Delta, I will take a look.
I had not expected the program to have antidebug tricks because most of the protection schemes seemed to be rather primitive. I had worked a pevious version of the program and it has not changed dramatically.
What has changed between then and now are the OS (Before I traced in W98, now in WXP) and the debugger version (Before Sice 4.05, now DS 2.7 and 3.0), so I thought the problem might be more in the OS-Debugger side of the equation,

BUT: I have not tried to trace the program im my ole win98/Sice 4.05 puter (Is put away for now).
I did try to trace it using ollyDbg, but it crashes my system.

Anyway, thank you again.

SpeKKeL
October 17th, 2003, 09:37
Yep,

I discovered allso some prob's(in ds 3.0) with breaking on setted bpx's..
It seems it breaks only if its breakpoint is set within the prog itself...
So putting a bpx on messagebox will only break if you set it when the prog is loaded in softice.

So back to ds 2.7 with all patches...

Spekk.

volodya
October 17th, 2003, 09:48
All bpx's now are context sensitive.

whyIII
October 17th, 2003, 21:13
That's the point, I think.

naides
October 18th, 2003, 09:20
Quote:
[Originally Posted by whyIII]That's the point, I think.


WhyIII an volodya,
1)can you elaborate a little?
2) is this new behavoir of the debugger documented or commented somewhere?
I saw nothing about the subject in Compuware.

Rummy
October 19th, 2003, 18:33
It's both a bug and a feature . The Using SICE manual says breakpoints set in the upper 2GB address range will break globally and breakpoints in the lower 2 GB address space will break only if the address context is the same in which the BP was set. It goes on to say that SI will pop up if the BP is set in a shared code module like kernel32.dll. I've yet to see that happen. In fact, I have had to modify several progs and insert INT 3 so that I can be in the proper context to set a BP that will pop up. Even for the so-called "shared modules".

My experience has been that the Compuware website is useless. There are a few pointers in the FAQs but there are no official web boards, forums or newsgroups where people share their experiences. Ever since NuMega sold the farm to Compuware it seems like support has gone downhill. No wonder more and more people are abandoning SICE and using tools like OllyDbg. I have not used OllyDbg myself so I can't comment on your problems there.

Please let everyone here know if you find out any secret tricks with DS 3.0. I think it does have bugs you won't find mentioned on the CW website and is woefully under-documented in general. Used to be you only needed the Using guide and the Reference but that's no longer the case. They took out a few commands that used to work just fine and added new stuff that doesn't work as advertised. I bought a ferw older versions of SICE over the years but there's no way I would pay for their current software. IMO SICE used to be a 10 on a scale of 1 to 10 but ever since Compuware took over I would give it only a 6 or a 7.

naides
October 19th, 2003, 19:12
Well I did a little digging by simultaneously running SoftIce 4.30 (DS 3.0), boot mode and Ollydbg

I set a bpx to GetVersion while standing in one memory context ie Notepad

In OllyDbg I load a different module i.e wordpad. While in Olly I use "Goto -> Expression" and ask it to go to GetVersion in Kernel32. Olly goes there and indeed, the first instruction of GetVersion is changed to 'CC': Int3

So the Breakpoints of Sice ARE placed inside the common code of the system modules, but, for one reason or another, Sice does not break.
What the hell, Sice 4.27, with patches and inconsistencies seems to do the job better,

I am going to have to learn OllyDbg. At my Age!

volodya
October 19th, 2003, 21:28
My guess it is made intentionally to prevent using Soft-Ice by pirates. May be. Cause, indeed, pointless to use 3.0 release. I myself prefer to use 3.0 beta 2 - still good bpx's. But time is coming, new MS OS are releasing and inevitably we will have to switch to 3.0 or 4.0 or whatever...

xfze
October 24th, 2003, 10:05
I have the same problem and i just found this russian site with patches for this problem (link and see)

http://www.translate.ru/url/tran_url.asp?lang=en&direction=re&template=General&cp1=NO&cp2=NO&autotranslate=on&transliterate=on&referrer=&first=1&url=http%3A%2F%2Freversing.kulichki.com%2Ffiles%2Fdebug%2Fdebug.htm
(version translated to english)

http://reversing.kulichki.com/files/debug/debug.htm
(original link)

I found it just a couple of minutes ago, so i will now test it and then i'll reply and say if it worked.

volodya
October 24th, 2003, 10:47
xfze

Man, don't be naive. First of all, these guys invented NOTHING new. Everything is on NuMega public http/ftp server for a long-long-long time already. Secondly - it is not working with DS 3.0.

xfze
October 24th, 2003, 13:43
Ok
I had seen already the patches in frontline.compuware but these were different...

But anyway there are some strange things...
In Win98SE SI3.2 i set a bpx SendDlgItemMessageA and i run a program where i know exactly were the break should work...and i press the magic button and...voila.
In WinXP_Pro DS3.0 i set the same bpx SendDlgItemMessageA, i run the same program, i click the same button...and...nothing no break! WHY? I'm beginning to loose it! XD
Just for fun i set a bpx CreateWindowExA i open almost everything i have installed...and still no popup! This way SoftIce is almost as useful as a broken watch...

Does anyone got DS3.0 under XPSp1..2 wathever running like it should? Should I downgrade SI? HELP!

naides
October 24th, 2003, 18:00
See Above
DS 2.7 (Sice 4.27) has its wrinkles but it DOES break in Windows API even when they are set from a different memory context.
By the way: I never paid much attention to the .t and .p
modifiers for bpx, but in Sice 4.3 .p (Break only if the brakpoint is within the current process) appears to be on by default.