6 replies to this topic

[DaveL]

Just found the ImDisk project today, it seems to be a good improvement upon anything else in the open source community. Good job! I'm looking at adding support for a custom disk format, most likely using the named pipe functionality to communicate to a user space program. Currently, I have implemented this with FUSE on Linux / OS X, and I'd like to have a similar open source project available for Windows. The disk format handler in question is provided by libewf (https://www.uitwisse...rojects/libewf/).

Is there any documentation on the named pipe interface, other than the devio code? If not, are there any big changes planned for this interface?

I saw the update earlier with the offset option to allow for parsing a partition on a "physical" disk. Are there any plans to implement the disk emulation code such that the entire physical drive can be presented to Windows, to take advantage of the partition handling abilities there?

libewf is frequently used in computer forensics. At times, it is necessary to provide a "PhysicalDrive" interface to Windows or to provide a disk to VMware, etc that can booted. Any thoughts on what would be required to make this happen? (This probably ties in to the above question.)

Has there been any thought to a plug in architecture for disk formats? Yeah, this is probably well beyond the scope of the ImDisk project right now, but it never hurts to ask.

Again, great job on the project.

Dave

[Olof Lagerkvist]

Just found the ImDisk project today, it seems to be a good improvement upon anything else in the open source community. Good job!

Thanks!

Is there any documentation on the named pipe interface, other than the devio code? If not, are there any big changes planned for this interface?

There is unfortunately no more documentation than the sample program 'devio' at the moment but there are no changes planned to the interface either. If you implement support for the commands currently specified in inc\imdproxy.h it should work. I use 'devio' (the FreeBSD version) frequently myself to access NTFS partitions on computers I have booted with a FreeBSD Live-CD so the communication protocol seems stable.

I saw the update earlier with the offset option to allow for parsing a partition on a "physical" disk. Are there any plans to implement the disk emulation code such that the entire physical drive can be presented to Windows, to take advantage of the partition handling abilities there?

libewf is frequently used in computer forensics. At times, it is necessary to provide a "PhysicalDrive" interface to Windows or to provide a disk to VMware, etc that can booted. Any thoughts on what would be required to make this happen? (This probably ties in to the above question.)

Could be something for the future but it would require lots of changes to the project and I am at the moment more thinking of implementing such things, along with Volume Mount Manager support, in a separate driver or something like that. Very often Windows does not actually need a \Device\HarddiskX (with a \DosDevices\PhysicalDriveX) but is quite happy with anything with Volume Mount Manager support.

Has there been any thought to a plug in architecture for disk formats? Yeah, this is probably well beyond the scope of the ImDisk project right now, but it never hurts to ask.

I think the easiest would be to implement such things in separate user-mode 'proxy server' applications, it is not necessary to add support for special file formats to the driver code.

[DaveL]

Well, I figured a post back here is in order. As suggested, I ended up using the proxy code to loop an interface back to imdisk for doing the mounting. This allows for mounting of EWF disk image formats that are typically used in digital forensics. From an abstract level, this is an implementation of devio in Python.

https://www.uitwisse...ewf-20070717.py

[Olof Lagerkvist]

Great!

This is exactly the kind of implementation I had in mind when I created the method to abstract the I/O backend from the driver code. Hope this is a useful method for supporting different formats in the future. I also think about 'compressed' formats that don't store exactly all sectors in the virtual disk file but instead use some kind of index to keep track of where each sector is physically allocated, or if it not allocated yet. Even though there are some kernel support routines (intended for filesystem drivers really) to handle allocation matrix etc, code like that is generally a lot easier to implement in user mode.

[pscEx]

Great!

This is exactly the kind of implementation I had in mind when I created the method to abstract the I/O backend from the driver code. Hope this is a useful method for supporting different formats in the future. I also think about 'compressed' formats that don't store exactly all sectors in the virtual disk file but instead use some kind of index to keep track of where each sector is physically allocated, or if it not allocated yet. Even though there are some kernel support routines (intended for filesystem drivers really) to handle allocation matrix etc, code like that is generally a lot easier to implement in user mode.

Due to ImDisk and its background I'm really a fool.

Can one of you explain in simple words what DaveL did and why it is great?

Thanks

Peter

[Olof Lagerkvist]

Can one of you explain in simple words what DaveL did and why it is great?

Maybe not much simpler, but anyway further explained...

He added support for another virtual disk file format without changing anything in the ImDisk driver code. He used existing methods in ImDisk to let it redirect requests to the virtual disk to another program, in this case the Python module he wrote, and that way made ImDisk support this EWF format through his Python module.

This is great because it shows that ImDisk as it is right now is flexible enough to support different file formats by adding simple user-mode modules that requires no special driver development skills to write, they can be written in practically any programming language and just needs to handle a few simple requests sent over an ordinary network socket.

[pscEx]

Maybe not much simpler, but anyway further explained...

He added support for another virtual disk file format without changing anything in the ImDisk driver code. He used existing methods in ImDisk to let it redirect requests to the virtual disk to another program, in this case the Python module he wrote, and that way made ImDisk support this EWF format through his Python module.

This is great because it shows that ImDisk as it is right now is flexible enough to support different file formats by adding simple user-mode modules that requires no special driver development skills to write, they can be written in practically any programming language and just needs to handle a few simple requests sent over an ordinary network socket.

Peter