Skip to content

Commit d9e5742

Browse files
committed
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 <[email protected]>
1 parent 770e424 commit d9e5742

File tree

1 file changed

+89
-0
lines changed

1 file changed

+89
-0
lines changed

README.md

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -15,6 +15,8 @@ Details on how to create checkpoints with the help of [CRIU][criu] can be found
1515

1616
## Usage
1717

18+
### `show` sub-command
19+
1820
To display an overview of a checkpoint archive you can just use
1921
`checkpointctl show`:
2022

@@ -41,6 +43,8 @@ $ checkpointctl show /var/lib/kubelet/checkpoints/checkpoint-counters_default-co
4143
+-----------+------------------------------------+--------------+---------+--------------------------------+--------+------------+------------+
4244
```
4345

46+
### `inspect` sub-command
47+
4448
To retrieve low-level information about a container checkpoint, use the `checkpointctl inspect` command:
4549

4650
```console
@@ -64,6 +68,91 @@ awesome_booth
6468

6569
For a complete list of flags supported, use `checkpointctl inspect --help`.
6670

71+
### `memparse` sub-command
72+
73+
To perform memory analysis of container checkpoints, you can use the `checkpointctl memparse` command.
74+
75+
```console
76+
$ checkpointctl memparse /tmp/jira.tar.gz --pid=1 | less
77+
78+
Displaying memory pages content for Process ID 1 from checkpoint: /tmp/jira.tar.gz
79+
80+
Address Hexadecimal ASCII
81+
-------------------------------------------------------------------------------------
82+
00005633bb080000 f3 0f 1e fa 48 83 ec 08 48 8b 05 d1 4f 00 00 48 |....H...H...O..H|
83+
00005633bb080010 85 c0 74 02 ff d0 48 83 c4 08 c3 00 00 00 00 00 |..t...H.........|
84+
00005633bb080020 ff 35 b2 4e 00 00 f2 ff 25 b3 4e 00 00 0f 1f 00 |.5.N....%.N.....|
85+
00005633bb080030 f3 0f 1e fa 68 00 00 00 00 f2 e9 e1 ff ff ff 90 |....h...........|
86+
*
87+
00005633bb0800a0 f3 0f 1e fa 68 07 00 00 00 f2 e9 71 ff ff ff 90 |....h......q....|
88+
00005633bb0800b0 f3 0f 1e fa 68 08 00 00 00 f2 e9 61 ff ff ff 90 |....h......a....|
89+
00005633bb0800c0 f3 0f 1e fa 68 09 00 00 00 f2 e9 51 ff ff ff 90 |....h......Q....|
90+
00005633bb0800d0 f3 0f 1e fa 68 0a 00 00 00 f2 e9 41 ff ff ff 90 |....h......A....|
91+
00005633bb0800e0 f3 0f 1e fa 68 0b 00 00 00 f2 e9 31 ff ff ff 90 |....h......1....|
92+
```
93+
94+
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` to find the stored password.
95+
96+
```console
97+
$ sudo podman run --name postgres -e POSTGRES_PASSWORD=mysecret -d postgres
98+
$ sudo podman container checkpoint -l --export=/tmp/postgres.tar.gz
99+
$ sudo checkpointctl memparse --pid 1 /tmp/postgres.tar.gz | grep -B 1 -A 1 mysecret
100+
000055dd725c1e60 50 4f 53 54 47 52 45 53 5f 50 41 53 53 57 4f 52 |POSTGRES_PASSWOR|
101+
000055dd725c1e70 44 3d 6d 79 73 65 63 72 65 74 00 00 00 00 00 00 |D=mysecret......|
102+
000055dd725c1e80 00 00 00 00 00 00 00 00 31 00 00 00 00 00 00 00 |........1.......|
103+
```
104+
105+
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.
106+
107+
```console
108+
# Start vulnerable web application
109+
$ sudo podman run --name dsvw -p 1234:8000 -d quay.io/rst0git/dsvw
110+
111+
# Perform arbitrary code execution attack: $(echo secret)
112+
$ curl "http://localhost:1234/?domain=www.google.com%3B%20echo%20secret"
113+
nslookup: can't resolve '(null)': Name does not resolve
114+
115+
Name: www.google.com
116+
Address 1: 142.250.187.228 lhr25s34-in-f4.1e100.net
117+
Address 2: 2a00:1450:4009:820::2004 lhr25s34-in-x04.1e100.net
118+
secret
119+
(reverse-i-search)`': ^C
120+
121+
# Create a checkpoint for forensic analysis and leave the container running
122+
$ sudo podman container checkpoint --leave-running -l -e /tmp/dsvw.tar
123+
124+
# Analyse checkpoint memory to identify the attacker's injected code
125+
$ sudo checkpointctl memparse --pid 1 /tmp/dsvw.tar | grep 'echo secret'
126+
00007faac5711f60 6f 6d 3b 20 65 63 68 6f 20 73 65 63 72 65 74 00 |om; echo secret.|
127+
```
128+
129+
For larger processes, it's recommended to write the contents of process memory pages to a file rather than standard output.
130+
131+
To get an overview of process memory sizes within the checkpoint, run `checkpointctl memparse` without arguments.
132+
133+
```console
134+
$ sudo checkpointctl memparse /tmp/jira.tar.gz
135+
136+
Displaying processes memory sizes from /tmp/jira.tar.gz
137+
138+
+-----+--------------+-------------+
139+
| PID | PROCESS NAME | MEMORY SIZE |
140+
+-----+--------------+-------------+
141+
| 1 | tini | 100.0 KiB |
142+
+-----+--------------+-------------+
143+
| 2 | java | 553.5 MiB |
144+
+-----+--------------+-------------+
145+
```
146+
147+
In this example, given the large size of the java process, it is better to write its output to a file.
148+
149+
```console
150+
$ sudo checkpointctl memparse --pid=2 /tmp/jira.tar.gz --output=/tmp/java-memory-pages.txt
151+
Writing memory pages content for process ID 2 from checkpoint: /tmp/jira.tar.gz to file: /tmp/java-memory-pages.txt...
152+
```
153+
154+
Please note that writing large memory pages to a file can take several minutes.
155+
67156
## Installing from source code
68157

69158
1. Clone the repository.

0 commit comments

Comments
 (0)