I am having problem in understanding following statement that i read from Microsoft .It says that "Multiple processes that load the same DLL at the same base address share a single copy of the DLL in physical memory."
SO what i understand is if a DLL has to be shared between different processes then that DLL has to loaded in the same base address in every processes virtual memory .Why this ? What happens if the process is loaded at different base addresses in the different processes virtual address space ,since ultimately all the process will be accessing the same physical memory in the end for the shared DLL .
image section bind to file on disk. while we not modify some page from section set - this page will be shared and backed by image file. but if we modify page - it can not be more backed by image file. system need allocate new physical page for this modified page. this page already will be private for process and backed by page file.
are section mapped at the same or different address not play direct role. but in case image section - if it mapped not at common preferred address - it must be relocated. relocation - require code modification. as result image pages modification, allocation new private physical pages
The reason is dynamic linking. Most DLL files are not just loaded into memory, they are processed so that absolute or long jumps inside the code are rewritten to make sense. THEN the pages are locked for read-only+execute purposes.
So if the same DLL is loaded at different base addresses in different processes, the results of the dynamic linking process will be different, and the memory pages cannot be shared.
This is true for the DLL file data, e.g. code. The memory which is allocated / used while the DLL code runs is of course something completely different.
Related
This question is asked in the context of Microsoft Windows.
If Process A uses CreateFileMapping() in Windows API to create a section object, and later on Process B access the same object, which process is in charge of hosting the section object???
If it's Process A the one hosting it, what happen when Process A is ended??? Does Process B able to continue to access the shared section object??? This second question only relevant provided it's indeed Process A the one hosting the shared section object.
I guess NTFS (file system of Windows) has some cache. Suppose I have a file, which is frequently accessed (read-only). How can I check if this file is in the file system cache ? Can I increase the file system cache size ?
Check
http://blogs.technet.com/b/askperf/archive/2010/08/13/introduction-to-the-new-sysinternals-tool-rammap.aspx
You can use RamMap which will give you a dedicated view of how current system is caching files.
Also to mention, cache isn't based on file, more by block/page.
There is no direct way from user space to detect if a file has been cached (partially or completely). In a multithreaded/multiprocessing environment, once you have received this information, it is instantly out of date.
There is no "limit" to caching in Windows that can be adjusted (although my data is Windows 7 and prior versions). The cache manager simply uses the memory manager to place data into memory and get callbacks when physical memory needs to be reclaimed (say, by an application's demands). The memory manager trades off file cache against memory demands of processes.
The system I'm working on has many processes running. In the context of shared memory, some are servers and some are clients.
They create/access the shared memory through CreateFileMapping and MapViewOfFile.
I recently changed a structure on one of the clients, which led the client to attempt to map a region of shared memory which is bigger than what was created by the server process. The result is Access Denied.
My problem is, I have no idea which darn process created the memory in the first place. Is there a way of accessing such meta-information about shared memory in order to determine which server program needs to be recompiled?
To confirm, it is MapViewOfFile which is failing, with an error code of 5: Access denied.
Two types of shared memory exist: dynamic (using CreateFileMapping...your scenario) and static (memory mapping declared in PE Section(s) characteristics). One could test the existence of PE sections with shared memory characteristics on file and process level.
On the other side, the reason why MapViewOfFile failed might be other than the different sizes of mapped memory (e.g. credentials, offset of memory, ....)
specifically i want to know if kernel32.dll load address can be different for two processes within the same session ?
I want to use createremote thread so just wanted to know if kernel32 load address in remote process can be different from the injecting process in any scenario ?
Kernel32.dll has the same base address on all processes to allow exactly what you'd like to do. Read: Why are certain DLLs required to be at the same base address system-wide?
System DLLs are loaded at random addresses (ASLRed) for security reasons so that a remote attacker can't guess where bits of code on your system are living in memory (i.e. remote attackers can't guess pointers on your computer).
This happens once per boot, and hence kernel32 will be loaded at the same address in all processes across your system.
How does this program access other processes memory? How can it write into the address space of another process? Wasn't it supposed to segfault or something?
A program with a system privilege level is capable of mapping physical addresses to its own virtual address.
Cheat O'Matic (and poke) maps the physical address of whatever program it is trying to scan into its own virtual space.
Once this is done, it scans all the bytes for the target value you enter. It isolates the correct memory address by asking the user to altering the address to known values and basically does a diff between the old and new memory to find the changes.
One way to do it is to inject a DLL (Google for 'Dll injection') into the address process that you want to spy on: that DLL is then inside the process and can do things with the process' memory. The spy process can use an Interprocess Communication method (pipes, sockets, anything) to talk with the DLL which it injected into the other process.
Injecting a DLL takes administrator priviledge (e.g. to set a relevent entry in the system registry).