Missing some IRP_MJ_* operations

NTFSD
1

I’m doing a project to familiar myself to writing windows drivers, so I wrote a minifilter driver which tries to catch every IO operation related to files.

Now I have two questions that probably related:

I’m monitoring IRP_MJ_{CREATE, WRITE, READ, SET_INFORMATION}.

Within the pre-operation callback I have something like:

if (FltObjects->FileObject != NULL && STATUS_SUCCESS == FltGetFileNameInformation(Data, FLT_FILE_NAME_OPENED, &nameInfo)) {
//Do my things here and return FLT_PREOP_SUCCESS_WITH_CALLBACK
}

else {
return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

The problem is that for the bellow C# code, I dont get the information I expect probably becase the if statement is not satisfied.

The C# code snipped in question:

private static void EncryptFile(SymmetricAlgorithm alg, string inputFile, string outputFile)
{
var buffer = new byte[65536];

using (var streamIn = new FileStream(inputFile, FileMode.Open))
using (var streamOut = new FileStream(outputFile, FileMode.Create))
using (var encrypt = new CryptoStream(streamOut, alg.CreateEncryptor(), CryptoStreamMode.Write))
{
int bytesRead;
do
{
bytesRead = streamIn.Read(buffer, 0, buffer.Length);
if (bytesRead != 0)
encrypt.Write(buffer, 0, bytesRead);
}
while (bytesRead != 0);
}
}

Do you have an idea why this can happen?

I use FltReadFile both in pre and post operation callbacks, the requirement for it is IRQL = LEVEL_PASIVE

However, nothing promises me that my callbacks run in IEQL = LEVEL_PASIVE

What can I do about it?

2

I would check for the return codes in the driver. You should probably do
your work in the POST Create operation most of the times not PRE because in
the PRE create there is no FILE_OBJECT structure that is opened by the
filesystem below.
The file object you get in PRE-Create has no FCB and does not “link” to
anything the filesystem recognizes YET, only until after a successful open
un thus post Create.
For all the other operations I am not sure what you want to achieve so both
pre and post are OK.
You FltGetFileNameInformation therefore will itself have to open the file
to query the name in the pre Create.

Also you could just attach a debugger and put a breakpoint on the running
C# process in your filter registered callbacks.

Gabriel.
www.kasardia.com

On Wed, Dec 13, 2017 at 9:58 PM, Naftaly Avadiaev <
xxxxx@gmail.com> wrote:

> I’m doing a project to familiar myself to writing windows drivers, so I
> wrote a minifilter driver which tries to catch every IO operation related
> to files.
>
>
>
> Now I have two questions that probably related:
>
>
>
>
>
> 1.
>
> I’m monitoring IRP_MJ_{CREATE, WRITE, READ, SET_INFORMATION}.
>
>
>
> Within the pre-operation callback I have something like:
>
>
>
> if (FltObjects->FileObject != NULL && STATUS_SUCCESS ==
> FltGetFileNameInformation(Data, FLT_FILE_NAME_OPENED, &nameInfo)) {
>
> //Do my things here and return FLT_PREOP_SUCCESS_WITH_
> CALLBACK
>
> }
>
>
>
> else {
>
> return FLT_PREOP_SUCCESS_NO_CALLBACK;
>
> }
>
>
>
> The problem is that for the bellow C# code, I dont get the information I
> expect probably becase the if statement is not satisfied.
>
>
>
>
>
> The C# code snipped in question:
>
>
>
> private static void EncryptFile(SymmetricAlgorithm alg, string inputFile,
> string outputFile)
>
> {
>
> var buffer = new byte[65536];
>
>
>
> using (var streamIn = new FileStream(inputFile, FileMode.Open))
>
> using (var streamOut = new FileStream(outputFile,
> FileMode.Create))
>
> using (var encrypt = new CryptoStream(streamOut,
> alg.CreateEncryptor(), CryptoStreamMode.Write))
>
> {
>
> int bytesRead;
>
> do
>
> {
>
> bytesRead = streamIn.Read(buffer, 0, buffer.Length);
>
> if (bytesRead != 0)
>
> encrypt.Write(buffer, 0, bytesRead);
>
> }
>
> while (bytesRead != 0);
>
> }
>
> }
>
>
>
>
>
> Do you have an idea why this can happen?
>
>
>
> 2.
>
> I use FltReadFile both in pre and post operation callbacks, the
> requirement for it is IRQL = LEVEL_PASIVE
>
>
>
> However, nothing promises me that my callbacks run in IEQL = LEVEL_PASIVE
>
>
>
> What can I do about it?
>
> —
> 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://www.osronline.com/page.cfm?name=ListServer&gt;
>

–
Bercea. G.</http:>