Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Data breakpoint on a driver image?

Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
via Email in WINDBG
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)

Comments

  • Jeffrey_Tippet_[MSFT]Jeffrey_Tippet_[MSFT] Member - All Emails Posts: 558

    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_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
    via Email
    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]Jeffrey_Tippet_[MSFT] Member - All Emails Posts: 558

    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_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
    via Email
    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]Jeffrey_Tippet_[MSFT] Member - All Emails Posts: 558

    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)Peter_Viscarola_(OSR) Administrator Posts: 7,470

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
    via Email
    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.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE