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

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

Change IRP Registration in CancelSafe Occurs BSOD

t4et4e Posts: 2
Since there is no such PsSetCreateProcessNotifyRoutineEx, according to
Microsoft a mini filter driver need to be developed.

My design was to register on IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION and
check for executable created section in order to spot a loaded module.
On every loaded module I want to pend the IRP and insert it into a queue
and in simultaneously a thread worker will poll the IRP and send the
information to a user mode application that will allow/disallow
execution(STATUS_ACCESS_DENIED) of the module.

So I took the CancelSafe sample and change it that it will register on
IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION but I got a BSOD.

The problem seems to be in the handler of FltCbdqInsertIo - I tried to find
something that it's unique for IRP_MJ_READ in order to change it and make
it compatible with the new registered IRP.

This is my analyze -v:
Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------

*** No owner thread found for resource 80551160
*** No owner thread found for resource 80551160
*** No owner thread found for resource 80551160
*** No owner thread found for resource 80551160
*** No owner thread found for resource 80551160

DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING: 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)

DUMP_TYPE: 0

BUGCHECK_P1: 0

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

PROCESS_NAME: System

FAULTING_IP:
fltMgr!FltpInsertIrp+24
f84ccee4 80490301 or byte ptr [ecx+3],1

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE_STR: c0000005

EXCEPTION_PARAMETER1: 00000001

EXCEPTION_PARAMETER2: 00000003

FOLLOWUP_IP:
KProcessMonitor!PreRead+1a5
[c:\projects\arim\kprocessmonitor\kprocessmonitor\kprocessmonitor.c @ 1570]
f89eb1b5 8945fc mov dword ptr [ebp-4],eax

BUGCHECK_STR: ACCESS_VIOLATION

WRITE_ADDRESS: Target machine operating system not supported
00000003

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

CPU_COUNT: 1

CPU_MHZ: af7

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 5e

CPU_STEPPING: 3

CPU_MICROCODE: 6,5e,3,0 (F,M,S,R) SIG: 49'00000000 (cache) 49'00000000
(init)


ANALYSIS_SESSION_TIME: 12-25-2017 08:34:56.0625

ANALYSIS_VERSION: 10.0.16299.91 x86fre

LOCK_ADDRESS: 805511e0 -- (!locks 805511e0)

Resource @ nt!IopDeviceTreeLock (0x805511e0) Shared 1 owning threads
Threads: 823c63c8-01<*>
1 total locks

PNP_TRIAGE:
Lock address : 0x805511e0
Thread Count : 1
Thread address: 0x823c63c8
Thread wait : 0x8b5b

LAST_CONTROL_TRANSFER: from f84cd85b to f84ccee4

STACK_TEXT:
f8af5188 f84cd85b 820dc6d4 f8af52d8 00000000 fltMgr!FltpInsertIrp+0x24
f8af51ac f84ccfca 820dc6d4 f8af5200 81f9e718
fltMgr!FltpIoCsqInsertIrpEx+0x49
f8af51cc f89eb1b5 820dc6d4 822d32fc 81f9e718 fltMgr!FltCbdqInsertIo+0x2c



BTW nothing to do with this problem, there are number of BSODS around
FltStartFiltering(Globals.FilterHandle);
and FltUnregisterFilter(Globals.FilterHandle);
it's always PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: e1e13470, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: f84d6d9d, If non-zero, the instruction address which referenced the
bad memory
address.
Arg4: 00000001, (reserved)

Comments

  • Tim_RobertsTim_Roberts Posts: 12,622
    On Dec 24, 2017, at 10:43 PM, xxxxx@gmail.com wrote:
    >
    > Since there is no such PsSetCreateProcessNotifyRoutineEx, according to Microsoft a mini filter driver need to be developed.

    Of course there is, but it was added in Vista SP1, and for some reason you're using the antique XP SP2.


    > My design was to register on IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION and check for executable created section in order to spot a loaded module.
    > On every loaded module I want to pend the IRP and insert it into a queue and in simultaneously a thread worker will poll the IRP and send the information to a user mode application that will allow/disallow execution(STATUS_ACCESS_DENIED) of the module.

    You're not allowed to return that. The return values for these filter callbacks are very limited, and described in the documentation.


    > So I took the CancelSafe sample and change it that it will register on IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION but I got a BSOD.
    >
    > The problem seems to be in the handler of FltCbdqInsertIo - I tried to find something that it's unique for IRP_MJ_READ in order to change it and make it compatible with the new registered IRP.

    It looks like you tried to queue a null IRP.

    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Regarding you 2nd random BSODs you need to know that FltUnregisterFilter will call the cleanup callbacak for all your registered contexts and also the instance teardown callbacks.
    You did not show the dump text for more details.

    Gabriel.
    www.kasardia.com

    Cheers,
    Gabriel

  • <QUOTE>
    So I took the CancelSafe sample and change it that it will register on
    IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION but I got a BSOD.
    </QUOTE>

    IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION isn’t really an IRP operation, it’s
    a FltMgr “pseudo IRP” operation.
    See the FltCbdqInsertIo remarks section:

    "The FltCbdqXxx routines can only be used for IRP-based I/O operations. To
    determine whether a given callback data structure represents an IRP-based
    I/O operation, use the FLT_IS_IRP_OPERATION macro. "

    -scott
    OSR
    @OSRDrivers

    -scott
    OSR

  • Develop for a modern OS environment and use PsSetCreateProcessNotifyRoutineEx. It's secure, stable and reliable. A lot less-hassle to do what you need to do as well. You also have the guarantee that it'll be triggered for a Portable Executable being executed, unlike with the mini-filter method where you have to execute more instructions which provides more overhead on performance for each execution (and non-process start-up related activities) to ensure it is indeed an executable for a process-startup request.
  • t4et4e Posts: 2
    I need to support Windows XP SP2 as well

    2018-01-02 22:41 GMT+02:00 xxxxx@gmail.com :

    > Develop for a modern OS environment and use PsSetCreateProcessNotifyRoutineEx.
    > It's secure, stable and reliable. A lot less-hassle to do what you need to
    > do as well. You also have the guarantee that it'll be triggered for a
    > Portable Executable being executed, unlike with the mini-filter method
    > where you have to execute more instructions which provides more overhead on
    > performance for each execution (and non-process start-up related
    > activities) to ensure it is indeed an executable for a process-startup
    > request.
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • > I need to support Windows XP SP2 as well

    But why? All you will be doing is developing software for an insecure Operation System which is no longer officially supported, while encouraging people to keep using it. It doesn't matter what product you develop, the OS is going to be vulnerable.

    Did no one learn from the WannaCry attack which used the stolen NSA exploit, EternalBlue? The EternalBlue exploit worked by exploiting the SRV.sys device driver, a component part of SMB networking on Windows; the vulnerability had been fixed except for Windows XP prior to the attack. If people on XP who were affected had been using an up-to-date, secure OS, they wouldn't have been affected by the damage they had been.

    I know you aren't asking about what OS to target for your software target market but seriously you may wish to re-consider this. XP is full of bugs, its not officially supported anymore and it is very limited in comparison to the modern Windows Kernel. As well as this, if you're supporting newer OS versions, don't execute the same code as you are for XP because you can use better documented and stable techniques which are also likely more secure on updated versions of Windows. If you insist on developing for XP, only go the XP support route for a system which actually has it loaded, and use updated and more efficient interfaces/techniques for the modern versions when a modern system is being used.
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!