# Captured Memories

For this challenge, you get given a `mem.raw` file. So initially this along with the title screams **memory forensics** and so the main program that comes to mind is [**Volatility**](https://github.com/volatilityfoundation/volatility), if unfamiliar with this tool, it can be best described as a memory forensics tool to help you look at memory captures of RAM. This tool should be automatically installed on Kali, but other distros should follow install instructions found on the GitHub page (linked above). 

*It is worth noting I used `Volatility 2` in this writeup, the syntax for `Volatility 3` is similar, just replace `volatility` with `vol3` it could also be worth noting that depending on your install, you might need to run it as `volatility.py`* 

So to start with you run the following command with a memdump/raw format, the `imageinfo` plugin will provide basic information on the memory capture:

```bash
volatility -f mem.raw imageinfo > raw_imageinfo.txt
```

Breaking this command down we have the name of the program `volatility` followed by `-f` which tells volatility to take in the file `mem.raw`, then as outlined above the `imageinfo` plugin gives us basic information on the image. I then personally followed it with `> raw_imageinfo.txt` just so I have it saved in a text file should i need it earlier. This is not essential, however i reccomend it, especially for when Volatility can have a lot of input, it also gives you the power of tools like `grep` and `awk`. 

```bash
Volatility Foundation Volatility Framework 2.6.1
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win10x64_17134, Win10x64_14393, Win10x64_10586, Win10x64_16299, Win2016x64_14393, Win10x64_17763, Win10x64_15063 (Instantiated with Win10x64_15063)
                     AS Layer1 : SkipDuplicatesAMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/home/REDACTED/Downloads/mem.raw)
                      PAE type : No PAE
                           DTB : 0x1aa000L
                          KDBG : 0xf8001e43d520L
          Number of Processors : 2
     Image Type (Service Pack) : 0
                KPCR for CPU 0 : 0xfffff8001d4e2000L
                KPCR for CPU 1 : 0xffffd40032268000L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2020-06-26 15:51:36 UTC+0000
     Image local date and time : 2020-06-26 08:51:36 -0700
```

Then we take the profile, normally we take the first however it won't always work, luckily ,in this case, it was the first profile which is `Win10x64_1734`. 

We then run the following command as we were told we needed the `PID` so automatically i decided to look at the processes, now this can be done with either the `pstree` plugin or the `pslist` plugin, the difference is mainly that `pstree` gives us a more visual representation of which process was launched by which, whereas `pslist` lists them all. I chose `pstree`, the command is shown below:

```bash
volatility -f raw.mem --profile=Win10x64_1734 pstree > raw_pstree.txt 
```

Breaking this down, we have the `volatility -f raw.mem` as I mentioned before which initialises Volatility along with specifying the file. The big difference here is that we now specify a profile as shown by the `--profile=Win10x64_1734` part of our command, when we ran `imageinfo` we took the profile and now we need to specify it to Volatility to run further plugins. The next part of our command is `pstree` which as outlined above creates a tree of all processes on the system. I then also save this in a file again with `> raw_pstree.txt` which helps me with things like grep but also means I only need to run this command once. Below is a shortened output for the sake of the writeup:

```bash
Name                                                  Pid   PPid   Thds   Hnds Time
-------------------------------------------------- ------ ------ ------ ------ ----
 0xffff87868e88d440:System                              4      0    111      0 2020-06-26 15:07:32 UTC+0000
. 0xffff878690147040:smss.exe                         348      4      2      0 2020-06-26 15:07:32 UTC+0000
. 0xffff87868e975040:Registry                          88      4      3      0 2020-06-26 15:07:23 UTC+0000
. 0xffff878690ccc040:MemCompression                  1168      4     50      0 2020-06-26 15:07:58 UTC+0000
 0xffff878690495080:wininit.exe                       528    424      1      0 2020-06-26 15:07:45 UTC+0000
. 0xffff8786904cd080:services.exe                     648    528      6      0 2020-06-26 15:07:46 UTC+0000
.. 0xffff8786914d2580:TrustedInstall                 2572    648      5      0 2020-06-26 15:43:20 UTC+0000
.. 0xffff878690c8d580:svchost.exe                    1052    648     18      0 2020-06-26 15:07:58 UTC+0000
.. 0xffff878690c2d580:svchost.exe                      60    648     64      0 2020-06-26 15:07:56 UTC+0000
... 0xffff8786909b0580:sihost.exe                    2672     60     15      0 2020-06-26 15:08:51 UTC+0000
... 0xffff87868fa02580:wuauclt.exe                   5288     60      7      0 2020-06-26 15:43:18 UTC+0000
... 0xffff8786909e1580:taskhostw.exe                 2764     60     10      0 2020-06-26 15:08:52 UTC+0000    
```

Now if we scroll down we see the below process: 

```bash
.... 0xffff87868f2e1080:winpmem_v3.3.r               3348    784      5      0 2020-06-26 15:51:36 UTC+0000     
```

I assumed this was the process as we know it was a Windows system from the challenge description. So for the flag, we simply took the `PID` which was `3348`, which we then submitted as the flag in the form specified which was: `flag{3348}`.

> Writeup created by Chris Harris (cjharris).