Access Violation after switch FCB of the File?

Hi, I’m developing a encryption filter based on minifilter.
Now I’m trying to create a shadow file object(with FltCreateFile) to do the real read/write operation and substitue the origin FCB with my own created one. I have read the source code of FastFAT and nearly do the same thing with my own created FCB.
But after substituing the orign FCB with the new ONE, I encounter an access violation like the following:
kd> g
Access violation - code c0000005 (!!! second chance !!!)
Ntfs!NtfsAcquireForCreateSection+0x15:
ba63e8cf ff704c push dword ptr [eax+4Ch]
kd> kb
ChildEBP RetAddr Args to Child
b19c2860 8056c0b9 89507dd0 894ee2f0 00000000 Ntfs!NtfsAcquireForCreateSection+0x15
b19c29ac 8056d046 89507dd0 00000001 00000004 nt!FsRtlAcquireFileExclusiveCommon+0x10f
b19c29c0 8050cc3c 89507dd0 00000004 00000000 nt!FsRtlAcquireToCreateMappedSection+0x12
b19c2a5c 805aaf1d b19c2aa8 0000000d b19c2b90 nt!MmCreateSection+0x26e
b19c2acc 8054160c b19c2bc0 0000000d b19c2b90 nt!NtCreateSection+0x12f
b19c2acc 80500499 b19c2bc0 0000000d b19c2b90 nt!KiFastCallEntry+0xfc
b19c2b60 8061db78 b19c2bc0 0000000d b19c2b90 nt!ZwCreateSection+0x11
b19c2bb8 8061f0df b19c2be0 00000081 b19c2c18 nt!CcPfGetSectionObject+0xca
b19c2c4c 8061fce1 b19c2c74 00000000 00000000 nt!CcPfPrefetchSections+0x2b7
b19c2c8c 8062010a e1158000 00080000 890dd608 nt!CcPfPrefetchScenario+0x7b
b19c2d08 805cf6e9 890dd608 e1a80f20 00000000 nt!CcPfBeginAppLaunch+0x158
b19c2d50 805460ce 00000000 7c810867 00000001 nt!PspUserThreadStartup+0xeb
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
kd> r
eax=00000000 ebx=ba63e8ba ecx=00000000 edx=895ecc80 esi=88f3f520 edi=895fd020
eip=ba63e8cf esp=b19c285c ebp=b19c2860 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
Ntfs!NtfsAcquireForCreateSection+0x15:
ba63e8cf ff704c push dword ptr [eax+4Ch] ds:0023:0000004c=???
I have checked the previous in OSR, which said it may be caused by FsRtlRegisterFileSystemFilterCallbacks, after I add support for FsRtlRegisterFileSystemFilterCallbacks it still remains the same, in fact it even not enter into the routine of FsRtlRegisterFileSystemFilterCallbacks, so this may not be the reason.

The following are my FCB-Creating-Function:
PFCB
KsCreateNewFcb(
__in PFILE_OBJECT origFileObject,
__in PUNICODE_STRING fileFullName
)
{
PFCB Fcb = NULL;
PERESOURCE Resource;
FSRTL_COMMON_FCB_HEADER * origFcbHeader = origFileObject->FsContext;

Fcb = ExAllocatePoolWithTag( NonPagedPool, sizeof(FCB), ‘HFK’ );

if ( Fcb!=NULL )
{
// Init
RtlZeroMemory( Fcb, sizeof(FCB) );

Fcb->Header.NodeTypeCode = KS_NTC_FCB;
Fcb->Header.NodeByteSize = sizeof(FCB);

Resource = ExAllocatePoolWithTag( NonPagedPool, sizeof(ERESOURCE), ‘HFK’);
ExInitializeResourceLite( Resource );
Fcb->Header.Resource = Resource;

Resource = NULL;

Resource = ExAllocatePoolWithTag( NonPagedPool, sizeof(ERESOURCE), ‘HFK’);
ExInitializeResourceLite( Resource );
Fcb->Header.PagingIoResource = Resource;

// Initialize Advanced FCB Header fields
ExInitializeFastMutex( &Fcb->AdvancedFcbHeaderMutex );
FsRtlSetupAdvancedHeader( &Fcb->Header,
&Fcb->AdvancedFcbHeaderMutex );

Fcb->Header.AllocationSize.QuadPart = origFcbHeader->AllocationSize.QuadPart;
Fcb->Header.FileSize.QuadPart = origFcbHeader->FileSize.QuadPart - FS_HEADER_SIZE - FS_FILE_KEY_SIZE;
Fcb->Header.ValidDataLength.QuadPart = origFcbHeader->ValidDataLength.QuadPart - FS_HEADER_SIZE - FS_FILE_KEY_SIZE;

Fcb->Header.IsFastIoPossible = TRUE;

Fcb->Header.Flags = FSRTL_FLAG_ADVANCED_HEADER;
Fcb->Header.Flags2 = FSRTL_FLAG2_SUPPORTS_FILTER_CONTEXTS;

Fcb->FileName.Length = 0;
Fcb->FileName.MaximumLength = NT_FILENAMELEN * sizeof(WCHAR);
Fcb->FileName.Buffer = ExAllocatePoolWithTag( NonPagedPool, NT_FILENAMELEN * sizeof(WCHAR), ‘HFK’);
RtlCopyUnicodeString( &Fcb->FileName, fileFullName );

Fcb->ReferenceCount = 0;

// Add to fcbQueue
KeEnterCriticalRegion();
ExAcquireResourceExclusiveLite(&fcbQueue.hashResource, TRUE);

Fcb->next = fcbQueue.hashTable[HASHNAME(fileFullName)];
fcbQueue.hashTable[HASHNAME(fileFullName)] = Fcb;

ExReleaseResourceLite(&fcbQueue.hashResource);
KeLeaveCriticalRegion();
}

return Fcb;
}

