a silly doubt

for a disc encryptor/decryptor driver, sitting right above disk.sys
and passing encrypted data to disk.sys and decrypting encrypted
sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
IOCTL_DISK_IS_WRITABLE etc…etc.

AFAIK IOCTLs have their own defined structures and these are pre
determined, thus if a driver above me asks to get the drive info
through IOCTL, how can I successfully decrypt the data in the disk
sector that is needed and pass it on. The driver below me, disk.sys
doesn’t know of the encryption, and would fetch garbage from the disk,
populate the IOCTL structure with garbage(probably) and send it up.

Thanks in advance.

  • Developer

The first thing to realize is your statnent “sitting right above disk.sys”
is impossible. One of the oldest and most common mistakes in designing
filter driver is claiming “my driver is first”, you cannot guarantee that
you will be the first filter above disk.sys, someone else may want that
position, then who wins?

The second major problem you have is that if you read disk.sys a heck of a
lot of the data you are talking about is used by disk.sys, so if you start
encrypting everything it is going to crash.

Bottom line, you have serious and unrecoverable design flaws in your current
approach.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Developer” wrote in message news:xxxxx@ntdev…
for a disc encryptor/decryptor driver, sitting right above disk.sys
and passing encrypted data to disk.sys and decrypting encrypted
sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
IOCTL_DISK_IS_WRITABLE etc…etc.

AFAIK IOCTLs have their own defined structures and these are pre
determined, thus if a driver above me asks to get the drive info
through IOCTL, how can I successfully decrypt the data in the disk
sector that is needed and pass it on. The driver below me, disk.sys
doesn’t know of the encryption, and would fetch garbage from the disk,
populate the IOCTL structure with garbage(probably) and send it up.

Thanks in advance.


- Developer

hi don,

Yes I know that I can’t guarentee that the driver WILL be loaded right
after disk.sys, but precautions have been taken about that issue. If
any other driver will try to modify the registry key and load itself
before us, then it also has tro support the hierarchy properly. Infact
partmgr.sys is usually loaded over disk.sys.

“The second major problem you have is that if you read disk.sys a heck of a
lot of the data you are talking about is used by disk.sys, so if you start
encrypting everything it is going to crash.”

I do not understand this part of your statement. In the stack of
drivers, I am attaching my driver, above disk.sys, and as of now was
tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
message, where as if I leave out the system area of the disc (bootsec
and MFT of that partition) then things work fine, ofcourse if I unload
the driver, these files cannot be read anymore.

But I need to to a sector level encryption, I know there are softwares
that do it, and they also attach above disk.sys ( device tree shows me
so). Is there something I am missing out?

“Bottom line, you have serious and unrecoverable design flaws in your current
approach.”

So then can you tell me a better approach please.

Any advice would be appreciated.

On 8/3/05, Don Burn wrote:
> The first thing to realize is your statnent “sitting right above disk.sys”
> is impossible. One of the oldest and most common mistakes in designing
> filter driver is claiming “my driver is first”, you cannot guarantee that
> you will be the first filter above disk.sys, someone else may want that
> position, then who wins?
>
> The second major problem you have is that if you read disk.sys a heck of a
> lot of the data you are talking about is used by disk.sys, so if you start
> encrypting everything it is going to crash.
>
> Bottom line, you have serious and unrecoverable design flaws in your current
> approach.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> for a disc encryptor/decryptor driver, sitting right above disk.sys
> and passing encrypted data to disk.sys and decrypting encrypted
> sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> IOCTL_DISK_IS_WRITABLE etc…etc.
>
> AFAIK IOCTLs have their own defined structures and these are pre
> determined, thus if a driver above me asks to get the drive info
> through IOCTL, how can I successfully decrypt the data in the disk
> sector that is needed and pass it on. The driver below me, disk.sys
> doesn’t know of the encryption, and would fetch garbage from the disk,
> populate the IOCTL structure with garbage(probably) and send it up.
>
> Thanks in advance.
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

Put the driver under disk.sys, this will have to be a different driver,
since the requests will look different. Note, be sure not to do this to the
system drive, or the boot drive since you will not be able to intercept
everything.

You are much better off, not encrypting the sectors you mentioned.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Developer” wrote in message news:xxxxx@ntdev…
hi don,

Yes I know that I can’t guarentee that the driver WILL be loaded right
after disk.sys, but precautions have been taken about that issue. If
any other driver will try to modify the registry key and load itself
before us, then it also has tro support the hierarchy properly. Infact
partmgr.sys is usually loaded over disk.sys.

“The second major problem you have is that if you read disk.sys a heck of a
lot of the data you are talking about is used by disk.sys, so if you start
encrypting everything it is going to crash.”

I do not understand this part of your statement. In the stack of
drivers, I am attaching my driver, above disk.sys, and as of now was
tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
message, where as if I leave out the system area of the disc (bootsec
and MFT of that partition) then things work fine, ofcourse if I unload
the driver, these files cannot be read anymore.

But I need to to a sector level encryption, I know there are softwares
that do it, and they also attach above disk.sys ( device tree shows me
so). Is there something I am missing out?

“Bottom line, you have serious and unrecoverable design flaws in your
current
approach.”

So then can you tell me a better approach please.

Any advice would be appreciated.

On 8/3/05, Don Burn wrote:
> The first thing to realize is your statnent “sitting right above disk.sys”
> is impossible. One of the oldest and most common mistakes in designing
> filter driver is claiming “my driver is first”, you cannot guarantee that
> you will be the first filter above disk.sys, someone else may want that
> position, then who wins?
>
> The second major problem you have is that if you read disk.sys a heck of a
> lot of the data you are talking about is used by disk.sys, so if you start
> encrypting everything it is going to crash.
>
> Bottom line, you have serious and unrecoverable design flaws in your
> current
> approach.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> for a disc encryptor/decryptor driver, sitting right above disk.sys
> and passing encrypted data to disk.sys and decrypting encrypted
> sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> IOCTL_DISK_IS_WRITABLE etc…etc.
>
> AFAIK IOCTLs have their own defined structures and these are pre
> determined, thus if a driver above me asks to get the drive info
> through IOCTL, how can I successfully decrypt the data in the disk
> sector that is needed and pass it on. The driver below me, disk.sys
> doesn’t know of the encryption, and would fetch garbage from the disk,
> populate the IOCTL structure with garbage(probably) and send it up.
>
> Thanks in advance.
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

don,

thanks again for taking the trouble. However, what you say, attaching
below disk.sys doesn’t seem to be solving my perpose, as I driver will
become very complex to implement.

The other solution you suggested, is leaving out the system sectors of
the disk. Well, if I do that, then the driver essentially becomes a
file level encryptor, also, there are other issues that needs
attention then.

  • Do I encrypt the root directory of the drive.
  • How to find out where exactly the system sectors end, that is the
    bootsec, the MFT and the root directory entries.
  • Also one of the objectives is to even make windows load from an
    encrypted drive, which is otherwise unreadable to the outside world.

Keeping these into mind I had targetted disk.sys.

One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
and WRITE out of them, send tem to disk.sys and in th completion
routine, decode the IRPs buffer and populate the IOCTL structures
accordingly, not an easy task, as there could be many different IOCTLs
( please correct me if I am totally on th worng track).

Can you throw some light on the pros and cons of this approach please.

So, is it that full sector wise encryption of disks are not possible?
Software that claim to do it, as actually just eliminating the system
sectors?

Thanks in advance.

On 8/3/05, Don Burn wrote:
> Put the driver under disk.sys, this will have to be a different driver,
> since the requests will look different. Note, be sure not to do this to the
> system drive, or the boot drive since you will not be able to intercept
> everything.
>
> You are much better off, not encrypting the sectors you mentioned.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> hi don,
>
> Yes I know that I can’t guarentee that the driver WILL be loaded right
> after disk.sys, but precautions have been taken about that issue. If
> any other driver will try to modify the registry key and load itself
> before us, then it also has tro support the hierarchy properly. Infact
> partmgr.sys is usually loaded over disk.sys.
>
> “The second major problem you have is that if you read disk.sys a heck of a
> lot of the data you are talking about is used by disk.sys, so if you start
> encrypting everything it is going to crash.”
>
> I do not understand this part of your statement. In the stack of
> drivers, I am attaching my driver, above disk.sys, and as of now was
> tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> message, where as if I leave out the system area of the disc (bootsec
> and MFT of that partition) then things work fine, ofcourse if I unload
> the driver, these files cannot be read anymore.
>
> But I need to to a sector level encryption, I know there are softwares
> that do it, and they also attach above disk.sys ( device tree shows me
> so). Is there something I am missing out?
>
> “Bottom line, you have serious and unrecoverable design flaws in your
> current
> approach.”
>
> So then can you tell me a better approach please.
>
> Any advice would be appreciated.
>
>
>
>
> On 8/3/05, Don Burn wrote:
> > The first thing to realize is your statnent “sitting right above disk.sys”
> > is impossible. One of the oldest and most common mistakes in designing
> > filter driver is claiming “my driver is first”, you cannot guarantee that
> > you will be the first filter above disk.sys, someone else may want that
> > position, then who wins?
> >
> > The second major problem you have is that if you read disk.sys a heck of a
> > lot of the data you are talking about is used by disk.sys, so if you start
> > encrypting everything it is going to crash.
> >
> > Bottom line, you have serious and unrecoverable design flaws in your
> > current
> > approach.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > and passing encrypted data to disk.sys and decrypting encrypted
> > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > IOCTL_DISK_IS_WRITABLE etc…etc.
> >
> > AFAIK IOCTLs have their own defined structures and these are pre
> > determined, thus if a driver above me asks to get the drive info
> > through IOCTL, how can I successfully decrypt the data in the disk
> > sector that is needed and pass it on. The driver below me, disk.sys
> > doesn’t know of the encryption, and would fetch garbage from the disk,
> > populate the IOCTL structure with garbage(probably) and send it up.
> >
> > Thanks in advance.
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

