Problem with encrypted and compressed files on NTFS.

Hi All,

I am using raw data-structures of NTFS to copy contents of a file in to other file.
I am traversing the data runs and copy the contents of the clusters in to other file.

It works for normal files, but if a file is encrypted or compressed it fails as new file does not have setting (Attributes) that tell File System that this file is encrypted or compressed. So file system treats this new file as normal file and it does not decrypt or decompress it while reading the new file.

I want that this new file behave same as of original file.
Can any one tell me how I can achieve it?

Thanks & Regards,
Amrapali.

>>I am using raw data-structures of NTFS to copy contents of a file in to other file. I am traversing the data runs and copy the contents of the clusters in to other file.

IIRC MS stores the key information in some ADS associated with encrypted file. If you are copying a file with in NTFS that you have to copy all related streams. if copy target is non-ntfs, than you have to decrypt this file with the private key. It may have dependency on registry too (for key stuff) but I am not aware about that.

May I ask why you need this? Is this a file which is not available from ntfs.sys? In case you can tell this to list some one can suggest you a solution or else an alternative to work.

Thanks
Aditya

> IIRC MS stores the key information in some ADS associated with
encrypted file.
This is not right. Encryption information is stored in its own attribute
in mft record. Encryption attribute ties into the key and identity
management infrastructure.

Reading data while bypassing NTFS is not an easy thing.
Handling compressed data is not that difficult (look for decompress
FsRtl) but handling encrypted files will require a lot of
“behind-the-scenes” knowledge.

Harish

-----Original Message-----
From: xxxxx@gmail.com [mailto:xxxxx@gmail.com]
Sent: Wednesday, April 01, 2009 4:33 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Problem with encrypted and compressed files on NTFS.

>I am using raw data-structures of NTFS to copy contents of a file in
to other file. I am traversing the data runs and copy the contents of
the clusters in to other file.

IIRC MS stores the key information in some ADS associated with encrypted
file. If you are copying a file with in NTFS that you have to copy all
related streams. if copy target is non-ntfs, than you have to decrypt
this file with the private key. It may have dependency on registry too
(for key stuff) but I am not aware about that.

May I ask why you need this? Is this a file which is not available from
ntfs.sys? In case you can tell this to list some one can suggest you a
solution or else an alternative to work.

Thanks
Aditya


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

wrote in message news:xxxxx@ntfsd…
> Hi All,
>
> I am using raw data-structures of NTFS to copy contents of a file in to
> other file.
> I am traversing the data runs and copy the contents of the clusters in to
> other file.
>
> It works for normal files, but if a file is encrypted or compressed it
> fails as new file does not have setting (Attributes) that tell File System
> that this file is encrypted or compressed. So file system treats this new
> file as normal file and it does not decrypt or decompress it while reading
> the new file.
>
> I want that this new file behave same as of original file.
> Can any one tell me how I can achieve it?

Just use the proper API for backup & restore of EFS files?
(OpenEncryptedFileRaw, ReadEncryptedFileRaw … )

– pa

>>This is not right. Encryption information is stored in its own attribute in mft record. Encryption attribute ties into the key and identity management infrastructure.

I never worked on this aspect but I read this somewhere months back, may be on wiki and hence answered that. My mistake if this is not correct information.

Thanks
Aditya

yes! I read it from wiki. following is the link. (from google)

http://en.wikipedia.org/wiki/Encrypting_File_System

The problem with this link is that though it talks about $EFS but says that it is an ADS (and probably this causes that wrong hint to come out from my mind ),

As an ADS has to be a $data attribute this statement is not true.

“encrypted FEK is stored in the $EFS alternate data stream of the encrypted file.” it should be $EFS attributes instead.

Thanks,
Aditya

> As an ADS has to be a $data attribute this statement is not true.

Actually alternative data streams are just the subkind of attributes - the named attributes of $DATA type.


Maxim S. Shatskih

Windows DDK MVP

xxxxx@storagecraft.com

http://www.storagecraft.com

>>May I ask why you need this? Is this a file which is not available from

>ntfs.sys? In case you can tell this to list some one can suggest you a
>solution or else an alternative to work.

We may need this in cases such as file is not accessed from usermode e.g. rootkit files, or in recovery software we come to this situation where we have to recover file that ie encripted and available on disk.

As the file is encripted we may not get actual data, so Amrapali Nimgire may want to know that how we can copy such encripted file so that we will get original one?

>>We may need this in cases such as file is not accessed from usermode e.g. rootkit files, or in recovery software we come to this situation where we have to recover file that ie encripted and available on disk.

I know these *assumptions* and that is why I asked the OP to provide an answer of this, for recovery software it is indeed true as the file is deleted and FS may not allow you to read it using standard call. In case of rootkits a check of IRP hooking for FSD could be beneficial as there is no need of raw parsing in case the FSD itself is not hooked and you can make a direct call to it.

When I asked this question to OP, I want OP to illustrate more on the problem scenario as otherwise the post was not answered and will remain in status quo. Obviously the question wan not meant for assuming the possible reasons, it was “Tell the list what exactly the scenario is and someone may provide a good suggestion(+ or -) for this”.

>As the file is encripted we may not get actual data, so Amrapali Nimgire may want to know that how we can copy such encripted file so that we will get original one?

Here you are just considering a specification problem scenario and not a complete one, what about third party encryption filter drivers which keeps their key in TPM chip? Raw parsing is not going to work their anyhow.