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).
Related
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.
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.
I'm working on a program with a plugin-based architecture. All the plugins are DLLs, and some of them can have dependencies on other plugin DLLs. I'd like to be able to do the following:
At program startup time, scan the plugins folder.
For each plugin found, check if that plugin is already loaded. (Which it could be, if a previously-loaded plugin caused it to be loaded as a dependency).
If not, load it.
The first and third steps are trivial, but how do I do the second? Is there a winapi call that, given a filename of a DLL, will tell me if that DLL is currently loaded into the current process? (Or perhaps one that takes a filename and a process handle?)
Please, no answers saying "just load it anyway." I know that will work. I'm trying to avoid that.
GetModuleHandle API gives you HMODULE for the loaded DLL, or otherwise NULL if it is not loaded. Note that you can omit path, if desired. You can also get HMODULE for a name without path, and then GetModuleFileName using this handle in order to obtain full path to compare to what you expect.
If lpModuleName does not include a path and there is more than one
loaded module with the same base name and extension, you cannot
predict which module handle will be returned. To work around this
problem, you could specify a path, use side-by-side assemblies, or use
GetModuleHandleEx to specify a memory location rather than a DLL name.
The GetModuleHandle function returns a handle to a mapped module
without incrementing its reference count. However, if this handle is
passed to the FreeLibrary function, the reference count of the mapped
module will be decremented. Therefore, do not pass a handle returned
by GetModuleHandle to the FreeLibrary function. Doing so can cause a
DLL module to be unmapped prematurely.
Enumerating loaded libraries in the process with EnumProcessModules is also possible, but might be a bit of an overkill for the task you described. You might be good with these plain and simple functions without PSAPI.
I'm currently at a point where I need to link in several modules (basically ELF object files) to my main executable due to a limitation of our target (background: kernel, targeting the ARM architecture). On other targets (x86 specifically) these object files would be loaded at runtime and a specific function in them would be called. At shutdown another function would be called. Both of these functions are exposed to the kernel as symbols, and this all works fine.
When the object files are statically linked however there's no way for the kernel to "detect" their presence so to speak, and therefore I need a way of telling the kernel about the presence of the init/fini functions without hardcoding their presence into the kernel - it needs to be extensible. I thought a solution to this might be to put all the init/fini function pointers into their own section - in much the same way you'd expect from .ctors and .dtors - and call through them at the relevant time.
Note that they can't actually go into .ctors, as they require specific support to be running by the time they're called (specifically threads and memory management, if you're interested).
What's the best way of going about putting a bunch of arbitrary function pointers into a specific section? Even better - is it possible to inject arbitrary data into a section, so I could also store stuff like module name (a struct rather than a function pointer, basically). Using GCC targeted to arm-elf.
GCC attributes can be used to specify a section:
__attribute__((section("foobar")))
There is a Flink and Blink (Forward Link and Backward Link) for a double-linked list of processes. There is a process identifier. All of this is packed in a struct that is referenced to as PEPROCESS or _KPROCESS. But where are those and what are the other elements in this structure?
Or, if the answer is neither short nor simple, where can one find references if not in the documentation or header files? (Which is the place i looked and probably overlooked something.)
EPROCESS reference
The EPROCESS structure is an opaque
structure that serves as the process
object for a process.
Some routines, such as
PsGetProcessCreateTimeQuadPart, use
EPROCESS to identify the process to
operate on. Drivers can use the
PsGetCurrentProcess routine to obtain
a pointer to the process object for
the current process and can use the
ObReferenceObjectByHandle routine to
obtain a pointer to the process object
that is associated with the specified
handle. The PsInitialSystemProcess
global variable points to the process
object for the system process.
Note that a process object is an
Object Manager object. Drivers should
use Object Manager routines such as
ObReferenceObject and
ObDereferenceObject to maintain the
object’s reference count.
This means, that you shouldn't care about what the members of a the process structure are. Nevertheless there are sources which detail the layout of the process structure.
This book has a more in detail description what the individual members are.
The EPROCESS structure is documented in the windows debugging symbols.
While connected to a kernel with windbg, assuming you have the debugging symbols properly set up, issuing the command "dt nt!_EPROCESS" should give you the layout for the EPROCESS struct specific to the version of the kernel you are attached to.
The EPROCESS structure are especially opaque and can only be found per build, by examining the data types exported by build debugging symbols.
So you could do the following:
Download volatility here
Run volatility on one of their sample memory dumps or your own dump if you'd want to.
Using the volshell.py plug-in, run
dt('_EPROCESS')
This would produce an output of the structure of EPROCESS and various other structures in the Windows kernel
or you could just see the structure contents here
This also might prove useful