Go read disk.sys, I believe you will find that is understands a number of
these fields, and you encryption breaks this.

Note: you still have the problem that you cannot do this to the boot
partition or the system partion.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Developer” wrote in message news:xxxxx@ntdev…
don,

thanks again for taking the trouble. However, what you say, attaching
below disk.sys doesn’t seem to be solving my perpose, as I driver will
become very complex to implement.

The other solution you suggested, is leaving out the system sectors of
the disk. Well, if I do that, then the driver essentially becomes a
file level encryptor, also, there are other issues that needs
attention then.
- Do I encrypt the root directory of the drive.
- How to find out where exactly the system sectors end, that is the
bootsec, the MFT and the root directory entries.
- Also one of the objectives is to even make windows load from an
encrypted drive, which is otherwise unreadable to the outside world.

Keeping these into mind I had targetted disk.sys.

One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
and WRITE out of them, send tem to disk.sys and in th completion
routine, decode the IRPs buffer and populate the IOCTL structures
accordingly, not an easy task, as there could be many different IOCTLs
( please correct me if I am totally on th worng track).

Can you throw some light on the pros and cons of this approach please.

So, is it that full sector wise encryption of disks are not possible?
Software that claim to do it, as actually just eliminating the system
sectors?

Thanks in advance.

On 8/3/05, Don Burn wrote:
> Put the driver under disk.sys, this will have to be a different driver,
> since the requests will look different. Note, be sure not to do this to
> the
> system drive, or the boot drive since you will not be able to intercept
> everything.
>
> You are much better off, not encrypting the sectors you mentioned.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> hi don,
>
> Yes I know that I can’t guarentee that the driver WILL be loaded right
> after disk.sys, but precautions have been taken about that issue. If
> any other driver will try to modify the registry key and load itself
> before us, then it also has tro support the hierarchy properly. Infact
> partmgr.sys is usually loaded over disk.sys.
>
> “The second major problem you have is that if you read disk.sys a heck of
> a
> lot of the data you are talking about is used by disk.sys, so if you start
> encrypting everything it is going to crash.”
>
> I do not understand this part of your statement. In the stack of
> drivers, I am attaching my driver, above disk.sys, and as of now was
> tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> message, where as if I leave out the system area of the disc (bootsec
> and MFT of that partition) then things work fine, ofcourse if I unload
> the driver, these files cannot be read anymore.
>
> But I need to to a sector level encryption, I know there are softwares
> that do it, and they also attach above disk.sys ( device tree shows me
> so). Is there something I am missing out?
>
> “Bottom line, you have serious and unrecoverable design flaws in your
> current
> approach.”
>
> So then can you tell me a better approach please.
>
> Any advice would be appreciated.
>
>
>
>
> On 8/3/05, Don Burn wrote:
> > The first thing to realize is your statnent “sitting right above
> > disk.sys”
> > is impossible. One of the oldest and most common mistakes in designing
> > filter driver is claiming “my driver is first”, you cannot guarantee
> > that
> > you will be the first filter above disk.sys, someone else may want that
> > position, then who wins?
> >
> > The second major problem you have is that if you read disk.sys a heck of
> > a
> > lot of the data you are talking about is used by disk.sys, so if you
> > start
> > encrypting everything it is going to crash.
> >
> > Bottom line, you have serious and unrecoverable design flaws in your
> > current
> > approach.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > and passing encrypted data to disk.sys and decrypting encrypted
> > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > IOCTL_DISK_IS_WRITABLE etc…etc.
> >
> > AFAIK IOCTLs have their own defined structures and these are pre
> > determined, thus if a driver above me asks to get the drive info
> > through IOCTL, how can I successfully decrypt the data in the disk
> > sector that is needed and pass it on. The driver below me, disk.sys
> > doesn’t know of the encryption, and would fetch garbage from the disk,
> > populate the IOCTL structure with garbage(probably) and send it up.
> >
> > Thanks in advance.
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

for booting part we have to use other mechanisms, such as modifying
the MBR and loading the decryptor that essentially decrypts the
kernel file and DISK.SYS and loads them into memory. Before the driver
to help it read teh disk comes into place. That is a totally different
module.

Thanks don, though it complicated my problem, rather than solving it,
it was great to get advice from you.

regards,

developer

On 8/3/05, Don Burn wrote:
> Go read disk.sys, I believe you will find that is understands a number of
> these fields, and you encryption breaks this.
>
> Note: you still have the problem that you cannot do this to the boot
> partition or the system partion.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> don,
>
> thanks again for taking the trouble. However, what you say, attaching
> below disk.sys doesn’t seem to be solving my perpose, as I driver will
> become very complex to implement.
>
> The other solution you suggested, is leaving out the system sectors of
> the disk. Well, if I do that, then the driver essentially becomes a
> file level encryptor, also, there are other issues that needs
> attention then.
> - Do I encrypt the root directory of the drive.
> - How to find out where exactly the system sectors end, that is the
> bootsec, the MFT and the root directory entries.
> - Also one of the objectives is to even make windows load from an
> encrypted drive, which is otherwise unreadable to the outside world.
>
> Keeping these into mind I had targetted disk.sys.
>
> One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
> and WRITE out of them, send tem to disk.sys and in th completion
> routine, decode the IRPs buffer and populate the IOCTL structures
> accordingly, not an easy task, as there could be many different IOCTLs
> ( please correct me if I am totally on th worng track).
>
> Can you throw some light on the pros and cons of this approach please.
>
> So, is it that full sector wise encryption of disks are not possible?
> Software that claim to do it, as actually just eliminating the system
> sectors?
>
> Thanks in advance.
>
> On 8/3/05, Don Burn wrote:
> > Put the driver under disk.sys, this will have to be a different driver,
> > since the requests will look different. Note, be sure not to do this to
> > the
> > system drive, or the boot drive since you will not be able to intercept
> > everything.
> >
> > You are much better off, not encrypting the sectors you mentioned.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > hi don,
> >
> > Yes I know that I can’t guarentee that the driver WILL be loaded right
> > after disk.sys, but precautions have been taken about that issue. If
> > any other driver will try to modify the registry key and load itself
> > before us, then it also has tro support the hierarchy properly. Infact
> > partmgr.sys is usually loaded over disk.sys.
> >
> > “The second major problem you have is that if you read disk.sys a heck of
> > a
> > lot of the data you are talking about is used by disk.sys, so if you start
> > encrypting everything it is going to crash.”
> >
> > I do not understand this part of your statement. In the stack of
> > drivers, I am attaching my driver, above disk.sys, and as of now was
> > tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> > I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> > message, where as if I leave out the system area of the disc (bootsec
> > and MFT of that partition) then things work fine, ofcourse if I unload
> > the driver, these files cannot be read anymore.
> >
> > But I need to to a sector level encryption, I know there are softwares
> > that do it, and they also attach above disk.sys ( device tree shows me
> > so). Is there something I am missing out?
> >
> > “Bottom line, you have serious and unrecoverable design flaws in your
> > current
> > approach.”
> >
> > So then can you tell me a better approach please.
> >
> > Any advice would be appreciated.
> >
> >
> >
> >
> > On 8/3/05, Don Burn wrote:
> > > The first thing to realize is your statnent “sitting right above
> > > disk.sys”
> > > is impossible. One of the oldest and most common mistakes in designing
> > > filter driver is claiming “my driver is first”, you cannot guarantee
> > > that
> > > you will be the first filter above disk.sys, someone else may want that
> > > position, then who wins?
> > >
> > > The second major problem you have is that if you read disk.sys a heck of
> > > a
> > > lot of the data you are talking about is used by disk.sys, so if you
> > > start
> > > encrypting everything it is going to crash.
> > >
> > > Bottom line, you have serious and unrecoverable design flaws in your
> > > current
> > > approach.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > >
> > > “Developer” wrote in message news:xxxxx@ntdev…
> > > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > > and passing encrypted data to disk.sys and decrypting encrypted
> > > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > > tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > > IOCTL_DISK_IS_WRITABLE etc…etc.
> > >
> > > AFAIK IOCTLs have their own defined structures and these are pre
> > > determined, thus if a driver above me asks to get the drive info
> > > through IOCTL, how can I successfully decrypt the data in the disk
> > > sector that is needed and pass it on. The driver below me, disk.sys
> > > doesn’t know of the encryption, and would fetch garbage from the disk,
> > > populate the IOCTL structure with garbage(probably) and send it up.
> > >
> > > Thanks in advance.
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

That isn’t enough, a large number of drivers plus parts of the registry will
be loaded into the OS before your driver get loaded, how are you going to
handle all the things a boot image needs before your driver starts working?


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Developer” wrote in message news:xxxxx@ntdev…
for booting part we have to use other mechanisms, such as modifying
the MBR and loading the decryptor that essentially decrypts the
kernel file and DISK.SYS and loads them into memory. Before the driver
to help it read teh disk comes into place. That is a totally different
module.

Thanks don, though it complicated my problem, rather than solving it,
it was great to get advice from you.

regards,

developer

On 8/3/05, Don Burn wrote:
> Go read disk.sys, I believe you will find that is understands a number of
> these fields, and you encryption breaks this.
>
> Note: you still have the problem that you cannot do this to the boot
> partition or the system partion.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> don,
>
> thanks again for taking the trouble. However, what you say, attaching
> below disk.sys doesn’t seem to be solving my perpose, as I driver will
> become very complex to implement.
>
> The other solution you suggested, is leaving out the system sectors of
> the disk. Well, if I do that, then the driver essentially becomes a
> file level encryptor, also, there are other issues that needs
> attention then.
> - Do I encrypt the root directory of the drive.
> - How to find out where exactly the system sectors end, that is the
> bootsec, the MFT and the root directory entries.
> - Also one of the objectives is to even make windows load from an
> encrypted drive, which is otherwise unreadable to the outside world.
>
> Keeping these into mind I had targetted disk.sys.
>
> One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
> and WRITE out of them, send tem to disk.sys and in th completion
> routine, decode the IRPs buffer and populate the IOCTL structures
> accordingly, not an easy task, as there could be many different IOCTLs
> ( please correct me if I am totally on th worng track).
>
> Can you throw some light on the pros and cons of this approach please.
>
> So, is it that full sector wise encryption of disks are not possible?
> Software that claim to do it, as actually just eliminating the system
> sectors?
>
> Thanks in advance.
>
> On 8/3/05, Don Burn wrote:
> > Put the driver under disk.sys, this will have to be a different driver,
> > since the requests will look different. Note, be sure not to do this to
> > the
> > system drive, or the boot drive since you will not be able to intercept
> > everything.
> >
> > You are much better off, not encrypting the sectors you mentioned.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > hi don,
> >
> > Yes I know that I can’t guarentee that the driver WILL be loaded right
> > after disk.sys, but precautions have been taken about that issue. If
> > any other driver will try to modify the registry key and load itself
> > before us, then it also has tro support the hierarchy properly. Infact
> > partmgr.sys is usually loaded over disk.sys.
> >
> > “The second major problem you have is that if you read disk.sys a heck
> > of
> > a
> > lot of the data you are talking about is used by disk.sys, so if you
> > start
> > encrypting everything it is going to crash.”
> >
> > I do not understand this part of your statement. In the stack of
> > drivers, I am attaching my driver, above disk.sys, and as of now was
> > tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> > I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> > message, where as if I leave out the system area of the disc (bootsec
> > and MFT of that partition) then things work fine, ofcourse if I unload
> > the driver, these files cannot be read anymore.
> >
> > But I need to to a sector level encryption, I know there are softwares
> > that do it, and they also attach above disk.sys ( device tree shows me
> > so). Is there something I am missing out?
> >
> > “Bottom line, you have serious and unrecoverable design flaws in your
> > current
> > approach.”
> >
> > So then can you tell me a better approach please.
> >
> > Any advice would be appreciated.
> >
> >
> >
> >
> > On 8/3/05, Don Burn wrote:
> > > The first thing to realize is your statnent “sitting right above
> > > disk.sys”
> > > is impossible. One of the oldest and most common mistakes in
> > > designing
> > > filter driver is claiming “my driver is first”, you cannot guarantee
> > > that
> > > you will be the first filter above disk.sys, someone else may want
> > > that
> > > position, then who wins?
> > >
> > > The second major problem you have is that if you read disk.sys a heck
> > > of
> > > a
> > > lot of the data you are talking about is used by disk.sys, so if you
> > > start
> > > encrypting everything it is going to crash.
> > >
> > > Bottom line, you have serious and unrecoverable design flaws in your
> > > current
> > > approach.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > >
> > > “Developer” wrote in message
> > > news:xxxxx@ntdev…
> > > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > > and passing encrypted data to disk.sys and decrypting encrypted
> > > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > > tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > > IOCTL_DISK_IS_WRITABLE etc…etc.
> > >
> > > AFAIK IOCTLs have their own defined structures and these are pre
> > > determined, thus if a driver above me asks to get the drive info
> > > through IOCTL, how can I successfully decrypt the data in the disk
> > > sector that is needed and pass it on. The driver below me, disk.sys
> > > doesn’t know of the encryption, and would fetch garbage from the disk,
> > > populate the IOCTL structure with garbage(probably) and send it up.
> > >
> > > Thanks in advance.
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

well sir,

the picture is still not very clear to me too, however, AFAIK, the
only drivers and system files that need to be loaded through the boot
level driver are those that load befoer Disk.sys is loaded, after
disk.sys is loaded and out driver gets the handle, after that the 16
bit code to handle loading can be discarded.

I repeat, I am just experimenting, nothing concrete.

-Developer

On 8/3/05, Don Burn wrote:
> That isn’t enough, a large number of drivers plus parts of the registry will
> be loaded into the OS before your driver get loaded, how are you going to
> handle all the things a boot image needs before your driver starts working?
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> for booting part we have to use other mechanisms, such as modifying
> the MBR and loading the decryptor that essentially decrypts the
> kernel file and DISK.SYS and loads them into memory. Before the driver
> to help it read teh disk comes into place. That is a totally different
> module.
>
> Thanks don, though it complicated my problem, rather than solving it,
> it was great to get advice from you.
>
> regards,
>
> developer
>
>
>
> On 8/3/05, Don Burn wrote:
> > Go read disk.sys, I believe you will find that is understands a number of
> > these fields, and you encryption breaks this.
> >
> > Note: you still have the problem that you cannot do this to the boot
> > partition or the system partion.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > don,
> >
> > thanks again for taking the trouble. However, what you say, attaching
> > below disk.sys doesn’t seem to be solving my perpose, as I driver will
> > become very complex to implement.
> >
> > The other solution you suggested, is leaving out the system sectors of
> > the disk. Well, if I do that, then the driver essentially becomes a
> > file level encryptor, also, there are other issues that needs
> > attention then.
> > - Do I encrypt the root directory of the drive.
> > - How to find out where exactly the system sectors end, that is the
> > bootsec, the MFT and the root directory entries.
> > - Also one of the objectives is to even make windows load from an
> > encrypted drive, which is otherwise unreadable to the outside world.
> >
> > Keeping these into mind I had targetted disk.sys.
> >
> > One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
> > and WRITE out of them, send tem to disk.sys and in th completion
> > routine, decode the IRPs buffer and populate the IOCTL structures
> > accordingly, not an easy task, as there could be many different IOCTLs
> > ( please correct me if I am totally on th worng track).
> >
> > Can you throw some light on the pros and cons of this approach please.
> >
> > So, is it that full sector wise encryption of disks are not possible?
> > Software that claim to do it, as actually just eliminating the system
> > sectors?
> >
> > Thanks in advance.
> >
> > On 8/3/05, Don Burn wrote:
> > > Put the driver under disk.sys, this will have to be a different driver,
> > > since the requests will look different. Note, be sure not to do this to
> > > the
> > > system drive, or the boot drive since you will not be able to intercept
> > > everything.
> > >
> > > You are much better off, not encrypting the sectors you mentioned.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > >
> > > “Developer” wrote in message news:xxxxx@ntdev…
> > > hi don,
> > >
> > > Yes I know that I can’t guarentee that the driver WILL be loaded right
> > > after disk.sys, but precautions have been taken about that issue. If
> > > any other driver will try to modify the registry key and load itself
> > > before us, then it also has tro support the hierarchy properly. Infact
> > > partmgr.sys is usually loaded over disk.sys.
> > >
> > > “The second major problem you have is that if you read disk.sys a heck
> > > of
> > > a
> > > lot of the data you are talking about is used by disk.sys, so if you
> > > start
> > > encrypting everything it is going to crash.”
> > >
> > > I do not understand this part of your statement. In the stack of
> > > drivers, I am attaching my driver, above disk.sys, and as of now was
> > > tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> > > I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> > > message, where as if I leave out the system area of the disc (bootsec
> > > and MFT of that partition) then things work fine, ofcourse if I unload
> > > the driver, these files cannot be read anymore.
> > >
> > > But I need to to a sector level encryption, I know there are softwares
> > > that do it, and they also attach above disk.sys ( device tree shows me
> > > so). Is there something I am missing out?
> > >
> > > “Bottom line, you have serious and unrecoverable design flaws in your
> > > current
> > > approach.”
> > >
> > > So then can you tell me a better approach please.
> > >
> > > Any advice would be appreciated.
> > >
> > >
> > >
> > >
> > > On 8/3/05, Don Burn wrote:
> > > > The first thing to realize is your statnent “sitting right above
> > > > disk.sys”
> > > > is impossible. One of the oldest and most common mistakes in
> > > > designing
> > > > filter driver is claiming “my driver is first”, you cannot guarantee
> > > > that
> > > > you will be the first filter above disk.sys, someone else may want
> > > > that
> > > > position, then who wins?
> > > >
> > > > The second major problem you have is that if you read disk.sys a heck
> > > > of
> > > > a
> > > > lot of the data you are talking about is used by disk.sys, so if you
> > > > start
> > > > encrypting everything it is going to crash.
> > > >
> > > > Bottom line, you have serious and unrecoverable design flaws in your
> > > > current
> > > > approach.
> > > >
> > > >
> > > > –
> > > > Don Burn (MVP, Windows DDK)
> > > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > > Remove StopSpam from the email to reply
> > > >
> > > >
> > > >
> > > > “Developer” wrote in message
> > > > news:xxxxx@ntdev…
> > > > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > > > and passing encrypted data to disk.sys and decrypting encrypted
> > > > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > > > tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > > > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > > > IOCTL_DISK_IS_WRITABLE etc…etc.
> > > >
> > > > AFAIK IOCTLs have their own defined structures and these are pre
> > > > determined, thus if a driver above me asks to get the drive info
> > > > through IOCTL, how can I successfully decrypt the data in the disk
> > > > sector that is needed and pass it on. The driver below me, disk.sys
> > > > doesn’t know of the encryption, and would fetch garbage from the disk,
> > > > populate the IOCTL structure with garbage(probably) and send it up.
> > > >
> > > > Thanks in advance.
> > > > –
> > > >
> > > > - Developer
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

Sorry, there is a heck of a lot loaded before your driver is initialized.
This includes:

  1. Kernel and Hal
  2. The current control set of the registry hive
  3. Several other DLL’s for display and debug as needed
  4. All drivers marked as boot

You have to handle all of this!


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Developer” wrote in message news:xxxxx@ntdev…
well sir,

the picture is still not very clear to me too, however, AFAIK, the
only drivers and system files that need to be loaded through the boot
level driver are those that load befoer Disk.sys is loaded, after
disk.sys is loaded and out driver gets the handle, after that the 16
bit code to handle loading can be discarded.

I repeat, I am just experimenting, nothing concrete.

-Developer

On 8/3/05, Don Burn wrote:
> That isn’t enough, a large number of drivers plus parts of the registry
> will
> be loaded into the OS before your driver get loaded, how are you going to
> handle all the things a boot image needs before your driver starts
> working?
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> for booting part we have to use other mechanisms, such as modifying
> the MBR and loading the decryptor that essentially decrypts the
> kernel file and DISK.SYS and loads them into memory. Before the driver
> to help it read teh disk comes into place. That is a totally different
> module.
>
> Thanks don, though it complicated my problem, rather than solving it,
> it was great to get advice from you.
>
> regards,
>
> developer
>
>
>
> On 8/3/05, Don Burn wrote:
> > Go read disk.sys, I believe you will find that is understands a number
> > of
> > these fields, and you encryption breaks this.
> >
> > Note: you still have the problem that you cannot do this to the boot
> > partition or the system partion.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > don,
> >
> > thanks again for taking the trouble. However, what you say, attaching
> > below disk.sys doesn’t seem to be solving my perpose, as I driver will
> > become very complex to implement.
> >
> > The other solution you suggested, is leaving out the system sectors of
> > the disk. Well, if I do that, then the driver essentially becomes a
> > file level encryptor, also, there are other issues that needs
> > attention then.
> > - Do I encrypt the root directory of the drive.
> > - How to find out where exactly the system sectors end, that is the
> > bootsec, the MFT and the root directory entries.
> > - Also one of the objectives is to even make windows load from an
> > encrypted drive, which is otherwise unreadable to the outside world.
> >
> > Keeping these into mind I had targetted disk.sys.
> >
> > One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
> > and WRITE out of them, send tem to disk.sys and in th completion
> > routine, decode the IRPs buffer and populate the IOCTL structures
> > accordingly, not an easy task, as there could be many different IOCTLs
> > ( please correct me if I am totally on th worng track).
> >
> > Can you throw some light on the pros and cons of this approach please.
> >
> > So, is it that full sector wise encryption of disks are not possible?
> > Software that claim to do it, as actually just eliminating the system
> > sectors?
> >
> > Thanks in advance.
> >
> > On 8/3/05, Don Burn wrote:
> > > Put the driver under disk.sys, this will have to be a different
> > > driver,
> > > since the requests will look different. Note, be sure not to do this
> > > to
> > > the
> > > system drive, or the boot drive since you will not be able to
> > > intercept
> > > everything.
> > >
> > > You are much better off, not encrypting the sectors you mentioned.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > >
> > > “Developer” wrote in message
> > > news:xxxxx@ntdev…
> > > hi don,
> > >
> > > Yes I know that I can’t guarentee that the driver WILL be loaded right
> > > after disk.sys, but precautions have been taken about that issue. If
> > > any other driver will try to modify the registry key and load itself
> > > before us, then it also has tro support the hierarchy properly. Infact
> > > partmgr.sys is usually loaded over disk.sys.
> > >
> > > “The second major problem you have is that if you read disk.sys a heck
> > > of
> > > a
> > > lot of the data you are talking about is used by disk.sys, so if you
> > > start
> > > encrypting everything it is going to crash.”
> > >
> > > I do not understand this part of your statement. In the stack of
> > > drivers, I am attaching my driver, above disk.sys, and as of now was
> > > tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> > > I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> > > message, where as if I leave out the system area of the disc (bootsec
> > > and MFT of that partition) then things work fine, ofcourse if I unload
> > > the driver, these files cannot be read anymore.
> > >
> > > But I need to to a sector level encryption, I know there are softwares
> > > that do it, and they also attach above disk.sys ( device tree shows me
> > > so). Is there something I am missing out?
> > >
> > > “Bottom line, you have serious and unrecoverable design flaws in your
> > > current
> > > approach.”
> > >
> > > So then can you tell me a better approach please.
> > >
> > > Any advice would be appreciated.
> > >
> > >
> > >
> > >
> > > On 8/3/05, Don Burn wrote:
> > > > The first thing to realize is your statnent “sitting right above
> > > > disk.sys”
> > > > is impossible. One of the oldest and most common mistakes in
> > > > designing
> > > > filter driver is claiming “my driver is first”, you cannot guarantee
> > > > that
> > > > you will be the first filter above disk.sys, someone else may want
> > > > that
> > > > position, then who wins?
> > > >
> > > > The second major problem you have is that if you read disk.sys a
> > > > heck
> > > > of
> > > > a
> > > > lot of the data you are talking about is used by disk.sys, so if you
> > > > start
> > > > encrypting everything it is going to crash.
> > > >
> > > > Bottom line, you have serious and unrecoverable design flaws in your
> > > > current
> > > > approach.
> > > >
> > > >
> > > > –
> > > > Don Burn (MVP, Windows DDK)
> > > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > > Remove StopSpam from the email to reply
> > > >
> > > >
> > > >
> > > > “Developer” wrote in message
> > > > news:xxxxx@ntdev…
> > > > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > > > and passing encrypted data to disk.sys and decrypting encrypted
> > > > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > > > tap the IOCTL calls to the system, like
> > > > IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > > > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > > > IOCTL_DISK_IS_WRITABLE etc…etc.
> > > >
> > > > AFAIK IOCTLs have their own defined structures and these are pre
> > > > determined, thus if a driver above me asks to get the drive info
> > > > through IOCTL, how can I successfully decrypt the data in the disk
> > > > sector that is needed and pass it on. The driver below me, disk.sys
> > > > doesn’t know of the encryption, and would fetch garbage from the
> > > > disk,
> > > > populate the IOCTL structure with garbage(probably) and send it up.
> > > >
> > > > Thanks in advance.
> > > > –
> > > >
> > > > - Developer
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > To unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

I think you need to find one of the “Inside Windows 2000” books and read it.
There is a LOT that happens before DISK.SYS or the kernel is accessed.
Modifying the MBR provides a weak link since there is no way you can assure
that the MBR you are reading is the MBR you wrote.

From what I am reading, your task really is a prime candidate for full disc
encryption. FDE, at least as Seagate’s does it, encrypts the ENTIRE disc
when it is enabled, including the MBR, and it is totally transparent to the
OS. Even a crash dump will be encrypted since it is the disc firmware that
is performing the crypto functions. It seems that just the savings in
man-hours alone to provide a kernel level solution would be worth
investigating the new drives on the market with FDE.


The personal opinion of
Gary G. Little

“Developer” wrote in message news:xxxxx@ntdev…
for booting part we have to use other mechanisms, such as modifying
the MBR and loading the decryptor that essentially decrypts the
kernel file and DISK.SYS and loads them into memory. Before the driver
to help it read teh disk comes into place. That is a totally different
module.

Thanks don, though it complicated my problem, rather than solving it,
it was great to get advice from you.

regards,

developer

On 8/3/05, Don Burn wrote:
> Go read disk.sys, I believe you will find that is understands a number of
> these fields, and you encryption breaks this.
>
> Note: you still have the problem that you cannot do this to the boot
> partition or the system partion.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> don,
>
> thanks again for taking the trouble. However, what you say, attaching
> below disk.sys doesn’t seem to be solving my perpose, as I driver will
> become very complex to implement.
>
> The other solution you suggested, is leaving out the system sectors of
> the disk. Well, if I do that, then the driver essentially becomes a
> file level encryptor, also, there are other issues that needs
> attention then.
> - Do I encrypt the root directory of the drive.
> - How to find out where exactly the system sectors end, that is the
> bootsec, the MFT and the root directory entries.
> - Also one of the objectives is to even make windows load from an
> encrypted drive, which is otherwise unreadable to the outside world.
>
> Keeping these into mind I had targetted disk.sys.
>
> One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
> and WRITE out of them, send tem to disk.sys and in th completion
> routine, decode the IRPs buffer and populate the IOCTL structures
> accordingly, not an easy task, as there could be many different IOCTLs
> ( please correct me if I am totally on th worng track).
>
> Can you throw some light on the pros and cons of this approach please.
>
> So, is it that full sector wise encryption of disks are not possible?
> Software that claim to do it, as actually just eliminating the system
> sectors?
>
> Thanks in advance.
>
> On 8/3/05, Don Burn wrote:
> > Put the driver under disk.sys, this will have to be a different driver,
> > since the requests will look different. Note, be sure not to do this to
> > the
> > system drive, or the boot drive since you will not be able to intercept
> > everything.
> >
> > You are much better off, not encrypting the sectors you mentioned.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > hi don,
> >
> > Yes I know that I can’t guarentee that the driver WILL be loaded right
> > after disk.sys, but precautions have been taken about that issue. If
> > any other driver will try to modify the registry key and load itself
> > before us, then it also has tro support the hierarchy properly. Infact
> > partmgr.sys is usually loaded over disk.sys.
> >
> > “The second major problem you have is that if you read disk.sys a heck
> > of
> > a
> > lot of the data you are talking about is used by disk.sys, so if you
> > start
> > encrypting everything it is going to crash.”
> >
> > I do not understand this part of your statement. In the stack of
> > drivers, I am attaching my driver, above disk.sys, and as of now was
> > tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> > I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> > message, where as if I leave out the system area of the disc (bootsec
> > and MFT of that partition) then things work fine, ofcourse if I unload
> > the driver, these files cannot be read anymore.
> >
> > But I need to to a sector level encryption, I know there are softwares
> > that do it, and they also attach above disk.sys ( device tree shows me
> > so). Is there something I am missing out?
> >
> > “Bottom line, you have serious and unrecoverable design flaws in your
> > current
> > approach.”
> >
> > So then can you tell me a better approach please.
> >
> > Any advice would be appreciated.
> >
> >
> >
> >
> > On 8/3/05, Don Burn wrote:
> > > The first thing to realize is your statnent “sitting right above
> > > disk.sys”
> > > is impossible. One of the oldest and most common mistakes in
> > > designing
> > > filter driver is claiming “my driver is first”, you cannot guarantee
> > > that
> > > you will be the first filter above disk.sys, someone else may want
> > > that
> > > position, then who wins?
> > >
> > > The second major problem you have is that if you read disk.sys a heck
> > > of
> > > a
> > > lot of the data you are talking about is used by disk.sys, so if you
> > > start
> > > encrypting everything it is going to crash.
> > >
> > > Bottom line, you have serious and unrecoverable design flaws in your
> > > current
> > > approach.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > >
> > > “Developer” wrote in message
> > > news:xxxxx@ntdev…
> > > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > > and passing encrypted data to disk.sys and decrypting encrypted
> > > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > > tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > > IOCTL_DISK_IS_WRITABLE etc…etc.
> > >
> > > AFAIK IOCTLs have their own defined structures and these are pre
> > > determined, thus if a driver above me asks to get the drive info
> > > through IOCTL, how can I successfully decrypt the data in the disk
> > > sector that is needed and pass it on. The driver below me, disk.sys
> > > doesn’t know of the encryption, and would fetch garbage from the disk,
> > > populate the IOCTL structure with garbage(probably) and send it up.
> > >
> > > Thanks in advance.
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

ok, this is a good input for me sir. Your advice is good.

Even if I let go for the boot partition, and go for other partitions
in the drive I am facing something strange.

As of now, the picture is like this,

DIsk.sys is loaded, then Mydriver.sys and tehn Partmgr.sys.

If I understand correctly, partmgr is responsible for all partition
related information. So all partition related IOCTLS should be handled
by the partmgr.sys file and these IOCTLS should be converted to
correcponding IRP_MJ_READ/WRITE requests and sent down to the disk.sys
file, which being a sector level driver should ideally have the
intelligence only to read nad write sectors and do some power
management.

But I still find, the several IOCTLs related to disk partition
information are sent down to disk.sys. Why is that so. Isnt it the
responsibility of partmgr.sys to handle those IOCTLs

NOTE:- 1. I did change the registry keys, so that my driver gets
loaded before partmgr.
2. In case of encrypting the boot partition, we need t
oconsider hibernation and crash dump handling also, that AFAIK
bypasses the driver stack and uses it’s own (diskdump.sys ) :slight_smile:

Please advice sir.

  • Developer

On 8/3/05, Don Burn wrote:
> Sorry, there is a heck of a lot loaded before your driver is initialized.
> This includes:
>
> 1. Kernel and Hal
> 2. The current control set of the registry hive
> 3. Several other DLL’s for display and debug as needed
> 4. All drivers marked as boot
>
> You have to handle all of this!
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
> “Developer” wrote in message news:xxxxx@ntdev…
> well sir,
>
> the picture is still not very clear to me too, however, AFAIK, the
> only drivers and system files that need to be loaded through the boot
> level driver are those that load befoer Disk.sys is loaded, after
> disk.sys is loaded and out driver gets the handle, after that the 16
> bit code to handle loading can be discarded.
>
> I repeat, I am just experimenting, nothing concrete.
>
> -Developer
>
> On 8/3/05, Don Burn wrote:
> > That isn’t enough, a large number of drivers plus parts of the registry
> > will
> > be loaded into the OS before your driver get loaded, how are you going to
> > handle all the things a boot image needs before your driver starts
> > working?
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > for booting part we have to use other mechanisms, such as modifying
> > the MBR and loading the decryptor that essentially decrypts the
> > kernel file and DISK.SYS and loads them into memory. Before the driver
> > to help it read teh disk comes into place. That is a totally different
> > module.
> >
> > Thanks don, though it complicated my problem, rather than solving it,
> > it was great to get advice from you.
> >
> > regards,
> >
> > developer
> >
> >
> >
> > On 8/3/05, Don Burn wrote:
> > > Go read disk.sys, I believe you will find that is understands a number
> > > of
> > > these fields, and you encryption breaks this.
> > >
> > > Note: you still have the problem that you cannot do this to the boot
> > > partition or the system partion.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > >
> > > “Developer” wrote in message news:xxxxx@ntdev…
> > > don,
> > >
> > > thanks again for taking the trouble. However, what you say, attaching
> > > below disk.sys doesn’t seem to be solving my perpose, as I driver will
> > > become very complex to implement.
> > >
> > > The other solution you suggested, is leaving out the system sectors of
> > > the disk. Well, if I do that, then the driver essentially becomes a
> > > file level encryptor, also, there are other issues that needs
> > > attention then.
> > > - Do I encrypt the root directory of the drive.
> > > - How to find out where exactly the system sectors end, that is the
> > > bootsec, the MFT and the root directory entries.
> > > - Also one of the objectives is to even make windows load from an
> > > encrypted drive, which is otherwise unreadable to the outside world.
> > >
> > > Keeping these into mind I had targetted disk.sys.
> > >
> > > One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
> > > and WRITE out of them, send tem to disk.sys and in th completion
> > > routine, decode the IRPs buffer and populate the IOCTL structures
> > > accordingly, not an easy task, as there could be many different IOCTLs
> > > ( please correct me if I am totally on th worng track).
> > >
> > > Can you throw some light on the pros and cons of this approach please.
> > >
> > > So, is it that full sector wise encryption of disks are not possible?
> > > Software that claim to do it, as actually just eliminating the system
> > > sectors?
> > >
> > > Thanks in advance.
> > >
> > > On 8/3/05, Don Burn wrote:
> > > > Put the driver under disk.sys, this will have to be a different
> > > > driver,
> > > > since the requests will look different. Note, be sure not to do this
> > > > to
> > > > the
> > > > system drive, or the boot drive since you will not be able to
> > > > intercept
> > > > everything.
> > > >
> > > > You are much better off, not encrypting the sectors you mentioned.
> > > >
> > > >
> > > > –
> > > > Don Burn (MVP, Windows DDK)
> > > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > > Remove StopSpam from the email to reply
> > > >
> > > >
> > > >
> > > > “Developer” wrote in message
> > > > news:xxxxx@ntdev…
> > > > hi don,
> > > >
> > > > Yes I know that I can’t guarentee that the driver WILL be loaded right
> > > > after disk.sys, but precautions have been taken about that issue. If
> > > > any other driver will try to modify the registry key and load itself
> > > > before us, then it also has tro support the hierarchy properly. Infact
> > > > partmgr.sys is usually loaded over disk.sys.
> > > >
> > > > “The second major problem you have is that if you read disk.sys a heck
> > > > of
> > > > a
> > > > lot of the data you are talking about is used by disk.sys, so if you
> > > > start
> > > > encrypting everything it is going to crash.”
> > > >
> > > > I do not understand this part of your statement. In the stack of
> > > > drivers, I am attaching my driver, above disk.sys, and as of now was
> > > > tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> > > > I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> > > > message, where as if I leave out the system area of the disc (bootsec
> > > > and MFT of that partition) then things work fine, ofcourse if I unload
> > > > the driver, these files cannot be read anymore.
> > > >
> > > > But I need to to a sector level encryption, I know there are softwares
> > > > that do it, and they also attach above disk.sys ( device tree shows me
> > > > so). Is there something I am missing out?
> > > >
> > > > “Bottom line, you have serious and unrecoverable design flaws in your
> > > > current
> > > > approach.”
> > > >
> > > > So then can you tell me a better approach please.
> > > >
> > > > Any advice would be appreciated.
> > > >
> > > >
> > > >
> > > >
> > > > On 8/3/05, Don Burn wrote:
> > > > > The first thing to realize is your statnent “sitting right above
> > > > > disk.sys”
> > > > > is impossible. One of the oldest and most common mistakes in
> > > > > designing
> > > > > filter driver is claiming “my driver is first”, you cannot guarantee
> > > > > that
> > > > > you will be the first filter above disk.sys, someone else may want
> > > > > that
> > > > > position, then who wins?
> > > > >
> > > > > The second major problem you have is that if you read disk.sys a
> > > > > heck
> > > > > of
> > > > > a
> > > > > lot of the data you are talking about is used by disk.sys, so if you
> > > > > start
> > > > > encrypting everything it is going to crash.
> > > > >
> > > > > Bottom line, you have serious and unrecoverable design flaws in your
> > > > > current
> > > > > approach.
> > > > >
> > > > >
> > > > > –
> > > > > Don Burn (MVP, Windows DDK)
> > > > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > > > Remove StopSpam from the email to reply
> > > > >
> > > > >
> > > > >
> > > > > “Developer” wrote in message
> > > > > news:xxxxx@ntdev…
> > > > > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > > > > and passing encrypted data to disk.sys and decrypting encrypted
> > > > > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > > > > tap the IOCTL calls to the system, like
> > > > > IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > > > > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > > > > IOCTL_DISK_IS_WRITABLE etc…etc.
> > > > >
> > > > > AFAIK IOCTLs have their own defined structures and these are pre
> > > > > determined, thus if a driver above me asks to get the drive info
> > > > > through IOCTL, how can I successfully decrypt the data in the disk
> > > > > sector that is needed and pass it on. The driver below me, disk.sys
> > > > > doesn’t know of the encryption, and would fetch garbage from the
> > > > > disk,
> > > > > populate the IOCTL structure with garbage(probably) and send it up.
> > > > >
> > > > > Thanks in advance.
> > > > > –
> > > > >
> > > > > - Developer
> > > > >
> > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > > To unsubscribe send a blank email to
> > > > > xxxxx@lists.osr.com
> > > > >
> > > >
> > > >
> > > > –
> > > >
> > > > - Developer
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

