Buffer Problem in FilterReplyMessage

All,

I want my user mode service to pass back a variable length reply to a
kernel mode message sent by the Driver. the reply is variable length
because, depending on the length of the buffer sought by the driver in the
FltSendMessage, the service creats and fills the buffer with data and sends
back.

Now, after reading the documentation, I wrote the following code:

// This is the structure the user mode will fill up and send down to Driver
typedef struct _MY_REPLY_CONTEXT {

BOOLEAN bReadStatus; // Tells
whether the read was a success or not
PUCHAR pBUffer[1]; // Contains the
data sought by the Kernel
// Size of this
buffer is not required as
// we already
pass length in Request message

} MY_REPLY_CONTEXT, *PMY_REPLY_CONTEXT;

typedef struct _MY_REPLY_FROM_USERLAND_MESSAGE {

FILTER_REPLY_HEADER ReplyHeader; // Must be the first
member of this structure

MY_REPLY_CONTEXT Reply; // This is the reply
from user

} MY_REPLY_FROM_USERLAND_MESSAGE, *PMY_REPLY_FROM_USERLAND_MESSAGE;

In the user land thread…

ULONG Len = sizeof(MY_REPLY_CONTEXT) + pTranslationRequest->uLen; //
the pTranslationRequest->uLen was received from driver
ULONG TotalLen = sizeof(FILTER_REPLY_HEADER) + Len;

pReplyMessage = (PMY_REPLY_FROM_USERLAND_MESSAGE) malloc(TotalLen );

memset(pReplyMessage, 0, TotalLen );
pReplyMessage->ReplyHeader.Status = 0;
pReplyMessage->ReplyHeader.MessageId = pMessage->MessageHeader.MessageId;

pReplyMessage->Reply.bReadStatus = TRUE;
memcpy(pReplyMessage->Reply.pBUffer, pBuff, ullBytesRead); //ullBytesRead
is equal to pTranslationRequest->uLen, pBuff is legit, I saw the contents
in the debugger

hr = FilterReplyMessage( pTPCtx->hPort,
(PFILTER_REPLY_HEADER) pReplyMessage,
Len ); // since in scanner sample they say we
only need to pass the length of our portion of the structure

When this executes, in the driver the buffer is all junk.

Can some one please let me know what I am doing incorrectly.

thanks

ami

there are a few issues here…

In the FilterReplyMessage() you gotta send the Whole buffer length, that
is, in your example the variable Totallen.

Filter manager will remove the FILTER_REPLY_HEADER from the message when
you receive the reply back in your driver (which is waiting on
FltSendMessage() ).

So your FltSendMessage() in the driver will get back a pointer to
MY_REPLY_CONTEXT
(again, this is as per your example above). The length of the returned
buffer will be the same as calculated in ‘Len’ in your example.

All these said, the right way to write the FltSendMessage() in your driver
would be as follows:

ULONG Len = sizeof(MY_REPLY_CONTEXT) + pTranslationRequest->uLen; //
the pTranslationRequest->uLen was received from driver
ULONG TotalLen = sizeof(FILTER_REPLY_HEADER) + Len;

PVOID ReplyBuffer = ExAllocatePoolWithTag(NonPagelPool, TotalLen, MY_TAG);

NTSTATUS FltSendMessage(
pFilter,
&ClientPort,
SenderBuffer,
SenderBufferLength,// till this parameter I am ignoring as your
problem starts after this…
(PFILTER_REPLY_HEADER)ReplyBuffer,

TotalLen,
NULL // if you want to wait forever
);

Once you get status Success, check the TotalLen variable, (this is an
__inout variable , the Len should be equal to Len calculated above in the
example.

Once you get a status_success, do the following:

PMY_REPLY_CONTEXT pRepCtx = (PMY_REPLY_CONTEXT)ReplyBuffer;

This should nicely give you your variable length serialized structure with
the buffer back to you.

Hope this helps…

Let us know it it worked for you…

AB

On Wed, Apr 24, 2013 at 10:04 PM, Ami Awbadhho wrote:

> All,
>
> I want my user mode service to pass back a variable length reply to a
> kernel mode message sent by the Driver. the reply is variable length
> because, depending on the length of the buffer sought by the driver in the
> FltSendMessage, the service creats and fills the buffer with data and sends
> back.
>
> Now, after reading the documentation, I wrote the following code:
>
>
> // This is the structure the user mode will fill up and send down to Driver
> typedef struct _MY_REPLY_CONTEXT {
>
> BOOLEAN bReadStatus; // Tells
> whether the read was a success or not
> PUCHAR pBUffer[1]; // Contains
> the data sought by the Kernel
> // Size of
> this buffer is not required as
> // we already
> pass length in Request message
>
> } MY_REPLY_CONTEXT, *PMY_REPLY_CONTEXT;
>
>
> typedef struct _MY_REPLY_FROM_USERLAND_MESSAGE {
>
> FILTER_REPLY_HEADER ReplyHeader; // Must be the first
> member of this structure
>
>
> MY_REPLY_CONTEXT Reply; // This is the reply
> from user
>
> } MY_REPLY_FROM_USERLAND_MESSAGE, *PMY_REPLY_FROM_USERLAND_MESSAGE;
>
>
>
>
> In the user land thread…
>
> ULONG Len = sizeof(MY_REPLY_CONTEXT) + pTranslationRequest->uLen; //
> the pTranslationRequest->uLen was received from driver
> ULONG TotalLen = sizeof(FILTER_REPLY_HEADER) + Len;
>
>
> pReplyMessage = (PMY_REPLY_FROM_USERLAND_MESSAGE) malloc(TotalLen );
>
> memset(pReplyMessage, 0, TotalLen );
> pReplyMessage->ReplyHeader.Status = 0;
> pReplyMessage->ReplyHeader.MessageId = pMessage->MessageHeader.MessageId;
>
> pReplyMessage->Reply.bReadStatus = TRUE;
> memcpy(pReplyMessage->Reply.pBUffer, pBuff, ullBytesRead); //ullBytesRead
> is equal to pTranslationRequest->uLen, pBuff is legit, I saw the contents
> in the debugger
>
> hr = FilterReplyMessage( pTPCtx->hPort,
> (PFILTER_REPLY_HEADER) pReplyMessage,
> Len ); // since in scanner sample they say we
> only need to pass the length of our portion of the structure
>
>
> When this executes, in the driver the buffer is all junk.
>
>
> Can some one please let me know what I am doing incorrectly.
>
> thanks
>
> ami
>
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file system
> seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer



- ab

Hi amit,

thanks for the detailed info. yes this works and solves my problem.

Ami

On Thu, Apr 25, 2013 at 10:50 PM, A B wrote:

> there are a few issues here…
>
> In the FilterReplyMessage() you gotta send the Whole buffer length, that
> is, in your example the variable Totallen.
>
> Filter manager will remove the FILTER_REPLY_HEADER from the message when
> you receive the reply back in your driver (which is waiting on
> FltSendMessage() ).
>
> So your FltSendMessage() in the driver will get back a pointer to MY_REPLY_CONTEXT
> (again, this is as per your example above). The length of the returned
> buffer will be the same as calculated in ‘Len’ in your example.
>
> All these said, the right way to write the FltSendMessage() in your driver
> would be as follows:
>
>
> ULONG Len = sizeof(MY_REPLY_CONTEXT) + pTranslationRequest->uLen; //
> the pTranslationRequest->uLen was received from driver
> ULONG TotalLen = sizeof(FILTER_REPLY_HEADER) + Len;
>
> PVOID ReplyBuffer = ExAllocatePoolWithTag(NonPagelPool, TotalLen, MY_TAG);
>
>
>
> NTSTATUS FltSendMessage(
> pFilter,
> &ClientPort,
> SenderBuffer,
> SenderBufferLength,// till this parameter I am ignoring as your problem starts after this…
> (PFILTER_REPLY_HEADER)ReplyBuffer,
>
> TotalLen,
> NULL // if you want to wait forever
> );
>
>
> Once you get status Success, check the TotalLen variable, (this is an
> __inout variable , the Len should be equal to Len calculated above in the
> example.
>
>
> Once you get a status_success, do the following:
>
> PMY_REPLY_CONTEXT pRepCtx = (PMY_REPLY_CONTEXT)ReplyBuffer;
>
> This should nicely give you your variable length serialized structure
> with the buffer back to you.
>
> Hope this helps…
>
> Let us know it it worked for you…
>
> AB
>
>
> On Wed, Apr 24, 2013 at 10:04 PM, Ami Awbadhho wrote:
>
>> All,
>>
>> I want my user mode service to pass back a variable length reply to a
>> kernel mode message sent by the Driver. the reply is variable length
>> because, depending on the length of the buffer sought by the driver in the
>> FltSendMessage, the service creats and fills the buffer with data and sends
>> back.
>>
>> Now, after reading the documentation, I wrote the following code:
>>
>>
>> // This is the structure the user mode will fill up and send down to
>> Driver
>> typedef struct _MY_REPLY_CONTEXT {
>>
>> BOOLEAN bReadStatus; // Tells
>> whether the read was a success or not
>> PUCHAR pBUffer[1]; // Contains
>> the data sought by the Kernel
>> // Size of
>> this buffer is not required as
>> // we already
>> pass length in Request message
>>
>> } MY_REPLY_CONTEXT, *PMY_REPLY_CONTEXT;
>>
>>
>> typedef struct _MY_REPLY_FROM_USERLAND_MESSAGE {
>>
>> FILTER_REPLY_HEADER ReplyHeader; // Must be the first
>> member of this structure
>>
>>
>> MY_REPLY_CONTEXT Reply; // This is the reply
>> from user
>>
>> } MY_REPLY_FROM_USERLAND_MESSAGE, *PMY_REPLY_FROM_USERLAND_MESSAGE;
>>
>>
>>
>>
>> In the user land thread…
>>
>> ULONG Len = sizeof(MY_REPLY_CONTEXT) + pTranslationRequest->uLen; //
>> the pTranslationRequest->uLen was received from driver
>> ULONG TotalLen = sizeof(FILTER_REPLY_HEADER) + Len;
>>
>>
>> pReplyMessage = (PMY_REPLY_FROM_USERLAND_MESSAGE) malloc(TotalLen );
>>
>> memset(pReplyMessage, 0, TotalLen );
>> pReplyMessage->ReplyHeader.Status = 0;
>> pReplyMessage->ReplyHeader.MessageId = pMessage->MessageHeader.MessageId;
>>
>> pReplyMessage->Reply.bReadStatus = TRUE;
>> memcpy(pReplyMessage->Reply.pBUffer, pBuff, ullBytesRead); //ullBytesRead
>> is equal to pTranslationRequest->uLen, pBuff is legit, I saw the contents
>> in the debugger
>>
>> hr = FilterReplyMessage( pTPCtx->hPort,
>> (PFILTER_REPLY_HEADER) pReplyMessage,
>> Len ); // since in scanner sample they say we
>> only need to pass the length of our portion of the structure
>>
>>
>> When this executes, in the driver the buffer is all junk.
>>
>>
>> Can some one please let me know what I am doing incorrectly.
>>
>> thanks
>>
>> ami
>>
>> — NTFSD is sponsored by OSR OSR is hiring!! Info at
>> http://www.osr.com/careers For our schedule of debugging and file system
>> seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
>> List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> –
>
> - ab
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file system
> seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer