Информация об изменениях

Сообщение FS Minifilter, IRP_MJ_CREATE. Кривой FileName? от 08.01.2018 5:21

Изменено 08.01.2018 5:31 sergey77666

FS Minifilter, IRP_MJ_CREATE. Кривой FileName?
Примерно такой код
FLT_POSTOP_CALLBACK_STATUS PostFileOperationCallback ( IN OUT PFLT_CALLBACK_DATA Data, 
                IN PCFLT_RELATED_OBJECTS FltObjects, 
                IN PVOID CompletionContext, 
                IN FLT_POST_OPERATION_FLAGS Flags) {
..
FILE_OBJECT pFileObject;
PWCHAR bufPFO = NULL; 
..
if (Data != NULL && Data->Iopb != NULL && !(Data->Iopb->Parameters.Create.Options & FILE_DIRECTORY_FILE)) {
            
            if (Data->Iopb->TargetFileObject != NULL)
            {
                pFileObject = *Data->Iopb->TargetFileObject;
                if (Data->IoStatus.Information == FILE_CREATED && pFileObject.FileName.Length > 0)
                {
                    ..
                    bufPFO = (PWCHAR)ExAllocatePoolWithTag(NonPagedPool, sizeof(WCHAR) * 1024, 'NC__');
                    for (iii = 0; iii < 1024; iii++)
                    {
                        bufPFO[iii] = 0;
                    }
                    res = RtlStringCchPrintfW(bufPFO, 1024, L"%wZ", pFileObject.FileName);


И вот на этом самом месте, где RtlStringCchPrintfW, иногда происходит ерунда. Обычно это было, когда я запускал Edge и пытался им скачать и запустить ChromeSetup.exe
То BSOD, то buffer overflow (хотя 1024 — это ведь даже много для пути к файлу, да и перед этим он логируется и видно, что там отнюдь не столько.

Какие есть мысли:
— разве что в след. раз посмотреть, не в нехватки ли оперативки проблема (это виртуалка, есть такое подозрение)
— ну, и проверить, что в этом самом pFileObject.FileName, взять его Buffer до \0 и попробовать обойтись без RtlStringCchPrintfW

Есть что добавить?

Еще: бывало Access violation (в основном опять тот же Edge), в том же каллбеке, в самом конце, где нет буквально ничего, кроме
return FLT_POSTOP_FINISHED_PROCESSING;
к которому и приводят все ветви.
FS Minifilter, IRP_MJ_CREATE. Кривой FileName?
Примерно такой код
FLT_POSTOP_CALLBACK_STATUS PostFileOperationCallback ( IN OUT PFLT_CALLBACK_DATA Data, 
                IN PCFLT_RELATED_OBJECTS FltObjects, 
                IN PVOID CompletionContext, 
                IN FLT_POST_OPERATION_FLAGS Flags) {
..
FILE_OBJECT pFileObject;
PWCHAR bufPFO = NULL; 
..
if (Data != NULL && Data->Iopb != NULL && !(Data->Iopb->Parameters.Create.Options & FILE_DIRECTORY_FILE)) {
            
            if (Data->Iopb->TargetFileObject != NULL)
            {
                pFileObject = *Data->Iopb->TargetFileObject;
                if (Data->IoStatus.Information == FILE_CREATED && pFileObject.FileName.Length > 0)
                {
                    ..
                    bufPFO = (PWCHAR)ExAllocatePoolWithTag(NonPagedPool, sizeof(WCHAR) * 1024, 'NC__');
                    for (iii = 0; iii < 1024; iii++)
                    {
                        bufPFO[iii] = 0;
                    }
                    res = RtlStringCchPrintfW(bufPFO, 1024, L"%wZ", pFileObject.FileName);


И вот на этом самом месте, где RtlStringCchPrintfW, иногда происходит ерунда. Обычно это было, когда я запускал Edge и пытался им скачать и запустить ChromeSetup.exe
То BSOD, то buffer overflow (хотя 1024 — это ведь даже много для пути к файлу, да и перед этим он логируется и видно, что там отнюдь не столько.

Какие есть мысли:
— разве что в след. раз посмотреть, не в нехватки ли оперативки проблема (это виртуалка, есть такое подозрение)
— ну, и проверить, что в этом самом pFileObject.FileName, взять его Buffer до \0 и попробовать обойтись без RtlStringCchPrintfW

Есть что добавить?
Можно вообще вот так напрямую пихать этот pFileObject.FileName в PWCHAR или UNICODE_STRING?

Еще: бывало Access violation (в основном опять тот же Edge), в том же каллбеке, в самом конце, где нет буквально ничего, кроме
return FLT_POSTOP_FINISHED_PROCESSING;
к которому и приводят все ветви.