gary,

you are right, that is the whole excercise. I have read several books,
including Inside Windows 2K, The W2K Dev Drv Book - Baker, Walter
Oney’s book and Rajiv Nagaar’s book. However, nothing firm was found
in them.

If you have any pointers that would be of immense help. Yes I know,
hibernation and crash dump is another uncharted territory, where we
are to investigate. Have you any idea about how to go with that?

Help is would be appreciated.

Thanks a ton in advance to all of you,

  • Amitrajit (Developer)

On 8/3/05, Gary G. Little wrote:
> I think you need to find one of the “Inside Windows 2000” books and read it.
> There is a LOT that happens before DISK.SYS or the kernel is accessed.
> Modifying the MBR provides a weak link since there is no way you can assure
> that the MBR you are reading is the MBR you wrote.
>
> From what I am reading, your task really is a prime candidate for full disc
> encryption. FDE, at least as Seagate’s does it, encrypts the ENTIRE disc
> when it is enabled, including the MBR, and it is totally transparent to the
> OS. Even a crash dump will be encrypted since it is the disc firmware that
> is performing the crypto functions. It seems that just the savings in
> man-hours alone to provide a kernel level solution would be worth
> investigating the new drives on the market with FDE.
>
> –
> The personal opinion of
> Gary G. Little
>
> “Developer” wrote in message news:xxxxx@ntdev…
> for booting part we have to use other mechanisms, such as modifying
> the MBR and loading the decryptor that essentially decrypts the
> kernel file and DISK.SYS and loads them into memory. Before the driver
> to help it read teh disk comes into place. That is a totally different
> module.
>
> Thanks don, though it complicated my problem, rather than solving it,
> it was great to get advice from you.
>
> regards,
>
> developer
>
>
>
> On 8/3/05, Don Burn wrote:
> > Go read disk.sys, I believe you will find that is understands a number of
> > these fields, and you encryption breaks this.
> >
> > Note: you still have the problem that you cannot do this to the boot
> > partition or the system partion.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > don,
> >
> > thanks again for taking the trouble. However, what you say, attaching
> > below disk.sys doesn’t seem to be solving my perpose, as I driver will
> > become very complex to implement.
> >
> > The other solution you suggested, is leaving out the system sectors of
> > the disk. Well, if I do that, then the driver essentially becomes a
> > file level encryptor, also, there are other issues that needs
> > attention then.
> > - Do I encrypt the root directory of the drive.
> > - How to find out where exactly the system sectors end, that is the
> > bootsec, the MFT and the root directory entries.
> > - Also one of the objectives is to even make windows load from an
> > encrypted drive, which is otherwise unreadable to the outside world.
> >
> > Keeping these into mind I had targetted disk.sys.
> >
> > One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
> > and WRITE out of them, send tem to disk.sys and in th completion
> > routine, decode the IRPs buffer and populate the IOCTL structures
> > accordingly, not an easy task, as there could be many different IOCTLs
> > ( please correct me if I am totally on th worng track).
> >
> > Can you throw some light on the pros and cons of this approach please.
> >
> > So, is it that full sector wise encryption of disks are not possible?
> > Software that claim to do it, as actually just eliminating the system
> > sectors?
> >
> > Thanks in advance.
> >
> > On 8/3/05, Don Burn wrote:
> > > Put the driver under disk.sys, this will have to be a different driver,
> > > since the requests will look different. Note, be sure not to do this to
> > > the
> > > system drive, or the boot drive since you will not be able to intercept
> > > everything.
> > >
> > > You are much better off, not encrypting the sectors you mentioned.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > >
> > > “Developer” wrote in message news:xxxxx@ntdev…
> > > hi don,
> > >
> > > Yes I know that I can’t guarentee that the driver WILL be loaded right
> > > after disk.sys, but precautions have been taken about that issue. If
> > > any other driver will try to modify the registry key and load itself
> > > before us, then it also has tro support the hierarchy properly. Infact
> > > partmgr.sys is usually loaded over disk.sys.
> > >
> > > “The second major problem you have is that if you read disk.sys a heck
> > > of
> > > a
> > > lot of the data you are talking about is used by disk.sys, so if you
> > > start
> > > encrypting everything it is going to crash.”
> > >
> > > I do not understand this part of your statement. In the stack of
> > > drivers, I am attaching my driver, above disk.sys, and as of now was
> > > tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> > > I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> > > message, where as if I leave out the system area of the disc (bootsec
> > > and MFT of that partition) then things work fine, ofcourse if I unload
> > > the driver, these files cannot be read anymore.
> > >
> > > But I need to to a sector level encryption, I know there are softwares
> > > that do it, and they also attach above disk.sys ( device tree shows me
> > > so). Is there something I am missing out?
> > >
> > > “Bottom line, you have serious and unrecoverable design flaws in your
> > > current
> > > approach.”
> > >
> > > So then can you tell me a better approach please.
> > >
> > > Any advice would be appreciated.
> > >
> > >
> > >
> > >
> > > On 8/3/05, Don Burn wrote:
> > > > The first thing to realize is your statnent “sitting right above
> > > > disk.sys”
> > > > is impossible. One of the oldest and most common mistakes in
> > > > designing
> > > > filter driver is claiming “my driver is first”, you cannot guarantee
> > > > that
> > > > you will be the first filter above disk.sys, someone else may want
> > > > that
> > > > position, then who wins?
> > > >
> > > > The second major problem you have is that if you read disk.sys a heck
> > > > of
> > > > a
> > > > lot of the data you are talking about is used by disk.sys, so if you
> > > > start
> > > > encrypting everything it is going to crash.
> > > >
> > > > Bottom line, you have serious and unrecoverable design flaws in your
> > > > current
> > > > approach.
> > > >
> > > >
> > > > –
> > > > Don Burn (MVP, Windows DDK)
> > > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > > Remove StopSpam from the email to reply
> > > >
> > > >
> > > >
> > > > “Developer” wrote in message
> > > > news:xxxxx@ntdev…
> > > > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > > > and passing encrypted data to disk.sys and decrypting encrypted
> > > > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > > > tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > > > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > > > IOCTL_DISK_IS_WRITABLE etc…etc.
> > > >
> > > > AFAIK IOCTLs have their own defined structures and these are pre
> > > > determined, thus if a driver above me asks to get the drive info
> > > > through IOCTL, how can I successfully decrypt the data in the disk
> > > > sector that is needed and pass it on. The driver below me, disk.sys
> > > > doesn’t know of the encryption, and would fetch garbage from the disk,
> > > > populate the IOCTL structure with garbage(probably) and send it up.
> > > >
> > > > Thanks in advance.
> > > > –
> > > >
> > > > - Developer
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

Check the archives, this has been discussed a dozen times.

Chuck

----- Original Message -----
From: “Developer”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, August 03, 2005 6:53 AM
Subject: [ntdev] a silly doubt

> for a disc encryptor/decryptor driver, sitting right above disk.sys
> and passing encrypted data to disk.sys and decrypting encrypted
> sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> IOCTL_DISK_IS_WRITABLE etc…etc.
>
> AFAIK IOCTLs have their own defined structures and these are pre
> determined, thus if a driver above me asks to get the drive info
> through IOCTL, how can I successfully decrypt the data in the disk
> sector that is needed and pass it on. The driver below me, disk.sys
> doesn’t know of the encryption, and would fetch garbage from the disk,
> populate the IOCTL structure with garbage(probably) and send it up.
>
> Thanks in advance.
> –
>
> - Developer

> 1. Kernel and Hal

  1. The current control set of the registry hive

Whole SYSTEM hive.

  1. Several other DLL’s for display and debug as needed
  2. All drivers marked as boot
  1. NLS charset tables.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

