Difference between revisions of "RAM analysis"

From YobiWiki
Jump to navigation Jump to search
Line 24: Line 24:
 
LOAD 0x0000000000000720 0x0000000000000000 0x0000000000000000 0x0000000040000000 0x0000000040000000 R 0
 
LOAD 0x0000000000000720 0x0000000000000000 0x0000000000000000 0x0000000040000000 0x0000000040000000 R 0
 
So memory dump is in test.elf, starting at offset 0x720 and counting 0x40000000 bytes (1024Mb)
 
So memory dump is in test.elf, starting at offset 0x720 and counting 0x40000000 bytes (1024Mb)
  +
<br>This deserves some automation but doing it by hand:
 
  +
Alternatively, using objdump:
  +
$ objdump -h test.elf|egrep -w "(Idx|load1)"
  +
Idx Name Size VMA LMA File off Algn
  +
1 load1 40000000 0000000000000000 0000000000000000 00000720 2**0
  +
  +
<br>Let's extract the RAM. Computations deserve some automation but doing it by hand (32*57 = 0x720, 32*33554432 = 0x40000000):
 
$ dd if=test.elf of=test.raw bs=32 skip=57 count=33554432
 
$ dd if=test.elf of=test.raw bs=32 skip=57 count=33554432
 
<br>Now using volatility on the obtained file:
 
<br>Now using volatility on the obtained file:

Revision as of 19:12, 7 February 2012

Misc notes on physical RAM analysis

Links

  • Volatility, for memory analysis of mainly Windows platforms
  • Volatilinux, should I explain?
  • Passware, a commercial tool mostly aiming at recovering passwords, including from memory dumps

RAM dump with VirtualBox

VMWare snapshots contain a .vmem which is basically a RAM dump, but for VirtualBox, it's not that easy...
Snapshot .sav files contain all machine state including memory but in a hardly exploitable format (even if VB is open-source...) and the few people having looked in that direction didn't succeed.
But there is another way to get a RAM dump with VirtualBox (I'm not talking about tools running in the guest as I don't want to interfere at all with the target):
See Ch8 of the manual about debugvm capabilities:
With dumpguestcore --filename <name>, you can create a system dump of the running VM, which will be written into the given file. This file will have the standard ELF core format (with custom sections);
The dump format itself is described here
So let's try:

  • VM has to run in order to be able to make the RAM dump, then:
$ vboxmanage debugvm "Win7" dumpguestcore --filename test.elf
  • We're interested into the first LOAD section, that's where main memory reference is:
$ readelf --program-headers test.elf|grep -m1 -A1 LOAD
  LOAD           0x0000000000000720 0x0000000000000000 0x0000000000000000
                 0x0000000040000000 0x0000000040000000  R      0

If I unwrap the info and label it, we have:

 Type           Offset             VirtAddr           PhysAddr           FileSiz            MemSiz              Flags  Align
 LOAD           0x0000000000000720 0x0000000000000000 0x0000000000000000 0x0000000040000000 0x0000000040000000  R      0

So memory dump is in test.elf, starting at offset 0x720 and counting 0x40000000 bytes (1024Mb)

Alternatively, using objdump:

$ objdump -h test.elf|egrep -w "(Idx|load1)"
Idx Name          Size      VMA               LMA               File off  Algn
  1 load1         40000000  0000000000000000  0000000000000000  00000720  2**0


Let's extract the RAM. Computations deserve some automation but doing it by hand (32*57 = 0x720, 32*33554432 = 0x40000000):

$ dd if=test.elf of=test.raw bs=32 skip=57 count=33554432


Now using volatility on the obtained file:

$ ./vol.py -f test.raw --profile=Win7SP1x86 pslist
Volatile Systems Volatility Framework 2.0
 Offset(V)  Name                 PID    PPID   Thds   Hnds   Time 
---------- -------------------- ------ ------ ------ ------ ------------------- 
0x83d33d40 System                    4      0     69    506 2012-02-07 16:06:19       
0x84c5c758 smss.exe                228      4      2     29 2012-02-07 16:06:19       
0x85475030 csrss.exe               304    296      9    398 2012-02-07 16:06:30       
0x83d9b108 wininit.exe             340    296      3     76 2012-02-07 16:06:41       
0x83d70528 csrss.exe               352    332      7    103 2012-02-07 16:06:41       
0x84d9c568 winlogon.exe            392    332      5    111 2012-02-07 16:06:42       

etc