8 replies to this topic

[strawtarget]

First, ImDisk works *great*. I love it. I've written a tool on linux that uses FUSE to mount various image formats (segmented dd, vmdk, encase/expert witness, ...). It also interprets several types of partition tables and automatically calculates offsets. Plus it has a read/write mounting mode that redirects writes to a separate "overlay" file so that the original image files are not modified. Anyway, my point is that your user-mode proxy system is general enough that *all* of these features can be implemented using ImDisk instead of FUSE. Thanks very much, Olof! ImDisk rocks!!

One thing I want to add is the ability to have physical disk images represented as physical disks in windows. I'm more of a linux guy, so learning about windows driver development is a bit daunting. But I'm a quick study and I think I might be able to make it happen.

If I can make it work, I will (of course) submit my work back to you for inclusion in ImDisk.

I guess what I'm requesting from you is a gentle shove in the proper direction, in a couple of ways.

1. Would I have to re-implement ImDisk driver portion as a disk driver instead of (or in addition to) a partition driver? Or is it a general purpose storage driver and I would just simply need to add Mount Manager request handling? (I'm guessing I'd have to make a disk driver that reported geometry and make/model info and whatnot.)

2. What driver dev documentation should I start reading first to give me the best understanding of how I should proceed?

Thanks!

[Olof Lagerkvist]

First, ImDisk works *great*. I love it.

Thanks a lot!

One thing I want to add is the ability to have physical disk images represented as physical disks in windows. I'm more of a linux guy, so learning about windows driver development is a bit daunting. But I'm a quick study and I think I might be able to make it happen.

If I can make it work, I will (of course) submit my work back to you for inclusion in ImDisk.

I guess what I'm requesting from you is a gentle shove in the proper direction, in a couple of ways.

1. Would I have to re-implement ImDisk driver portion as a disk driver instead of (or in addition to) a partition driver?

It would need quite a lot of more handling of IOCTL commands etc and I would say that it is not worth it. There are simpler, more straightforward ways than adding this functionality to ImDisk.

Or is it a general purpose storage driver and I would just simply need to add Mount Manager request handling?

Mount Manager is a different thing. Mount Manager can handle both partitionable disk objects such as physical disks and non-partitionable object such as floppies and CDs. You would not need to support Mount Manager just to present a partitionable disk to Windows, but it could be useful, for example it would show up in Disk Management etc.

(I'm guessing I'd have to make a disk driver that reported geometry and make/model info and whatnot.)

Well, that part is already pretty much ready in the current ImDisk driver and should not need to be modified if you turn it into a partitionable disk driver.

2. What driver dev documentation should I start reading first to give me the best understanding of how I should proceed?

Download the latest WDK from Microsoft and look at the storage driver samples. Basically, if you go for modifying ImDisk driver you will need to support everything that disk.sys supports (the source code is included in the WDK samples directory).

The other option, and the option that most developer of virtual (complete) disk drivers seem to go for is to write a virtual SCSI port driver and enumerate SCSI disks on the port and then handle SCSI commands. Then you will get quite a lot for free, Windows will see the SCSI port and find disks on it and use the usual disk.sys with all it's included functionality to handle them (this includes partitioning and Mount Manager support without any special requirements in your driver). The main drawback is that this means that you would have to write a completely different kind of driver and practically nothing of the current ImDisk driver would be useful in the project.

Anyway, both require a lot of work, especially if you are not experienced in Windows driver programming, but I would suggest that you read and try to follow the sample storage drivers in the WDK and from that point make a decision which way you want to go.

WDK:
http://www.microsoft...WDK/WDKpkg.mspx

Good luck!

[strawtarget]

Thanks for the info!

I have a third idea... instead of physical disk emulation, what if I could make an emulated "image file"? Maybe I could make a reparse point file called "image.dd" that behaves just like the raw data you see when you open the ImDisk drive letter in a hex editor.

Could this be done really easily, by perhaps making a hard-link (or something) to the \Device\ImDisk entry or something in \\.\?

Or, would I need to write a companion file system filter that communicates with the ImDisk proxy service to handle reparse-point requests?

Thanks again!

[was_jaclaz]

@strawtarget

FYI, VDK.EXE already creates a "PhysicalDrive" type of connection, though still not "good enough" to also work with device manager/disk manager.

Some of the other "Commercial" drivers listed here:
do provide full access to "Physicaldrive":
http://www.boot-land...?showtopic=1507

The source of VDK is available, maybe some of the work done can be re-used.

jaclaz

[Olof Lagerkvist]

Or, would I need to write a companion file system filter that communicates with the ImDisk proxy service to handle reparse-point requests?

Yes, what you describe here is a filesystem filter driver project. You will need to create a reparse point file with a reparse information block that points to your filter driver and then in the filter driver handle Read/Write/Get/SetFileInformation etc requests by forwarding them (or most of them) to a disk volume object. The path to the target volume object could of course also be included in the reparse point information block.

[Yorn]

Olof, if you could integrate this into IMdisk somehow, that would be great. Especially for those of us with spare computers. We'd be able to make them part of like a distributed file share.

[milindsmart]

Necropost!

 

https://docs.microso...int-tag-request: this Microsoft hardware dev center page asks developers who want their own reparse tag to send an email to them with some identification details.

 

Now we CAN just take whatever reparse point we find unused and just use it, but this would be the cleaner approach.

 

Any progress on this project? This sounds a lot like kpartx :-)

[Wonko the Sane]

@milindsmart

I would call that "irrelevant" (almost ten years later), Olof in the meantime has written the Arsenal Image Mounter that exposes the "whole" disk just fine.

 

Having a "named reparse point" may be an interesting solution but right now I completely fail to see what is the problem that needs that solution.

 

Interesting , though.

 

Wonko 

[Olof Lagerkvist]

I think the reparse point idea in this thread came from some kind of misunderstanding och similar. Since that time, there have already been entirely user-mode proxy services written for ImDisk and Arsenal Image Mounter that work without any kind of reparse point or similar for "image emulation". The user-mode service applications instead communicate in other ways with the drivers, for example through shared memory and events.