Re[2]: Win10 x64 PreSetInfo cannot block DELETE operation ?

Peter_Scott · May 16, 2016, 8:53am

Have you confirmed that the system is not preforming a rename? How are
you testing the delete processing in your setup?

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: xxxxx@yahoo.com
To: “Windows File Systems Devs Interest List”
Sent: 5/16/2016 3:23:46 AM
Subject: RE:[ntfsd] Win10 x64 PreSetInfo cannot block DELETE operation ?

>Gabriel, the DELETE sample also does not consists any
>STATUS_ACCESS_DENIED operation under pre-create operation.
>
>I have tracked DELETE signal and returned STATUS_ACCESS_DENIED on
>pre-create(), pre-setinfo()operation based on:
>
>Data->Iopb->Parameters.Create.Options & FO_DELETE_ON_CLOSE
>
>FltObjects->FileObject->Flags & FO_DELETE_ON_CLOSE
>
>IS_DELETE_OPERATION( Data )
>
>WHERE IS_DELETE_OPERATION() is:
>#define IS_DELETE_OPERATION(Data) ( ( Data->Iopb->MajorFunction ==
>IRP_MJ_SET_INFORMATION ) &&
>( Data->Iopb->Parameters.SetFileInformation.FileInformationClass ==
>FileDispositionInformation ) &&
>( ( (
>PFILE_DISPOSITION_INFORMATION)Data->Iopb->Parameters.SetFileInformation.InfoBuffer)->DeleteFile
>) )
>
>However, none of this can block the DELETE operation under both Windows
>10 x64 and x86.
>
>I am running out of solution or idea.
>
>Please adivse.
>
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>

Scott_Noone_OSR · May 16, 2016, 8:59am

FO_DELETE_ON_CLOSE != FILE_DELETE_ON_CLOSE, you’re checking the wrong flag.

I highly suggest adding traces or breakpoints to your code and making sure
you’re actually hitting the code paths that you’re expecting.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Scoot,

Yes I have detected FILE_DELETE_ON_CLOSE with the following method:

if( Data->Iopb->Parameters.Create.Options & FO_DELETE_ON_CLOSE )

and returned with the following at PreCreate() operation:

if( !FlagOn( Data->Iopb->IrpFlags, IRP_PAGING_IO ) )
{
Data->IoStatus.Status = STATUS_ACCESS_DENIED;
Data->IoStatus.Information = 0;
return FLT_PREOP_COMPLETE;
}

Moreover, I traced through using SysInternals ProcMon and the result of
FDOC=FILE_DELETE_ON_CLOSE only available once at:

https://www.dropbox.com/sc/gcqh05ghqqegw0k/AADNAl6JbPGHh8nkJx6bpNwBa

Gabriel,

Which DELETE sample from Microsoft, any reference link will be appreciated.

Please advise.

RICKY_GAI · May 17, 2016, 10:32pm

Hi Scott,

Yes, I did use the following RENAME method for checking:

Under pre_setinfo():

#define IS_SETINFO_RENAME_OPERATION(Data) ( ( Data->Iopb->MajorFunction == IRP_MJ_SET_INFORMATION ) && \
( Data->Iopb->Parameters.SetFileInformation.FileInformationClass == FileRenameInformation ) )

…and the FDOC method under pre_create():

#define IS_CREATE_FDOC_OPERATION(Data) ( ( Data->Iopb->MajorFunction == IRP_MJ_CREATE ) && \
( Data->Iopb->Parameters.Create.Options & FILE_DELETE_ON_CLOSE ) )

…lastly on pre_setinfo(), pre_create() and post_create():

if( FltObjects->FileObject->Flags & FO_DELETE_ON_CLOSE )

The result still the same, I will try to focus on RENAME methods, do you have any other ways
to detect RENAME operation ?

Please advise.

RICKY_GAI · May 18, 2016, 3:51am

Scott,

I noticed there is no pre_setinfo() called when I right click on a file and select “delete” option from the shell menu on the desktop screen.

However, when I single click and do a rename, the signal is sent to pre_setinfo() and IS_SETINFO_RENAME_OPERATION(Data) is TRUE.

I am not sure why under Windows 10, there is no pre_setinfo() when I try to delete a file.

Please advise.

Scott_Noone_OSR · May 18, 2016, 9:50am

Run some FileSpy or Process Monitor traces and analyze the behavior of the
shell during delete and shift+delete operations. You’re missing something.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Hi Scott,

Yes, I did use the following RENAME method for checking:

Under pre_setinfo():

#define IS_SETINFO_RENAME_OPERATION(Data) ( ( Data->Iopb->MajorFunction ==
IRP_MJ_SET_INFORMATION ) && \
( Data->Iopb->Parameters.SetFileInformation.FileInformationClass ==
FileRenameInformation ) )

…and the FDOC method under pre_create():

#define IS_CREATE_FDOC_OPERATION(Data) ( ( Data->Iopb->MajorFunction ==
IRP_MJ_CREATE ) && \
( Data->Iopb->Parameters.Create.Options & FILE_DELETE_ON_CLOSE ) )

…lastly on pre_setinfo(), pre_create() and post_create():

if( FltObjects->FileObject->Flags & FO_DELETE_ON_CLOSE )

