Disclaimer: I'm not a lawyer, so my advice is not binding.
There isn't a failproof way to keep memory in a specific state. Yet, there is a way of arguing that a memory dump can be reproduced and/or argue that you can tell which parts of the memory may have changed.
Proposed tactic
The moment you are making a full memory dump, several processes are running and a kernel is scheduling them. And, moreover, it is possibly swapping memory pages between physical memory and a disk area (swap).
So the first thing you need is to get the memory dump and the swap are at the single point in time. Second you need to get the state of the CPU registers (I'll come back to it in a moment).
I'm thinking in terms of a Linux machine because it is the OS I'm most familiar with. For that OS you can dump /dev/mem and dd the swap areas, or use something like LiME. For other OSes the are several alternatives.
Now, to be able to argue that the memory dump can be reproduced you will need to find and analyze the Global Paging Table (PT). That table resides in memory and links memory access by the kernel onto the actual parts of memory. The location of the table should be in a register (register CR3). But this is why you need the registers, all of them not just RAX, RBX, RCX, RDX, R5, R6, RSP, etc), so the CPU unit responsible for paging can access it.
It is viable to argue that if you can make an index of the PT you can tell which part of the memory may get updated. How?
- The PT holds pages in the physical memory and on the swap too, so your index covers the entire memory.
- DPL (part of the PT) will tell you which pages are owned by the kernel and which are owned by user processes.
Now, based on what the machine does you can tell which memory pages may have been affected and which don't. For example, connecting a pen drive (assuming that the machine does not perform clever udev rule or similar) should only change kernel pages (well, almost, virtual filessystems, e.g. /proc would also be updated).
Pessimistic reality check
Unfortunately, most OSes today will run daemons that will periodically scan userspace visible part of the kernel and act upon it. Possibly messing userspace (DPL 3) pages considerably. You will definitely need physical control of the machine, and analysis of what happens (userspace-wise) when you do something to the machine.
Optimistic notes
On the bright side, when you have the memory dump divided into pages, you can reproduce the sate of the machine (to a good extent). For example, you can boot a VM, start a kernel debugger and overwrite all memory pages one by one.
How that would be seen by a court, may still depend on more classic forensic points. For example, how do you prove that the memory dump in question is of the machine you claim it to be. But that is something that can be solved by procedures that document exactly how the forensic was performed on the machine.
References/Related
