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

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Data breakpoint on a driver image?

Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 327
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: 573

    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: 327
    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: 573

    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: 327
    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: 573

    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,900

    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: 327
    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
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA