±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 35390
New Yesterday: 2 Visitors: 118

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Webinars

Memory Acquisition Tools - Occupied RAM

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
 
  

Dan_Forensics
Newbie
 

Memory Acquisition Tools - Occupied RAM

Post Posted: Mar 19, 19 13:20

Hi

I am conducting some tests to determine the efficacy of open-source memory acquisition tools. Obviously a pretty pertinent performance metric is the amount of RAM a specific tool occupies whilst the acquisition is being performed. After looking at some academic journals, I have seen some individuals record only the amount of private bytes being attributed to a tool. Others I have seen them record working set/working set peak, virtual bytes and virtual bytes peak and pagefile bytes/page file bytes peak.

I'm wondering as for why there is such a disparity in testing and what metrics I should include which would give a true reflection of how much RAM is being occupied by a tool. I hope this makes sense.

Any information would be great.

Thanks  
 
  

Passmark
Senior Member
 

Re: Memory Acquisition Tools - Occupied RAM

Post Posted: Mar 19, 19 16:23

Windows memory management is complex and poorly understood by nearly everyone. Thus the differences in what is reported.

As to how important the memory foot print is, it really depends on what you are looking for.

If you are looking at the RAM usage of just a particular process, then it doesn't matter what the other processes are doing or how much RAM they use. Process A won't change it's memory usage based on what process B does.

If you are looking at what all the active processes are doing (and dumping physical RAM), then again it doesn't matter so much what the tool's foot print is. Sure some of the processes might be forced to swap some memory pages to disk, but then the same data is in the paging file. Nothing is actually lost.

The case where is does matter is when you are looking for data in free RAM, that isn't currently in use by any process. (e.g. dumping all physical RAM and then just doing a grep for strings)  
 
  

athulin
Senior Member
 

Re: Memory Acquisition Tools - Occupied RAM

Post Posted: Mar 20, 19 03:49

- Dan_Forensics
I'm wondering as for why there is such a disparity in testing and what metrics I should include which would give a true reflection of how much RAM is being occupied by a tool.


The reason for different metrics ... may depend on OS platform, as well as what instrumentation services it offers. For most practical use, the metric you ask about -- occupied RAM -- is not relevant.

The closest would be working set size, or possibly non-shared working set, depending on if you want shared libraries/other code to be included or excluded. (not all platforms provide the latter).

But a working set size is measured over some particular time: under *this* second the working set size may be X, under *that* second it may be 0 ... because the process got entirely paged out, perhaps because it's waiting for I/O to complete, and other processes needed memory to execute.

So you also need to consider if you measure peak size or some type of averaged size, and over what period of time: entire lifetime, or what? And you looking at system time or process time?

All this is closely related to system tuning, where much of this and other system measurements are important. You may need to refer to system documentation related to that particular topic to make entirely certain that you are measuring the right thing.  
 

Page 1 of 1