Impact of Tools on The Acquisition of RAM Memory

When responding to a security incident in a system, several basic principles must be followed regarding the collection of pieces of evidence from the system. The capture of these pieces of evidence has to be done according to its order of volatility. In this sense, RAM memory constitute the most important element to capture, given its extreme volatility. RAM memory must be acquired and analyzed because the data it holds, which may belong to the system itself or to any other device connected to it, can survive a certain amount of time in it. Since RAM is a constantly changing element, it must be stood out that any action carried on the system under analysis will modify the contents of the RAM. In this article a comparative and an objective analysis has been carried out, showing the impact that the execution of some tools for the capture of RAM has on the system. This comparative study details both the private shared workspaces, for each of the processes executed by each of the tools used.

to recover useful information from the RAM memory because, this one, is constantly changing. Therefore, when using tools to capture RAM memory in a live system, it is altered and, therefore, the image of RAM memory that is being acquired is also altered. Because RAM memory does not freeze. Data can survive in RAM for a certain time.
For example, an image file that has been opened on a system from an external device could be recovered, with the metadata properties, through thumbnails or, even, fragmented; a carving can be made on the forensic image in the RAM, or, more effectively, on its memory pages; a timeline of this element can be carried out; hashes and/or credentials that are in use can be obtained from, for example, encrypted content in the System; Windows Registry hives, Event Logs, etc., can be exported; processes in execution, historical processes, hidden processes or network connections can be seen, just to give some examples. Everything will depend on the time elapsed since the action of the incident and the actions carried out in the System afterwards.
Very interesting and valuable data can be extracted from the RAM, which could consist of a type of information that is key to the satisfactory resolution of the case. Depending on the type of case, it could even be solved with the analysis of the RAM memory.
Without a doubt, each scenario must be valued because, each one of them, will present its peculiarities and characteristics. For example, it is not the same case, nor does it require the same study, the analysis of an email header as a case where child pornography or terrorism content is found.
But, before starting to analyse the RAM, it must be captured. For this reason, it is vital to choose the right tool to use to capture as much useful information as possible.
Many articles have spoken, on many occasions, of the existing tools available to carry out such an action, explaining its basic operation. But nothing has been said about the impact that the execution of these tools has on the RAM that we want to acquire.

