**PSA: I know this is not the right way to solve this challenge, but tought it was fun and wanted to share this solution as it could be useful in some situations... ;)**

## So conventional way first (skip to the second part if you only want the twist):

In the given zip file, we find a pcap and a memory dump.
Taking a quick look at the pcap show us a communication between two hosts, more particularly one host sending data to another host.

We can easily retrieve the raw TCP data exchanged using tcpflow and remove potential command headers separating base64 encoded data:
```
tcpflow -r taking-a-look-inside.pcap
cat 192.168.056.101.60182-192.168.056.001.42042 | tr '|' '\n' > exfilt_data
sed -i '/^NCS/d' exfilt_data
sed -i '/SCN$/d' exfilt_data
```

We now have 36 lines of base64 encoded data that we can split and decode into multiple files:
```
split -l 1 exfilt_data
for file in x*; do base64 -d $file > $file.dec; done
```

But given the entropy of the files, they must be ciphered.

The next logical step is to open the memory dump with volatility, but we first need the correct profile.
Searching 'Linux' through the dump give us some information about the kernel version (Debian kernel4.9.0-6), and we also find that the user tried to clone and checkout a specific branch of volatility:
```
git checkout -b Linux4_8_kslr_support_take2
```

So now we have to get the correct branch from the git and build the correct profile (the compilation of the module.dwarf should be done on a Debian running the same kernel version):
```
git clone https://github.com/bneuburg/volatility.git
git checkout -b Linux4_8_kslr_support_take2
cd tools/linux/
make # or just get the module.dwarf from your temporary Debian build VM ;)
wget http://ftp.debian.org/debian/pool/main/l/linux/linux-image-4.9.0-6-amd64_4.9.82-1+deb9u3_amd64.deb
ar x linux-image-4.9.0-6-amd64_4.9.82-1+deb9u3_amd64.deb
tar xvf data.tar.xz ./boot/System.map-4.9.0-6-amd64
zip -r Debian-4.9.0-6.zip boot/System.map-4.9.0-6-amd64 module.dwarf
mv Debian-4.9.0-6.zip ../../volatility/plugins/overlays/linux
```

And now let's search through the dump with volatility right?
```
python2 vol.py --profile=LinuxDebian-4_9_0-6x64 -f taking-a-look-inside.dmp linux_pstree
python2 vol.py --profile=LinuxDebian-4_9_0-6x64 -f taking-a-look-inside.dmp linux_enumerate_files
```

We find many interesting things such as some python and GIMP processes and some files in /media/sf_vms-share/taking-a-look-inside/.
/media/sf_vms-share/taking-a-look-inside/src/goggles is the most interesting file and probably the one transmitting the .png files located right next to it.

But after all this, volatility was a bit picky at extracting files and I could not get the potential .pyc file containing the AES key from the memory.

## And this is the point where all of this work becomes completely useless!

While beeing disappointed by volatility, a friend mentionned the GIMP process inside the memory dump and it gave me an idea. Why not "take a look inside" as the name of the challenge implies?

Knowing that it was a thing, I tought why not open the raw dump in GIMP?


And it allows us to scroll through the memory:


The goal here is to find visual artefacts still present in memory and large image can be distinguished like this:


After adjusting the width using the arrow, we see the image evolve in real time up to a point it's readable!


Scrolling just a bit further we find the rest of the flag.


We just need to get everything together in the right order and we have our flag!
INSA{aa80467558a76019b99ecec7b4f6d0c7}

So here it is, a forensic challenge containing a pcap and a memory dump that can be solved only using GIMP.