search

pi-2r / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

volatility-2.3.1 raw2dmp does not record registers from hibernation files in the crashdump output #468

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
When I use the two command :
1 python vol.py imagecopy -f d:\hibernateWin764.sys --profile=Win7SP1x64 -O 
c:\win7.raw;
2 python vol.py raw2dmp -f c:\win7.raw --profilw=Win7SP1x64 -O c:\win7.dmp
 and use windbgx64 to open win7.dmp, it can not get the correct infomation!
My python is python 2.7. Could anyone help me ?Thank you!

Original issue reported on code.google.com by sssyyy...@gmail.com on 30 Dec 2013 at 12:53

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Can you get output from pslist or modules from either c:\win7.raw or 
c:\win7.dmp?  what commands did you do with windbg and how did it fail?

Original comment by jamie.l...@gmail.com on 30 Dec 2013 at 4:27

GoogleCodeExporter commented 9 years ago 
yes, I can get the pslist or modules result from c:\win7.raw or 
c:\win7.dmp.Here is the result:
Offset(V)          Name                    PID   PPID   Thds     Hnds   Sess  
Wow64 Start                          Exit                          
------------------ -------------------- ------ ------ ------ -------- ------ 
------ ------------------------------ ------------------------------
0xfffffa80006b1040 System                    4      0     87      387 ------    
  0 2013-12-26 11:11:14 UTC+0000                                 
0xfffffa8000bdd950 smss.exe                244      4      2       29 ------    
  0 2013-12-26 11:11:14 UTC+0000                                 
0xfffffa8000e42950 csrss.exe               344    336     10      439      0    
  0 2013-12-26 11:11:21 UTC+0000                                 
0xfffffa80019f9940 csrss.exe               384    376     10      301      1    
  0 2013-12-26 11:11:22 UTC+0000                                 
0xfffffa80019fd660 wininit.exe             392    336      3       76      0    
  0 2013-12-26 11:11:22 UTC+0000                                 
0xfffffa8001a15b30 winlogon.exe            432    376      4      117      1    
  0 2013-12-26 11:11:22 UTC+0000                                 
0xfffffa8001a5b700 services.exe            492    392      9      199      0    
  0 2013-12-26 11:11:24 UTC+0000                                 
0xfffffa8001a62b30 lsass.exe               500    392      6      545      0    
  0 2013-12-26 11:11:24 UTC+0000                                 
0xfffffa8001a63910 lsm.exe                 508    392     10      157      0    
  0 2013-12-26 11:11:24 UTC+0000                                 
0xfffffa8001ac0b30 svchost.exe             600    492     13      358      0    
  0 2013-12-26 11:11:28 UTC+0000                                 
0xfffffa8001af6b30 svchost.exe             676    492     24      307      0    
  0 2013-12-26 11:11:29 UTC+0000                                 
0xfffffa8001b27970 svchost.exe             756    492     19      456      0    
  0 2013-12-26 11:11:29 UTC+0000                                 
0xfffffa8001b4ab30 svchost.exe             804    492     13      258      0    
  0 2013-12-26 11:11:30 UTC+0000                                 
0xfffffa8001b4f060 svchost.exe             828    492     51      952      0    
  0 2013-12-26 11:11:30 UTC+0000                                 
0xfffffa8001b83060 audiodg.exe             916    756      4      130      0    
  0 2013-12-26 11:11:32 UTC+0000                                 
0xfffffa8001ba4b30 svchost.exe             964    492     16      525      0    
  0 2013-12-26 11:11:33 UTC+0000                                 
0xfffffa8001bc3060 svchost.exe             296    492     14      362      0    
  0 2013-12-26 11:11:33 UTC+0000                                 
0xfffffa8001c27060 spoolsv.exe             908    492     12      312      0    
  0 2013-12-26 11:11:35 UTC+0000                                 
0xfffffa8001c46b30 svchost.exe            1036    492     20      311      0    
  0 2013-12-26 11:11:37 UTC+0000                                 
0xfffffa8001cc6b30 vmtoolsd.exe           1172    492      9      275      0    
  0 2013-12-26 11:11:38 UTC+0000                                 
0xfffffa8001d59990 taskhost.exe           1320    492      8      188      1    
  0 2013-12-26 11:11:42 UTC+0000                                 
0xfffffa8001d90b30 dwm.exe                1404    804      3       70      1    
  0 2013-12-26 11:11:43 UTC+0000                                 
0xfffffa8001d9fb30 explorer.exe           1416   1364     43     1109      1    
  0 2013-12-26 11:11:43 UTC+0000                                 
0xfffffa80016f6b30 TPAutoConnSvc.         1628    492     10      141      0    
  0 2013-12-26 11:11:48 UTC+0000                                 
0xfffffa80017133d0 TPAutoConnect.         1916   1628      5      121      1    
  0 2013-12-26 11:11:51 UTC+0000                                 
0xfffffa8001774060 conhost.exe            1952    384      1       34      1    
  0 2013-12-26 11:11:52 UTC+0000                                 
0xfffffa8001e60260 msdtc.exe              1164    492     12      145      0    
  0 2013-12-26 11:11:54 UTC+0000                                 
