Problems while crypting names

NTFSD
1

HI all,

I am writing a Filter that crypts file names. In the IRP_MJ_CREATE my
filter replaces
the original file name with an encrypted version. The encrypted name can
be longer
than the original; so I create a new buffer in the non paged memory and
I change the
IrpStack->FileObject->FileName to use the crypted name.

In the completion function I copy back the
IrpStack->FileObject->FileName to the original
name. All the filters above mine should see the original file name; the
filters below and the
file systems see the crypted name. Then I release the “crypted” buffer.

All seems to work using VFAT. In NTFS when I send an
IRP_MJ_QUERY_INFORMATION,
I receive just garbage. To my understanding the file system is saving
the data contained in the
crypted buffer after the buffer has been released (I release the buffer
after I restored the original
file name in the IRP stack).

Normally I don’t get the original name neither the crypted one. But if I
don’t release the buffer,
I got the crypted name.

I tried returning both STATUS_SUCCESS and STATUS_MORE_PROCESSING_REQUIRED
in the compl. procedure.

Do you see any mistake in my approach?

Thank you.

2

I guess the error is that you change IrpSp->FileObject->FileName?

“Francesco Garelli” wrote in message news:xxxxx@ntfsd…
> HI all,
>
> I am writing a Filter that crypts file names. In the IRP_MJ_CREATE my
> filter replaces
> the original file name with an encrypted version. The encrypted name can
> be longer
> than the original; so I create a new buffer in the non paged memory and I
> change the
> IrpStack->FileObject->FileName to use the crypted name.
>
> In the completion function I copy back the IrpStack->FileObject->FileName
> to the original
> name. All the filters above mine should see the original file name; the
> filters below and the
> file systems see the crypted name. Then I release the “crypted” buffer.
>
> All seems to work using VFAT. In NTFS when I send an
> IRP_MJ_QUERY_INFORMATION,
> I receive just garbage. To my understanding the file system is saving the
> data contained in the
> crypted buffer after the buffer has been released (I release the buffer
> after I restored the original
> file name in the IRP stack).
>
> Normally I don’t get the original name neither the crypted one. But if I
> don’t release the buffer,
> I got the crypted name.
>
> I tried returning both STATUS_SUCCESS and STATUS_MORE_PROCESSING_REQUIRED
> in the compl. procedure.
>
>
> Do you see any mistake in my approach?
>
> Thank you.
>

3

Ok,

so any way to change a file name in IRP_MJ_CREATE?

Thanks

I guess the error is that you change IrpSp->FileObject->FileName?

“Francesco Garelli” wrote in message
> news:xxxxx@ntfsd…
>> HI all,
>>
>> I am writing a Filter that crypts file names. In the IRP_MJ_CREATE my
>> filter replaces
>> the original file name with an encrypted version. The encrypted name
>> can be longer
>> than the original; so I create a new buffer in the non paged memory
>> and I change the
>> IrpStack->FileObject->FileName to use the crypted name.
>>
>> In the completion function I copy back the
>> IrpStack->FileObject->FileName to the original
>> name. All the filters above mine should see the original file name;
>> the filters below and the
>> file systems see the crypted name. Then I release the “crypted”
>> buffer.
>>
>> All seems to work using VFAT. In NTFS when I send an
>> IRP_MJ_QUERY_INFORMATION,
>> I receive just garbage. To my understanding the file system is saving
>> the data contained in the
>> crypted buffer after the buffer has been released (I release the
>> buffer after I restored the original
>> file name in the IRP stack).
>>
>> Normally I don’t get the original name neither the crypted one. But
>> if I don’t release the buffer,
>> I got the crypted name.
>>
>> I tried returning both STATUS_SUCCESS and
>> STATUS_MORE_PROCESSING_REQUIRED in the compl. procedure.
>>
>>
>> Do you see any mistake in my approach?
>>
>> Thank you.
>>
>
>
>
>

4

Reparse point?

“Francesco” wrote in message news:xxxxx@ntfsd…
> Ok,
>
> so any way to change a file name in IRP_MJ_CREATE?
>
> Thanks
>
>
>> I guess the error is that you change IrpSp->FileObject->FileName?
>>
>> “Francesco Garelli” wrote in message
>> news:xxxxx@ntfsd…
>>> HI all,
>>>
>>> I am writing a Filter that crypts file names. In the IRP_MJ_CREATE my
>>> filter replaces
>>> the original file name with an encrypted version. The encrypted name
>>> can be longer
>>> than the original; so I create a new buffer in the non paged memory
>>> and I change the
>>> IrpStack->FileObject->FileName to use the crypted name.
>>>
>>> In the completion function I copy back the
>>> IrpStack->FileObject->FileName to the original
>>> name. All the filters above mine should see the original file name;
>>> the filters below and the
>>> file systems see the crypted name. Then I release the “crypted”
>>> buffer.
>>>
>>> All seems to work using VFAT. In NTFS when I send an
>>> IRP_MJ_QUERY_INFORMATION,
>>> I receive just garbage. To my understanding the file system is saving
>>> the data contained in the
>>> crypted buffer after the buffer has been released (I release the
>>> buffer after I restored the original
>>> file name in the IRP stack).
>>>
>>> Normally I don’t get the original name neither the crypted one. But
>>> if I don’t release the buffer,
>>> I got the crypted name.
>>>
>>> I tried returning both STATUS_SUCCESS and
>>> STATUS_MORE_PROCESSING_REQUIRED in the compl. procedure.
>>>
>>>
>>> Do you see any mistake in my approach?
>>>
>>> Thank you.
>>>
>>
>>
>>
>>
>
>