Can anyone help me? Any help will be much appreciated!

> Now I’m trying to create a shadow file object(with FltCreateFile) to do

the real read/write operation and substitue the origin FCB with my own
created one

If you mean:

CreateLowerFile(&OutHandle, &OutFileObject);

OutFileObject->FsContext = MakeMyFCB(Data, FltObjects);

Then you cannot do that. You own FltObjects->FileObject->FsContext and
FltObjects->FileObject->FsContext2 and can put whatever you want in there
(within certain restrictions), but OutFileObject isn’t your structure.

R

No No, I do not mean that.
What I did is to substitue FltObjects->FileObject->FsContext with my own created one.
In fact, after debugging I found that the bug was caused by FsContext+48h(Ntfs!NtfsAcquireForCreateSection+0x15), it is zero value in my own created SCB/FCB.
I know that the header of FsContext is filled with FSRTL_ADVANCED_FCB_HEADER, but what was the member in FsContext+48h(SCB+48h)? How can this bug occured?
I need some help!

I think this kind of request should be caught by FsRtlRegisterFileSystemFilterCallbacks, but as I have mentioned, I have add support functions by using FsRtlRegisterFileSystemFilterCallbacks, but it seems not taking effects… I don not know why

What Rod is referring to is that if you swap out the FsContent pointers
in a file object with your own then you need to swap them back to the
underlying file systems before the file object is passed down the stack.
From your stack crash, it appears that you have sent a file object down
the stack which contains your FsContext pointer … though I’m surprised
the crash didn’t occur in the decoding routine.
Or if you setup the FsContext pointer in the file object then you need
to handle ALL requests for that file object and NOT pass it down to the
underlying file system … ever.

Pete

On 9/15/2014 7:55 AM, xxxxx@serpurity.com wrote:

No No, I do not mean that.
What I did is to substitue FltObjects->FileObject->FsContext with my own created one.
In fact, after debugging I found that the bug was caused by FsContext+48h(Ntfs!NtfsAcquireForCreateSection+0x15), it is zero value in my own created SCB/FCB.
I know that the header of FsContext is filled with FSRTL_ADVANCED_FCB_HEADER, but what was the member in FsContext+48h(SCB+48h)? How can this bug occured?
I need some help!


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

Yes, Peter. I have the same thought.
So as I have mentioned, I added support for FsRtlRegisterFileSystemFilterCallbacks, which I think should be responsible for handling the requests in the current circumstance.
But it seems FsRtlRegisterFileSystemFilterCallbacks doesn’t take effects, I just don’t know why.

You are a mini-filter, correct? If you are taking ownership of
fileobjects; i.e. setting up your own SOP and FsContext/2 pointers, then
you should register for ALL possible callbacks in the mini-filter
registration structure. This will provide you everything you need
including the callbacks for the FsRtlRegisterFileSystemFilterCallbacks()
API …

Pete

On 9/15/2014 7:06 PM, xxxxx@serpurity.com wrote:

Yes, Peter. I have the same thought.
So as I have mentioned, I added support for FsRtlRegisterFileSystemFilterCallbacks, which I think should be responsible for handling the requests in the current circumstance.
But it seems FsRtlRegisterFileSystemFilterCallbacks doesn’t take effects, I just don’t know why.


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

Thanks Peter :slight_smile:
I have fixed this problem, I should have register for ALL possible callbacks in the mini-filter instead of using FsRtlRegisterFileSystemFilterCallbacks.
Thanks for your help again!