-
Notifications
You must be signed in to change notification settings - Fork 15
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
readme: add examples for
memparse
usage
This commit adds a new section to the README.md file that provides an example of how to use the memparse sub-command. Signed-off-by: Kouame Behouba Manasse <behouba@gmail.com>
- Loading branch information
Showing
1 changed file
with
71 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,6 +15,8 @@ Details on how to create checkpoints with the help of [CRIU][criu] can be found | |
|
||
## Usage | ||
|
||
### `show` sub-command | ||
|
||
To display an overview of a checkpoint archive you can just use | ||
`checkpointctl show`: | ||
|
||
|
@@ -41,6 +43,8 @@ $ checkpointctl show /var/lib/kubelet/checkpoints/checkpoint-counters_default-co | |
+-----------+------------------------------------+--------------+---------+--------------------------------+--------+------------+------------+ | ||
``` | ||
|
||
### `inspect` sub-command | ||
|
||
To retrieve low-level information about a container checkpoint, use the `checkpointctl inspect` command: | ||
|
||
```console | ||
|
@@ -64,6 +68,73 @@ awesome_booth | |
|
||
For a complete list of flags supported, use `checkpointctl inspect --help`. | ||
|
||
### `memparse` sub-command | ||
|
||
To perform memory analysis of container checkpoints, you can use the `checkpointctl memparse` command. | ||
|
||
Here's an example of memory analysis of a PostgreSQL container. In this case, we start a PostgreSQL container with a password set to 'mysecret'. Then, we create a checkpoint of the container and use the memparse command to find the stored password. | ||
|
||
```console | ||
$ sudo podman run --name postgres -e POSTGRES_PASSWORD=mysecret -d postgres | ||
$ sudo podman container checkpoint -l --export=/tmp/postgres.tar.gz | ||
$ sudo checkpointctl memparse --pid 1 /tmp/postgres.tar.gz | grep -B 1 -A 1 mysecret | ||
000055dd725c1e60 50 4f 53 54 47 52 45 53 5f 50 41 53 53 57 4f 52 |POSTGRES_PASSWOR| | ||
000055dd725c1e70 44 3d 6d 79 73 65 63 72 65 74 00 00 00 00 00 00 |D=mysecret......| | ||
000055dd725c1e80 00 00 00 00 00 00 00 00 31 00 00 00 00 00 00 00 |........1.......| | ||
``` | ||
|
||
Here's another scenario, of memory analysis for a web application container. We start a vulnerable web application container, perform an arbitrary code execution attack, create a checkpoint for forensic analysis while leaving the container running, and finally analyze the checkpoint memory to identify the injected code. | ||
|
||
```console | ||
# Start vulnerable web application | ||
$ sudo podman run --name dsvw -p 1234:8000 -d quay.io/rst0git/dsvw | ||
|
||
# Perform arbitrary code execution attack: $(echo secret) | ||
$ curl "http://localhost:1234/?domain=www.google.com%3B%20echo%20secret" | ||
nslookup: can't resolve '(null)': Name does not resolve | ||
|
||
Name: www.google.com | ||
Address 1: 142.250.187.228 lhr25s34-in-f4.1e100.net | ||
Address 2: 2a00:1450:4009:820::2004 lhr25s34-in-x04.1e100.net | ||
secret | ||
(reverse-i-search)`': ^C | ||
|
||
# Create a checkpoint for forensic analysis and leave the container running | ||
$ sudo podman container checkpoint --leave-running -l -e /tmp/dsvw.tar | ||
|
||
# Analyse checkpoint memory to identify the attacker's injected code | ||
$ sudo checkpointctl memparse --pid 1 /tmp/dsvw.tar | grep 'echo secret' | ||
00007faac5711f60 6f 6d 3b 20 65 63 68 6f 20 73 65 63 72 65 74 00 |om; echo secret.| | ||
``` | ||
|
||
For larger processes, it's recommended to write the contents of process memory pages to a file rather than standard output. | ||
|
||
To get an overview of process memory sizes within the checkpoint, run `checkpointctl memparse` without arguments. | ||
|
||
|
||
Check failure on line 114 in README.md GitHub Actions / lint_markdownMultiple consecutive blank lines
|
||
```console | ||
$ sudo ./checkpointctl memparse /tmp/jira.tar.gz | ||
|
||
Displaying processes memory sizes from /tmp/jira.tar.gz | ||
|
||
+-----+--------------+-------------+ | ||
| PID | PROCESS NAME | MEMORY SIZE | | ||
+-----+--------------+-------------+ | ||
| 1 | tini | 100.0 KiB | | ||
+-----+--------------+-------------+ | ||
| 2 | java | 553.5 MiB | | ||
+-----+--------------+-------------+ | ||
``` | ||
|
||
In this case given the large size of the java process, it is better to write it output to a file. | ||
|
||
```console | ||
$ sudo ./checkpointctl memparse --pid=2 /tmp/jira.tar.gz --output=/tmp/java-memory-pages.txt | ||
Writing memory pages content for process ID 2 from checkpoint: /tmp/jira.tar.gz to file: /tmp/java-memory-pages.txt... | ||
``` | ||
|
||
Please note that writing large memory pages to a file can take several minutes. | ||
|
||
## Installing from source code | ||
|
||
1. Clone the repository. | ||
|