I've used the tool
fmem for creating a memory dump dd-file. That works fine.
But how can I access this image? I've tried it with
mount but it says I have to specify a filesystem. But non of the given possibilities works (ext4, vfat etc).
fmem is a memory snapshotting tool. It creates an image of the contents of RAM.
While this may be useful for forensics or low-level debugging, it is not a filesystem image and cannot be mounted by any means.
In trying this out myself this file is not anything other than a raw data dump/snapshot of memory. So you can examine it using any hex editor or a tool such as
hexdump, or an appropriate forensic analysis tool.
I found the latest version of
After unpacking it you can compile it like so:
$ make rm -f *.o *.ko *.mod.c Module.symvers Module.markers modules.order \.*.o.cmd \.*.ko.cmd \.*.o.d rm -rf \.tmp_versions make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` modules make: Entering directory `/usr/src/kernels/3.14.4-100.fc19.x86_64' CC [M] /home/saml/Downloads/fmem/fmem_1.6-0/lkm.o LD [M] /home/saml/Downloads/fmem/fmem_1.6-0/fmem.o Building modules, stage 2. MODPOST 1 modules CC /home/saml/Downloads/fmem/fmem_1.6-0/fmem.mod.o LD [M] /home/saml/Downloads/fmem/fmem_1.6-0/fmem.ko make: Leaving directory `/usr/src/kernels/3.14.4-100.fc19.x86_64'
To load the
fmem kernel module you can run the included
run.sh script with the archive:
$ sudo ./run.sh Module: insmod fmem.ko a1=0xffffffff81090ca0 : OK Device: /dev/fmem ----Memory areas: ----- reg01: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg02: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back reg04: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back reg05: base=0x23c000000 ( 9152MB), size= 64MB, count=1: uncachable reg06: base=0x0bc000000 ( 3008MB), size= 64MB, count=1: uncachable ----------------------- !!! Don't forget add "count=" to dd !!!
You can then collect ~10MB of data, into file
$ sudo dd if=/dev/fmem of=tst.dd bs=1MB count=10 10+0 records in 10+0 records out 10000000 bytes (10 MB) copied, 0.0541226 s, 185 MB/s
If we throw the typical gamut of tools at this file you'll see that it doesn't contain anything other than raw binary data.
$ file tst.dd tst.dd: data
$ fdisk -l tst.dd Disk tst.dd: 9 MB, 9999872 bytes, 19531 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
$ hexdump -C tst.dd | head -10 00000000 53 ff 00 f0 53 ff 00 f0 c3 e2 00 f0 53 ff 00 f0 |S...S.......S...| 00000010 53 ff 00 f0 54 ff 00 f0 c9 a3 00 f0 53 ff 00 f0 |S...T.......S...| 00000020 a5 fe 00 f0 87 e9 00 f0 9f 11 00 f0 9f 11 00 f0 |................| 00000030 9f 11 00 f0 9f 11 00 f0 57 ef 00 f0 49 f5 00 f0 |........W...I...| 00000040 14 00 00 c0 4d f8 00 f0 41 f8 00 f0 9f c7 71 e1 |....M...A.....q.| 00000050 39 e7 00 f0 59 f8 00 f0 99 66 71 e1 d2 ef 00 f0 |9...Y....fq.....| 00000060 57 ff 00 f0 f2 e6 00 f0 6e fe 00 f0 53 ff 00 f0 |W.......n...S...| 00000070 53 ff 00 f0 a4 f0 00 f0 c7 ef 00 f0 01 9b 00 c0 |S...............| 00000080 9f 11 00 f0 9f 11 00 f0 9f 11 00 f0 9f 11 00 f0 |................|
$ tune2fs -l tst.dd tune2fs 1.42.7 (21-Jan-2013) tune2fs: Bad magic number in super-block while trying to open tst.dd Couldn't find valid filesystem superblock.
$ sudo mount -o loop -t auto tst.dd /mnt/ mount: /dev/loop0 is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so.
[332140.394396] fmem init_module 449: init [332140.394401] fmem find_symbols 439: set guess_page_is_ram: ffffffff81090ca0 [333010.390836] loop: module loaded
If you want to find out more about the category of tools that can dump memory similarly to
fmem take a look at the list of resources in the references section.
I found this article which discusses the creation AND analysis of these files. It's in the following article titled: Tracing Clues: Memory Analysis - Admin Network & Security Magazine. The article mentions 2 tools, Draugr & Volatilitux.
One of the first tools for memory analysis on Linux was the Python script Draugr. The Draugr script allows users to investigate the memory of a running system directly via the
/dev/mempseudodevice. However, Draugr also analyzes memory dumps available in files. A disadvantage of Draugr is its limited functionality, which is restricted to listing processes and extracting specific memory areas. Development on Draugr stopped in 2009.
Another memory analysis tool is Volatilitux, which was long heralded as the Linux equivalent to the Volatility tool used on Windows systems. The Volatility Analysis Framework now has built-in Linux support, which I will describe later in this article. Volatility has the biggest feature scope of the available Linux RAM analysis tools; however, it is worth noting that Volatility lacks two important features found in Volatilitux.
In addition to the functions known from Draugr, Volatilitux lets you view and extract the open files of a process. A new release in December 2011 added 64-bit support.
NOTE: The Windows tool, Volatility can also be used to analyze the output of