How do I gather CPU's REGISTER and CACHE Informations?

At the order of volatility, Registers and Caches are the first evidences to gater for computer forensic. but I can't find how to gather it.

Not sure you got your the first parts of that sentence right – have you double-checked that you did?

Assuming you have, registers and caches given what contect and circumstances?

In general? Registers … well, read the hardware manual of the CPU model. There's usually some way of stopping it dead, and extract information from it. You need considerable hardware knoweldge to do it, or you need a hardware debugging environment around the CPU.

Caches … depends where they are. Are we talking instructions or data caches, on the CPU or data caches on hard drives or network cards? But again, the answer is probably in the hardware reference manuals of those devices. Dumping caches is not much of a general requirement in every-day computing, though, so you probably can't trust that functionality to be implemented in the device drivers of any particular operating system. You need to check.

In the typical situation, though, you're faced with an unknown computer, running partly unknown software. You're not even sure if the software on the computer can be trusted to do what you want it to do, you may not even have local admin rights, and you do not have the option of doing much tweaking.

You better know what you are going to do with that register dump once you've got it.

If you want to start at another end, sit down at a Windows computer, bring up the command console, and enter the 'debug' command. Then write 'r'. That's a register dump. Not 'the' register dump, just 'a'.

Now what registers are you looking at? Those established in the context of the debugger that you started. Is that the information you want to have? If not, what register status are you looking for?

Now, just by running the debugger, any instruction and data caches on the CPU are probably messed up – you're likely to find they contain information from debug.exe that you started. (Though if you had a program to dump their contents, you'd probably find large parts of that program in the caches when you examined the dumps, on top of the changes made by the debug.exe.) And hard drive caches are also like to have received a dose of debug.exe, at least the one with the drive where that program resides.

So context is important here. What particular context are you interested in? And how do you maintain it during forensic data collection?

This is approximately where the hardware angle I mentioned comes in can you get at the information you want without destroying it by your own data-collecting software? or can you do it only if you have the CPU and everything else in a hardware debugging rig that you control? (Well, why not? Academical forensics and practical forensics are not necessarily on the same page in the book)

If the computer you wanted to acquire was playing music, I'm sure you could find perhaps a tenth of a second of music data in the CD reader's cache, or perhaps in the audio card buffer. Not quite as volatile as regiser or cache contents, but close. Under what circumstances would that 1/10th of a second of audio data be important to collect?

athulin, I mean CPU's Registers and Caches. )
thanks for very helpful informations!

Drugfish,

This isn't actually done very often, in part because it *is* so volatile. Those items were most likely included in the Order of Volatility for example and completeness.

I think some of the work done with the Volatility project in parsing memory dumps can provide some of this information if you really need it, but I have yet to see a live response toolkit that retrieves that information.

hth