3

I have a memory dump of a VM running Windows server 2012 R2. The dump is of the entire RAM (4 GB).

I want to extract as many features as possible from this dump. Mainly I want to extract all stacks of all threads running on the machine and exist in the memory. Alternatively, I want to extract call sequences of all threads.

Are there any tools / tutorials / books etc. which can help me perform this task?

I am familiar with both Volatility and Rekall, are there any specific plugins that can help me achieve my goals there?

4
  • I might have misunderstood your problem, but why not simply using the pstree command in Volatility and, then, manage something with procmemdump, dlldump or memdump? But, I must have missed something.
    – perror
    Jun 2, 2016 at 9:40
  • I am not sure, but how can I extract the stack or call-sequence of the processes using these commands?
    – Yuval
    Jun 2, 2016 at 11:47
  • Well, you can dump the memory of the process. It contains the stack for sure... But, you see, your question lack of a precise definition of what you want because what kind of stack representation would you have at the end?
    – perror
    Jun 2, 2016 at 13:01
  • 2
    @perror: I assume OP wants to extract the call stacks or backtraces (like Windbg's k or GDB's bt).
    – Igor Skochinsky
    Jun 2, 2016 at 17:29

2 Answers 2

4

I am Not Sure what you are looking for let me try

i have a dump file of a vm too MEMORY.dmp from a vm that ran xp sp3 created using .crash from a kernel debugger attached to it

i loaded it using windbg as below

windbg -z memory.dmp 

now i thought i will count how many threads are running so i did some thing like this

kd> r $t0 = 0; !for_each_thread "r $t0= @$t0+1" ; ? @$t0
Evaluate expression: 306 = 00000132

now let me see the call stacks for all threads so i do

kd> !for_each_thread  ".thread @#Thread ; k2"

it spits out

Implicit thread is now 812915b8
 # ChildEBP RetAddr  
00 fc8d37b4 804dc0f7 nt!KiSwapContext+0x2e
01 fc8d37c0 804e3b7d nt!KiSwapThread+0x46
Implicit thread is now 8128eda8
 # ChildEBP RetAddr  
00 fc8e3d34 804dc0f7 nt!KiSwapContext+0x2e
01 fc8e3d40 804e407e nt!KiSwapThread+0x46
Implicit thread is now 8128eb30
 # ChildEBP RetAddr  
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

ok instead of k2 i do k i get a full stack trace

Implicit thread is now 810efda8
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
00 f8ad3c38 804dc0f7 nt!KiSwapContext+0x2e
01 f8ad3c44 804dc143 nt!KiSwapThread+0x46
02 f8ad3c6c bf802f52 nt!KeWaitForSingleObject+0x1c2
03 f8ad3ca8 bf801b2a win32k!xxxSleepThread+0x192
04 f8ad3cec bf819e6c win32k!xxxRealInternalGetMessage+0x418
05 f8ad3d4c 804de7ec win32k!NtUserGetMessage+0x27
06 f8ad3d4c 7c90e4f4 nt!KiFastCallEntry+0xf8
07 0007fe24 7e4191be ntdll!KiFastSystemCallRet
08 0007fe44 0100a740 USER32!NtUserGetMessage+0xc
09 0007fe80 0100c216 wmiprvse!WindowsDispatch+0x31
0a 0007ff14 0100c314 wmiprvse!Process+0x225
0b 0007ff1c 010247aa wmiprvse!WinMain+0x4e
0c 0007ffc0 7c817067 wmiprvse!WinMainCRTStartup+0x174
0d 0007fff0 00000000 kernel32!BaseProcessStart+0x23
Implicit thread is now 8113b960
  *** Stack trace for last set context - .thread/.cxr resets it

XXXXXXXXXXXXXXXX

hope your query is answered if not please explain what is it you mean by call sequences

addressing the comment by Igor Skochinsky

if the format of the file is raw as in lets say captured with matthieu suiches now defunct win32dd.exe one can use volatility's plugin raw2dmp and use the resulting windbg compatible dmpfile in windbg as above

vol25 -f foo.dmp --profile=Win7SP1x86 imageinfo

Volatility Foundation Volatility Framework 2.5
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win7SP0x86, Win7SP1x86
                     AS Layer1 : IA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : FileAddressSpace (E:\vola\foo.dmp)
                      PAE type : PAE
                           DTB : 0x185000L
                          KDBG : 0x82d32c28L
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0x82d33c00L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2016-06-02 18:08:14 UTC+0000

vol25 -f foo.dmp --profile=Win7SP1x86 raw2dmp --output-image=foowind.dmp

Volatility Foundation Volatility Framework 2.5
Writing data (5.00 MB chunks): |.....

dumpchk.exe foowind.dmp

Loading dump file foowind.dmp

Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [xxx\foowind.dmp]
Kernel Complete Dump File: Full address space is available

Comment: 'File was converted with Volatility'
xxxxxxxxxxxxxxxxxxxxxxx
*** ERROR: Module load completed but symbols could not be loaded for win32dd.exe
Cannot find frame 0x6c, previous scope unchanged
*** ERROR: Module load completed but symbols could not be loaded for win32dd.sys
Probably caused by : win32dd.exe ( win32dd!Unknown )
2
  • I think the OP has a raw (plain binary) memory dump, not a DMP file.
    – Igor Skochinsky
    Jun 2, 2016 at 17:47
  • @IgorSkochinsky i see i didn't realize that well then either volatility or memoryze should be able to read them – i edited my answer to address this issue with volatility raw2dmp
    – blabb
    Jun 3, 2016 at 6:07
0
  • Extract full memory area for each process
  • In each process get TIB for each thread in the process
  • TIB will help you to get to the start/bottom of the stack memory area for each thread
  • all of the above you can do with Volatility of Rekall. Go over respectful documentation for plugins (pstree, threads, procdump)
  • OS internal structs will also be helpful

Now, if you can elaborate a little bit more on what are you trying to find. I'll probably will be give more specific instructions.

Good luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.