Hello All, I was wondering if someone could help me by giving me the idea. I need to develop a virtual drive which is actually mapped to a file. The size would remain the constant. I know using DDK, it can be done, but I need to transfer the data over network. That is whenever the data is written to drive, it would be transferred to a remote server(encrypted+compressed). On read, the data would be retrieved from server(decrypted+uncompressed). The should never be stored locally. Any idea, any help!!! any directions. regards, Munir

Samba perhaps?

Then host the disk using one of encrypted Linux file systems.

Thanks Samba for the reply,

Infact, I need to be doing it through coding it myself.

The thing I'm worried about transfering the data to my remote server.

Its a type of remote storage, where I need to show user a virtual drive(like X:,Z:)

The data written to that drive is never stored locally, but remotely.

I was thinking to write the driver, when that's initialized, it created a thread. Every write to the disk is actually put to the queue from where the thread would transfer the data to network.

Similar, for read operation, the thread collects the required data from the server, and returns to IO function.

Is it a good way, would that be a safe design...

Any idea...???

Quote:Is it a good way, would that be a safe design...

Not really. Good design would be to choose tried and tested solutions like Samba for the interface and existing encrypted file system for the storage.

Quote:Infact, I need to be doing it through coding it myself.

Why?

Quote:Its a type of remote storage, where I need to show user a virtual drive(like X:,Z:)

Windows file mappings provide that transparently when using Samba. Just map a network drive that's hosted elsewhere. It's what I've been using for years, disks S-Z on my system are all remote storage using Linux.

Quote:The data written to that drive is never stored locally, but remotely.

If all you are providing is file system driver, then this isn't true. Any application with access to disk drive will be able to access unencrypted contents. Windows Explorer and notepad will be enough to see all contents.

The only way to ensure secure access would be to deliver data straight into your application, decrypt it there into non-pagable buffers, process it as locally as possible, then overwrite the memory contents.

This would provide minimal safety, but not enough against a targeted attack, since simple memory dump from a debugger would be able to obtain plain-text.

Quote:I was thinking to write the driver, when that's initialized, it created a thread. Every write to the disk is actually put to the queue from where the thread would transfer the data to network.

Similar, for read operation, the thread collects the required data from the server, and returns to IO function.

File system driver has an API you must implement. I don't remember right now which functions must be implemented in which way, but some may be blocking. Those will prescribe how something needs to be handled.

Threads aren't needed here in slightest, nor desirable. If API requires blocking reads, then you can do blocking requests to file host. If you're handling overlapped IO, then use IOCP or non-blocking IO.


Either way, such a system, with decades of testing is available for free in the combination I mentioned above. It takes about 2 hours to set up, and provides exactly the same type of security your system will be able to.

Hello,

Thanks for you reply. Let me explain why I need to do it.

Infact I'm trying to make a solution of remote storage service using Amazon S3 service.


I want to have virtual drive to appear just like a drive on local hard drive. But whenever user writes the data(by creating a file, making/deleting directory, editing file or deleting it) would use the Amazon S3 service in background to store the data to our web server. Similarly read would fetch the data using Amazon S3 service, and data would be available over local machine.

When Data is removed off the local machine, it should have been compressed and encrypted, and when put back to machine, it should be uncompressed and decrypted.

Should I write a Drive using DDK, writing a virtual drive where data is always stay over the disk is not a big task, the only think I'm worried, that whenever user drags a file to my virtual drive, the data should be transferred to our webserver for storage.

That's why I was thinking to create a thread when virtual drive driver(.sys file) is initialized, the thread would send the daata from a queue(when data is written to virtual drive), and would fill up the queue(when data is requested). But I was thinking this could be dangerous to have a thread on kernel level.

Any help....any idea..

Looking forward to you help!

regards

I think you can do what you want with a shell extension instead of a file system driver, and it should be simpler to write that way.

I believe that's how Windows handles zip files form example.

The only downside of that is that you'll only be able to get at the data through explorer, and not from say a command prompt, although there's nothing stopping you creating a command line tool to get at the data too.

Quote:Original post by mnirahd

That's why I was thinking to create a thread when virtual drive driver(.sys file) is initialized, the thread would send the daata from a queue(when data is written to virtual drive), and would fill up the queue(when data is requested). But I was thinking this could be dangerous to have a thread on kernel level.

The problem lies in the API. You don't receive a "file". You're told which offsets to access.

As such, the file driver doesn't really know how and what it'll write, it's just being told to write random chunks of data, but not what came before or after - that depends solely on application.

This simply means you cannot run threads or queues or anything similar, since OS relies on one operation completing before beginning next one. Local caching could obviously be done, but that's what system file cache does already. The only benefit could be that you would keep some encrypted chunks around.

While you could pre-load each file when it's accessed, Windows might decide to touch every file when you access the disk, simply meaning this operation isn't viable.

Best bet for this would be IOCTL command, where you'd issue non-blocking network request, and dispatch completion when response arrives.

A good place to start would probably be Ramdisk example driver.

Hello,

Thanks Antheus, the reply was really helpful.

I was already looking at Ramdisk example, and I think...since the data is always in memory, so that would be useful for me.

Thanks for you all, but please stay in touch. I would need to have your guys attention again!!

regards,

Munir Ahmed