search

arjunsingharyan / volatility

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

Hpak Overflow Using Strings Plugin #496

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. use an uncompress hpak memory dump 
2. create a string file from mem using strings -q -o mem.img>raw_strings.txt
3. run volatility using -f mem.img strings -s raw_strings.txt >vol_strings.txt

What is the expected output? What do you see instead?

The expected behavior is a volatility map of the strings to their respective 
places in memory (correlation).  

Volatility Foundation Volatility Framework 2.3.1
Traceback (most recent call last):
  File "<string>", line 184, in <module>
  File "<string>", line 175, in main
  File "C:\volatility\build\pyi.win32\pyinstaller\out00-PYZ.pyz\volatility.comma
nds", line 122, in execute
  File "C:\volatility\volatility\plugins\strings.py", line 85, in render_text
  File "C:\volatility\volatility\plugins\strings.py", line 152, in get_reverse_m
ap
  File "C:\volatility\volatility\plugins\addrspaces\intel.py", line 284, in get_
available_pages
  File "C:\volatility\volatility\plugins\addrspaces\intel.py", line 252, in _rea
d_long_long_phys
  File "C:\volatility\volatility\plugins\addrspaces\hpak.py", line 83, in read
  File "C:\volatility\volatility\plugins\addrspaces\standard.py", line 100, in r
ead
OverflowError: long too big to convert

What version of the product are you using? On what operating system?
Volatility Foundation Volatility Framework 2.3.1 (windows standalone exe)

Please provide any additional information below.

Original issue reported on code.google.com by robin.ja...@wt4n6.com on 18 Apr 2014 at 4:14

GoogleCodeExporter commented 8 years ago 
Hi Robin, 

I assume this is an XP x86 memory dump since you didn't use --profile in your 
strings command? Do plugins like pslist and psscan work on the uncompressed 
memory dump? 

Also, please run hpakinfo on the memory dump so we can see the metadata 
associated with it (the memory runs, etc). 

Thanks

Original comment by michael.hale@gmail.com on 19 Apr 2014 at 3:20

GoogleCodeExporter commented 8 years ago 
Sorry, just getting this.  I'll get the information for you Monday AM.
 Thanks, God bless, and have a blessed Easter.

Rob

Robin Jackson
Security+, CISSP, ITIL
(406) 465-0354

Original comment by robin.ja...@wt4n6.com on 20 Apr 2014 at 1:04

GoogleCodeExporter commented 8 years ago 
eport\FRTK_tempdir>volpy -f MECTXPRD06.hpak imageinfo
Volatility Foundation Volatility Framework 2.3.1
Determining profile based on KDBG search...

          Suggested Profile(s) : Win2003SP0x86, Win2003SP1x86, Win2003SP2x86
                     AS Layer1 : IA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : HPAKAddressSpace
(C:\Users\jacksrob\Documents\C
ases\ForwardFollow\MECTXPRD06_2014.03.24_21-33-58_report\FRTK_tempdir\MECTXPRD06
.hpak)
                     AS Layer3 : FileAddressSpace
(C:\Users\jacksrob\Documents\C
ases\ForwardFollow\MECTXPRD06_2014.03.24_21-33-58_report\FRTK_tempdir\MECTXPRD06
.hpak)
                      PAE type : PAE
                           DTB : 0x50a000L
                          KDBG : 0x808903d8L
          Number of Processors : 1
     Image Type (Service Pack) : 2
                KPCR for CPU 0 : 0xffdff000L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2014-03-25 02:34:00 UTC+0000
     Image local date and time : 2014-03-24 21:34:00 -0500

eport\FRTK_tempdir>volpy -f MECTXPRD06.hpak hpakinfo
Volatility Foundation Volatility Framework 2.3.1
Header:     HPAKSECTHPAK_SECTION_PHYSDUMP
Length:     0x101800000
Offset:     0x4f8
NextOffset: 0x1018004f8
Name:       memdump.bin
Compressed: 0

