Memparse output can be overwhelming

[GGh41th]

The current implementation of memparse will print an hexdump of the provided process memory. This hexdump will cover all the memory segments (VMAs) and all the memory pages.

Even for small processes (~2MB of memory) the output is quite large, and for many scenarios some filtering can be very helpful.
Such filters can be:

• The protection flags
• Virtual addresses range (this can be extremely useful if we already know which memory segments we'd like to inspect),
• Or based on the VMA types (shared,file backed memory segments, stack,heap etc).

I've been digging through the CRIT code, and I believe most of that is feasible, and if you think that this fits in the memparse subcommand then I will organize this into one or more PRs and start working on it (I've got few other ideas but let's go slowly :) )

[GGh41th]

@rst0git @adrianreber

[rst0git]

@GGh41th Our use case for this functionality was mainly memory forensics. At the time of developing this functionality, it made sense for us to introduce the --output and --search options to support this:

checkpointctl memparse --help
Analyze container checkpoint memory

Usage:
   memparse [flags]

Flags:
  -c, --context int           Print the specified number of bytes surrounding each match
  -h, --help                  help for memparse
  -o, --output string         Specify the output file to be written to
  -p, --pid uint32            Specify the PID of a process to analyze
  -s, --search string         Search for a string pattern in memory pages
  -r, --search-regex string   Search for a regex pattern in memory pages

for many scenarios some filtering can be very helpful

Could you please describe the scenarios?

[GGh41th]

@rst0git Well my motivation came from a forensic usecase as well, I know that users would usually dump the whole hexdump to a file and work with it, but isolating a specific region could make analysis easier and faster sometimes.
I was inspired by volatility design, where you can for instance inspect the virtual memory areas, with the linux.proc.Maps plugin, which returns something like this:

PID	Process	Start	End	Flags	PgOff	Major	Minor	Inode	File Path	File output
900	snapd	0x7575b764a000	0x7575b764c000	rw-	0x39000	8	3	2230368	/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2	Disabled
900	snapd	0x7ffe6aaaa000	0x7ffe6aacb000	rw-	0x0	0	0	0	[stack]	Disabled
900	snapd	0x7ffe6aba6000	0x7ffe6abaa000	r--	0x0	0	0	0	Anonymous Mapping	Disabled
900	snapd	0x7ffe6abaa000	0x7ffe6abac000	r-x	0x0	0	0	0	[vdso]	Disabled
******** 

Then you can choose which VMA to dump, by providing any valid address in that VMA address range (other VMAs will be excluded), and the VMA choice will be based on factors like the protection flags, backing files, VMA types.

I'm not a memory forensics expert, and these use cases and scenarios are based on few CTF challenges and blogs/videos I have encountered, and I would be happy to be corrected if I'm wrong.

• Some prot flags could indicate a fishy behavior, such as a combination "wx", or an "x" permission on a memory segment that is not backed by a file.
• Attackers could inject malicous code into the heap or into an anonymous VMA, so isolating these regions will make analysis easier and faster.
• If you are only interested by a specific file (e.g,. a deleted malware file), or a shared library, you can just dump the VMA backed by that file.
• I found other scenarios while searching that I didn't fully understood :)

After writing this answer, I think that in terms of memparse, we should only introduce an address range selector flag (or a similar flag to the one used in volatility), and maybe an option to allow users to create binary dumps for specific memory areas, because even if we offer an hexdump utility in checkpointctl, forensic analysts are used to other utilities that offer the same functionality with more advanced options, add to that the other operations that can be done on mem dumps (e.g,. reverse engineering) though this issue would be discussed seperately.

As I mentionned I am not that knowledgeable in memory foren, and many of my assumptions might not be too accurate.