5

> than the original; so I create a new buffer in the non paged memory and

I change the IrpStack->FileObject->FileName to use the crypted name.

Oooooops. I don’t know if you can even do that.
Encrypted file names ?
How you’ll recognize the name is encrypted ?
How you’ll deal with unacceptable characters ?
If you’ll encrypt it and code to Base64, how you’ll
distinguish between “normal” file name and “encrypted”
file name ?

It is me clear that you don’t want to hear this,
but either think another files protection or give it up.

L.

6

Actually changing the filename on the dispatch side is not an issue. You can
replace the buffer for the name and pass it down to the underlying FSD and
it won’t know any different. Now changing it back after the FSD has
processed it may be another story.

Have you simply to just change the name on the way down but not putting it
back to the original on the completion side?

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Sunday, June 26, 2005 4:07 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Problems while crypting names

Reparse point?

“Francesco” wrote in message news:xxxxx@ntfsd…
> Ok,
>
> so any way to change a file name in IRP_MJ_CREATE?
>
> Thanks
>
>
>> I guess the error is that you change IrpSp->FileObject->FileName?
>>
>> “Francesco Garelli” wrote in message
>> news:xxxxx@ntfsd…
>>> HI all,
>>>
>>> I am writing a Filter that crypts file names. In the IRP_MJ_CREATE my
>>> filter replaces
>>> the original file name with an encrypted version. The encrypted name
>>> can be longer
>>> than the original; so I create a new buffer in the non paged memory
>>> and I change the
>>> IrpStack->FileObject->FileName to use the crypted name.
>>>
>>> In the completion function I copy back the
>>> IrpStack->FileObject->FileName to the original
>>> name. All the filters above mine should see the original file name;
>>> the filters below and the
>>> file systems see the crypted name. Then I release the “crypted”
>>> buffer.
>>>
>>> All seems to work using VFAT. In NTFS when I send an
>>> IRP_MJ_QUERY_INFORMATION,
>>> I receive just garbage. To my understanding the file system is saving
>>> the data contained in the
>>> crypted buffer after the buffer has been released (I release the
>>> buffer after I restored the original
>>> file name in the IRP stack).
>>>
>>> Normally I don’t get the original name neither the crypted one. But
>>> if I don’t release the buffer,
>>> I got the crypted name.
>>>
>>> I tried returning both STATUS_SUCCESS and
>>> STATUS_MORE_PROCESSING_REQUIRED in the compl. procedure.
>>>
>>>
>>> Do you see any mistake in my approach?
>>>
>>> Thank you.
>>>
>>
>>
>>
>>
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

It is possible to change IrpSp->FileObject->FileName.Buffer pointer in
create request and Length/MaximumLength field, some file system do this to
create so-called normalized file name ( full file name after concatenating
name contained in IrpSp->FileObject->FileName and in related file name(
actually some directory name ) ). My guess- the problem is not in changing
buffer pointer- it is allowed, but file system may use encrypted file name
as name used to open file and return it for query information request.

“Francesco Garelli” wrote in message news:xxxxx@ntfsd…
> HI all,
>
> I am writing a Filter that crypts file names. In the IRP_MJ_CREATE my
> filter replaces
> the original file name with an encrypted version. The encrypted name can
> be longer
> than the original; so I create a new buffer in the non paged memory and I
> change the
> IrpStack->FileObject->FileName to use the crypted name.
>
> In the completion function I copy back the IrpStack->FileObject->FileName
> to the original
> name. All the filters above mine should see the original file name; the
> filters below and the
> file systems see the crypted name. Then I release the “crypted” buffer.
>
> All seems to work using VFAT. In NTFS when I send an
> IRP_MJ_QUERY_INFORMATION,
> I receive just garbage. To my understanding the file system is saving the
> data contained in the
> crypted buffer after the buffer has been released (I release the buffer
> after I restored the original
> file name in the IRP stack).
>
> Normally I don’t get the original name neither the crypted one. But if I
> don’t release the buffer,
> I got the crypted name.
>
> I tried returning both STATUS_SUCCESS and STATUS_MORE_PROCESSING_REQUIRED
> in the compl. procedure.
>
>
> Do you see any mistake in my approach?
>
> Thank you.
>