direction

i want to have on the fly encryption and decryption, i would
rather a simple implmentation than a more complex one that
was faster.

if i capture all non paging irp_mjr_read, and decrypt the
data in the mdl and then replace the mdl with decrypted data
is that correct ? no future issues ?

if i write data should i capture non pagging irp_mj_write,
get the mdl, encrypt the data in the mdl and then replace the
mdl with the encrypted data mdl.

?

Hi,

there’s no “simple implementation” of an encryption filter.
This kind of filters is one of the most complex drivers
you can find.

if i capture all non paging irp_mjr_read, and decrypt the

This will cause wrong functionalty
of all software which use memory mapping (Notepad,
Office, EXE launching, and more)

if i write data should i capture non pagging irp_mj_write,

This will cause data corruption in all applications which
write data to a memory map.

L.

what’s a guide i can use? i don’t know how i would support
memory mapped files via a filter driver.

i know that i can filter irp_mj_read and write, open and
close. i made a test application that filtered read and
writes for a device and then changed the data in the mdl
buffer. worked ok but also had unexpected results.

what is a basic structure? i have searched the posts and cant
find much.

thank you

basicly, from what i have found posted on the mailing list is
that its a bad idea to edit the bufferers of read and write
irp’s.

but i don’t see a way to have on the fly encryption with out
editing the buffers of irp read and write.

You must encrypt snd decrypt during Paging I/O.

L.

You may change data in the buffer given to the read operation.
Try to see the read logic:

  1. Application: ReadFile
  2. Filter: Pass down
  3. FSD: stores encrypted data
  4. Filter: decrypts data
  5. Application: return from ReadFile

The write logic

  1. Application: WriteFile
  2. Filter: Allocates new buffer and copies data there, passes the new buffer
    down
  3. FSD: Wites encrypted data
  4. Filter: does nothing at this point
  5. Applicarion: Return frm WriteFile, application’s buffer unchanged.

L.

I think this is beyond your capabilities and knowledge. It is a ‘short’ hop
over that little ocean to the OSR File Systems class in Los Angeles next
month.

The rules are (basically with some exceptions and special cases):

  1. Read - decrypt the data during a paging read. Also look for files that
    are opened with no caching and you have to decrypt them during normal reads.
    You use the buffers provided since nothing above you should ever see the
    encrypted data. Only the storage stack (disk.sys and below) should see
    encrypted data.

  2. Write - copy the data from the supplied buffers to new buffers, encrypt
    and write. Make sure you change the IRP to point to the new buffers in all
    locations. Don’t forget to restore the pointers/MDLs during write
    completion. This is also for paging IO only. Non-cached data will have
    different flags than writes being done for the cache manager.

Use filter manager and this will be easier. Not easy, but much simpler than
doing a full file system filter driver. Hooking the appropriate file
systems can be a challenge especially if you support NT4, 2000, XP, 2003,
and Vista. NT4 cannot be done with the filter manager, otherwise the others
can. I hope you have all the books you need for this type of project.
Nagar’s book, IFS Kit, OSR FAQs, NTFSD history, etc. Also watch out for the
problems involved with using headers and trailers in the file to support
encryption. If you want to support FAT, start there first and then try NTFS

There are so many pitfalls in this kind of project, it will take at least a
man year. I also hope you don’t forget the problems with implementing
encryption. This requires experts even if you decide to use a standard
encryption algorithm. If you have lots of money, RSA provides some
excellent toolkits. They might have a discount for educational
institutions. Good encryption using a GemPlus PK16000 RSA smartcard, with
AES for the encryption algorithm. Don’t forget using seeds and chaining to
keep repeated blocks of plaintext from repeating. The smartcard will keep
the private RSA key away from any exposure.

wrote in message news:xxxxx@ntfsd…
> basicly, from what i have found posted on the mailing list is
> that its a bad idea to edit the bufferers of read and write
> irp’s.
>
> but i don’t see a way to have on the fly encryption with out
> editing the buffers of irp read and write.
>
>

“1) Application: ReadFile
2) Filter: Pass down
3) FSD: stores encrypted data
4) Filter: decrypts data
5) Application: return from ReadFile”

what is the difference between “FSD” and “filter” ?