0xfffffa8001e77b30 vmtoolsd.exe           1276   1416      8     1106      1    
  0 2013-12-26 11:11:56 UTC+0000                                 
0xfffffa8001eae060 sidebar.exe            1464   1416     11      307      1    
  0 2013-12-26 11:11:56 UTC+0000                                 
0xfffffa8001191b30 SearchIndexer.         2140    492     12      548      0    
  0 2013-12-26 11:12:05 UTC+0000                                 
0xfffffa800174c120 svchost.exe            2664    492      5       67      0    
  0 2013-12-26 11:13:48 UTC+0000                                 
0xfffffa8001dfaa30 svchost.exe            2732    492      9      303      0    
  0 2013-12-26 11:13:49 UTC+0000                                 
0xfffffa8000a3f9e0 TrueCrypt.exe           732   1416      2       73      1    
  1 2013-12-26 11:15:08 UTC+0000                                 
0xfffffa80011da1f0 taskmgr.exe            2212    448      6      111      1    
  0 2013-12-26 11:15:19 UTC+0000                                 
0xfffffa8001b647d0 WmiPrvSE.exe           2852    600      6      113      0    
  0 2013-12-26 11:15:47 UTC+0000                                 
0xfffffa800075bb30 notepad.exe            2208   1416      1       57      1    
  0 2013-12-26 11:15:54 UTC+0000                                 
0xfffffa8001a408e0 cmd.exe                 616   1416      1       19      1    
  0 2013-12-26 11:16:00 UTC+0000                                 
0xfffffa8000761060 conhost.exe             956    384      2       50      1    
  0 2013-12-26 11:16:00 UTC+0000                                 
0xfffffa800119c710 cmd.exe                2416   1416      1       19      1    
  0 2013-12-26 11:16:18 UTC+0000                                 
0xfffffa800075d450 conhost.exe            2424    384      2       50      1    
  0 2013-12-26 11:16:18 UTC+0000                                 
0xfffffa8001687a70 msiexec.exe            2936    492      6      343      0    
  0 2013-12-26 11:17:48 UTC+0000                                 
0xfffffa8001e1fb30 windbg.exe             2304   1416      7      299      1    
  1 2013-12-26 11:20:23 UTC+0000                                 
0xfffffa8002067060 dllhost.exe             876    492     11      138      0    
  0 2013-12-26 11:20:47 UTC+0000                                 
0xfffffa8001a73a70 LogonUI.exe            2704    432      7      164      1    
  0 2013-12-26 11:25:36 UTC+0000     
I open the windbg(6.2.9200.16384 AMD64),and open the win7.dmp,it get the 
following result. Is my windbg version old? Or the file format generated by 
raw2dmp command is wrong? Thank you !

Original comment by sssyyy...@gmail.com on 31 Dec 2013 at 7:16

Attachments:

GoogleCodeExporter commented 9 years ago 
I can not get the result of command "!process 0 0 ",or registers information or 
calls information.

Original comment by sssyyy...@gmail.com on 31 Dec 2013 at 7:28

GoogleCodeExporter commented 9 years ago 
Could anyone help me ? Thank you !

Original comment by sssyyy...@gmail.com on 2 Jan 2014 at 1:57

GoogleCodeExporter commented 9 years ago 
Based on the prompt in your screenshot "kd: x86>" your debugger is in 32-bit 
mode. Try ".effmach amd64" to switch into 64-bit mode.

Original comment by michael.hale@gmail.com on 2 Jan 2014 at 3:39

GoogleCodeExporter commented 9 years ago 
Thank you very much !But sometimes the dump file got from hiberfile do not need 
the command ".effmach amd64" .The registers got their values. Sometimes I need 
the command ".effmach amd64".The register values are zero. Could you tell me 
why?

Original comment by sssyyy...@gmail.com on 4 Jan 2014 at 3:27

Attachments:

GoogleCodeExporter commented 9 years ago 
Why can not I get the values of registers? Thank you !

Original comment by sssyyy...@gmail.com on 6 Jan 2014 at 8:16

GoogleCodeExporter commented 9 years ago 
A hibernation file isn't the same as a full copy of RAM. It doesn't include 
pages swapped to disk, for example. Thus data that is normally available when 
you're debugging the kernel live is not guaranteed to exist in the hibernation 
file. The context structure for some threads will be available and others 
won't.

Original comment by michael.hale@gmail.com on 6 Jan 2014 at 7:39

GoogleCodeExporter commented 9 years ago 
Please note, you also converted the file to a raw format, which definitely does 
not have the capability to contain additional metadata (such as registers) 
before converting it to the windows crash dump.  There is no way the register 
information could end up in that final crash dump.

I'm not sure how to solve the problem you're currently facing, however.  
Ideally windbg might be able to operate on hibernation files directly.  Failing 
that, volatility would need some interface for knowing how to access such 
register in the hibernation file (if they exist in the first place) and then 
figure out how to store them in the crash dump.  I don't believe volatility 
currently has that capability, but this is not an error on the part of 
volatility.

Original comment by mike.auty@gmail.com on 6 Jan 2014 at 7:52