I am playing around with the demo of IDA and I am trying to do some reverse engineering of a program to figure out the structure of one of its files that it uses. My final goal is to be able to read that file directly from my own program.
Using Process Monitor I was able to find the subroutine that calls kernel32_ReadFile. What I would like to know is how do I find out what the hFile variable is pointing to before it makes the call to ReadFile
I have been exploring around the menus while in debug mode and I have not found anywhere inside IDA where I can look up information about what file is associated with a file handle.
How do I map a handle to a real file?
This MSDN page describes ways to get the file name from a file handle:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366789(v=vs.85).aspx
Is that the information you were looking for? I'm not sure why you can't see the the file name directly in Process Monitor.
I would set a breakpoint on CreateFileA and CreateFileW and see what files are being opened. You can then match the returned HANDLE value to the subsequent ReadFile call.
Related
I'm using SysInternal's handle.exe and I'm trying to understand the output.
Here's a snippet:
24C: File (RW-) C:\Program Files (x86)\Google\Chrome\Application\Dictionaries\en-US-8-0.bdic
2E8: Section \Sessions\1\BaseNamedObjects\CrSharedMem_5ae414b12a307dbddc3f42b8b35edcbf313107945050b3aaab1602ecd937c940
2F4: Section \Sessions\1\BaseNamedObjects\CrSharedMem_ccfa88ab65617b75dbdcb72cb6512bf1a9cc76d07a25e9f770b46f4f7c2234bf
314: File (R--) C:\Windows\Fonts\arial.ttf
324: File (R--) C:\Windows\Fonts\arialbd.ttf
328: File (R--) C:\Windows\Fonts\arialbi.ttf
What does the number at the start mean?
What does "Section" mean? I can understand an open file, but what's an open section?
What does the RWD triplet mean? I'm guessing R and W are read and write, but what's D?
The first column is the HANDLE value, it serves as the unique identifier of the OS kernel object. Like the ID column of a database record. It is only useful if you need to compare it with what the debugger tells you when you debug code.
The second column identifies the type of OS object. "File" is obvious, a "Section" is an object that allows processes to share memory. "Memory mapped file" is the usual phrase in programming. "Mutant" tends to be confusing, it is a mutex in normal speech. The author of the program uses the kind of terms that David Cutler likes, he speaks with a VMS lisp. The WinObj utility is another way to look at these kernel objects.
The letters in parentheses are the sharing options specified when the object was created. The third argument to CreateFile. Important to know since it tells you what another program can do when it also wants to access the object. R says that it can read, W says that it can write, D says that it can delete the object without affecting anybody else that uses the object. The object won't be destroyed until everybody closes their handle. An anti-malware scanner or search indexer are typical examples of programs that use delete sharing.
I want to write the code in kernel space to find all open file handles in the system and the process id which holdes those handles.
In user space we can do it using the utility "lsof". Similarly, i want the same in kernel space.
What's so great about Linux Kernel is that it's open source. If you want to understand how to implement something that is similar to lsof why not inspecting its' source code (I suggest the following implementation, from Android 4.2.2 source tree, at it is simplified and easier to understand) or straceing it to understand how the magic happens?
If you'll do so, at some point you'll encounter the following line
openat(AT_FDCWD, "/proc/<PID>/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
Which will hint you that for each PID that is running, procfs is able to print information about all open file descriptors that this process holds. Therefore, this is where I would start my research and journey through the code.
I need to read a file in Windows and avoid any OS-level locks so users can delete the file even while my application is reading from it.
Using typical read operations via C++, Python, Java, etc reveal the same expected sequence of Winapi calls when evaluated through procmon:
CreateFile
ReadFile (multiple times until "END OF FILE" is reached)
CloseFile
If I try to delete the file via Explorer between steps 1 and 3 (basically after CreateFile and before CloseFile), I'll get a "file in use" error.
However, I noticed that when Dropbox reads files to upload to the server, the sequence is:
CreateFile
CloseFile
ReadFile
Repeat steps 1-3
Since ReadFile is called after CloseFile, I can still delete the file even while Dropbox is reading it.
I can't figure out how Winapi allows for ReadFile after CloseFile is called.
I've attached a screenshot of Procmon that shows Dropbox's behavior.
Anybody know how this is done?
This create-close-read semantics should be caused by the fact that the file is mapped to a memory region in application's address space. When the application attempts to read from that region, the operating system reads necessary data from the file and delivers them to the application (the data appear in the memory region where the file is mapped).
Memory mapped files are backed by a file mapping objects (called a section in the kernel world). Given a file handle, you can create such an object via CreateFileMapping and map it to your address space through MapViewOfFile (some Ex variants also exist). The file mapping object keeps an extra reference to the file it maps. So, after creating the file mapping object for a file, you can close the file handle and read the file through the file mapping object.
Say I have app TestApp.exe
While TestApp.exe is running I want a separate program to be able to read the executable code that is resident in memory. I'd like to ignore stack and heap and anything else that is tangential.
Put another way, I guess I'm asking how to determine where the memory-side equivalent of the .exe binary data on disk resides. I realize it's not a 1:1 stuffing into memory.
Edit: I think what I'm asking for is shown as Image in the following screenshot of vmmap.exe
Edit: I am able to get from memory all memory that is tagged with any protect flag of Execute* (PAGE_EXECUTE, etc) using VirtualQueryEx and ReadProcessMemory. There are a couple issues with that. First, I'm grabbing about 2 megabytes of data for notepad.exe which is a 189 kilobyte file on disk. Everything I'm grabbing has a protect flag of PAGE_EXECUTE. Second, If I run it on a different Win7 64bit machine I get the same data, only split in half and in a different order. I could use some expert guidance. :)
Edit: Also, not sure why I'm at -1 for this question. If I need to clear anything up please let me know.
Inject a DLL to the target process and call GetModuleHandle with the name of the executable. That will point to its PE header that has been loaded in the memory. Once you have this information, you can parse the PE header manually and find where .text section is located relative to the base address of the image in the memory.
no need to inject a dll
use native api hooking apis
I learned a ton doing this project. I ended up parsing the PE header and using that information to route me all over. In the end I accomplished what I set out to and I am more knowledgeable as a result.
Is there a way to detect the file name of a file when a user prints from any application, somwhere in the printer events? I am looking for a windows api where I can determine what file is being printed.
Print jibs are opened with names but typically this doesn't mean the filename - the names which are displayed in the print queue are accessible by querying the printer driver directly I believe.
The printer driver does not have any external API for finding the filename. I assume you would be looking at creating some kind of systray agent sort of app that would be monitoring print queues for jobs being sent. If so -
Refer to http://support.microsoft.com/kb/196805 for a microsoft tool that allows you to monitor print queues for print job status
Refer to http://msdn.microsoft.com/en-us/library/ff562742%28v=vs.85%29.aspx which explains how Windows supports printer change notifications. You can create an app that registers for this and get handle to the Print Queue. Once you get a handle you can call the GetPrinter and GetJob APIs to get access to the JOB_INFO_2 structure. The pDocumentName in the JOB_INFO_2 structure is the name of the file
Hope this helps. If so, please vote a +1 :)
No, there is not, at least not reliably. Keep in mind that there may not be a file name at all. For example, I could open an application like notepad, type some stuff, and print. What file am I printing? None.
In the above scenario most applications will provide some sort of default file name like "untitled", and sometimes you can find that name by parsing the print job's name. For example, if you call GetJob, the JOB_INFO_1 struct's pDocument member will contain a pointer to the print job's name, and that name will often contain the file name.
However, every application formats it differently, and some don't provide it at all. So the answer is you can find the file name perhaps 75% of the time with a lot of effort, but there simply is no 100% solution.