Methods
Since the aim of acquiring RAM in a system is to collect as much useful information as possible, and since the integrity of that memory must be maintained in the best possible way, this study has been carried out, to show the impact of some of the most frequently used tools on the acquisition of RAM. The data exposed shows the resource consumption of the memory itself, in its private space and in its shared space for each of the processes executed by each tool, and the RAM acquisition time. Both factors, running processes and time, are key elements.
Two tests were carried out for this study, using two versions of Windows 10. The first system consists of Windows 10, in its compilation number 17763.253, with an allocated RAM of 4,096 MB. This System has been downloaded from the official Microsoft site («Get Windows 10 development environment») virtualized under VirtualBox («Download VirtualBox»). The second system consists of Windows 10, in its compilation number 17763.292, being a physical system, without virtualization, that has 15,306 MB of RAM memory (See Figure 1).
To monitor the processes running on the various RAM acquisition tools, the 'Process Explorer' («Russinovich») tool has been chosen, in its version 16.22, which is available on Microsoft's official website («Windows Sysinternals»).
The values that have been taken into account as a reference are those related to the private workspace, which consists of the memory dedicated to that monitored process, and which is not shared with other processes, as well as the workspace that is shared with other processes. This size is measured in kilobytes.
The reference values that have been taken into account for the execution times are those relating to the time marks corresponding to the creation and modification of the forensic image of the RAM, because the file is created at the same time as the dump of the RAM begins and is last modified when the last data is recorded, this is, the last bit.
In order not to lose any detail during the acquisition of the dumps, it has been decided to record the whole process on video, using the 'Record that' function of the 'Game Bar', which incorporates Windows 10 system («Background recording settings in Captures on Windows 10»).
Regarding the tools tested, it has been decided to use some that are free of charge and more widely used, such as those listed below: • Belkasoft Live RAM Capturer («Belkasoft») (See Figure 2).
• Winpmem, in its version 3.2 («Cohen») (See Figure 20). During the acquisition of the RAM memory with this tool, two processes has been executed: The 'RamCapture64.exe' process, as the parent process, and a child process 'conhost.exe'. The 'conhost.exe' process is responsible for opening instances for each Windows console. That is, for each Windows console that is opened, a process 'conhost.exe' will appear (See Figure 3). The 'RamCapture64.exe' process has presented a range of consumption values, in its private space, from 1,872-1,988, as minimum and maximum values. In its shared memory, it has oscillated between 1,1476-11,672 (See Figure 3). The process 'conhost.exe' has presented a range of consumption values, in its private space, of 7,260-7,344, as minimum and maximum values. In its shared memory, it has oscillated between 16,768-16,816.
The time it took this tool to acquire the complete memory of the system was 3.150000003 minutes, as it can be seen from the timestamps relating to the creation and modification of the memory image (See Figure 4). This tool can be executed in two different ways: directly from the executable itself, or from a cmd console, where some parameters can be configured. Depending on how the tool is executed, some values can be found or others.
If this tool is executed from the executable itself, two processes can be found: 'DumpIT.exe', as the parent process, and a child process 'conhost.exe'.
The process 'DumpIT.exe' has presented a range of consumption values, in its private space, from 1,644-1,988, as minimum and maximum values. In its shared memory, it has oscillated between 8,980-9,028 (See Figure 6).
The process 'conhost.exe' has presented a range of consumption values, in its private space, of 7,104-7,296, as minimum and maximum values. In its shared memory, it has oscillated between 17,132-17,200 (See Figure 6). The time it took this tool to acquire the complete RAM memory of the system, with this type of execution, was 7.716666658 minutes, as it can be seen in the timestamps relating to the creation and modification of the memory image (See Figure 7). However, if this tool is executed from the cmd console, where some parameters can be configured, the parent process 'cmd.exe' can be seen, with its child process 'conhost.exe', and the parent process 'DumpIT.exe', with its child process 'conhost.exe'.
The 'cmd.exe' process has presented a range of consumption values, in its private space, of 6,108-11,484, as minimum and maximum values. In its shared memory, it has oscillated between 14,460-16,776 (See Figure 8).
The process 'conhost.exe', dependent on the process 'cmd.exe', has presented a range of consumption values, in its private space, of 8,520-8,524, as minimum and maximum values. In its shared memory, it has oscillated between 22,180-22,284 (See Figure 8).
The process 'DumpIT.exe' has presented a range of consumption values, in its private space, of 1,688-1,776, as minimum and maximum values. In its shared memory, it has oscillated between 8,900-8,988 (See Figure 8).
The process 'conhost.exe' has presented a range of consumption values, in its private space, of 7,192-7,280, as minimum and maximum values. In its shared memory, it has oscillated between 16,540-17,012 (See Figure 8). The time it took this tool to acquire the complete RAM of the system, with this type of execution, was 4.8666662 minutes, as it can be seen in the timestamps relating to the creation and modification of the memory image (See Figure 9). As a general comment, this tool will provide, at the end, a very interesting report with information relating to the KDBG, which will help to identify, properly, the profile of the acquired RAM, as well as information relating to the file generated, with a SHA256 hash, information on the machine where it has been executed, information on the operating system and information on the version of the tool itself. All very important information that must be attached to the final report (See Figure 10). This process has presented a range of consumption values, in its private space, of 21,588-22,024, as minimum and maximum values. In its shared memory, it has oscillated between 50,764-51,744 (See Figure 12). The time it took this tool to acquire the complete RAM memory of the system was 3.5833333 minutes, as it can be seen from the timestamps relating to the creation and modification of the memory image (See Figure 13). This process has presented a range of consumption values, in its private space, of 9,656-10,484, as minimum and maximum values. In its shared memory, it has oscillated between 32,812-34,296 (See Figure 15). The time it took this tool to acquire the full RAM of the system was 4.066666664 minutes, as it can be seen from the timestamps relating to the creation and modification of the memory image (See Figure 16). This tool is executed through the cmd console, so the following processes were presented during the acquisition: a parent process 'cmd.exe' with a child 'conhost.exe' process, and a parent process 'Memorize.exe' with a child 'conhost.exe' process. In addition to these processes, a 'netsh.exe' process is presented at the end of the acquisition, which is a command line utility, dependent on the 'Memoryze.exe' process.
The 'cmd.exe' process has presented a range of consumption values, in its private space, of 5,708-11,020, as minimum and maximum values. In its shared memory, it has oscillated between 14,512-16,320 (See Figure 18).
The process 'conhost.exe', dependent on the process 'cmd.exe', has presented a range of consumption values, in its private space, of 7,604-7,688, as minimum and maximum values. In its shared memory, it has oscillated between 19,904-20,032 (See Figure 18).
The 'Memoryze.exe' process has presented a range of consumption values, in its private space, of 3,616-3,644, as minimum and maximum values. In its shared memory, it has oscillated between 11,860-11,960 (See Figure 18).
The process 'conhost.exe' has presented a range of consumption values, in its private space, of 7,276-8,180, as minimum and maximum values. In its shared memory, it has oscillated between 16,804-17,924 (See Figure 18).
The process 'netsh.exe', has presented a memory consumption, in its private space, of 980. In its shared memory, it has presented a value of 120 (See Figure 18).

