3 ms·
LoadLibrary is not guaranteed to have the same address across processes. As of Win7 you might also have a process link to kernelbase and not kernel32, so it's n
by asveikau 5y ago
LoadLibrary is not guaranteed to have the same address across processes. As of Win7 you might also have a process link to kernelbase and not kernel32, so it's not even guaranteed to be in the same DLL.
However it should be possible to use GetModuleHandleEx to find the DLL base addresss in a remote process, then ReadProcessMemory to implement your own remote GetProcAddress.
- NtGuy25 5y agoYou do end with modules having the same address in every process if untampered though. This is due to Copy on Write windows implements internally with DLL's to save space. So while not guaranteed. On X64 you can be certain that because of COW the module will have the same address.
- asveikau 5y agoThat's not true. You're not considering different virtual addresses backed by the same pages. Yes, the loader will create file-backed memory mappings and not redundantly store read-only parts. However, it is free to load it at a different address in each process. This can happen via ASLR, or if the mapping is already claimed by the time the module loads. They may get the same base address repeatedly in multiple processes and work most of the time, but it's not guaranteed.
- barchar 5y agoIt's extremely likely for stuff from Kernel32.dll. > That's not true. You're not considering different virtual addresses backed by the same pages. technically I suppose, but PEs don't tend to be relocatable, so if it mapped it in at different virtual addresses that would be extremely unlikely to be backed by the same pages as much of the just-mapped-in code would need relocs