I'm wondering how can I prove the integrity of a computer forensic evidence which was obtained from a running machine (e.g.: memory image). As soon as I do anything with that box, connect a pendrive for example, I alter the registry hives in the memory, and probably on the disk as well, will be altered. How can I ensure that the evidence is still admissible? How can I ensure that the memory image is the same as it was at the time of the examination? I'm afraid there is no solution for this. Does anyone have any court experience with this? What could be accepted by the court?

To avoid any misunderstanding I'm not talking about imaging a standalone HDD with writeblocker and stuff.

1 Answer 1


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.


  • 1
    The register containing the base of the page table is CR3.
    – forest
    Mar 9, 2018 at 4:13
  • 1
    By DLP, do you mean DPL?
    – forest
    Nov 18, 2019 at 5:11
  • @forest - Heh, yes. Very good catch. Not sure if it is worth editing (and bumping) a 3 year old answer just to fix a typo though.
    – grochmal
    Nov 18, 2019 at 6:14
  • You could fix the typo and simultaneously add in that CR3 was the register you were thinking of. I think typos are important since I had to Google "DLP" just to make sure it wasn't some obscure feature distinct from the DPL, since it was used twice and so seemed intentional. Just my 2¢.
    – forest
    Nov 18, 2019 at 6:15
  • 1
    @forest - fair point, fixed a handful of extra typos too. Thanks for finding this btw.
    – grochmal
    Nov 18, 2019 at 6:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.