Hi all
I'm back again with one of my strange question..
Here is my problem:
I have read a file from disk and I need to feed it into another application after processing it.
But I don't want to write processed file to disk again for feeding it into another application.
I can use any file on disk,IF my file is not written into it. I thought for example make a link from a fake file on disk to my file body as a buffer in my application.

Do you think is this possible?Or do you know any other way to do this?If any articles or samples,it will be great.

Regards

I am not sure I understand your question (That is a surprise right there!) but the solution that comes to my mind is ridiculously simple: The output, modified "file" is a stream that gets piped into the receptor application using > . . .
Now The question is, how much control you have over the receptor application? does it need to "think" it is opening a file on a disk, because it uses Disk read API, or would it accept input streams?? That is the real question . . .

Hi naides
I'm sorry, awfull english... :P
problem is that piping will not work because I have no control over receptor aplication. For example:
notepad <asd.txt
opens asd.txt,but:
notepad <asd
will not do anything.
Most of applications work if they get a file as input,but a lot of them will not if you only send a buffer to them by piping.

For a great example is, assume a small application that runs any file name which is sent it by CreateProcess.
Now I want to feed my buffer to this application without writing my buffer to disk. How I can do this,so other application could run it?

Regards

Well this could be a real challenge, because, files, file handles, and buffers for the file read and file write live in ring 0, and are handled by the OS with very low level API.
So locating the buffer that holds the contents of a file (And taking care of the page in, page out dynamics. Hooking a very low level API to read your buffer instead of the "original buffer" is deep ring 0 hacking.
One long shot strategy would be to open the receptor application under a ring 0 debugger. Reverse the file read routines, which believe me, are multiple layers in depth, and locate the point in which a file name becomes associated to a buffer in kernel memory. Then change those buffer addresses to you modif buffer addresses, which need to exist in kernel memory also. In the meantime, your hooking and intervention needs to allow regular low level file read and write to work seamlessly, or you are going to crash the whole system. . .

I think a lateral solution to your problem is more workable: Open your receptor app under an ad-hock debugger ring 3 , (Olly for starters, then you can refine the approach), identify the mometiin which the app reads the contents of the original file provided by the OS into the buffer that exist in ring 3, inside the
receptor memory space, Stop execution, do your file processing/modification then and there, then allow the receptor to read the altered contents of the buffer, making it think it is reading it right from the file from disk. Still, paging in could be an issue to deal with, if the app does not map the whole "To be modified" text file all at once in the buffer. . .

Build a simple driver that fakes a read-only CD-ROM (well, a device), then use the path on such device which leads (surprise, surprise!) to a memory-kept fixed buffer. So you feed a path, and OS takes care of doing all the translation, sending to your driver just a bunch of easy-to-process requests. Of course, if you need to emulate the full R/W interface you are out of luck: but for a RO interface, that's will be more than enough. 30k of code and you are in.

Oh, remember that unmounting such a driver will be possible, but at your own risk once you mounted it...

Another approach for this would be to inject modified versions of the CreateFile, ReadFile etc API's into the target process, via for example its import table.

But I also think that simply writing the file to disk will be easier and less time consuming than trying to fake the file . It's not like you will notice any difference in execution time (well, unless you're intending to batch process thousands of files through this method).

Hi Maximus
Your idea seems to be interesting,But can you describe this more please?



Regards

There are also ready-made ram disk utilities, which can serve you as a model to design an in memory structure that acts as a disk containing files, that exist only in RAM, you can write to them, and read from them, and in general are very small apps. If I remember correctly some of them come with source code. . . I

Here is an idea that just popped into my head. If you hook CreateFile and ReadFile as arc says above, I think you can do it. Here are some notes. You hook CreateFile so as to check the filename of the file being opened to make sure it is the one you want to replace. Also, this will give you the file handle so that you can compare it later in the ReadFile calls. Ok, once you have the file handle for the file you are interested in, just compare every call to ReadFile to see if that handle is being used. If it IS, just memcpy the amount of data being requested to the buffer they provide, and return a suitable return value, and you're done.

Does this make sense?

Assuming you go the route of hooking CreateFile and ReadFile, don't forget to also hook functions like SetFilePointer.