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

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

why I can not debug a driver ( not programmed by me )

Anthony-2Anthony-2 Member Posts: 12
hello, why I can not do it? or how to Can I do it?

Comments

  • mmmm Member - All Emails Posts: 1,410
    There's a document in your windbg directory called
    'kernel_debugging_tutorial.doc.'

    It's a good place to start.



    Good luck,

    mm

    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of
    xxxxx@hotmail.com
    Sent: Monday, September 03, 2012 12:25 PM
    To: Kernel Debugging Interest List
    Subject: [windbg] why I can not debug a driver ( not programmed by me )

    hello, why I can not do it? or how to Can I do it?

    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Don_BurnDon_Burn Member - All Emails Posts: 1,653
    You can do it, but assuming that you don't have the sources (the not
    programmed by me) comment means you will have to do this all in assembler
    with limited symbol support. The work can be done, just like one can walk
    through a system routine.


    Don Burn
    Windows Filesystem and Driver Consulting
    Website: http://www.windrvr.com
    Blog: http://msmvps.com/blogs/WinDrvr




    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of
    xxxxx@hotmail.com
    Sent: Monday, September 03, 2012 3:25 PM
    To: Kernel Debugging Interest List
    Subject: [windbg] why I can not debug a driver ( not programmed by me )

    hello, why I can not do it? or how to Can I do it?

    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Anthony-2Anthony-2 Member Posts: 12
    thanks, yes, about symbols does not matter, I want to debug a driver without symbols, for information only.
    I set a breakpoint and then when I load the driver, Windbg shows:

    watchdog!WdUpdateRecoveryState: Recovery enabled.
    *** ERROR: Module load completed but symbols could not be loaded for drvkold.sys
    Breakpoint 5's offset expression evaluation failed.
    Check for invalid symbols or bad syntax.
    WaitForEvent failed
    nt!DebugService2+0x11:
    8052e4f5 5d pop ebp
  • mmmm Member - All Emails Posts: 1,410
    How did you set the breakpoint?


    mm

    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of
    xxxxx@hotmail.com
    Sent: Monday, September 03, 2012 12:48 PM
    To: Kernel Debugging Interest List
    Subject: RE:[windbg] why I can not debug a driver ( not programmed by me )

    thanks, yes, about symbols does not matter, I want to debug a driver without
    symbols, for information only.
    I set a breakpoint and then when I load the driver, Windbg shows:

    watchdog!WdUpdateRecoveryState: Recovery enabled.
    *** ERROR: Module load completed but symbols could not be loaded for
    drvkold.sys Breakpoint 5's offset expression evaluation failed.
    Check for invalid symbols or bad syntax.
    WaitForEvent failed
    nt!DebugService2+0x11:
    8052e4f5 5d pop ebp



    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Anthony-2Anthony-2 Member Posts: 12
    Before loading the driver I break to windbg, then
    bp driver!DriverEntry, and I use osrloader to load and starts the driver.
    If I remove the breakpoint, it runs normally
  • mmmm Member - All Emails Posts: 1,410
    In general, you're going to have to set breakpoints by address, since you
    don't have symbols.


    mm
    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of
    xxxxx@hotmail.com
    Sent: Monday, September 03, 2012 1:05 PM
    To: Kernel Debugging Interest List
    Subject: RE:[windbg] why I can not debug a driver ( not programmed by me )

    Before loading the driver I break to windbg, then bp driver!DriverEntry, and
    I use osrloader to load and starts the driver.
    If I remove the breakpoint, it runs normally

    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Anthony-2Anthony-2 Member Posts: 12
    right, So how can I find the address of the entry point if the driver is not loaded yet?
  • mmmm Member - All Emails Posts: 1,410
    Look in the PE header.


    mm

    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of
    xxxxx@hotmail.com
    Sent: Monday, September 03, 2012 1:13 PM
    To: Kernel Debugging Interest List
    Subject: RE:[windbg] why I can not debug a driver ( not programmed by me )

    right, So how can I find the address of the entry point if the driver is not
    loaded yet?

    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Anthony-2Anthony-2 Member Posts: 12
    still without success, I tried to find the entry point and/or use the bu command but does not works
  • Don_BurnDon_Burn Member - All Emails Posts: 1,653
    Do you need to debug DriverEntry? If not use !drvobj to get the drivers
    object and its dispatch entry points.


    Don Burn
    Windows Filesystem and Driver Consulting
    Website: http://www.windrvr.com
    Blog: http://msmvps.com/blogs/WinDrvr




    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of
    xxxxx@hotmail.com
    Sent: Monday, September 03, 2012 5:29 PM
    To: Kernel Debugging Interest List
    Subject: RE:[windbg] why I can not debug a driver ( not programmed by me )

    still without success, I tried to find the entry point and/or use the bu
    command but does not works

    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Anthony-2Anthony-2 Member Posts: 12
    yes, I would like to debug DriverEntry...
  • AtulAtul Member Posts: 50
    Well, assuming it is your test system , and the driver you are trying to
    debug is manually loaded, here is a trick you could try.

    1) Write a simple driver of your own.
    2) Register callback using PsSetLoadImageNotify. The callback function
    could be a no-op. Simply return.
    3) Load your driver (the one whose source code and symbols you have)
    4) Put a break point at the callback function.
    5) Now load your *target* driver.
    6) Your break-point should hit and give you the memory addresses where the
    target driver is mapped.
    7) Parse the PE headers from ImageBase address to get to the Entry point
    address.

    This should be the DriverEntry routine which will be invoked after your
    callback exits. Use ba to put a break point.

    Good luck and let know if it worked :)


    On Mon, Sep 3, 2012 at 3:22 PM, wrote:

    > yes, I would like to debug DriverEntry...
    >
    > ---
    > WINDBG is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • Ladislav_ZezulaLadislav_Zezula Member - All Emails Posts: 65
    OR, just write "KdBreakPoint();" at the beginning of the DriverEntry.



    Since the driver is not programmed by you, you can patch the first

    byte at entry point in an EXE editing tool, and then change the byte

    back when debugger stops there.



    Run driver with debugger attached, you are good to go.

    Note: Loading such driver without debugger attached leads

    to BSOD with bugcheck code 0x80000003 (breakpoint).



    L.



    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of Atul Kabra
    Sent: Tuesday, September 04, 2012 7:35 AM
    To: Kernel Debugging Interest List
    Subject: Re: [windbg] why I can not debug a driver ( not programmed by me )



    Well, assuming it is your test system , and the driver you are trying to
    debug is manually loaded, here is a trick you could try.



    1) Write a simple driver of your own.

    2) Register callback using PsSetLoadImageNotify. The callback function could
    be a no-op. Simply return.

    3) Load your driver (the one whose source code and symbols you have)

    4) Put a break point at the callback function.

    5) Now load your *target* driver.

    6) Your break-point should hit and give you the memory addresses where the
    target driver is mapped.

    7) Parse the PE headers from ImageBase address to get to the Entry point
    address.



    This should be the DriverEntry routine which will be invoked after your
    callback exits. Use ba to put a break point.



    Good luck and let know if it worked :)



    On Mon, Sep 3, 2012 at 3:22 PM, wrote:

    yes, I would like to debug DriverEntry...


    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer



    --- WINDBG is sponsored by OSR For our schedule of WDF, WDM, debugging and
    other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
    List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Ladislav_ZezulaLadislav_Zezula Member - All Emails Posts: 65
    I forgot one thing - If you are going to patch the driver entry,

    you also need to recalculate the image checksum, otherwise

    it won't be loaded. I use a tool named HIEW for both.



    L.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,142
    "Atul Kabra" <xxxxx@gmail.com> wrote in message news:xxxxx@windbg...
    >Well, assuming it is your test system , and the driver you are trying to
    >debug is manually loaded,
    >here is a trick you could try.

    There's an easier way to do this. The debugger already has support for
    breaking in when a particular module is loaded, so you just need to enable
    that support for the module of interest. From there, you can use information
    in the PE header to find the entry point in the image. Note that this entry
    point is typically *not* the driver's DriverEntry, but some pre-processing
    code that will eventually jump to DriverEntry.

    Here's an example with a driver called nothing.sys:

    1. Enable a break in the debugger when the module is loaded:

    sxe ld nothing.sys

    2. Resume the debugger:

    g

    3. Load the driver

    4. Debugger will break in as a result of the module load:

    nt!DebugService2+0x5:
    fffff801`47ae9985 cc int 3


    5. Dump the PE header for the loaded module with !dh

    1: kd> !dh nothing

    File Type: EXECUTABLE IMAGE
    FILE HEADER VALUES
    8664 machine (X64)
    6 number of sections
    503BCFB3 time date stamp Mon Aug 27 15:51:15 2012

    0 file pointer to symbol table
    0 number of symbols
    F0 size of optional header
    22 characteristics
    Executable
    App can handle >2gb addresses

    OPTIONAL HEADER VALUES
    20B magic #
    11.00 linker version
    C00 size of code
    800 size of initialized data
    0 size of uninitialized data
    157C address of entry point
    1000 base of code
    ----- new -----
    000007f6d9930000 image base
    1000 section alignment
    200 file alignment
    1 subsystem (Native)
    6.02 operating system version
    6.02 image version
    6.02 subsystem version
    7000 size of image
    400 size of headers
    4AFF checksum

    6. Add the value of, "address of entry point" to the base of the image to
    get the breakpoint address:

    1: kd> bp nothing+157C
    *** ERROR: Module load completed but symbols could not be loaded for
    NOTHING.sys

    7. Resume the debugger and hit the breakpoint:

    1: kd> g
    Breakpoint 0 hit
    NOTHING+0x157c:
    fffff880`0d9e657c 48895c2408 mov qword ptr [rsp+8],rbx

    For demonstration, with symbols loaded you can see that this breakpoint is
    in some pre-processing code that eventually jumps to my DriverEntry:

    fffff880`0d9e657c mov qword ptr [rsp+8],rbx
    fffff880`0d9e6581 push rdi
    fffff880`0d9e6582 sub rsp,20h
    fffff880`0d9e6586 mov rbx,rdx
    fffff880`0d9e6589 mov rdi,rcx
    fffff880`0d9e658c call NOTHING!__security_init_cookie
    fffff880`0d9e6591 mov rdx,rbx
    fffff880`0d9e6594 mov rcx,rdi
    fffff880`0d9e6597 mov rbx,qword ptr [rsp+30h]
    fffff880`0d9e659c add rsp,20h
    fffff880`0d9e65a0 pop rdi
    fffff880`0d9e65a1 jmp NOTHING!DriverEntry

    -scott


    "Atul Kabra" <xxxxx@gmail.com> wrote in message news:xxxxx@windbg...
    Well, assuming it is your test system , and the driver you are trying to
    debug is manually loaded, here is a trick you could try.

    1) Write a simple driver of your own.
    2) Register callback using PsSetLoadImageNotify. The callback function could
    be a no-op. Simply return.
    3) Load your driver (the one whose source code and symbols you have)
    4) Put a break point at the callback function.
    5) Now load your *target* driver.
    6) Your break-point should hit and give you the memory addresses where the
    target driver is mapped.
    7) Parse the PE headers from ImageBase address to get to the Entry point
    address.

    This should be the DriverEntry routine which will be invoked after your
    callback exits. Use ba to put a break point.

    Good luck and let know if it worked :)



    On Mon, Sep 3, 2012 at 3:22 PM, <xxxxx@hotmail.com> wrote:
    yes, I would like to debug DriverEntry...


    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer

    -scott
    OSR

  • raj_rraj_r Member - All Emails Posts: 981
    well you can break on most of drivers entry with this two breakpoints
    demo is for xp sp3 32bit but you can adapt it for all the os

    Will breakin at next boot. ( using ctr+alt+r or sxe ibp or -b on command line )
    kd> .reboot
    Shutdown occurred at (Wed Sep 5 00:59:09.234 2012 (UTC +
    5:30))...unloading all symbol tables.
    Waiting to reconnect...
    Connected to Windows XP 2600 x86 compatible target at (Wed Sep 5
    00:59:23.437 2012 (UTC + 5:30)), ptr64 FALSE
    Kernel Debugger connection established.
    Symbol search path is: SRV*F:\symbols*http://msdl.microsoft.com/download/symbols
    Executable search path is:
    Windows XP Kernel Version 2600 UP Free x86 compatible
    Built by: 2600.xpsp.080413-2111
    Machine Name:
    Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
    System Uptime: not available
    eax=00000003 ebx=00000000 ecx=0005ffa4 edx=0005ff74 esi=8008a978 edi=8008aa1c
    eip=80506d3e esp=0005ff60 ebp=0005ff60 iopl=0 nv up di ng nz na pe nc
    cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000086
    nt!DebugService2+0x10:
    80506d3e cc int 3

    grep for an indirect call that calls driver entry of bootloaded drivers

    kd> .shell -ci "uf /c nt!IopInitializeBuiltinDriver" grep -B 1 -i "call.*\[e.*h"
    nt!IopInitializeBuiltinDriver+0x25d (806a9ef9):
    unresolvable call: call dword ptr [ebx+2Ch]
    .shell: Process exited

    grep for an indirect call that calls driver entry of demand start drivers

    kd> .shell -ci "uf /c nt!IopLoadDriver" grep -B 1 -i "call.*\[e.*h"
    nt!IopLoadDriver+0x66a (805a399a):
    unresolvable call: call dword ptr [edi+2Ch]
    .shell: Process exited

    i am setting a logging bp on them for demo
    this can be customised to your will

    kd> bp 806a9ef9 ".printf \"%y\t\t%msu\n\n\" , poi (ebx+2ch),poi (esp+4);g"
    kd> bp 805a399a ".printf \"%y\t\t%msu\n\n\" , poi (edi+2ch),poi (esp+4);g"


    kd> bl
    0 e 806a9ef9 0001 (0001) nt!IopInitializeBuiltinDriver+0x25d
    ".printf \"%y\t\t%msu\n\n\" , poi (ebx+2ch),poi (esp+4);g"
    1 e 805a399a 0001 (0001) nt!IopLoadDriver+0x66a ".printf
    \"%y\t\t%msu\n\n\" , poi (edi+2ch),poi (esp+4);g"

    the msu will print the registry path
    NTSTATUS
    DriverEntry(
    __in PDRIVER_OBJECT DriverObject,
    __in PUNICODE_STRING RegistryPath <--------------------

    the %y actual driver entry that is called



    kd> g
    nt!RawInitialize (806a61f7)
    ACPI!GsDriverEntry
    (bafda059) \Registry\Machine\System\CurrentControlSet\Services\ACPI
    pci!GsDriverEntry
    (bafae004) \Registry\Machine\System\CurrentControlSet\Services\PCI
    isapnp+0x7a02 (fc4c3a02) \Registry\Machine\System\CurrentControlSet\Services\isapnp
    intelide+0xf05 (fc9c0f05) \Registry\Machine\System\CurrentControlSet\Services\IntelIde
    MountMgr!GsDriverEntry
    (fc4d5234) \Registry\Machine\System\CurrentControlSet\Services\MountMgr
    ftdisk!DriverEntry
    (baf9c4e2) \Registry\Machine\System\CurrentControlSet\Services\Ftdisk
    dmload!DriverEntry
    (fc9c2bf6) \Registry\Machine\System\CurrentControlSet\Services\dmload


    **********************cut**************** total 92 driver entry broken


    aec!GsDriverEntry
    (f901686a) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\aec
    swmidi!GsDriverEntry
    (f9259c85) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\swmidi
    DMusic!GsDriverEntry
    (f9249024) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\DMusic
    kmixer!GsDriverEntry
    (f8ff2105) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\kmixer
    drmkaud!GsDriverEntry
    (fcbd5505) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\drmkaud
    HTTP!GsDriverEntry
    (f8e0c757) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\HTTP



    On 9/4/12, Scott Noone <xxxxx@osr.com> wrote:
    > "Atul Kabra" <xxxxx@gmail.com> wrote in message
    > news:xxxxx@windbg...
    >>Well, assuming it is your test system , and the driver you are trying to
    >>debug is manually loaded,
    >>here is a trick you could try.
    >
    > There's an easier way to do this. The debugger already has support for
    > breaking in when a particular module is loaded, so you just need to enable
    > that support for the module of interest. From there, you can use information
    >
    > in the PE header to find the entry point in the image. Note that this entry
    >
    > point is typically *not* the driver's DriverEntry, but some pre-processing
    > code that will eventually jump to DriverEntry.
    >
    > Here's an example with a driver called nothing.sys:
    >
    > 1. Enable a break in the debugger when the module is loaded:
    >
    > sxe ld nothing.sys
    >
    > 2. Resume the debugger:
    >
    > g
    >
    > 3. Load the driver
    >
    > 4. Debugger will break in as a result of the module load:
    >
    > nt!DebugService2+0x5:
    > fffff801`47ae9985 cc int 3
    >
    >
    > 5. Dump the PE header for the loaded module with !dh
    >
    > 1: kd> !dh nothing
    >
    > File Type: EXECUTABLE IMAGE
    > FILE HEADER VALUES
    > 8664 machine (X64)
    > 6 number of sections
    > 503BCFB3 time date stamp Mon Aug 27 15:51:15 2012
    >
    > 0 file pointer to symbol table
    > 0 number of symbols
    > F0 size of optional header
    > 22 characteristics
    > Executable
    > App can handle >2gb addresses
    >
    > OPTIONAL HEADER VALUES
    > 20B magic #
    > 11.00 linker version
    > C00 size of code
    > 800 size of initialized data
    > 0 size of uninitialized data
    > 157C address of entry point
    > 1000 base of code
    > ----- new -----
    > 000007f6d9930000 image base
    > 1000 section alignment
    > 200 file alignment
    > 1 subsystem (Native)
    > 6.02 operating system version
    > 6.02 image version
    > 6.02 subsystem version
    > 7000 size of image
    > 400 size of headers
    > 4AFF checksum
    >
    > 6. Add the value of, "address of entry point" to the base of the image to
    > get the breakpoint address:
    >
    > 1: kd> bp nothing+157C
    > *** ERROR: Module load completed but symbols could not be loaded for
    > NOTHING.sys
    >
    > 7. Resume the debugger and hit the breakpoint:
    >
    > 1: kd> g
    > Breakpoint 0 hit
    > NOTHING+0x157c:
    > fffff880`0d9e657c 48895c2408 mov qword ptr [rsp+8],rbx
    >
    > For demonstration, with symbols loaded you can see that this breakpoint is
    > in some pre-processing code that eventually jumps to my DriverEntry:
    >
    > fffff880`0d9e657c mov qword ptr [rsp+8],rbx
    > fffff880`0d9e6581 push rdi
    > fffff880`0d9e6582 sub rsp,20h
    > fffff880`0d9e6586 mov rbx,rdx
    > fffff880`0d9e6589 mov rdi,rcx
    > fffff880`0d9e658c call NOTHING!__security_init_cookie
    > fffff880`0d9e6591 mov rdx,rbx
    > fffff880`0d9e6594 mov rcx,rdi
    > fffff880`0d9e6597 mov rbx,qword ptr [rsp+30h]
    > fffff880`0d9e659c add rsp,20h
    > fffff880`0d9e65a0 pop rdi
    > fffff880`0d9e65a1 jmp NOTHING!DriverEntry
    >
    > -scott
    >
    >
    > "Atul Kabra" <xxxxx@gmail.com> wrote in message
    > news:xxxxx@windbg...
    > Well, assuming it is your test system , and the driver you are trying to
    > debug is manually loaded, here is a trick you could try.
    >
    > 1) Write a simple driver of your own.
    > 2) Register callback using PsSetLoadImageNotify. The callback function could
    >
    > be a no-op. Simply return.
    > 3) Load your driver (the one whose source code and symbols you have)
    > 4) Put a break point at the callback function.
    > 5) Now load your *target* driver.
    > 6) Your break-point should hit and give you the memory addresses where the
    > target driver is mapped.
    > 7) Parse the PE headers from ImageBase address to get to the Entry point
    > address.
    >
    > This should be the DriverEntry routine which will be invoked after your
    > callback exits. Use ba to put a break point.
    >
    > Good luck and let know if it worked :)
    >
    >
    >
    > On Mon, Sep 3, 2012 at 3:22 PM, <xxxxx@hotmail.com> wrote:
    > yes, I would like to debug DriverEntry...
    >
    >
    > ---
    > WINDBG is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
    >
    >
    > ---
    > WINDBG is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • raj_rraj_r Member - All Emails Posts: 981
    i had this script but couldnt dig it yesterday so i posted a .shell
    substitute yesterday
    but .shell has a drawback that i cannot use the result as input to
    another debugger extension command so i used a .foreach earlier and
    made this script generic

    ie i can run it and it will always be available through out the
    session when ever any driver loads

    windbg will simply show me all the relevent details about the driver

    script is like this

    .foreach /pS 1 /ps 10 ( place { # call*dword*ptr*\[*\+*\]
    nt!IopInitializeBuiltinDriver} ) {bp place ".printf \"%msu\\n\",
    poi(esp+4);r $t0 = poi(esp); gu; !drvobj $t0 2;g"}

    .foreach /pS 1 /ps 10 ( place { # call*dword*ptr*\[*\+*\]
    nt!IoploadDriver} ) {bp place ".printf \"%msu\\n\", poi(esp+4);r $t1
    = poi(esp); gu; !drvobj $t1 2;g"}

    it searches for the patten in the function (first match is taken here
    not fool proof )
    call dword ptr [R32+const]
    sets a bp there and prints the registry path
    sets the driverobj that is passed to driver entry to a pseudo register
    executes the driver entry and then
    prints out the dispatch routines of the driver that was loaded

    and it lies dormant waiting for any driver that loads through this route

    demo below

    kd> sxe ibp;.reboot
    Shutdown occurred at (Wed Sep 5 17:37:17.343 2012 (UTC +
    5:30))...unloading all symbol tables.
    Waiting to reconnect...
    Connected to Windows XP 2600 x86 compatible target at (Wed Sep 5
    17:37:27.703 2012 (UTC + 5:30)), ptr64 FALSE
    Kernel Debugger connection established. (Initial Breakpoint requested)
    Symbol search path is: SRV*F:\symbols*http://msdl.microsoft.com/download/symbols
    Executable search path is:
    Windows XP Kernel Version 2600 UP Free x86 compatible
    Built by: 2600.xpsp.080413-2111
    Machine Name:
    Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
    System Uptime: not available
    Break instruction exception - code 80000003 (first chance)
    *******************************************************************************
    * *
    * You are seeing this message because you pressed either *
    * CTRL+C (if you run kd.exe) or, *
    * CTRL+BREAK (if you run WinDBG), *
    * on your debugger machine's keyboard. *
    * *
    * THIS IS NOT A BUG OR A SYSTEM CRASH *
    * *
    * If you did not intend to break into the debugger, press the "g" key, then *
    * press the "Enter" key now. This message might immediately reappear. If it *
    * does, press "g" and "Enter" again. *
    * *
    *******************************************************************************
    nt!RtlpBreakWithStatusInstruction:
    804e3592 cc int 3
    kd> $$>a< .\scripts\drventry.txt
    kd> bl
    0 e 806a9ef9 0001 (0001) nt!IopInitializeBuiltinDriver+0x25d
    ".printf \"%msu\\n\", poi(esp+4);r $t0 = poi(esp); gu; !drvobj $t0
    2;g"
    1 e 805a399a 0001 (0001) nt!IopLoadDriver+0x66a ".printf
    \"%msu\\n\", poi(esp+4);r $t1 = poi(esp); gu; !drvobj $t1 2;g"

    kd> g

    *** ERROR: Module load completed but symbols could not be loaded for isapnp.sys
    *** ERROR: Module load completed but symbols could not be loaded for
    diskperf.sys
    *** ERROR: Module load completed but symbols could not be loaded for
    intelide.sys
    Driver object (812ade18) is for:
    \FileSystem\RAW
    DriverEntry: 806a61f7 nt!RawInitialize
    DriverStartIo: 00000000
    DriverUnload: 8063043a nt!RawUnload
    AddDevice: 00000000

    Dispatch routines:
    [00] IRP_MJ_CREATE 805a09c1 nt!RawDispatch
    [01] IRP_MJ_CREATE_NAMED_PIPE 804fa87e nt!IopInvalidDeviceRequest
    [02] IRP_MJ_CLOSE 805a09c1 nt!RawDispatch
    [03] IRP_MJ_READ 805a09c1 nt!RawDispatch
    [04] IRP_MJ_WRITE 805a09c1 nt!RawDispatch
    [05] IRP_MJ_QUERY_INFORMATION 805a09c1 nt!RawDispatch
    [06] IRP_MJ_SET_INFORMATION 805a09c1 nt!RawDispatch
    [07] IRP_MJ_QUERY_EA 804fa87e nt!IopInvalidDeviceRequest
    [08] IRP_MJ_SET_EA 804fa87e nt!IopInvalidDeviceRequest
    [09] IRP_MJ_FLUSH_BUFFERS 804fa87e nt!IopInvalidDeviceRequest
    [0a] IRP_MJ_QUERY_VOLUME_INFORMATION 805a09c1 nt!RawDispatch
    [0b] IRP_MJ_SET_VOLUME_INFORMATION 804fa87e nt!IopInvalidDeviceRequest
    [0c] IRP_MJ_DIRECTORY_CONTROL 804fa87e nt!IopInvalidDeviceRequest
    [0d] IRP_MJ_FILE_SYSTEM_CONTROL 805a09c1 nt!RawDispatch
    [0e] IRP_MJ_DEVICE_CONTROL 805a09c1 nt!RawDispatch
    [0f] IRP_MJ_INTERNAL_DEVICE_CONTROL 804fa87e nt!IopInvalidDeviceRequest
    [10] IRP_MJ_SHUTDOWN 806303d5 nt!RawShutdown
    [11] IRP_MJ_LOCK_CONTROL 804fa87e nt!IopInvalidDeviceRequest
    [12] IRP_MJ_CLEANUP 805a09c1 nt!RawDispatch
    [13] IRP_MJ_CREATE_MAILSLOT 804fa87e nt!IopInvalidDeviceRequest
    [14] IRP_MJ_QUERY_SECURITY 804fa87e nt!IopInvalidDeviceRequest
    [15] IRP_MJ_SET_SECURITY 804fa87e nt!IopInvalidDeviceRequest
    [16] IRP_MJ_POWER 804fa87e nt!IopInvalidDeviceRequest
    [17] IRP_MJ_SYSTEM_CONTROL 804fa87e nt!IopInvalidDeviceRequest
    [18] IRP_MJ_DEVICE_CHANGE 804fa87e nt!IopInvalidDeviceRequest
    [19] IRP_MJ_QUERY_QUOTA 804fa87e nt!IopInvalidDeviceRequest
    [1a] IRP_MJ_SET_QUOTA 804fa87e nt!IopInvalidDeviceRequest
    [1b] IRP_MJ_PNP 805a09c1 nt!RawDispatch

    \Registry\Machine\System\CurrentControlSet\Services\ACPI
    Driver object (812ad998) is for:
    \Driver\ACPI
    DriverEntry: fc496059 ACPI!GsDriverEntry
    DriverStartIo: 00000000
    DriverUnload: fc473866 ACPI!ACPIUnload
    AddDevice: fc473a9a ACPI!ACPIDispatchAddDevice

    Dispatch routines:
    [00] IRP_MJ_CREATE fc473cb8 ACPI!ACPIDispatchIrp
    [01] IRP_MJ_CREATE_NAMED_PIPE fc473cb8 ACPI!ACPIDispatchIrp
    [02] IRP_MJ_CLOSE fc473cb8 ACPI!ACPIDispatchIrp
    [03] IRP_MJ_READ fc473cb8 ACPI!ACPIDispatchIrp
    [04] IRP_MJ_WRITE fc473cb8 ACPI!ACPIDispatchIrp
    [05] IRP_MJ_QUERY_INFORMATION fc473cb8 ACPI!ACPIDispatchIrp
    [06] IRP_MJ_SET_INFORMATION fc473cb8 ACPI!ACPIDispatchIrp
    [07] IRP_MJ_QUERY_EA fc473cb8 ACPI!ACPIDispatchIrp
    [08] IRP_MJ_SET_EA fc473cb8 ACPI!ACPIDispatchIrp
    [09] IRP_MJ_FLUSH_BUFFERS fc473cb8 ACPI!ACPIDispatchIrp
    [0a] IRP_MJ_QUERY_VOLUME_INFORMATION fc473cb8 ACPI!ACPIDispatchIrp
    [0b] IRP_MJ_SET_VOLUME_INFORMATION fc473cb8 ACPI!ACPIDispatchIrp
    [0c] IRP_MJ_DIRECTORY_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
    [0d] IRP_MJ_FILE_SYSTEM_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
    [0e] IRP_MJ_DEVICE_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
    [0f] IRP_MJ_INTERNAL_DEVICE_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
    [10] IRP_MJ_SHUTDOWN fc473cb8 ACPI!ACPIDispatchIrp
    [11] IRP_MJ_LOCK_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
    [12] IRP_MJ_CLEANUP fc473cb8 ACPI!ACPIDispatchIrp
    [13] IRP_MJ_CREATE_MAILSLOT fc473cb8 ACPI!ACPIDispatchIrp
    [14] IRP_MJ_QUERY_SECURITY fc473cb8 ACPI!ACPIDispatchIrp
    [15] IRP_MJ_SET_SECURITY fc473cb8 ACPI!ACPIDispatchIrp
    [16] IRP_MJ_POWER fc473cb8 ACPI!ACPIDispatchIrp
    [17] IRP_MJ_SYSTEM_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
    [18] IRP_MJ_DEVICE_CHANGE fc473cb8 ACPI!ACPIDispatchIrp
    [19] IRP_MJ_QUERY_QUOTA fc473cb8 ACPI!ACPIDispatchIrp
    [1a] IRP_MJ_SET_QUOTA fc473cb8 ACPI!ACPIDispatchIrp
    [1b] IRP_MJ_PNP fc473cb8 ACPI!ACPIDispatchIrp

    Fast I/O routines:
    FastIoDetachDevice
    fc4740d4 ACPI!ACPIFilterFastIoDetachCallback




    the paste below is a demand start drivers driver entry and its dispatch routines


    \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\CDO
    [Cdo]: Driver being loaded
    [Cdo]: Creating CDO ...
    [Cdo]: Creating CDO successful
    [Cdo]: FltObjects is fc913a6c Flags is 1 VolumeDeviceType is
    14 VolumefileSystemType is 7
    [Cdo]: FltObjects is fc913a6c Flags is 1 VolumeDeviceType is
    14 VolumefileSystemType is 6
    [Cdo]: FltObjects is fc913a6c Flags is 1 VolumeDeviceType is
    8 VolumefileSystemType is 2
    *** ERROR: Module load completed but symbols could not be loaded for cdo.sys
    Driver object (ffab0a30) is for:
    \FileSystem\CDO
    DriverEntry: fc8186f4 cdo
    DriverStartIo: 00000000
    DriverUnload: fc3f2f08 fltMgr!FltpMiniFilterDriverUnload
    AddDevice: 00000000

    Dispatch routines:
    [00] IRP_MJ_CREATE fc815710 cdo+0x1710
    [01] IRP_MJ_CREATE_NAMED_PIPE fc815710 cdo+0x1710
    [02] IRP_MJ_CLOSE fc815710 cdo+0x1710
    [03] IRP_MJ_READ fc815710 cdo+0x1710
    [04] IRP_MJ_WRITE fc815710 cdo+0x1710
    [05] IRP_MJ_QUERY_INFORMATION fc815710 cdo+0x1710
    [06] IRP_MJ_SET_INFORMATION fc815710 cdo+0x1710
    [07] IRP_MJ_QUERY_EA fc815710 cdo+0x1710
    [08] IRP_MJ_SET_EA fc815710 cdo+0x1710
    [09] IRP_MJ_FLUSH_BUFFERS fc815710 cdo+0x1710
    [0a] IRP_MJ_QUERY_VOLUME_INFORMATION fc815710 cdo+0x1710
    [0b] IRP_MJ_SET_VOLUME_INFORMATION fc815710 cdo+0x1710
    [0c] IRP_MJ_DIRECTORY_CONTROL fc815710 cdo+0x1710
    [0d] IRP_MJ_FILE_SYSTEM_CONTROL fc815710 cdo+0x1710
    [0e] IRP_MJ_DEVICE_CONTROL fc815710 cdo+0x1710
    [0f] IRP_MJ_INTERNAL_DEVICE_CONTROL fc815710 cdo+0x1710
    [10] IRP_MJ_SHUTDOWN fc815710 cdo+0x1710
    [11] IRP_MJ_LOCK_CONTROL fc815710 cdo+0x1710
    [12] IRP_MJ_CLEANUP fc815710 cdo+0x1710
    [13] IRP_MJ_CREATE_MAILSLOT fc815710 cdo+0x1710
    [14] IRP_MJ_QUERY_SECURITY fc815710 cdo+0x1710
    [15] IRP_MJ_SET_SECURITY fc815710 cdo+0x1710
    [16] IRP_MJ_POWER fc815710 cdo+0x1710
    [17] IRP_MJ_SYSTEM_CONTROL fc815710 cdo+0x1710
    [18] IRP_MJ_DEVICE_CHANGE fc815710 cdo+0x1710
    [19] IRP_MJ_QUERY_QUOTA fc815710 cdo+0x1710
    [1a] IRP_MJ_SET_QUOTA fc815710 cdo+0x1710
    [1b] IRP_MJ_PNP fc815710 cdo+0x1710

    Fast I/O routines:
    FastIoCheckIfPossible fc815fe0 cdo+0x1fe0
    FastIoRead fc8160f0 cdo+0x20f0
    FastIoWrite fc816200 cdo+0x2200
    FastIoQueryBasicInfo fc816310 cdo+0x2310
    FastIoQueryStandardInfo fc816420 cdo+0x2420
    FastIoLock fc816530 cdo+0x2530
    FastIoUnlockSingle fc816640 cdo+0x2640
    FastIoUnlockAll fc816750 cdo+0x2750
    FastIoUnlockAllByKey fc816860 cdo+0x2860
    FastIoDeviceControl fc816970 cdo+0x2970
    FastIoQueryNetworkOpenInfo fc816ab0 cdo+0x2ab0
    MdlRead fc816bc0 cdo+0x2bc0
    MdlReadComplete fc814b90 cdo+0xb90
    PrepareMdlWrite fc816cd0 cdo+0x2cd0
    MdlWriteComplete fc814c50 cdo+0xc50
    FastIoReadCompressed fc816de0 cdo+0x2de0
    FastIoWriteCompressed fc816ef0 cdo+0x2ef0
    MdlReadCompleteCompressed fc814d10 cdo+0xd10
    MdlWriteCompleteCompressed fc814dd0 cdo+0xdd0
    FastIoQueryOpen fc817000 cdo+0x3000

    [Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0x0 )
    [Cdo]: CdoHandlePrivateOpen entry ( Irp = 81183D68 )
    [Cdo]: CdoHandlePrivateOpen -> Device open successful. ( Irp =
    81183D68, Flags = 0x3, status = 0x0 )
    [Cdo]: CdoHandlePrivateOpen exit ( Irp = 81183D68, status = 0x0 )
    [Cdo]: Value At Irp->IoStatus.Information is 1
    [Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
    0x0, status = 0x0 )
    [Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0xd )
    [Cdo]: CdoHandlePrivateFsControl entry ( Irp = 81183D68 )
    IoControlCode = 0x90060
    InputBuffer = 811C9518
    ??
    InputBufferLength = 0x38
    OutputBuffer = 811C9518
    OutputBufferLength = 0x38
    [Cdo]: CdoHandlePrivateFsControl -> Processing IOCTL while handle to
    CDO is definitely open. ( Irp = 81183D68, IoControlCode = 0x90060 )
    [Cdo]: CdoHandlePrivateFsControl exit ( Irp = 81183D68, IoControlCode
    = 0x90060, status = 0x0 )
    [Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
    0xd, status = 0x0 )
    [Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0xd )
    [Cdo]: CdoHandlePrivateFsControl entry ( Irp = 81183D68 )
    IoControlCode = 0x90060
    InputBuffer = 81144480

    InputBufferLength = 0x0
    OutputBuffer = 81144480
    OutputBufferLength = 0x38
    [Cdo]: CdoHandlePrivateFsControl -> Processing IOCTL while handle to
    CDO is definitely open. ( Irp = 81183D68, IoControlCode = 0x90060 )
    [Cdo]: CdoHandlePrivateFsControl exit ( Irp = 81183D68, IoControlCode
    = 0x90060, status = 0x0 )
    [Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
    0xd, status = 0x0 )
    [Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0x12 )
    [Cdo]: CdoHandlePrivateCleanup entry ( Irp = 81183D68 )
    [Cdo]: CdoHandlePrivateCleanup -> Device cleanup successful. ( Irp =
    81183D68, Flags = 0x1, status = 0x0 )
    [Cdo]: CdoHandlePrivateCleanup exit ( Irp = 81183D68, status = 0x0 )
    [Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
    0x12, status = 0x0 )
    [Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0x2 )
    [Cdo]: CdoHandlePrivateClose entry ( Irp = 81183D68 )
    [Cdo]: CdoHandlePrivateClose -> Device close successful. ( Irp =
    81183D68, Flags = 0x0, status = 0x0 )
    [Cdo]: CdoHandlePrivateClose exit ( Irp = 81183D68, status = 0x0 )
    [Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
    0x2, status = 0x0 )
    [Cdo]: Unloading driver
    [Cdo]: Deleting CDO ...
    [Cdo]: Deleting CDO successful






    On 9/5/12, raj_r <xxxxx@gmail.com> wrote:
    > well you can break on most of drivers entry with this two breakpoints
    > demo is for xp sp3 32bit but you can adapt it for all the os
    >
    > Will breakin at next boot. ( using ctr+alt+r or sxe ibp or -b on command
    > line )
    > kd> .reboot
    > Shutdown occurred at (Wed Sep 5 00:59:09.234 2012 (UTC +
    > 5:30))...unloading all symbol tables.
    > Waiting to reconnect...
    > Connected to Windows XP 2600 x86 compatible target at (Wed Sep 5
    > 00:59:23.437 2012 (UTC + 5:30)), ptr64 FALSE
    > Kernel Debugger connection established.
    > Symbol search path is:
    > SRV*F:\symbols*http://msdl.microsoft.com/download/symbols
    > Executable search path is:
    > Windows XP Kernel Version 2600 UP Free x86 compatible
    > Built by: 2600.xpsp.080413-2111
    > Machine Name:
    > Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
    > System Uptime: not available
    > eax=00000003 ebx=00000000 ecx=0005ffa4 edx=0005ff74 esi=8008a978
    > edi=8008aa1c
    > eip=80506d3e esp=0005ff60 ebp=0005ff60 iopl=0 nv up di ng nz na pe
    > nc
    > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
    > efl=00000086
    > nt!DebugService2+0x10:
    > 80506d3e cc int 3
    >
    > grep for an indirect call that calls driver entry of bootloaded drivers
    >
    > kd> .shell -ci "uf /c nt!IopInitializeBuiltinDriver" grep -B 1 -i
    > "call.*\[e.*h"
    > nt!IopInitializeBuiltinDriver+0x25d (806a9ef9):
    > unresolvable call: call dword ptr [ebx+2Ch]
    > .shell: Process exited
    >
    > grep for an indirect call that calls driver entry of demand start drivers
    >
    > kd> .shell -ci "uf /c nt!IopLoadDriver" grep -B 1 -i "call.*\[e.*h"
    > nt!IopLoadDriver+0x66a (805a399a):
    > unresolvable call: call dword ptr [edi+2Ch]
    > .shell: Process exited
    >
    > i am setting a logging bp on them for demo
    > this can be customised to your will
    >
    > kd> bp 806a9ef9 ".printf \"%y\t\t%msu\n\n\" , poi (ebx+2ch),poi (esp+4);g"
    > kd> bp 805a399a ".printf \"%y\t\t%msu\n\n\" , poi (edi+2ch),poi (esp+4);g"
    >
    >
    > kd> bl
    > 0 e 806a9ef9 0001 (0001) nt!IopInitializeBuiltinDriver+0x25d
    > ".printf \"%y\t\t%msu\n\n\" , poi (ebx+2ch),poi (esp+4);g"
    > 1 e 805a399a 0001 (0001) nt!IopLoadDriver+0x66a ".printf
    > \"%y\t\t%msu\n\n\" , poi (edi+2ch),poi (esp+4);g"
    >
    > the msu will print the registry path
    > NTSTATUS
    > DriverEntry(
    > __in PDRIVER_OBJECT DriverObject,
    > __in PUNICODE_STRING RegistryPath <--------------------
    >
    > the %y actual driver entry that is called
    >
    >
    >
    > kd> g
    > nt!RawInitialize (806a61f7)
    > ACPI!GsDriverEntry
    > (bafda059) \Registry\Machine\System\CurrentControlSet\Services\ACPI
    > pci!GsDriverEntry
    > (bafae004) \Registry\Machine\System\CurrentControlSet\Services\PCI
    > isapnp+0x7a02
    > (fc4c3a02) \Registry\Machine\System\CurrentControlSet\Services\isapnp
    > intelide+0xf05
    > (fc9c0f05) \Registry\Machine\System\CurrentControlSet\Services\IntelIde
    > MountMgr!GsDriverEntry
    > (fc4d5234) \Registry\Machine\System\CurrentControlSet\Services\MountMgr
    > ftdisk!DriverEntry
    > (baf9c4e2) \Registry\Machine\System\CurrentControlSet\Services\Ftdisk
    > dmload!DriverEntry
    > (fc9c2bf6) \Registry\Machine\System\CurrentControlSet\Services\dmload
    >
    >
    > **********************cut**************** total 92 driver entry broken
    >
    >
    > aec!GsDriverEntry
    > (f901686a) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\aec
    > swmidi!GsDriverEntry
    > (f9259c85) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\swmidi
    > DMusic!GsDriverEntry
    > (f9249024) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\DMusic
    > kmixer!GsDriverEntry
    > (f8ff2105) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\kmixer
    > drmkaud!GsDriverEntry
    > (fcbd5505) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\drmkaud
    > HTTP!GsDriverEntry
    > (f8e0c757) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\HTTP
    >
    >
    >
    > On 9/4/12, Scott Noone <xxxxx@osr.com> wrote:
    >> "Atul Kabra" <xxxxx@gmail.com> wrote in message
    >> news:xxxxx@windbg...
    >>>Well, assuming it is your test system , and the driver you are trying to
    >>>debug is manually loaded,
    >>>here is a trick you could try.
    >>
    >> There's an easier way to do this. The debugger already has support for
    >> breaking in when a particular module is loaded, so you just need to
    >> enable
    >> that support for the module of interest. From there, you can use
    >> information
    >>
    >> in the PE header to find the entry point in the image. Note that this
    >> entry
    >>
    >> point is typically *not* the driver's DriverEntry, but some
    >> pre-processing
    >> code that will eventually jump to DriverEntry.
    >>
    >> Here's an example with a driver called nothing.sys:
    >>
    >> 1. Enable a break in the debugger when the module is loaded:
    >>
    >> sxe ld nothing.sys
    >>
    >> 2. Resume the debugger:
    >>
    >> g
    >>
    >> 3. Load the driver
    >>
    >> 4. Debugger will break in as a result of the module load:
    >>
    >> nt!DebugService2+0x5:
    >> fffff801`47ae9985 cc int 3
    >>
    >>
    >> 5. Dump the PE header for the loaded module with !dh
    >>
    >> 1: kd> !dh nothing
    >>
    >> File Type: EXECUTABLE IMAGE
    >> FILE HEADER VALUES
    >> 8664 machine (X64)
    >> 6 number of sections
    >> 503BCFB3 time date stamp Mon Aug 27 15:51:15 2012
    >>
    >> 0 file pointer to symbol table
    >> 0 number of symbols
    >> F0 size of optional header
    >> 22 characteristics
    >> Executable
    >> App can handle >2gb addresses
    >>
    >> OPTIONAL HEADER VALUES
    >> 20B magic #
    >> 11.00 linker version
    >> C00 size of code
    >> 800 size of initialized data
    >> 0 size of uninitialized data
    >> 157C address of entry point
    >> 1000 base of code
    >> ----- new -----
    >> 000007f6d9930000 image base
    >> 1000 section alignment
    >> 200 file alignment
    >> 1 subsystem (Native)
    >> 6.02 operating system version
    >> 6.02 image version
    >> 6.02 subsystem version
    >> 7000 size of image
    >> 400 size of headers
    >> 4AFF checksum
    >>
    >> 6. Add the value of, "address of entry point" to the base of the image to
    >> get the breakpoint address:
    >>
    >> 1: kd> bp nothing+157C
    >> *** ERROR: Module load completed but symbols could not be loaded for
    >> NOTHING.sys
    >>
    >> 7. Resume the debugger and hit the breakpoint:
    >>
    >> 1: kd> g
    >> Breakpoint 0 hit
    >> NOTHING+0x157c:
    >> fffff880`0d9e657c 48895c2408 mov qword ptr [rsp+8],rbx
    >>
    >> For demonstration, with symbols loaded you can see that this breakpoint
    >> is
    >> in some pre-processing code that eventually jumps to my DriverEntry:
    >>
    >> fffff880`0d9e657c mov qword ptr [rsp+8],rbx
    >> fffff880`0d9e6581 push rdi
    >> fffff880`0d9e6582 sub rsp,20h
    >> fffff880`0d9e6586 mov rbx,rdx
    >> fffff880`0d9e6589 mov rdi,rcx
    >> fffff880`0d9e658c call NOTHING!__security_init_cookie
    >> fffff880`0d9e6591 mov rdx,rbx
    >> fffff880`0d9e6594 mov rcx,rdi
    >> fffff880`0d9e6597 mov rbx,qword ptr [rsp+30h]
    >> fffff880`0d9e659c add rsp,20h
    >> fffff880`0d9e65a0 pop rdi
    >> fffff880`0d9e65a1 jmp NOTHING!DriverEntry
    >>
    >> -scott
    >>
    >>
    >> "Atul Kabra" <xxxxx@gmail.com> wrote in message
    >> news:xxxxx@windbg...
    >> Well, assuming it is your test system , and the driver you are trying to
    >> debug is manually loaded, here is a trick you could try.
    >>
    >> 1) Write a simple driver of your own.
    >> 2) Register callback using PsSetLoadImageNotify. The callback function
    >> could
    >>
    >> be a no-op. Simply return.
    >> 3) Load your driver (the one whose source code and symbols you have)
    >> 4) Put a break point at the callback function.
    >> 5) Now load your *target* driver.
    >> 6) Your break-point should hit and give you the memory addresses where
    >> the
    >> target driver is mapped.
    >> 7) Parse the PE headers from ImageBase address to get to the Entry point
    >> address.
    >>
    >> This should be the DriverEntry routine which will be invoked after your
    >> callback exits. Use ba to put a break point.
    >>
    >> Good luck and let know if it worked :)
    >>
    >>
    >>
    >> On Mon, Sep 3, 2012 at 3:22 PM, <xxxxx@hotmail.com> wrote:
    >> yes, I would like to debug DriverEntry...
    >>
    >>
    >> ---
    >> WINDBG is sponsored by OSR
    >>
    >> For our schedule of WDF, WDM, debugging and other seminars visit:
    >> http://www.osr.com/seminars
    >>
    >> To unsubscribe, visit the List Server section of OSR Online at
    >> http://www.osronline.com/page.cfm?name=ListServer
    >>
    >>
    >>
    >> ---
    >> WINDBG is sponsored by OSR
    >>
    >> For our schedule of WDF, WDM, debugging and other seminars visit:
    >> http://www.osr.com/seminars
    >>
    >> To unsubscribe, visit the List Server section of OSR Online at
    >> http://www.osronline.com/page.cfm?name=ListServer
    >>
    >
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
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA