You would not want to allocate a ‘stream handle’ context, this is a
context allocated for each handle associated to a file. Instead, based
on your requirements so far, you will want a ‘stream context’. So when
you call FltAllocateContext() you specify a FLT_STREAM_CONTEXT. This
will allocate 1 context for a given file or directory, independent of
how many times it is opened. There is plenty of documentation on the
differences here.
Yes, post read callback for non-cached (including paging) IO. You will
know the offset because it is part of the information provided for the
read so if you know the offset from your application, then you will know
if this read contains it. But I feel you have a catch 22 here … if
your application is going to read the file to determine where the offset
of the KOKO string is but your filter is going to modify the content,
then it is possible your application will pull the KOKO string into the
system cache, depending on how the IO is issued. There are some issues
here you need to consider in terms of how your application is operating.
That said, if your user mode application is just scanning the content of
the file for the KOKO string to determine the offset, then why not just
have your filter driver scan the read buffers for the KOKO string and
perform a replacement of it? Of course this will impact performance but
at this point it sounds like you just want to get a PoC in place?
You will also need to handle pre-write, again non-cached, so the KOKO
can be updated with KEKE before getting written to disk.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
------ Original Message ------
From: “Bekir Karul”
To: “Windows File Systems Devs Interest List”
Sent: 5/3/2017 9:57:00 AM
Subject: Re: [ntfsd] How to detect if callbacks already called beforefor
this I/O?
>Hello Pete,
>
>Thank you very much for your reply.
>
>So I assume that checking for if this file already have a stream
>handle context would be enough in post-create. If it is already have
>one, so I don’t need to ask user mode for string offset again.
>
>I’m not sure if I could clearly tell what I’m trying to do. So let me
>give another example. Think that there is a file named “bpe.bbdk”. This
>file have a “KOKO” string somewhere inside it. If I open this file with
>my application, my application sees that “KOKO” string in file and pop
>up a message box and says “Heey! I got KOKO”. This string can be
>anywhere on file. So that is why I’m asking to user mode application
>for detect where it is exactly. Then, my mini-filter will use this
>offset, and catch when this offset is read. At the moment it catch it,
>it will modify read buffer (at least I hope so) and change “KOKO” to
>"KEKE.
>
>So we can say that if my mini-filter is installed on system, there will
>be no message box because mini-filter will change that string. But if
>there is no mini-filter, my application will see “KOKO” and pop up
>message box.
>
>I thought that I can modify read buffer in post-read callback. Pete, am
>I right about that? Can I see read buffer in post-read callback, and
>change it as I wanted?
>
>If so, how it can be possible to catch when that exact offset is
>reading?
>
>Thank you again for spending your valuable time with answering my
>questions.
>
>Best regards…
>
>03.05.2017, 18:35, “PScott” :
>>
>>1) Assuming you are creating a stream context, then your call to
>>FltGetStreamContext() in post-create will return STATUS_NOT_FOUND if
>>you have not created a context for the given file yet. Here you would
>>initialize and insert the stream context.
>>
>>2) You probably want to handle all non-cached (including paging here
>>of course) read/write requests. For the read processing, you would
>>modify the data in post-read to return the ‘KEKE’ string. For write
>>requests, you would handle the data in pre-write, ensuring that the
>>‘KOKO’ is stored on disk.
>>
>>3) Doing as prescribed in 2), the cache would contain the ‘KEKE’
>>string but on disk it would always contain ‘KOKO’.
>>
>>Pete
>>
>>–
>>Kernel Drivers
>>Windows File System and Device Driver Consulting
>>www.KernelDrivers.com
>>866.263.9295
>>
>>
>>
>>------ Original Message ------
>>From: “Bekir Karul”
>>To: “Windows File Systems Devs Interest List”
>>Sent: 5/3/2017 8:58:21 AM
>>Subject: [ntfsd] How to detect if callbacks already called beforefor
>>this I/O?
>>
>>>Hello there!
>>>
>>>I’m working on a mini-filter driver which changes a same size value
>>>in my application spesific file. Let me explain what I’m trying to
>>>archieve a bit. My user-mode application uses some files for handling
>>>it’s own data. This files have a extension “bbkd”. In these “bbkd”
>>>files, I have a fixed size string about this file. Let say it is
>>>“KOKO”. I want to make this “KOKO” to “KEKE” when it reads by any
>>>application only in memory. So it will still same on disk. So I
>>>tought that It would be fine if I can catch this read and change
>>>“KOKO” to “KEKE”.
>>>
>>>For this reason, I’ve registered both pre create, post create and
>>>post read callbacks. In pre-create callback, I check file extension,
>>>if it is “bbdk” I return PRE_SUCCESS_WITH_CALLBACK so my post-create
>>>callback catchs this I/O operation. In post-create callback, I send a
>>>message to my user-mode application and ask for “Hey, where that
>>>spesific string is stored? Please return me it’s offset”. She returns
>>>offset value to me and I create a stream handle context and store
>>>that offset value in there.
>>>
>>>OK, Here is where I stuck, and I have three question.
>>>
>>>1-) As far as I can see I’ve got several pre-create callback for my
>>>“hello.bbdk” file. But I guess only one of them is enough for getting
>>>offset value. What can I do about this? Hmm, can I test if this file
>>>already have a context, if so I pass it, if not so I need to handle
>>>it again?
>>>2-) Is post-write is right place for changing “KOKO” to “KEKE”? If
>>>so, what kind of a way I should follow?
>>>3-) I just want to change “KOKO” to “KEKE” when xxx.bbdk file read,
>>>so it does not have to be written to file. So what about cache? Is
>>>anything can go wrong with cache in this situation?
>>>
>>>Best regards…
>>>— NTFSD is sponsored by OSR MONTHLY seminars on crash dump
>>>analysis, WDF, Windows internals and software drivers! Details at To
>>>unsubscribe, visit the List Server section of OSR Online at
>>
>>—
>>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:
>— NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
>WDF, Windows internals and software drivers! Details at To unsubscribe,
>visit the List Server section of OSR Online at</http:></http:>
