7

In Digital Forensics, as a best practice, an investigator should collect data from the most volatile source to the least volatile source. Usually, when talking about live/Dynamic Acquisition, most textbooks starts with the RAM as the most volatile data source even though CPU registers are more volatile. However, I can't seem to find a source describing data acquisition from a suspected device's CPU. Since running any program will change at least one register (EIP/RIP). So my questions are, Is neglecting the data within the registers is because there is no investigative value for them? or because it is not possible?

And -depending on the answer for the above question- Is there a way to do so?

SDsolar
  • 977
  • 1
  • 6
  • 25
HSN
  • 968
  • 5
  • 14
  • 1
    Interesting question! check these papers: http://ieeexplore.ieee.org/document/6159113/?reload=true ; http://homepage.cs.uri.edu/~thenry/csc414/11_The_CPU_TOC.pdf – Soufiane Tahiri May 23 '17 at 09:21

2 Answers2

5

Even if no program runs, the OS itself runs. And you can't alter that - neither technically nor forensically.

Furthermore, a modern quad-core CPU can have several hundred CPU registers, most of which are invisible ! This is an optimization: when you're writing a value from a CPU register to cache, it may take a while. By using an invisible register to hold the value for a while, the CPU can continue. But as soon as the value is written, the register can be cleared. So effectively you're dealing with invisible registers that change state even if no program is running - good luck!

Which also gets us to the next problem: the CPU cache is permanently and pretty independently updating itself. It wouldn't be efficient if this would be under program control.

Now what is possible is to dump a program. A typical modern OS can save the full program state, including registers, to a disk file. On Linux this is known as a core file, on Windows as a user mode dump. This capacity was needed anyway because a multi-tasking OS may need to suspend and resume a running process (e.g. when another process is scheduled to run). Obviously, to resume the process, the registers need to be restored. Cache is typically just cleared as it shouldn't affect program correctness anyway, and therefore doesn't end up in dump files either.

MSalters
  • 2,699
  • 1
  • 15
  • 16
  • 1
    @SDsolar: How are you going to get the value of a register by watching its I/O? It is very, very likely that the register value will be overwritten without ever occurring in I/O. This can be proven by looking at the number of register updates possible, which significantly exceeds the memory bandwidth. – MSalters May 24 '17 at 07:09
  • It might be useful to mention the fact that it's not the actual registers that are being dumped, but the contents of the registers that were pushed to the kernel stack during a context switch (i.e. the registers that are to be restored when the process is to resume). – forest Nov 01 '18 at 08:49
3

The accepted way to do so is to attach logic probes to the CPU and/or other places in the circuit.

With that arrangement you can trace instructions and data movement into and out of the CPU, and are able to deduce the register states accordingly.

But once you introduce a new running program into the system you have violated the first rule about legally-useable forensic evidence. You have changed the system. Any decent defense attorney would be able to impeach such evidence.

SDsolar
  • 977
  • 1
  • 6
  • 25
  • 1
    I like this answer since it technically makes sense (+1). But I'm not that sure about the legal part. I believe that the strictness with which you need to collect the evidence and document what you did varies considerably between both jurisdictions and what data you're actually after. (Although IANAL) – grochmal May 24 '17 at 00:57
  • Logic probes are not able to record the data in the registers of any modern processor. You would need to use a debugging interface like JTAG. – forest Apr 08 '18 at 22:14