Figure 18. Detail of memory consumption of the tool Memoryze
The time that this tool took to acquire the complete RAM memory of the system, with this type of execution, was 6.583333332 minutes, as it can be seen in the timestamps relating to the creation and modification of the memory image (See Figure 19). This tool, which is executed via the cmd command line, will have a parent process 'cmd.exe', with two dependent processes: 'conhost.exe' and 'winpmem_3.2.exe.
The 'cmd.exe' process has presented a range of consumption values, in its private space, of 2,828-5,920, as minimum and maximum values. In its shared memory, it has oscillated between 4,944-4,992 (See Figure 21).
The process 'conhost.exe', dependent on the process 'cmd.exe', has presented a range of consumption values, in its private space, of 7,552-7,640, as minimum and maximum values. In its shared memory, it has oscillated between 20,016-20,064 (See Figure 21).
The process 'winpmem_3.2.exe' has presented a range of consumption values, in its private space, from 1,840-3,824, as minimum and maximum values. In its shared memory, it has oscillated between 6,720-8,948 (See Figure 21).

Figure 21. Detail of memory consumption of the tool Winpmem
The time it took this tool to acquire the complete RAM memory of the system was 5.116666668 minutes, as it can be seen from the timestamps relating to the creation and modification of the memory image (See Figure 22).

Figure 22. Timestamps of the generated memory dump, with Winpmem
This tool allows the capture of memory using the network, which can be carried out using the Netcat utility, but this would mean setting up another extraordinary process under the name 'nc.exe' that would have a memory consumption, in its private workspace, of about 624 Kb.
As a general comment, the implementation of this procedure would be carried out through the lines: winpmem_3.2.exe -m --format raw --output -| nc.exe TargetIP Port nc.exe -l -p Port > C:\Test\Memory_Winpmem_remote.raw

Results and Discussion
Any tool for RAM memory acquisition will always dump the entire memory of the system. All the files generated will have the same size unless they are compressed or splitted (See Figure 23).

Figure 23. Size of the RAM memory dumps acquired in the tests
In the case of performing the acquisition process with the Winpmem tool, the resulting file will be larger than the system's memory because, in addition to this, it extracts and acquires other types of data. For this reason, the resulting file will be a '.zip' file, which is a container that cannot be directly analysed and which must be decompressed. Inside it, the image of the physical memory is found under the name of 'PhysicalMemory' (See Figure 24). It has been commented in some articles that, some tools, give problems with RAM sizes over 8 GB. This is not true. The main problem that exists is that the memory profile is not identified correctly. The forensic image profile of the RAM must be correctly identified before proceeding with the analysis of the memory. All the memory images created with the tools shown in this study can be analysed with the appropriate tools, such as Volatility (See Figures 24 & 25).

Objective data: Acquisition times
The objective data of the tests they have carried out are set out below. The first data to be presented will be the one relating to time. The time, established in seconds, that a tool takes to acquire the System's RAM memory.
As it can be seen (See Figure 26), in the tests run, the fastest tool has been Belkasoft Live RAM Capturer, while the slowest has been DumpIT, running from the command prompt, where a format type and output path were specified. However, the DumpIT tool, if executed directly, without using the Command Prompt, is not the slowest, leaving that position to Memoryze. The difference between the fastest and slowest tool is 274 seconds.
As mentioned at the beginning of this article, RAM memory is constantly changing. In other words, it contains highly volatile information. Therefore, the 274 second difference between the fastest and slowest tool is a very long time. With the course of this time, the possibilities of recovering elements of interest decrease. Elements that, with proper intervention, could be found in the RAM memory.

Objective data: RAM memory consumption
Below are the objective data regarding RAM consumption, in its private workspace, for each of the tools tested. This consumption is measured in Kilobytes.
Because memory is constantly changing, processes will never have a single value. And they will not even present the same range of values in another similar execution.
In the tests carried out (See Figure 27), the tool that has used the fewest private resources has been DumpIT, with a minimum value of 1,644 Kilobytes, compared to the 21,588 Kilobytes used by FTK Imager Lite. Even at maximum values, the DumpIT tool consumes fewer resources, with a maximum value of 1,988 Kilobytes (the same as the Belkasoft RAM Capturer tool), as opposed to the 22,024 Kilobytes maximum value of FTK Imager Lite. The difference between the two minimum values is 19,944 Kilobytes. A lot of information can be found in this space. Vital information that could be lost by not thinking about that consumption, in that size. Figure 27. Consumption, measured in Kilobytes, for each of the tools used, in the private work space Maybe it could be thought, and believe, that these values, this comparison, are enough to determine whether to choose one tool or another. But you must also think about the rest of the processes that are executed by the System with each one of the tools, and about the workspace shared with other processes. For this reason, the information corresponding to this data is also presented, where the values obtained with the total sum of the consumption of each of the tools are shown below.
As it can be seen (See Figure 28), the tool with the lowest total consumption, in the tests carried out, was DumpIT, with direct execution, without the use of the cmd console, with a value of 24,860 Kilobytes. On the other hand, the tool with the highest consumption is Memoryze, with a total value of 88,264 Kilobytes. A difference in total consumption of 53,404 Kilobytes can be seen. Certainly, a huge amount of information can be saved, found and/or lost, in that workspace, in that size.

Conclusion
In this article it has been presented only some small tests that have been carried out with some of the free RAM acquisition tools and that are considered being of more extended use. Other similar tests could be carried out with other tools. To name a few examples, this same study could be carried out, comparing a small utility, such as MDD («Stotts»), with the OSForensics suite («PassMark® Software Pty Ltd»).
Since RAM is constantly changing, no tool will have a single value, either in terms of resource consumption or time. It will not even display the same range of values in two different executions. It is not possible to obtain two identical RAM dumps. It all depends on the case. Everything depends on the system. Everything depends on what is being executed at that moment.
In my humble opinion, I believe that this study is an excellent way to compare the way in which the different tools work, without making subjective assessments, full of interests or opinions, since it is a question of presenting objective data in a real environment.
Each user can use the tool with which is most comfortable, regardless of which one it is, without taking into consideration what has been seen in this article, or, it can be taken into consideration that, since memory presents very volatile, constantly changing information, one must choose carefully what is going to be executed and how it is going to be executed.
Each user can evaluate only one factor in the use of the tools or can take into account everything that needs to be evaluated: the memory consumption of each of the tools, both in their private and in the shared workspaces, the time that each tool invests in carrying out its function, or the fact that there are tools that provide a final report with information on the memory profile that has been worked on.
The final objective of this work is to show that the tool to be used must be well chosen and that the impact that this tool has on the RAM of the system must be calculated. A memory that is being acquired to carry out a later study on it. A study that contains key information for the resolution of a case. Information that will be lost if the appropriate tool is not used properly.

Declaration of Conflicting Interest
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding
The author(s) declared no financial support for the research, authorship, and/or publication of this article.