Robin Jackson
Security+, CISSP, ITIL
(406) 465-0354

Original comment by robin.ja...@wt4n6.com on 21 Apr 2014 at 3:21

GoogleCodeExporter commented 8 years ago 
Hi Robin, 

Just to clarify, previously you mentioned the commands were:

$ strings -q -o mem.img > raw_strings.txt
$ python vol.py -f mem.img strings -s raw_strings.txt > vol_strings.txt

From the imageinfo output, it looks like the profile would be Win2003SP2x86. 
Did you supply that as --profile=Win2003SP2x86 in your Volatility command? 

Also, the first command (strings -q -o) should be run on a raw memory dump, not 
directly against the MECTXPRD06.hpak file. The extra headers that the .hpak 
file contains will throw off the offsets during translation. 

To produce a raw memory dump from your .hpak file, use the hpakextract command. 
So try it again but this time:

1) Extract a raw memory sample 
2) Run strings -q -o on the raw memory sample
3) When you use Volatility's strings plugin, make sure to specify 
--profile=Win2003SP2x86

Let me know if that works better.

Original comment by michael.hale@gmail.com on 23 Apr 2014 at 8:28

GoogleCodeExporter commented 8 years ago 
Thanks, yes I did specify the profile. it was uncompressed so i didn't take
into consideration the hpak header throwing off the offsets.  unfortunately
when i tried to use hpakextract it didn't work ( i can easily use fdpro
though).

I appreciate your time, I know you're not around to catch my stupid
mistakes ;)

I'll test it now.

Robin Jackson
Security+, CISSP, ITIL
(406) 465-0354

Original comment by robin.ja...@wt4n6.com on 24 Apr 2014 at 4:26

GoogleCodeExporter commented 8 years ago 
Hi Robin, 

How did the test go? 

Also, in what way did hpakextract fail? Did you receive any error messages or 
did something just not work the way you expected? Please let me know, so we can 
fix whatever problem exists with that plugin. 

Thanks!

Original comment by michael.hale@gmail.com on 24 Apr 2014 at 1:18

GoogleCodeExporter commented 8 years ago 
Sorry

I was working the case, cuz everything worked fine...head down ;)

As far as hpakextract, I'll double back and see what I did wrong.  I know I
got no error message it ended normally.

Thanks again

Robin Jackson
Security+, CISSP, ITIL
(406) 465-0354

Original comment by robin.ja...@wt4n6.com on 24 Apr 2014 at 1:29

GoogleCodeExporter commented 8 years ago 
Hi Robin, 

Just checking if you were able to run hpakextract again and see if there was 
really an issue. Can you let me know? 

Thanks!

Original comment by michael.hale@gmail.com on 28 Apr 2014 at 9:40

GoogleCodeExporter commented 8 years ago 
omg...sorry, down the rabbit hole again with a few gigs of PCAPs.  Let me
see if I can go back and pull the command out of my notes.

Thanks for your patience.

Robin Jackson
Security+, CISSP, ITIL
(406) 465-0354

Original comment by robin.ja...@wt4n6.com on 30 Apr 2014 at 2:35

GoogleCodeExporter commented 8 years ago 
Hi Robin, 

I'm going to close this issue and assume you'll let me know if this becomes a 
problem again in the future.

Original comment by michael.hale@gmail.com on 25 May 2014 at 5:16

GoogleCodeExporter commented 8 years ago 
I am having problems extracting the raw memory image from the .hpak file.  What 
is the proper syntax to use?  

I have been trying:  vol -f /memory.hpak hpakextract --output-file=/memory.bin

The output is a zero length memory.bin file

Original comment by tim.duck...@gmail.com on 2 Jul 2014 at 6:45

GoogleCodeExporter commented 8 years ago 
Don't know if it matters, but I am using Framework 2.3.1 that comes with Kali 
Linux.

Original comment by tim.duck...@gmail.com on 2 Jul 2014 at 6:48