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, ....)
Related
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.
I have a file which is read/write by many processes, they use a mutex to serialize the read/writes.
Is it required that I call FlushFileBuffers after WriteFile in ProcessA so that ProcessB would see these changes? Or would ProcessB be guaranteed to see the changes that ProcessA made, assuming the OS disk cache for this file is shared between all processes? After calling WriteFile I do not call CloseHandle on the file, I leave it open in all processes but they have the FILE_SHARE_READ and FILE_SHARE_WRITE flags passed to CreateFile.
This is required to work across Windows XP to Windows 8.1 - I've found that calling FlushFileBuffers presents an unacceptable performance bottleneck.
Processes which have a memory-mapped view of the file have direct access to the page in the disk cache; accesses are coherent with all other processes on the same machine, and your mutex is sufficient for synchronization.
Processes which use file access APIs need to call FlushFileBuffers to ensure coherency.
If you can't get away from shared files for IPC (for example, you can't change one of the participants), you can at least migrate the ones you do control to memory-mapped file views, for a big performance benefit.
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.
I need a way to store a value somewhere for temporarily by say Process A. Process A can exit the after storing the value in memory. After sometime Process B comes accesses the same location of memory and read the value. I need to store in memory, because I dont want the data to persistent across reboots. But as long as the system is up, it Independent of the Process the data must be accessible. I tried MailSlots and Temporary files in windows, both seem to have problem where the process reference count drops to zero , the entities dont persist in memory. What is a suitable mechanism for this in Windows preferably using Win32 API?
Ganesh
Write a service that is started at boot time, and let it create some shared memory.
This shared memory can then be filled by process A, and process B can read it afterwards.
If your system is rebooted, the shared memory is gone and you have a fresh, new piece of shared memory.
Make sure that your service correctly 'initializes' the shared memory.
Is there a reason why the data must be resident in memory when ProcessA quits as opposed to being stored somewhere on disk? I ask as you mention temporary files which should work unless ProcessA fails in an unexpected way.
Depending on your needs a nice way to provide shared/fast/atomic data is via the ESENT API.
Try the following. I can't say I know this works, but it seems reasonable.
Create a shared memory file in the global namespace using OpenFileMapping. Then call Duplicatehandle and for the target process handle use some process that will live longer than process A. You may be able to add the handle to winlogon.exe This should stop the shared memory from being destroyed when process A terminates. Then in process B you can look up the shared memory file.
Well, I managed to a create a MailSlot on a Process which doesnt exit, the other two Processes can read and write to the MailSlot server as clients... Even if the clients exit, the Mailslot will still have the data... the MailSlot server enables me to store data in volatile memory has long as the MailSlot server process is up.. or the OS is up.. and vanishes on OS reboot... Thanks for all the ideas and help.... :)
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).