Hi all
I'm gonna to do a security project that is used for encrypting hard disk.
My target in this project is:
Bringing up OS from a encrypted hard disk,then whenever I pull hard disk out of its slot,it will be encrypted.
Because the special conditions of this project,it seems that i need to write boot-loader and a driver UNDER file system...
What I need:
suggestion on how i should do this.... and how much time do you think I need for this project?

Note:
similar project has done by a german company named CompuSec:
http://www.ce-infosys.com/english/downloads/free_compusec/free_compusec_faq.html

Regards

I would start by studying and reversing some existing harddisk encryption programs, since as far as I can understand from your explanation, it will work just as any full harddisk encryption program, right?

Btw, is the goal of your project to learn, or to just get such a program? If it is the latter, I'm sure you already know that there exists lots of programs like this.

Don't have any good idea about the time for such project though, but there will be quite some new low-level stuff to learn if you didn't deal with this kind of thing before, which should take some time anyway.

yea,it is a full disk encryption one...
I know there a lot of teams that done this,but me and my friends wana do this as a job.
I need to get ome info about this.
In addition after more though in it I reached a important question:
What is the meaning of being UNDER file system?Doesn't file system driver work with interrupts for reading and writing from/to HDD?
If yes,what is meaning of being under interuppt?I think it means rewriting ISR for injecting encryption algorithms in it.
If no,what is mean of being under file system?it means standing between file system driver and ntokernel.exe?

Regards

as far as i believe being under file system means writing a filter driver that sits below or viceversa above the file system in stack
so it gets to see the irps thats being sent to and or emanated from the file system

for example filemon is a kind of filter driver that sits somewhere out there and checks out every IRP_MJ_create IRP_MJ_READ requests and logs them

it is not a relation between any sys or exes

you can get authoritative and well worded answers if you look through and read the osronlines mailing list archieves

hey,

another good point to start is to take a look at truecrypt.
is its free and iirc with open source provided. the project will include everthing you will need to write your own harddisk encryption. what you then have to discover by your own is writing an own bootloader which encrypts the harddisk for the first time.
It's just a guess but i think the bootloader stuff will be most of the work because you will have to deal with driver programming and windows internal stuff. as mentioned before, if you are not into that stuff you will need a long time to get the necessary "basics" to implement the needed driver.

Anyway, you will be gonin' to get a lot of experience if you finish such a project successfully, even if you finish it not successfully

Have fun,

Regards.

I have seen this too,but i should say it is something over file system,and the one we are doing this for is a fool and not accepting on file system level encryption and wants full disk enryption like that CompuSec that I linked
This can be done by witing a IFS and implementing enryption in it,but it still uses current file system structures,then there is no FULL disk encryption....

in additon a tool file filemon is a filter driver,that simply attacks file system driver,and not too hard to implement.But this one has the same problem like prevoius one,and I imagine that you can't implement FULL disk encryption through it.

Regards

If you really want "FULL disk encryption" you'll have to do it in hardware (disk controller card bridge?).

The closest you can get with software is an unpacker stub in the first sector(s) that unpacks to a RAM disk, then loads the OS kernel and everything else from RAM. Of course, Windows would probably need extensive reversing to do this, but a Linux kernel may be better.

You don't need any special hardware or RAM disks for software full disk encryption (of course a tiny piece of unencrypted loader stub in the boot sector is no problem). Simply hook the sector-level disk operations and encrypt/decrypt them on the fly.

I actually think that this is easier (complexity-wise) than filtering above the file system level btw Hero.

And just like Hero says, this can be done (and normally is done) with a filter driver placed on a level under the file system drivers.

imo you would need two completely different parts in this program.
One that would intercept the BIOS ints to hd access and perform decryption (to get the OS loaded) and another one that deactivates the first part and takes over the job. The second one would be a windows driver.

Dunno if that makes any sense :P

I'd suggest taking a look at SecuStar DriveCrypt Plus Pack, it does everything you're asking for.

Yes, that is correct.

hehe,we don't need 'simple' word in that sentense. But have you seen any document in something similar for reference?
But there is a question:
Is windows using BIOS int for reading from and writing to HDD?somebody told me windows is working with HDD directly and is not using BIOS ints.
which one is correct?

Regards

Hehe, yeah, I didn't mean it was simple, not just as "impossible" as you theorized it above.

I'm sure there are many people here more suitable than me to answer your last question btw.

You might like this info though:

http://www.osronline.com/showThread.cfm?link=3841

Also, see the "SIMBAD" example in the DDK, for info and example code for disk class filter drivers.

And here are some more good examples:

http://www.acc.umu.se/~bosse

lol,Great help like always dELTA!!! very great information!!!

OK,due this thread information,can i get this conclusion?
(If I assume that my HDD is only IDE,and I use 'Multi' in 'boot.ini')
***
first NTLDR first switchs memory into 32-bit flat mode,
next uses INT13 to work with disk,and gets all required drivers,like miniFS,
then it grants working with disk to miniFS.
miniFS themselves cannot use IN/OUT directly and use underlying driver for it and this driver is NTBootDD.sys for SCSI HDD.
***

if I got these correct, what is underlying driver that miniFS uses for IDE HDDs?

And with these information,i assume the best place for writing a full disk encryption driver,is a filter driver BETWEEN miniFS and its underlying driver,am I right?
In addition it seems reversing NTLDR can be some help...

Regards

dELTA has too many fans

Don't you hate it when nobody pays attention to what you say?

.. I said ..
Don't you hate it when nobody pays attention to what you say?

HEY, I SAID

Don't you hate it when nobody pays atte

The encryption/decryption is simple, ensuring the hook actually does hook ALL accesses is not...
Can you be absolutely sure that ALL disk accesses from that point on take place through miniFS? Do you want NTLDR encrypted as well? Is there an authentication aspect to this (e.g. type a password to decrypt disk and continue booting), or do you just want to encrypt an entire disk with some trivial algorithm just for the purposes of doing it?

Definitely reverse NTLDR.