Hooking ReadFile() HELP PLEASE!
Well, I have hooked the ReadFile() and I could play a lot with it, like injecting MessageBox()es and all that but I could never replace the arguments it writes, I've read a lot about ReadFile and I still can't handle this...
Let's see... the application whose IAT I patched is "FileEditor.exe" (it's like Windows Notepad)...now FileEditor.exe uses myKernel32.dll.
This is a snipped of MyKernel.CPP
Code:
extern "C" __stdcall __E__675__(HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped)
{
MessageBox(0,"We are in the ReadFile function!","Info",0);
char* newbuffer = "ReadFile was hooked!"
ReadFile(hFile,lpBuffer, nNumberOfBytesToRead, lpNumberOfBytesRead,lpOverlapped);
}
Obviously, the code above invokes ReadFile with the very same parameters with which the hooked function has been called. The only thing I want to change is the second parameter, i.e lpBuffer and replace it with newbuffer so that the FileEditor.exe displays "ReadFile hooked!" instead of the original file's content.
Any idea how could I do it? I even tried to figure out what ReadFile() pushes onto the stack, I've figured out it pushes 3 values (it takes 5 to work but only 3 are output values i.e: lpNumberOfBytesRead, lpOverlapped and, most importantly, lpBuffer)
then I added this to the code above:
Code:
LPVOID xlpBuffer;
LPDWORD xnNumberOfBytesRead;
LPOVERLAPPED xlpOverlapped;
__asm{
pop xlpOverlapped
pop xnNumberOfBytesRead
pop xlpBuffer // <---
push newbuffer
push xnNumberOfBytesRead
push xlpOverlapped //<-- this is where things are supossed to change!
}
unfortunately it didn't work either... it was as if I added nothing to the code. Then I simply added, instead of that __asm crap this:
Code:
lpBuffer = newbuffer;
and still, the FileEditor.exe successfully loads any TXT file as if I could never "touch" the information it pushes onto the stack... now... WHERE is this lpBuffer stored? and HOW can I find it and replace it?
Re: Hooking ReadFile() HELP PLEASE!
Code:
extern "C" __stdcall __E__675__(HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped)
{
MessageBox(0,"We are in the ReadFile function!","Info",0);
char * buf = (char*)lpBuffer;
lstrcpyA( buf, "ReadFile was hooked!" );
}
Re: Hooking ReadFile() HELP PLEASE!
When ReadFile is called it is called with a preallocated buffer and the length of that buffer
if you would like to alter the buffer you have to copy your data into that buffer up to the size passed in. ReadFile also returns the number of bytes actually copied to buffer.
There may be more. Make sure to read the doc on ReadFile
Re: Hooking ReadFile() HELP PLEASE!
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)....
Code:
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 :D
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:
Code:
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)
Code:
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)
Quote:
"·$"·$%·&$%&%/&/(&/(&/())(=()=%·$%·"$"$"·$"·$·$·$"·""$$"··$"·$%&!
Now, when my DLL decrypts it into memory, it looks like this (newbuffer):
Quote:
Hi, this is a readfile.txt the contents of this file are originally encrypted.
after ReadFile reads it... the application shows this:
Quote:
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? :D
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 ;) ;) ;)
