Re: Removable media enc/dec driver design.
- From: Jakob Bohm <jb@xxxxxxxxxx>
- Date: Mon, 25 May 2009 17:34:47 +0200
Dr.GEORGE wrote:
Thank you Jakob.
"Jakob Bohm" wrote:
No, make a Disk Device (not File System) filter driver which is loaded
on top of the disk driver before the "File System Recognizers" look at
the disk. This Disk Device filter driver would decrypt all the sectors
on read (and encrypt on write), so Windows and 3rd party file system
drivers will see the decrypted sectors and recognize them as containing
a known file system.
Our product saves original MBR, writes our one (in sector 0), and when
someone wants to read sector zero, our driver just "redicects" that call.
If the information (such as a password) needed to decrypt the disk does
not become available until after the file system drivers have already
tried to read the disk (and failed to get meaningful data), then once
that information becomes available to the driver, the driver must
deceive higher level drivers into believing that the old disk was
ejected and a new one (with the decrypted contents) was inserted. Ditto
if the user chooses to "stop" or "logout" from the disk decryption code.
Yes, password needed. But before I receive the password (from user), format
dialog from Vista has been already showen.
Is there any way to stop OS determining File System, get password from user,
redirect sector zero, and continue OS determining?
Does Windows use a specific control code for determining File System?
Or is there any problem in the work sequence of our driver?
Thank you...
As far as I know, the sequence of events at driver level is something
like this:
1. The partition handling intermediate driver reads the MBR and any
chained "MBRs" in extended partitions, then creates device objects that
make each partition look like its own disk to higher layers.
2. The "File System Recognizers" reads the some of the sectors from each
partition type (from step 1) indicates it should contain a Windows file
system. If this results in recognizing the content of the partition as
matching one of the installed file systems (FAT, NTFS, FAT32 if >= NT
5.0, HPFS if <= NT 3.51 etc.), the driver for that file system is loaded
and told to use the disk. If these steps fail to recognize the contents
of the read sectors, either an error or a suggestion to format this
"blank" partition is displayed.
Because returning the "right" data in step 2 would not only reveal some
of the data your encryption is supposed to hide but would also cause
windows to start read/write to the rest of the partition based on the
(wrong) assumption that the entire disk has been decrypted, returning
the "right" data would not be a good solution.
A simpler solution is to return some fixed (or almost fixed, it may be
necessary to include disk sizes etc.) sector contents for the first few
sectors making Windows think the disk is valid but with no files and no
free sectors (Simulating a FAT or FAT32 file system completely filled
with bad sectors is probably the easiest value to fake).
Once the user has provided the correct decryption key, the driver should
tell Windows that the disk/giantdiskette has been removed from the drive
and a new one inserted containing the decrypted data. Then Windows will
redo steps 1 and 2, recognizing the real partitions and file systems.
An even more radical solution would be to play with the plug and play
detection of the disk, pretending the disk isn't even there until the
decryption keys are ready.
--
Jakob Bøhm, M.Sc.Eng. * jb@xxxxxxxxxx * direct tel:+45-45-90-25-33
Netop Solutions A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right.
Information in this posting may not be the official position of Netop
Solutions A/S, only the personal opinions of the author.
.
- References:
- Removable media enc/dec driver design.
- From: Dr.GEORGE
- Re: Removable media enc/dec driver design.
- From: Tim Roberts
- Re: Removable media enc/dec driver design.
- From: Dr.GEORGE
- Re: Removable media enc/dec driver design.
- From: Jakob Bohm
- Re: Removable media enc/dec driver design.
- From: Dr.GEORGE
- Removable media enc/dec driver design.
- Prev by Date: Display driver
- Next by Date: Re: Display driver
- Previous by thread: Re: Removable media enc/dec driver design.
- Next by thread: Re: Removable media enc/dec driver design.
- Index(es):
Relevant Pages
|
