Using memfetch, page 37 
http://shellcoders.blogspot.com/2009/05/using-memfetch-page-37.html

memfetch - Linux on-demand process image dump
---------------------------------------------

Copyright (C) 2002, 2003 by Michal Zalewski <lcamtuf@coredump.cx>
Distributed under terms and conditions of GNU Public License version 2.

=============================================================================

Memfetch is a very simple utility that can be used to dump process memory of 
any userspace process running on the system without affecting its execution.
Why bother? Well, quite often it is desirable to see what code and what data
actually resides in memory under some pid (/proc entries are not always
accurate). Debuggers like gdb are pretty good for examining small sections
of code or memory, but are pretty much useless for massive comparison, 
sophisticated searches and such. It's good to be able to retrieve full
memory image to run it thru grep, strings, your favorite viewer or any other
tool. Quite obviously, I developed this code not because it's extremely
difficult to do it on your own, but because it is a valuable shell utility
for all kinds of deep hacking activities that simply saves you time.

Memfetch is a convenient screenshot grabber for ssh or screen sessions, by 
the way ;-)

The tool can be also used to retrieve memory dump on fault conditions -
such as segmentation fault - even if core file won't be generated on
kernel level (rlimit settings, custom signal handlers, setuid or otherwise
privileged code, cwd permissions, etc). With its extra option, -s, the
program will wait until SIGSEGV, SIGPIPE, SIGILL, SIGFPE or SIGBUS is
delivered to a monitored process before taking a snapshot.

Memory is dumped in a set of files - mfetch.lst describes all files,
including their mapping addresses and source. map*.bin files are a copy of all
non-anonymous maps (shared libraries, mostly). This is a useful piece
of information you won't find in a core dump - while this data is generally
not supposed to be different from file contents (with exceptions), it's also
an interesting attack vector... Finally, mem*.bin files are anonymous memory 
blocks, most likely code, stack and heap segments. I think it's much easier 
to parse and more complete this way.

Limitations, bugs and requirements: 

  1) Only Linux supported; 2.2 or later is strongly recommended, as
     map detection won't work properly on 2.0. Thanks to Linus, it is
     no longer possible to mmap /proc/pid/mem on 2.4, so expect things
     to work slower. Well done.

  2) /proc filesystem has to be mounted.

  3) You cannot generate a dump of a process that is already traced with
     a ptrace-based debugger like strace, ltrace or gdb.

  4) Do not use -s option on a hostile code; -s is intended for debugging
     fault conditions in casual code, and can be easily detected by any
     baseline anti-debugging routine.
 
  5) There's a dumb kernel 2.2 and 2.4 bug - literal \n is not
     escaped in any way in /proc/pid/maps. Not a big deal, but it's there
     and may be used to trick this program into "seeing things".

  6) Because ptrace() interface stinks, you cannot use -s in conjunction
     with threads. 

  7) On Linux 2.2, dumping threds using mmap() can cause wonderful system
     hanging in some cases. Use -m option (slower) to avoid this.

Please send your comments, bug-reports, enhancements and, as always,
chocolate, to lcamtuf@coredump.cx