SecureVol Project Part 2 General Overview

 As the reader already might know, every interaction we do with file systems is managed by the I/O manager, now you can ask yourself, what if i create my own file system ?. It does not matter, your own file system also executes in the Windows kernel space, so it must follow the same rules.

In my personal opinion,the I/O manager is (alongside the Memory manager) one of the greatest things ever created for NT. It is a really complex and extremely efficient work of art. I strongly recommend reading the Windows documentation regarding the I/O model for a better understanding.

The following picture represents in a very global way the SecureVol file system procedure


As you can observe, every action in user-mode have a similar action in kernel-mode. This transition is generated by the I/O Manager in the form of IRP's. Using a human body analogy, if the I/O represents the heart, the IRP's are the major blood vessels.

After creating the device object we will setup FsInternalThread() which will manage the queue of IRP's the user is sending from SecureVol.exe. Inside the thread we will extract such IRP's calling ExInterlockedRemoveHeadList() function. IRP's are extracted with FIFO order. Because we are working inside a multiprocessor and multithreading environment we always need to protect insertion and deletion of elements when working with linked lists.
 

Code snippet that shows what we commented above. This thread will only run as long as there is something in the queue to process. Depending what IRP function type we process (Minor or Major), we will call the corresponding dispatch routine.
In further articles we will see how we manage this calls, including enhancements.






























Comments

Popular Posts