Difference between revisions of "RAM analysis"
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 18: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