hi chuck, thanks for the pointer, but there are so many thereads
running ,I tried findins and reading them, abd I *cannot* search, due
to system restrictions of the network. it would be gud if you could
send me the links please.

On 8/3/05, Chuck Batson wrote:
> Check the archives, this has been discussed a dozen times.
>
> Chuck
>
> ----- Original Message -----
> From: “Developer”
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, August 03, 2005 6:53 AM
> Subject: [ntdev] a silly doubt
>
>
> > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > and passing encrypted data to disk.sys and decrypting encrypted
> > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > tap the IOCTL calls to the system, like IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > IOCTL_DISK_IS_WRITABLE etc…etc.
> >
> > AFAIK IOCTLs have their own defined structures and these are pre
> > determined, thus if a driver above me asks to get the drive info
> > through IOCTL, how can I successfully decrypt the data in the disk
> > sector that is needed and pass it on. The driver below me, disk.sys
> > doesn’t know of the encryption, and would fetch garbage from the disk,
> > populate the IOCTL structure with garbage(probably) and send it up.
> >
> > Thanks in advance.
> > –
> >
> > - Developer
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

My suggestion is what I have already suggested: FDE. Encrypting the
Hiberfile and a crash dump file may well be impossible since I have read
those do not go through storage stack and hence will not see your filter.
An FDE disc will encrypt the Hiberfile and a crash dump file since it is the
disc firmware that has the crypto functions.


The personal opinion of
Gary G. Little

“Developer” wrote in message news:xxxxx@ntdev…
gary,

you are right, that is the whole excercise. I have read several books,
including Inside Windows 2K, The W2K Dev Drv Book - Baker, Walter
Oney’s book and Rajiv Nagaar’s book. However, nothing firm was found
in them.

If you have any pointers that would be of immense help. Yes I know,
hibernation and crash dump is another uncharted territory, where we
are to investigate. Have you any idea about how to go with that?

Help is would be appreciated.

Thanks a ton in advance to all of you,

- Amitrajit (Developer)

On 8/3/05, Gary G. Little wrote:
> I think you need to find one of the “Inside Windows 2000” books and read
> it.
> There is a LOT that happens before DISK.SYS or the kernel is accessed.
> Modifying the MBR provides a weak link since there is no way you can
> assure
> that the MBR you are reading is the MBR you wrote.
>
> From what I am reading, your task really is a prime candidate for full
> disc
> encryption. FDE, at least as Seagate’s does it, encrypts the ENTIRE disc
> when it is enabled, including the MBR, and it is totally transparent to
> the
> OS. Even a crash dump will be encrypted since it is the disc firmware that
> is performing the crypto functions. It seems that just the savings in
> man-hours alone to provide a kernel level solution would be worth
> investigating the new drives on the market with FDE.
>
> –
> The personal opinion of
> Gary G. Little
>
> “Developer” wrote in message news:xxxxx@ntdev…
> for booting part we have to use other mechanisms, such as modifying
> the MBR and loading the decryptor that essentially decrypts the
> kernel file and DISK.SYS and loads them into memory. Before the driver
> to help it read teh disk comes into place. That is a totally different
> module.
>
> Thanks don, though it complicated my problem, rather than solving it,
> it was great to get advice from you.
>
> regards,
>
> developer
>
>
>
> On 8/3/05, Don Burn wrote:
> > Go read disk.sys, I believe you will find that is understands a number
> > of
> > these fields, and you encryption breaks this.
> >
> > Note: you still have the problem that you cannot do this to the boot
> > partition or the system partion.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > “Developer” wrote in message news:xxxxx@ntdev…
> > don,
> >
> > thanks again for taking the trouble. However, what you say, attaching
> > below disk.sys doesn’t seem to be solving my perpose, as I driver will
> > become very complex to implement.
> >
> > The other solution you suggested, is leaving out the system sectors of
> > the disk. Well, if I do that, then the driver essentially becomes a
> > file level encryptor, also, there are other issues that needs
> > attention then.
> > - Do I encrypt the root directory of the drive.
> > - How to find out where exactly the system sectors end, that is the
> > bootsec, the MFT and the root directory entries.
> > - Also one of the objectives is to even make windows load from an
> > encrypted drive, which is otherwise unreadable to the outside world.
> >
> > Keeping these into mind I had targetted disk.sys.
> >
> > One thing I can think of is, intercept the IOCTLs, make IRP_MJ_READ
> > and WRITE out of them, send tem to disk.sys and in th completion
> > routine, decode the IRPs buffer and populate the IOCTL structures
> > accordingly, not an easy task, as there could be many different IOCTLs
> > ( please correct me if I am totally on th worng track).
> >
> > Can you throw some light on the pros and cons of this approach please.
> >
> > So, is it that full sector wise encryption of disks are not possible?
> > Software that claim to do it, as actually just eliminating the system
> > sectors?
> >
> > Thanks in advance.
> >
> > On 8/3/05, Don Burn wrote:
> > > Put the driver under disk.sys, this will have to be a different
> > > driver,
> > > since the requests will look different. Note, be sure not to do this
> > > to
> > > the
> > > system drive, or the boot drive since you will not be able to
> > > intercept
> > > everything.
> > >
> > > You are much better off, not encrypting the sectors you mentioned.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > >
> > > “Developer” wrote in message
> > > news:xxxxx@ntdev…
> > > hi don,
> > >
> > > Yes I know that I can’t guarentee that the driver WILL be loaded right
> > > after disk.sys, but precautions have been taken about that issue. If
> > > any other driver will try to modify the registry key and load itself
> > > before us, then it also has tro support the hierarchy properly. Infact
> > > partmgr.sys is usually loaded over disk.sys.
> > >
> > > “The second major problem you have is that if you read disk.sys a heck
> > > of
> > > a
> > > lot of the data you are talking about is used by disk.sys, so if you
> > > start
> > > encrypting everything it is going to crash.”
> > >
> > > I do not understand this part of your statement. In the stack of
> > > drivers, I am attaching my driver, above disk.sys, and as of now was
> > > tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right, when
> > > I try to read an entirely encrypted disc, I get a “Disk Not Formatted”
> > > message, where as if I leave out the system area of the disc (bootsec
> > > and MFT of that partition) then things work fine, ofcourse if I unload
> > > the driver, these files cannot be read anymore.
> > >
> > > But I need to to a sector level encryption, I know there are softwares
> > > that do it, and they also attach above disk.sys ( device tree shows me
> > > so). Is there something I am missing out?
> > >
> > > “Bottom line, you have serious and unrecoverable design flaws in your
> > > current
> > > approach.”
> > >
> > > So then can you tell me a better approach please.
> > >
> > > Any advice would be appreciated.
> > >
> > >
> > >
> > >
> > > On 8/3/05, Don Burn wrote:
> > > > The first thing to realize is your statnent “sitting right above
> > > > disk.sys”
> > > > is impossible. One of the oldest and most common mistakes in
> > > > designing
> > > > filter driver is claiming “my driver is first”, you cannot guarantee
> > > > that
> > > > you will be the first filter above disk.sys, someone else may want
> > > > that
> > > > position, then who wins?
> > > >
> > > > The second major problem you have is that if you read disk.sys a
> > > > heck
> > > > of
> > > > a
> > > > lot of the data you are talking about is used by disk.sys, so if you
> > > > start
> > > > encrypting everything it is going to crash.
> > > >
> > > > Bottom line, you have serious and unrecoverable design flaws in your
> > > > current
> > > > approach.
> > > >
> > > >
> > > > –
> > > > Don Burn (MVP, Windows DDK)
> > > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > > Remove StopSpam from the email to reply
> > > >
> > > >
> > > >
> > > > “Developer” wrote in message
> > > > news:xxxxx@ntdev…
> > > > for a disc encryptor/decryptor driver, sitting right above disk.sys
> > > > and passing encrypted data to disk.sys and decrypting encrypted
> > > > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need to also
> > > > tap the IOCTL calls to the system, like
> > > > IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > > > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > > > IOCTL_DISK_IS_WRITABLE etc…etc.
> > > >
> > > > AFAIK IOCTLs have their own defined structures and these are pre
> > > > determined, thus if a driver above me asks to get the drive info
> > > > through IOCTL, how can I successfully decrypt the data in the disk
> > > > sector that is needed and pass it on. The driver below me, disk.sys
> > > > doesn’t know of the encryption, and would fetch garbage from the
> > > > disk,
> > > > populate the IOCTL structure with garbage(probably) and send it up.
> > > >
> > > > Thanks in advance.
> > > > –
> > > >
> > > > - Developer
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > To unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

You misunderstand what partmgr does (on windows XP and server 2003). It
does not handle the partitioning I/O controls - it simply hands
partitions enumerated by the disk driver off to volume management
drivers.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, August 03, 2005 8:16 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] a silly doubt

ok, this is a good input for me sir. Your advice is good.

Even if I let go for the boot partition, and go for other partitions
in the drive I am facing something strange.

As of now, the picture is like this,

DIsk.sys is loaded, then Mydriver.sys and tehn Partmgr.sys.

If I understand correctly, partmgr is responsible for all partition
related information. So all partition related IOCTLS should be handled
by the partmgr.sys file and these IOCTLS should be converted to
correcponding IRP_MJ_READ/WRITE requests and sent down to the disk.sys
file, which being a sector level driver should ideally have the
intelligence only to read nad write sectors and do some power
management.