The result still the same, I will try to focus on RENAME methods, do you
have any other ways
to detect RENAME operation ?

Please advise.

OSR_Community_User · May 18, 2016, 11:44am

This is because the behavior of how file deletion is done change (Windows 8?) - rather than open/set information/close the sequence is now open-with-delete-on-close/close.

Look to see if you observe FILE_DELETE_ON_CLOSE specified in the create path.

Tony

RICKY_GAI · May 19, 2016, 5:24am

Tony,

I detected FILE_DELETE_ON_CLOSE at pre_create() stage and return a STATUS_ACCESS_DENIED and FLT_PREOP_COMPLETE, still cannot stop
Win10 from deleting a file.

I try to set DeleteFile to FALSE at pre_create() using FltSetInformationFile()
but FltSetInformationFile() returns a STATUS_INVALID_PARAMETER.

I understand, this question had been reviewed before in the past at this forum such as:
http://www.osronline.com/showthread.cfm?link=221932

However, it is happening on Windows 10 currently, not sure the same solution based on
link above still works.

Please advise.

Scott_Noone_OSR · May 19, 2016, 9:36am

Did you run Process Monitor or FileSpy and look at the output?

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Tony,

I detected FILE_DELETE_ON_CLOSE at pre_create() stage and return a
STATUS_ACCESS_DENIED and FLT_PREOP_COMPLETE, still cannot stop
Win10 from deleting a file.

I try to set DeleteFile to FALSE at pre_create() using
FltSetInformationFile()
but FltSetInformationFile() returns a STATUS_INVALID_PARAMETER.

I understand, this question had been reviewed before in the past at this
forum such as:
http://www.osronline.com/showthread.cfm?link=221932

However, it is happening on Windows 10 currently, not sure the same solution
based on
link above still works.

Please advise.

RICKY_GAI · May 19, 2016, 5:51pm

Scott,

Yes, I captured using ProMon and the result is at:

https://www.dropbox.com/sc/l1vak3dhskf8bsx/AABpOdbqqbDodnRjZULgBDMsa

Where, the file to prevent from being deleted is “License Agreement.txt”.

OSR_Community_User · May 19, 2016, 6:05pm

I see “Delete On Close” and then “SUCCESS” in this trace. Then the subsequent attempts to open the file fail, so it appears to have been successful.

So it doesn’t look like you are refusing the FILE_DELETE_ON_CLOSE option.

Tony

RICKY_GAI · May 20, 2016, 3:51am

Tony, here is the snapshot captured with STATUS_ACCESS_DENIED.

https://www.dropbox.com/sc/qq6udemulv0fnpu/AACe6e5G7bXia7Dcl_Wyv-raa

RICKY_GAI · May 20, 2016, 4:39am

Tony, the complete file deletion events captured with STATUS_ACCESS_DENIED is imported as EXCEL file below:

https://www.dropbox.com/s/qzrf9vi8blqri43/Windows%2010%20-%20Sysinternal%20ProcMon%20operation%20captured%20on%20deleting%20a%20file%20with%20STATUS_ACCESS_DENIED.xlsx?dl=0

RICKY_GAI · May 20, 2016, 5:04am

…to remark, the file is deleted immediately after the Credential Prompt is granted.

RICKY_GAI · May 20, 2016, 5:10am

…if without the minifilter activated, the file is deleted straight away without Credential Prompt dialog pops up.

RICKY_GAI · May 20, 2016, 5:22am

…this is the ProcMon result after Credential Prompt dialog is granted with minifilter is turned ON.

https://www.dropbox.com/sc/1uq6tekca79nna2/AADGYZyGSvyogq1KfYZ5ar5ea

I am not sure why the last CreateFile with Options DeleteOnClose can pass through the filter driver after Credential UAC Prompt is granted under Windows 10 ?

OSR_Community_User · May 20, 2016, 11:10am

Given that it is your filter driver, I can’t tell you either. What is your criteria for rejecting the delete on close request?

Tony
OSR

RICKY_GAI · May 24, 2016, 2:28am

Tony & Scott,

I just resolved the issues as when deleting a file under Windows 10 via SHELL context menu Delete option, immediately after the UAC Credential Prompt is granted, I found out kernel detects the behavior with abbreviation as shown below:

fdoc=FILE_DELETE_ON_CLOSE flag.
exec=FILE_EXECUTE flag.

When right click and clicked the “Delete” option from shell context menu on a file (“License Agreement.txt” ).
pre_create(): fdoc=[1] exec=[0] \windows\explorer.exe —> \demo\readonly\license agreement.txt
Windows 10 pops up UAC Credential Prompt and clicked OK to grant:
pre_create(): fdoc=[0] exec=[1] \windows\system32\svchost.exe —> \windows\system32\dllhost.exe
pre_create(): fdoc=[1] exec=[0] \windows\system32\dllhost.exe —> \demo\readonly\license agreement.txt

Is my programming mistake that skipped any caller from \windows\system32\ where initially my intention was not to touch any caller application from windows\system32.

I am not sure this filtering method is efficient but it does work as expected via the same rejection method eg. STATUS_ACCESS_DENIED.

If there is any further comments or suggestions, I am ok to hear from it.

Thank you.