Digg this topic Add to my del.icio.us Submit to SlashDot  
Reply to this topicStart new topic
> Adding support for custom disk formats
DaveL
post May 15 2007, 03:19 AM
Post #1


Newbie
*

Group: Members
Posts: 2
Joined: 15-May 07
Member No.: 7,088


United States


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.uitwisselplatform.nl/projects/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
Go to the top of the page
 
+Quote Post
Olof Lagerkvist
post May 15 2007, 11:26 AM
Post #2


Advanced Member
***

Group: Developer
Posts: 122
Joined: 27-April 07
From: Borås, Sweden
Member No.: 6,234


Sweden


QUOTE (DaveL @ May 15 2007, 05:19 AM) *
Just found the ImDisk project today, it seems to be a good improvement upon anything else in the open source community. Good job!


Thanks! (IMG:http://www.boot-land.net/forums/style_emoticons/default/cool.gif)

QUOTE (DaveL @ May 15 2007, 05:19 AM) *
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.

QUOTE (DaveL @ May 15 2007, 05:19 AM) *
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.

QUOTE (DaveL @ May 15 2007, 05:19 AM) *
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.
Go to the top of the page
 
+Quote Post
DaveL
post Jul 18 2007, 05:23 PM
Post #3


Newbie
*

Group: Members
Posts: 2
Joined: 15-May 07
Member No.: 7,088


United States


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.uitwisselplatform.nl/frs/downlo...ewf-20070717.py
Go to the top of the page
 
+Quote Post
Olof Lagerkvist
post Aug 2 2007, 05:18 PM
Post #4


Advanced Member
***

Group: Developer
Posts: 122
Joined: 27-April 07
From: Borås, Sweden
Member No.: 6,234


Sweden


Great! (IMG:http://www.boot-land.net/forums/style_emoticons/default/thumbup.gif)

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.
(IMG:http://www.boot-land.net/forums/style_emoticons/default/cheers.gif)
Go to the top of the page
 
+Quote Post
psc
post Aug 2 2007, 06:15 PM
Post #5


Guru
***

Group: .script developer
Posts: 3,894
Joined: 14-July 06
From: Korschenbroich, Germany
Member No.: 3


Germany


QUOTE (Olof Lagerkvist @ Aug 2 2007, 07:18 PM) *
Great! (IMG:http://www.boot-land.net/forums/style_emoticons/default/thumbup.gif)

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.
(IMG:http://www.boot-land.net/forums/style_emoticons/default/cheers.gif)

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
Go to the top of the page
 
+Quote Post
Olof Lagerkvist
post Aug 2 2007, 08:59 PM
Post #6


Advanced Member
***

Group: Developer
Posts: 122
Joined: 27-April 07
From: Borås, Sweden
Member No.: 6,234


Sweden


QUOTE (psc @ Aug 2 2007, 08:15 PM) *
Can one of you explain in simple words what DaveL did and why it is great?

Maybe not much simpler, but anyway further explained... (IMG:http://www.boot-land.net/forums/style_emoticons/default/wink.gif)

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.
Go to the top of the page
 
+Quote Post
psc
post Aug 3 2007, 08:55 AM
Post #7


Guru
***

Group: .script developer
Posts: 3,894
Joined: 14-July 06
From: Korschenbroich, Germany
Member No.: 3


Germany


QUOTE (Olof Lagerkvist @ Aug 2 2007, 10:59 PM) *
Maybe not much simpler, but anyway further explained... (IMG:http://www.boot-land.net/forums/style_emoticons/default/wink.gif)

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.

(IMG:http://www.boot-land.net/forums/style_emoticons/default/thumbsup.gif)

Peter
Go to the top of the page
 
+Quote Post
« Next Oldest · ImDisk · Next Newest »
 

Fast ReplyReply to this topicStart new topic

Members Who Viewed Topic Today ()

 

Display Mode: Standard · Switch to: Linear+ · Switch to: Outline

Track this topic · Email this topic · Print this topic · Subscribe to this forum

RSS Lo-Fi Version Time is now: 3rd March 2008 - 08:21 AM

MKPortal ©2003-2006 mkportal.it