Hello Rafa,
Your problems are almost certainly due to your in-place
encryption of the buffer during writes (reads are ok). The
reason is while the write is taking place, the system will
continue to use the data in the buffer for other threads. If
you encrypt it, the other threads will be working with the
encrypted data. This is most obvious when it is the data that
forms the file system structure itself that is being written and
will lead to the file system becoming corrupted.
So for writes, you must copy the buffer to your own allocated
from non-paged pool, encrypt the data in your buffer, change the
MDL in the IRP to one describing your buffer and send it down to the
lower driver. On completion of the request you need to restore the
original MDL in the IRP and free your buffer.
Shaun
Sunday, August 22, 2004, 8:13:21 PM, you wrote:
R> I know that the problem is in my code, but I am looking for some hint or
R> advice from someone that has developed something similar.
R> SafeBoot surely works fine, and Secuware, and SafeGuard, … I know
R> that’s possible to develop this kind of filter driver. But the problem
R> it’s that my filter is not working and I’m asking for help in this list
R> because I don’t know why is failing.
R> I have reviewed the list database for similar cases but none is useful
R> for me. I have found this thread:
R> http://www.osronline.com/lists_archive/ntfsd/thread782.html, whose code
R> is very similar to mine. I see that he copies the buffer at
Irp->>MdlAddress to a non paged pool, encrypts/decrypts the pool, and
R> then he copies the pool to the buffer. Is this necessary? Cannot work
R> with the user buffer at MdlAddress directly?
R> Rafa.
R> David J. Craig wrote:
> Did I write “Safe Boot” mode? I put it in quotes as “SafeBoot” as a fairly
> too subtle hint you should search Google for it. Or maybe just try
> www.safeboot.com. If you look at that product, which I have no relationship
> too, you can find your proof of concept. If it works and yours doesn’t,
> then it leads me to believe that the problem is in your code.
>
> “Rafa” wrote in message news:xxxxx@ntdev…
>>
>>>Hi David,
>>>
>>>Do you mean the “Safe Boot” mode? I don’t understand how that could be
>>>useful.
>>>
>>>I’m sorry, if I’ve misunderstood you.
>>>
>>>Oh, when I’m talking about the proof of concept I’m referring to include
>>>very simple cases of partitions. As much, four primary partitions but the
>>>part relative to encryption/decryption must be accomplished.
>>>
>>>In my code, when my driver processes an IRP_MJ_READ or IRP_MJ_WRITE, it
>>>works encrypting/decrypting directly the buffer at Irp->MdlAdress. Is
>>>correct this approach?
>>>
>>>It seems that some kind of writing (reading?), that my filter does not
>>>treat correctly, introduces corruption in the filesystem but I cannot see
>>>why. Any suggestions?
>>>
>>>Thanks in advance,
>>>
>>>Rafa.
>>>
>>>
>>>David J. Craig wrote:
>>>
>>>>Why not just look for “SafeBoot”? That is a good proof of concept as it
>>>>works and has for several years.
>>>>
>>>>“Rafa” wrote in message news:xxxxx@ntdev…
>>>>
>>>>
>>>>>Hi Maxim,
>>>>>
>>>>>I think that’s not a problem because the Partition Table (really, the
>>>>>sector 0) at the MBR is not encrypted and the filter driver does not
>>>>>encrypt/decrypt the accesses to the sector 0.
>>>>>
>>>>>Besides, the harddisk that I’m talking about has only one primary
>>>>>partition. I’m not interested in logic partitions because this is a
>>>>>concept-proof driver (at least, for now).
>>>>>
>>>>>Maxim S. Shatskih wrote:
>>>>>
>>>>>
>>>>>> Note: IoReadPartitionTable is not subject to filtering. It ignores
>>>>>>the disk
>>>>>>upper filters. Possibly this is a bug, but nevertheless it is so.
>>>>>>
