Hooking ReadFile() HELP PLEASE!

[sonnyk88]

Thank you all guys for your attention and replies though I could finally solve this problem with memcpy(). The reality is that I used a simple char* in my first post to make things simpler for explaining better my problem. This is a long post but I think it will be very useful for all those (I've known of MANY MANY MANY of them in Google who are struggling trying to hook this function)....

LPVOID newbuffer; // this is a global variable...

memcpy(lpBuffer, newbuffer, FileSize);

// FileSize was previously obtained with:
// DWORD filesize = GetFileSize(hFile,NULL);

My DLL had previously decrypted the file data and stored it in newbuffer. Now, my (hooked) ReadFile replaces its original lpBuffer with newbuffer

It works wonderfully. FileEditor now is able to decrypt files and display them. I was so happy

Unfortunately, FileEditor.exe was just a simple application I used first to experiment with before trying with others.

I used ProcMon.exe (a Windows API Monitor from Sysinternals) and I could see how FileEditor.exe only calls ReadFile ONCE whereas other applications I modified into using my DLL call ReadFile() many times with different Offset values and the amount of bytes to read.

And this is where I'm screwed up because other applications do not only call ReadFile many times but limit how much information should be stored in lpBuffer. That's why my DLL crashed in the complex applications at this line:

memcpy(lpBuffer,newbuffer,FileSize)

It was because FileSize is larger than the buffer the ReadFile function was called with in the first place. I later reduced the FileSize for testing purposes. So I tried first with 1024. (Because I could see with ProcMon that the minimal value it was called with was 1024)

memcpy(lpBuffer,newbuffer,1024)

It worked very well but, the funny thing was that the textbox displaying the file content showed everything in a crazy way. I can only explain this in this way:

Let's suppose that the readme.txt I encrypted in Harddisk looks like this (lpBuffer)

"·$"·$%·&$%&%/&/(&/(&/())(=()=%·$%·"$"$"·$"·$·$·$"·""$$"··$"·$%&!

Now, when my DLL decrypts it into memory, it looks like this (newbuffer):

Hi, this is a readfile.txt the contents of this file are originally encrypted.

after ReadFile reads it... the application shows this:

Hi, this is a readfileHi, this is a readfileHi, this is a readfileHi, this is a rHi, this is a readfileHi, this is a readfileHi, this is a readfileHi, this is a readfileHi, this is a readfile

I came to the conclusion that it was not only about replacing the lpBuffer with newchar. I'd also have to know (maybe with some parameters in ReadFile that I still don't know) where I would have to "chop" the newbuffer and use this chunk as a replacement for lpBuffer in order to show the information properly.

Looking for a solution, two parameters from ReadFile() drew my attention:
ReadFile(hFile,lpBuffer,nNumberOfBytesToRead,lpNumberOfBytesRead,Overlapped);

I had to forget about nNumberofBytesToRead because it's simply the maximum number of bytes it would store in lpBuffer and this is thus almost random between 1 and X.

Then, when I tried using lpNumberOfBytesRead as a guide to know where I'd "chop" the newbuffer and replace lpBuffer. Unfortunately, I've found out that this parameter does not always contain how many bytes the ReadFile has read in the whole process and I could corroborate this by storing a TXT log file the values it takes everytime the function is called and when I summed then up them all, the final value was always significantly bigger from the original file size.

Also, according to MSDN, one should never read/write/etc the lpBuffer whilst ReadFile/WriteFile/etc is in progress... it makes things even harder!

The last thing I still have to try is the members of the overlapped structure ((last parameter in ReadFile) two of them are called "Offset" and "OffsetHigh". I have to read more about structures (tomorrow, I'm tiiired) and see if this value is easy to intercept.... (I base my hope on the fact that Systernal's Process Monitor could always show me the offset and the amount of bytes with with ReadFile was called. I summed them up all and they, as anyone would logically expect, have the very same value as the size of the original file)
so if ProcMon can do it... why wouldn't a DLL?

I am sorry for this long post. Though I believe that it will serve much for many who like to play around with this stuff. They'd save their time I've wasted....

Thank you all guys again. Any suggestion or idea would be really appreciated too