Data breakpoint on a driver image?

Dejan_Maksimovic

I notice that clipsp gets a lot of bit errors (!chkimg reports about 15k).
Even though thus happens on a vanilla Win10, with nothing else, I used it
to test something...

At clipsp load, I set up a data breakpoint on the first DWORD that gets
changed (always the same offset).
It never fires, whether I set it to R or W.


Is this normal? Is this some DMA access changing the location? (I would not
know of anything else, but other than CPUs my knowledge of hardware is
almost nonexistent)

Jeffrey_Tippet_[MSFT]

That particular driver employs a number of anti-debugging techniques. It is by design that it is confusing to look at in the debugger. If you're trying to understand how a typical driver behaves, this is not the one to learn from.

Dejan_Maksimovic

Hmmm, thanks. Does it mean that its bit errors are normal, considering
they happen on a vanilla Win10 installation then? They are not always
the same in number, nor the same in overwritten data, but the offset
of the first incorrect BYTE is always the same.

I am trying to find a memory corruption issue in my own driver, and
clipsp is always the first driver that !chkimg reports errors on. I
wanted to catch what writes to those addresses, and whether it is me.


> That particular driver employs a number of anti-debugging techniques. It is
> by design that it is confusing to look at in the debugger. If you're trying
> to understand how a typical driver behaves, this is not the one to learn
> from.
>

Jeffrey_Tippet_[MSFT]

A couple general observations:

• A driver that employs self-modifying code would always fail !chkimg since the code segment in memory doesn't match the segment on disk.
• One common anti-debugging technique is to manually manipulate the processor's debug registers, to prevent breakpoints from functioning normally.

It's reasonable to run with the assumption that the memory corruption you're chasing down is unlikely to be affecting this particular driver's code segments, and that this particular driver is just intentionally doing unusual stuff to itself.

Dejan_Maksimovic

Got it. I'll !ba on other drivers then.

I thought self-modying code was not possible due to CI, BTW?

> A couple general observations:
>
>
> * A driver that employs self-modifying code would always fail !chkimg since
> the code segment in memory doesn't match the segment on disk.
> * One common anti-debugging technique is to manually manipulate the
> processor's debug registers, to prevent breakpoints from functioning
> normally.
>
> It's reasonable to run with the assumption that the memory corruption
> you're chasing down is unlikely to be affecting this particular driver's
> code segments, and that this particular driver is just intentionally doing
> unusual stuff to itself.
>
> --
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/comment/293685#Comment_293685
>
> Check it out:
> https://community.osr.com/discussion/comment/293685#Comment_293685
>

Jeffrey_Tippet_[MSFT]

I thought self-modying code was not possible due to CI, BTW?

The operating system makes the rules. That means it doesn't always have to play by them

Peter_Viscarola_(OSR)

The operating system makes the rules. That means it doesn't always have to play by them

I should have a plaque made with that motto, and hang it on the wall of my office.

Peter

Dejan_Maksimovic

On a different topic, I wonder if this makes the OS more vulnerable.
Not the general "not playing by its own rules", but that some part of
the OS can override CI/CG.

>> The operating system makes the rules. That means it doesn't always have to
>> play by them
>
> I should have a plaque made with that motto, and hang it on the wall of my
> office.