研究过滤加密的标志问题.

  小弟还在研究 TooFlat 的加密程序,由于愚笨.有点东西总是搞不懂!请大家指点 .
    //
    // Initialize some useful variables
    //
    ExInitializeFastMutex(&NewDevExt->FsCtxTableMutex);
    RtlInitializeGenericTable(&NewDevExt->FsCtxTable,
        SfGenericCompareRoutine,
        SfGenericAllocateRoutine,
        SfGenericFreeRoutine,
        NULL
        );
创建这个内核表
        SfGenericCompareRoutine, 比较函数
        SfGenericAllocateRoutine,   分配函数
        SfGenericFreeRoutine,        释放函数
用这个表存储

typedef struct _FILE_CONTEXT_HDR
{
    PVOID FsContext;
} FILE_CONTEXT_HDR, *PFILE_CONTEXT_HDR;

typedef struct _FILE_CONTEXT
{
    FILE_CONTEXT_HDR;

    ULONG RefCount;
    BOOLEAN DecryptOnRead;
    BOOLEAN EncryptOnWrite;
    BOOLEAN EncryptFlagExist; // if encrypt flag file exists, then the file is

encrypted
    BOOLEAN NeedEncrypt;
    BOOLEAN DeleteOnClose;
    KEVENT Event;
    WCHAR Name[MAX_PATH];
    UCHAR EncryptExtData[ENCRYPT_BIT_SIZE / sizeof(UCHAR)];
} FILE_CONTEXT, *PFILE_CONTEXT;

PFILE_CONTEXT FileCtxPtr = NULL;
FileCtxPtr->FsContext = FileObject->FsContext;
上面的结构里面没有FsContext  这个变量哦.
只有 FILE_CONTEXT_HDR 有这个变量.有点蒙

使用 这个 添加一个元素
FileCtxPtr2 = RtlInsertElementGenericTable(
                    &DevExt->FsCtxTable,
                    FileCtxPtr,
                    sizeof(FILE_CONTEXT),
                    &NewElement
                    );


RtlDeleteElementGenericTable(
                    &DevExt->FsCtxTable,
                    Element
                    );
使用中遇到
需要加密，已加密，无标志

需要加密 ，没有加密 没有标志

需要加密 ，未加密，有标志

不需要加密，被加密，无标志

FileCtxPtr->FsContext = FileObject->FsContext;
是从文    PIO_STACK_LOCATION IrpSp = IoGetCurrentIrpStackLocation(Irp);
FileObject = IrpSp->FileObject; 得到了 这里面 FsContext;
 是做什么? 快表 为什么要用这个作判断呀? 她能确保标志文件的唯一性吗?

问题的原因 完全是，后的文件全路径的问题。
正在解决ing

最后发现是  
    FileCtxPtr2 = RtlLookupElementGenericTable(&DevExt->FsCtxTable, FileCtxPtr);
            if (FileCtxPtr2){

                KdPrint(("sfilter!SfCreate: Find a it = \r\n%wZ\n%ws \n%d\n",&FileObject->FileName, FileCtxPtr2->Name,FileCtxPtr2->RefCount));

                if(FileName)
                    wcscpy(FileCtxPtr2->Name, FileName);
                    
                ++FileCtxPtr2->RefCount;

            }
            else
            {
                FileCtxPtr2 = RtlInsertElementGenericTable(
                    &DevExt->FsCtxTable,
                    FileCtxPtr,
                    sizeof(FILE_CONTEXT),
                    &NewElement
                    );

                if(FileCtxPtr2 > 0){
                    FileCtxPtr2->RefCount = 1;

//                    ASSERT(FileName);
                    if(FileName)
                        wcscpy(FileCtxPtr2->Name, FileName);
                    else{
                    }

                    KeInitializeEvent(&FileCtxPtr2->Event, SynchronizationEvent, TRUE);
                }
            }
如果是 从 块表里面查出来的 FileCtxPtr2->FileName，其文件名 和 sfCreate 打开的文件名 不一样 。
但是使用同一个 FileObject->FsContext; 查出来的 。怎么不同呢？
从而导致加密标志混乱，如何能解决 在保证文件 FileCtxPtr2指向正确的文件 位置， 在 sfClose时。当计数器
减为 0 时 ，
if ((0 == FileCtxPtr->RefCount)&&
(!FileObject->SectionObjectPointer ||
(!FileObject->SectionObjectPointer->DataSectionObject &&
!FileObject->SectionObjectPointer->ImageSectionObject))){
        RtlDeleteElementGenericTable(&DevExt->FsCtxTable, &FileCtxHdr);
    }
}
其他的这些 有 一个为空 才能 释放 这个表项 。我测试很多  = 0 时。其他的都不为空 ，所以没有释放 。会不会这个指针。在某个时候被释放，然后使用到别的文件上。而且打开这个文件，有能查到 我们保存的信息，从而使我们 维护的 标志 信息混乱呢？
原因这些是 文件层  的 Cache 吗？
(!FileObject->SectionObjectPointer ||
(!FileObject->SectionObjectPointer->DataSectionObject &&
!FileObject->SectionObjectPointer->ImageSectionObject)
我如果忽略 这些 标志。发现写回去的 文件 部分混乱。是不是Cache导致的。

所以 如何使用良好的  内存表记录 需要加密的文件信息呢？  请指教哦 1

由于STREAM、FILE-MAPPING的情形，很多情况下条件：
(!FileObject->SectionObjectPointer ||
(!FileObject->SectionObjectPointer->DataSectionObject &&
!FileObject->SectionObjectPointer->ImageSectionObject))

是不成立的！

以下来自OSR的内容：

Q: I see the user close the file. My filter receives an IRP_MJ_CLEANUP. But I never see the IRP_MJ_CLOSE? Why not?
The purpose of IRP_MJ_CLEANUP is to indicate that the last handle reference against the given file object has been released. The purpose of IRP_MJ_CLOSE is to indicate that the last system reference against the given file object has been released. This is because the operating system uses two distinct reference counts for any object, including the file object. These values are stored within the object header, with the HandleCount representing the number of open handles against the object and the PointerCount representing the number of references against the object. Since the HandleCount always implies a reference (from a handle table) to the object, the HandleCount is less than or equal to the PointerCount.

Any kernel mode component may maintain a private reference to the object. Routines such as ObReferenceObject, ObReferenceObjectByHandle, and IoGetDeviceObjectPointer all bump the reference count on a specific object. A kernel mode driver releases that reference by using ObDereferenceObject to decrement the PointerCount on the given object.

A file system, or file system filter driver, will often see a long delay between the IRP_MJ_CLEANUP and IRP_MJ_CLOSE because a component within the operating system is maintaining a reference against the file object. Frequently, this is because the memory manager maintains a reference against a file object that is backing a section object. So long as the section object remains "in use" the file object will be referenced. Section objects, in turn, remain referenced for extended periods of time because they are used by the memory manager in tracking the usage of memory for file-backed shared memory regions (e.g., executables, DLLs, memory mapped files). For example, the cache manager uses the section object as part of its mappings of file system data within the cache. Thus, the period of time between the IRP_MJ_CLEANUP and the IRP_MJ_CLOSE can be arbitrarily long.

The other complication here is that the memory manager uses only a single file object to back the section object. Any subsequent file object created to access that file will not be used to back the section and thus for these new file objects the IRP_MJ_CLEANUP is typically followed by an IRP_MJ_CLOSE. Thus, the first file object may be used for an extended period of time, while subsequent file objects have a relatively short lifespan.

3Q .帅哥 ！