Hi Prashanth,
I worked on a similar project once, though ours was a disk upper filter
driver, we ignored format and other IOCTL based stuff as it was a prototype,
only disks were encrypted and decrypted at sector level sparing the system
sectors like the partition table etc.
We also had the int 13 interceptor, all worked fine. Since you are sitting
below disk.sys I think you are working at the SRB level rather than the IRP
level? Is this correct?
Anyway, where exactly are you loading the 16 bit encryption module? This one
one problem we faced, no matter where we tried to load it through the MBR,
windows would over write it. Ultimately we found a happy place. Can this be
your problem. As Don says, if the system shifts between real and protected
mode, then there is a high possibility that your routines are zapped.
Regards,
Amitrajit
Hi Amitrajit,
>We also had the int 13 interceptor, all worked fine. Since you are sitting below >>disk.sys I think you are working at the SRB level rather than the IRP level? Is >>this correct?
Yes. we are dealing with the SRB in the lower filter.
>Anyway, where exactly are you loading the 16 bit encryption module? This >>one one problem we faced, no matter where we tried to load it through the >>MBR, windows would over write it. Ultimately we found a happy place. Can >>this be your problem. As Don says, if the system shifts between real and >>protected mode, then there is a high possibility that your routines are zapped
We are storing the 16 bit encryption module from LBA 0-LBA 46 in the first cylinder since this is the unused space on every disk and also we are relocating the MBR somewhere between LBA 47-LBA 62 .
I have this problem only on Windows XP. everything is fine on Win2k.
Developer wrote: Hi Prashanth,
I worked on a similar project once, though ours was a disk upper filter driver, we ignored format and other IOCTL based stuff as it was a prototype, only disks were encrypted and decrypted at sector level sparing the system sectors like the partition table etc.
We also had the int 13 interceptor, all worked fine. Since you are sitting below disk.sys I think you are working at the SRB level rather than the IRP level? Is this correct?
Anyway, where exactly are you loading the 16 bit encryption module? This one one problem we faced, no matter where we tried to load it through the MBR, windows would over write it. Ultimately we found a happy place. Can this be your problem. As Don says, if the system shifts between real and protected mode, then there is a high possibility that your routines are zapped.
Regards,
Amitrajit
— Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17 You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping
>We are storing the 16 bit encryption module from LBA 0-LBA 46 in the first
cylinder since this is the >unused space on every disk and also we are
relocating the MBR somewhere between LBA 47-LBA >62
Storing the magic sectors in the disk is not what I am referring to, when
the machine boots, you MBR gets control (assuming that you have rewritten
one) that is where you load the int 13h interceptor and the
encryption/decryption routines. Unless you are a wizard, I don’t think all
this can fit in one sector and thus we need to *load* the module *somewhere
in memory*. That is what I was referring to. Where exactly in memory do you
load the interceptor code and the decryptor library? May be that location is
being over written by the OS (infact that is in our case).
Amitrajit
>Where exactly in memory do you load the interceptor code and the decryptor >library? May be that location is being over written by the OS (infact that is in our >case).
The memory is created by decreasing 5kb of the conventional 640k (0xa0000) memory. The int13 interceptor code is stored in the hole created.
Developer wrote:
>We are storing the 16 bit encryption module from LBA 0-LBA 46 in the first cylinder since this is the >unused space on every disk and also we are relocating the MBR somewhere between LBA 47-LBA >62
Storing the magic sectors in the disk is not what I am referring to, when the machine boots, you MBR gets control (assuming that you have rewritten one) that is where you load the int 13h interceptor and the encryption/decryption routines. Unless you are a wizard, I don’t think all this can fit in one sector and thus we need to load the module somewhere in memory. That is what I was referring to. Where exactly in memory do you load the interceptor code and the decryptor library? May be that location is being over written by the OS (infact that is in our case).
Amitrajit
— Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17 You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping
>Anyway, where exactly are you loading the 16 bit encryption module? This one
one problem we faced, no matter where we tried to load it through the MBR,
windows would over write it.
Try trimming the amount of base real-mode memory to below 640KB by hooking int
11h, and place your code to this trimmed memory.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Gary, you gave the same advice when I did my project 
I do agree that this
type of schemes are not fool proof, but it is fun making such projects.
Anyway, since my team had success in making a fully encrypted machine boot,
and resume from encrypted hibernate state (yes, we were able to break the
magic of hibernation and crash dumps also), I think that let prashant do
what he he up to
Prashant, there is a section called EBDA in the memory, read up about it,
that is the trick we used to solve all our *hooker* related issues. Good
luck.