But I still find, the several IOCTLs related to disk partition
information are sent down to disk.sys. Why is that so. Isnt it the
responsibility of partmgr.sys to handle those IOCTLs

NOTE:- 1. I did change the registry keys, so that my driver gets
loaded before partmgr.
2. In case of encrypting the boot partition, we need t
oconsider hibernation and crash dump handling also, that AFAIK
bypasses the driver stack and uses it’s own (diskdump.sys ) :slight_smile:

Please advice sir.

  • Developer

On 8/3/05, Don Burn wrote:
> Sorry, there is a heck of a lot loaded before your driver is
initialized.
> This includes:
>
> 1. Kernel and Hal
> 2. The current control set of the registry hive
> 3. Several other DLL’s for display and debug as needed
> 4. All drivers marked as boot
>
> You have to handle all of this!
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
> “Developer” wrote in message
news:xxxxx@ntdev…
> well sir,
>
> the picture is still not very clear to me too, however, AFAIK, the
> only drivers and system files that need to be loaded through the boot
> level driver are those that load befoer Disk.sys is loaded, after
> disk.sys is loaded and out driver gets the handle, after that the 16
> bit code to handle loading can be discarded.
>
> I repeat, I am just experimenting, nothing concrete.
>
> -Developer
>
> On 8/3/05, Don Burn wrote:
> > That isn’t enough, a large number of drivers plus parts of the
registry
> > will
> > be loaded into the OS before your driver get loaded, how are you
going to
> > handle all the things a boot image needs before your driver starts
> > working?
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> > “Developer” wrote in message
news:xxxxx@ntdev…
> > for booting part we have to use other mechanisms, such as modifying
> > the MBR and loading the decryptor that essentially decrypts the
> > kernel file and DISK.SYS and loads them into memory. Before the
driver
> > to help it read teh disk comes into place. That is a totally
different
> > module.
> >
> > Thanks don, though it complicated my problem, rather than solving
it,
> > it was great to get advice from you.
> >
> > regards,
> >
> > developer
> >
> >
> >
> > On 8/3/05, Don Burn wrote:
> > > Go read disk.sys, I believe you will find that is understands a
number
> > > of
> > > these fields, and you encryption breaks this.
> > >
> > > Note: you still have the problem that you cannot do this to the
boot
> > > partition or the system partion.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > >
> > >
> > > “Developer” wrote in message
news:xxxxx@ntdev…
> > > don,
> > >
> > > thanks again for taking the trouble. However, what you say,
attaching
> > > below disk.sys doesn’t seem to be solving my perpose, as I driver
will
> > > become very complex to implement.
> > >
> > > The other solution you suggested, is leaving out the system
sectors of
> > > the disk. Well, if I do that, then the driver essentially becomes
a
> > > file level encryptor, also, there are other issues that needs
> > > attention then.
> > > - Do I encrypt the root directory of the drive.
> > > - How to find out where exactly the system sectors end, that is
the
> > > bootsec, the MFT and the root directory entries.
> > > - Also one of the objectives is to even make windows load from an
> > > encrypted drive, which is otherwise unreadable to the outside
world.
> > >
> > > Keeping these into mind I had targetted disk.sys.
> > >
> > > One thing I can think of is, intercept the IOCTLs, make
IRP_MJ_READ
> > > and WRITE out of them, send tem to disk.sys and in th completion
> > > routine, decode the IRPs buffer and populate the IOCTL structures
> > > accordingly, not an easy task, as there could be many different
IOCTLs
> > > ( please correct me if I am totally on th worng track).
> > >
> > > Can you throw some light on the pros and cons of this approach
please.
> > >
> > > So, is it that full sector wise encryption of disks are not
possible?
> > > Software that claim to do it, as actually just eliminating the
system
> > > sectors?
> > >
> > > Thanks in advance.
> > >
> > > On 8/3/05, Don Burn wrote:
> > > > Put the driver under disk.sys, this will have to be a different
> > > > driver,
> > > > since the requests will look different. Note, be sure not to do
this
> > > > to
> > > > the
> > > > system drive, or the boot drive since you will not be able to
> > > > intercept
> > > > everything.
> > > >
> > > > You are much better off, not encrypting the sectors you
mentioned.
> > > >
> > > >
> > > > –
> > > > Don Burn (MVP, Windows DDK)
> > > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > > Remove StopSpam from the email to reply
> > > >
> > > >
> > > >
> > > > “Developer” wrote in message
> > > > news:xxxxx@ntdev…
> > > > hi don,
> > > >
> > > > Yes I know that I can’t guarentee that the driver WILL be loaded
right
> > > > after disk.sys, but precautions have been taken about that
issue. If
> > > > any other driver will try to modify the registry key and load
itself
> > > > before us, then it also has tro support the hierarchy properly.
Infact
> > > > partmgr.sys is usually loaded over disk.sys.
> > > >
> > > > “The second major problem you have is that if you read disk.sys
a heck
> > > > of
> > > > a
> > > > lot of the data you are talking about is used by disk.sys, so if
you
> > > > start
> > > > encrypting everything it is going to crash.”
> > > >
> > > > I do not understand this part of your statement. In the stack of
> > > > drivers, I am attaching my driver, above disk.sys, and as of now
was
> > > > tapping only IRP_MJ_READS and IRP_MJ_WRITES. Yes, you are right,
when
> > > > I try to read an entirely encrypted disc, I get a “Disk Not
Formatted”
> > > > message, where as if I leave out the system area of the disc
(bootsec
> > > > and MFT of that partition) then things work fine, ofcourse if I
unload
> > > > the driver, these files cannot be read anymore.
> > > >
> > > > But I need to to a sector level encryption, I know there are
softwares
> > > > that do it, and they also attach above disk.sys ( device tree
shows me
> > > > so). Is there something I am missing out?
> > > >
> > > > “Bottom line, you have serious and unrecoverable design flaws in
your
> > > > current
> > > > approach.”
> > > >
> > > > So then can you tell me a better approach please.
> > > >
> > > > Any advice would be appreciated.
> > > >
> > > >
> > > >
> > > >
> > > > On 8/3/05, Don Burn wrote:
> > > > > The first thing to realize is your statnent “sitting right
above
> > > > > disk.sys”
> > > > > is impossible. One of the oldest and most common mistakes in
> > > > > designing
> > > > > filter driver is claiming “my driver is first”, you cannot
guarantee
> > > > > that
> > > > > you will be the first filter above disk.sys, someone else may
want
> > > > > that
> > > > > position, then who wins?
> > > > >
> > > > > The second major problem you have is that if you read disk.sys
a
> > > > > heck
> > > > > of
> > > > > a
> > > > > lot of the data you are talking about is used by disk.sys, so
if you
> > > > > start
> > > > > encrypting everything it is going to crash.
> > > > >
> > > > > Bottom line, you have serious and unrecoverable design flaws
in your
> > > > > current
> > > > > approach.
> > > > >
> > > > >
> > > > > –
> > > > > Don Burn (MVP, Windows DDK)
> > > > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > > > Remove StopSpam from the email to reply
> > > > >
> > > > >
> > > > >
> > > > > “Developer” wrote in message
> > > > > news:xxxxx@ntdev…
> > > > > for a disc encryptor/decryptor driver, sitting right above
disk.sys
> > > > > and passing encrypted data to disk.sys and decrypting
encrypted
> > > > > sectors from disk.sys, through IRP_MJ_READ/WRITE, do we need
to also
> > > > > tap the IOCTL calls to the system, like
> > > > > IOCTL_DISK_GET_DRIVE_GEOMETRY,
> > > > > IOCTL_DISK_GET_PARTITION_INFO, IOCTL_DISK_GET_DRIVE_LAYOUT,
> > > > > IOCTL_DISK_IS_WRITABLE etc…etc.
> > > > >
> > > > > AFAIK IOCTLs have their own defined structures and these are
pre
> > > > > determined, thus if a driver above me asks to get the drive
info
> > > > > through IOCTL, how can I successfully decrypt the data in the
disk
> > > > > sector that is needed and pass it on. The driver below me,
disk.sys
> > > > > doesn’t know of the encryption, and would fetch garbage from
the
> > > > > disk,
> > > > > populate the IOCTL structure with garbage(probably) and send
it up.
> > > > >
> > > > > Thanks in advance.
> > > > > –
> > > > >
> > > > > - Developer
> > > > >
> > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > > To unsubscribe send a blank email to
> > > > > xxxxx@lists.osr.com
> > > > >
> > > >
> > > >
> > > > –
> > > >
> > > > - Developer
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Developer wrote:

hi chuck, thanks for the pointer, but there are so many thereads
running ,I tried findins and reading them, abd I *cannot* search, due
to system restrictions of the network. it would be gud if you could
send me the links please.

Go to http://www.osronline.com and use the SEARCH dialog box.

To emphasize what you’ve already been told:

(1) You cannot filter above disk.sys and make this work.

(2) You need to filter BELOW disk.sys – IF this makes your
implementation “more complicated” (I don’t see why that would be, but if
you say so…) that’s the way it is. It’s “more complicated” but it
will work.

The most typical way to handle encryption of disk data prior to your
driver being loaded is by hooking the bios. This is not the least bit
uncommon. [as an aside, Mr. Little’s decription of Seagate’s design
sounds brilliant, but you have to be a disk vendor to do it.]

Now, go off and search the archives like Mr. Batson suggested. You’ll
find a lot of wisdom there, and we won’t have to repeat what we’ve
already told people with similar questions a hundred times.

Peter
OSR