Como montar uma imagem dd que foi criada via fmem (ferramenta de despejo de memória)

2

Eu usei a ferramenta fmem para criar um arquivo dd de despejo de memória. Isso funciona bem.

Mas como posso acessar essa imagem? Eu tentei com mount , mas ele diz que eu tenho que especificar um sistema de arquivos. Mas não das possibilidades dadas funciona (ext4, vfat etc).

    
por Dee 08.06.2014 / 20:29

2 respostas

2

fmem é uma ferramenta de instantâneo de memória . Cria uma imagem do conteúdo da RAM.

Embora isso possa ser útil para análise forense ou depuração de baixo nível, ela não é uma imagem do sistema de arquivos e não pode ser montada por nenhum meio.

    
por 08.06.2014 / 22:35
2

Ao tentar isso eu mesmo este arquivo não é nada diferente de um despejo de dados brutos / instantâneo de memória. Assim, você pode examiná-lo usando qualquer editor hexadecimal ou uma ferramenta como hexdump ou uma ferramenta de análise forense apropriada.

Download e compilação

Eu encontrei a versão mais recente de fmem aqui:

Depois de descompactar, você pode compilar da seguinte forma:

$ 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[1]: 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[1]: Leaving directory '/usr/src/kernels/3.14.4-100.fc19.x86_64'

Para carregar o módulo do kernel fmem , você pode executar o script run.sh incluído com o arquivo:

$ 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 !!!

Você pode coletar ~ 10 MB de dados no arquivo tst.dd :

$ 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

Examinando o arquivo resultante

Se lançarmos a gama típica de ferramentas neste arquivo, você verá que não contém nada além de dados binários brutos.

arquivo

$ file tst.dd 
tst.dd: data

fdisk

$ 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

$ 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

$ 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.

monte

$ 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.

dmesg

[332140.394396] fmem init_module 449: init
[332140.394401] fmem find_symbols 439: set guess_page_is_ram: ffffffff81090ca0
[333010.390836] loop: module loaded

Se você quiser saber mais sobre a categoria de ferramentas que podem despejar memória de forma semelhante a fmem , dê uma olhada na lista de recursos na seção de referências.

Então, o que posso fazer com os arquivos de despejo do fmem?

Eu encontrei este artigo que discute a criação AND análise desses arquivos. É no seguinte artigo intitulado: Tracing Clues: Análise de Memória - Admin Network & Revista de Segurança . O artigo menciona duas ferramentas, Draugr & Volatilitux .

trechos

Draugr

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/mem pseudodevice. 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.

Volatilitux

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.

OBSERVAÇÃO: A ferramenta do Windows Volatility também pode ser usada para analisar a saída de fmem arquivos!

Referências

por 08.06.2014 / 23:04