First a little background. There are two devices that don’t talk to one another properly. One device writes data to a file while the other device is supposed to ingest it. Problem is, the ingesting device requires a certain format (basically XML) while the outputting device just writes raw data.
So I need to bridge the gap by modifying the data the ingesting process reads in. While there are simpler methods to bridge these devices there are some other considerations why this is the route I’m going.
I’ve created a minifilter that changes EOF, VDL, and allocation sizes in IRP_MJ_QUERY, IRP_MJ_NET_QUERY_OPEN, and IRP_MJ_DIR_CONTROL to take into account this new XML data for the ingesting process. But during testing, I’m getting some strange results during IRP_MJ_READ.
First, normal reading.
IRP_MJ_QUERY_INFORMATION QueryStandardInformationFile, AllocationSize: 32, EndOfFile: 26
IRP_MJ_READ Offset: 0, Length: 26, Priority: Normal
With the filter loaded.
IRP_MJ_QUERY_INFORMATION QueryStandardInformationFile, AllocationSize: 512, EndOfFile: 224
IRP_MJ_READ Offset: 144, Length: 65,536, Priority: Normal
The sizes are changed but when the first read comes in, the parameters don’t make sense. So I’m either missing some query or the cache is causing a problem. Which takes me to the subject question. Is this design possible without an isolation filter? If it is, any thoughts on what I may be missing?
I’m glad you said it before I did My mind is racing with different ways
to solve this, but I’ll put that on hold for the moment.
So, just to be clear, the raw version of the file is 26 bytes and your XML’d
version is 224 bytes?
Process Monitor should tell you if you’re capturing all the relevant
queries. If the change in Offset is strange, but my two guesses at this
point:
Are you accidentally updating the CurrentBytesOffset field of the File
Object? For example, this could happen if you use the application’s
synchronous File Object for I/O to the lower file system
Do you have the application source code? Maybe it treats files
differently if they have particular sizes? (A stretch, but not unheard of if
there’s a structure to the file)
If the application that you’re trying to fool memory maps the file then you
need Isolation. if it just does ReadFile then you can probably get away with
faking the sizes and changing the buffer returned to the application.
Presumably you just need to tack on some XML elements at the start of the
file and at the end, correct?
I?d put a write access breakpoint on the CurrentByteOffset field and see if it?s changing. Like I said, even if you?re not directly modifiying it you could be accidentally modifying it.
Also, have you tried just reading the file yourself using FileTest? That would tell you if it?s an app sensitivity issue or something in general that you?re messing up.
Thanks for your help Scott. Turns out the app I was using to test the filter does some stupid offset calculation so the value I was getting was the actual value sent from the app. Took a while to figure out that it wasn’t my filter though. Breakpoints on CBO did nothing. Other apps, like notepad and wordpad, worked perfectly so I thought I was missing some esoteric EOF/Position/VDL update path but ProcMon wasn’t showing anything unusual. Finally dug into the app’s code and saw what it was doing. Probably should of done that first to avoid the aggravation.
My mind is racing with different ways