Feature request: stream memdump over the network

[svdb0]

For forensic purposes, it is desirable to leave as small a (memory and disk) footprint as possible on the system whose memory is being dumped.
Regarding the disk footprint, it would for this reason be useful to be able to stream the memory directly across the network to another system.

[demoray]

There isn't built-in support to remotely capture memory without touching local disks, as this often leads to a less coherent snapshot due to the latencies involved. That said, we have tested using /dev/stdout enable remote capture.

Example:
ssh username@ip sudo avml --compress /dev/stdout > local-file.lime

Does this model work for you?

[svdb0]

Hmm... I tried

./avml /dev/stdout > /dev/tcp/1.2.3.4/1234

using the Bash > /dev/tcp/<host>/<port> syntax, in an attempt to avoid an extra pipe.
That however fails due to reasons which now turn out to be unrelated to AVML.

Your command, or the converse

avml /dev/stdout | ssh username@ip 'cat > remote-file.lime'

will indeed be a suitable solution for most cases, and with that my reason for this feature request is more or less eliminated.

It would still be nice not to depend on the presence of any particular software on the target system. (Now I think of it, even the need for AVML could be eliminated with cat /proc/kcore > /dev/tcp/1.2.3.4/1234. 😉)
Also, there could be situations where directly uploading to an HTTP server (using chunked encoding perhaps) may be more convenient.

Regarding capturing to the network often leading to less coherent memdumps, sometimes the opposite may be the case; you could have a very fast network connection and a fast SSD on the remote system, while you only have a slow HDD on the system of which you're capturing the memory.
Also, if you're only planning on carving the memdump (for encryption keys perhaps), a lack of internal coherency may not be prohibitive.

[demoray]

Of note, cat /proc/kcore exposes the entire address space, not just that which is mapped to memory. That would be significantly larger amount of data.

[JakePeralta7]

you can use the following bash script:

mkfifo mypipe  # Create the named pipe
./avml --compress /dev/stdout > mypipe &  # Write AVML output to the pipe
cat < mypipe > /dev/tcp/target_ip/target_port  # Read from the pipe and send over TCP
rm -f mypipe  # Remove the named pipe when done

[SolitudePy]

you can use the following bash script:

mkfifo mypipe  # Create the named pipe
./avml --compress /dev/stdout > mypipe &  # Write AVML output to the pipe
cat < mypipe > /dev/tcp/target_ip/target_port  # Read from the pipe and send over TCP
rm -f mypipe  # Remove the named pipe when done

Very nice, would like a built-in feature to dump memory directly to tcp remote port and also why it doesn't work to directly forward it to /dev/tcp//?

[demoray]

This is not something we are likely to include by default at this time. We're open to a contribution that implements this as a compile-time feature.