I iterate trough my process memory using VirtualQuery, I would like to know witch module the certain memory range is owned by whom. Either the executable either some other dll, and get it's name.
Is there a way I can find out ?
Yes, a module handle value in Windows is simply the base address of the VM allocation for the module.
So you can cast the MEMORY_BASIC_INFORMATION.AllocationBase you get back to (HMODULE) and pass that to GetModuleFileName(). Of course, do keep in mind that this only works for allocations that were made for code loaded from executable files. You normally encounter lots of VM allocations with VirtualQuery() that are data or stacks. They don't have an owner and are not associated with a module.
Related
I'm trying to write a pseudo kernel driver (it uses CVE 2018-8120 to get kernel permission so it's technically not a driver) and I want to be as safe as possible when entering ring0. I'm writing a function to read and write MSR's from userland, and before the transition to ring0 I'm trying to guarantee that the void pointer given to my function can be written, I decided the ideal way to do this was to make it writable if it is not already.
The problem is that the only way I know how to do this is with VirtualProtect() and NtAllocateVirtualMemory, but VirtualProtect() sometimes fails and returns an error instead. I want to know precisely where these access permissions are stored (in ram? in some special CPU register?) how I can obtain their address and how can I modify them directly?
User-mode code should never try to muck around in kernel data structures, and any properly written kernel will prevent it anyway. The best way for user mode code to ensure that an address can be written is to write to it. If the page was not already writeable, the page fault will cause the kernel to make it so.
Nevertheless, the kernel code /cannot/ rely on the application having done so, for two reasons:
1) Even if the application does it properly, the page might be unmapped again before (or after) entering ring 0.
2) The kernel should /never/ rely on application code to do the right thing. It always has to protect itself.
The access permissions information and page data is stored in the page directory, page table, CR0 and CR3.
More information can be found here: https://wiki.osdev.org/Paging.
is there any way to determine which driver is the owner of the hanlde?
I mean is it stored any where is Windows objects?
I can see handles via volatilty but all kernel handles are assigned to System.exe pid:4, I need to know exactly which driver is using this system handle?
thanks
Is there any way to determine which driver is the owner of the
handle?
When kernel modules (or thread in kernel space) call Kernel API (NtCreateFile, for example), the handles are allocated from handle table of System process. In this case, the answer is: no.
I mean is it stored any where is Windows objects?
I guess no
I need to know exactly which driver is using this system handle?
Depend on analisys you're doing. If you need to associate an object back to the driver that owns it, you can try to analize _POOL_HEADER structure to obtain information about who produced the allocation. BUT if you need to analyze an executive object (_FILE object, for example), the PoolTag field in this header will be equal to ObjectType.Key, so this way is not very useful for your purpose.
In general, if you're looking for which resources a process can access (i.e. memory-mapped files), you can analyze with memmap volatility's plugin the process' page tables and so the memory area of the process. I suggest you to use VAD structures' dedicated plugin so that you can gather an high-level information about virtual address space of the process.
Problem defitintion
I have two applications: First and Second. The First is mine, the Second is developed by the outsource.
1) At a certain time I need to send a message from the First app to the Second, to make Second one visible and maximized, after it has been minimized.
2) In order to do the (1) step, Second app should store its handle somewhere in a shared memory, which could be accessed by the name or by whatever it might be (like mutexes do).
Question
So, what is the better option to store data (a handle) in an operating memory?
If you want to store this information in a shared place, then you would typically use shared memory. In Windows terms that's a file mapping object. Create one by calling CreateFileMapping. These are kernel objects and so can be named in the kernel namespace.
File mappings are not a whole lot of fun to work with, so you might like to find an easier solution. Give your application's main form a unique class name. For instance you might name the form's class TMyCompanyNameMyProductNameMainForm. Then call FindWindow passing that class name to find an existing application window.
Is there a function that you can use to provide a mapping an address to use?
I am trying to figure out a way to take advantage of large pages even when I have to map small files. I know I can waste memory. Optionally I could use VirtualAlloc to allocate a page sized block which I could then dice up and map multiple files into. I am assuming, since memory mapping is backed by the virtual memory subsystem, that this is not possible - a single page of memory probably has to be backed by a single file.
I thought I would ask before I did anything.
I suspect that it is impossible, but just an idea:
Address allocation decision belongs to MapViewOfFile, not to CreateFileMapping. And MapViewOfFile certainly calls some native API stuff in NTDLL.DLL. You could figure out which function does it call to actually create a mapping, and who knows — that function might be more flexible and allow something which is impossible with KERNEL32. (e.g. we know that PE file sections are mapped in a manner you can't imitate with MapViewOfFile).
I am reading < windows via c/c++ >, it describes GetModuleHandle() API as below:
When you call this function, you pass a zero-terminated string that specifies the name of an executable or DLL file loaded into the calling process's address space. If the system finds the specified executable or DLL name, GetModuleHandle returns the base address where that executable or DLL;s file image is loaded.
I am wondering where does the system look for the file name? When I loaded some file into my process address space, is there some centralized table to store the mapping of all the loaded files' names and their load addresses? If we search based on a string match, is it kind of low efficiency?
Many thanks for your insigts.
The loaded module info is maintained as a linked list in process' PEB, in a struct named PEB_LDR_DATA. If you get the PEB pointer, you can traverse through this list and get information like DLL name, base address, entry point, size etc. Check out these pages:
http://msdn.microsoft.com/en-us/library/aa813708.aspx
http://www.codeproject.com/KB/threads/CmdLine.aspx
It looks in the loader (the Windows name for the dynamic linker)'s internal data structure.
GetModuleHandle only works for DLLs that you have loaded in the current process. Whenever the loader loads a DLL into the process, it of course maintains a data structure that includes the module's name. No need to visit the file system.
LdrInitializeThunk runs in user space to start the process of pulling in the DLLs.
I wanted confirm (see the answer of swatkat), that in my information the implementation of GetModuleHandle() really look inside of Wine and ReactOS (and this). You will see the implementation of GetModuleHandle(). The developers of Wine and ReactOS disassemble the code of Windows and implemented his own code based on the results of disassemble. So the code do in the most cases the same as Windows code do.
If you want you can implement your own implementation of GetModuleHandle() base of VirtualAllocEx() only. See my old answer for details. (If you not yet know the handle returned by the function GetModuleHandle() is the Address of the corresponding module in the memory, so one need just find in any way the dll in the memory of the current process).