errors in get_available_addresses in volatility-3.0-tp2

[GoogleCodeExporter]

What steps will reproduce the problem?
1. 
C:\Users\xxxxx\Downloads\volatility-tp2\volatility-3.0-tp2>c:\Python27\python.
exe vol.py --profile=Win2008R2SP1x64 -f c:\test\physmem-xxxxxx.dump --debu
g cmdscan
ERROR:root:Error: unpack requires a string argument of length 4096
> c:\downloads\volatility-tp2\volatility-3.0-tp2\volatility\plugin
s\addrspaces\amd64.py(171)get_available_addresses()
-> pte_table = struct.unpack("<" + "Q" * 0x200, data)
(Pdb) Traceback (most recent call last):
  File "vol.py", line 145, in <module>
    main()
  File "vol.py", line 131, in main
    pdb.post_mortem()
  File "c:\Python27\lib\pdb.py", line 1267, in post_mortem
    p.interaction(None, t)
  File "c:\Python27\lib\pdb.py", line 210, in interaction
    self.cmdloop()
  File "c:\Python27\lib\cmd.py", line 130, in cmdloop
    line = raw_input(self.prompt)
KeyboardInterrupt
2.
3.

What is the expected output? What do you see instead?
Other than crashing

What version of the product are you using? On what operating system?
Volatility-3.0-tp2 on Win7x64 processing a memory dump from a virtualized 
instance of Win2008R2SP1x64

Please provide any additional information below.

One simple fix to address both:
volatility-3.0-tp2\volatility\plugins\addrspaces\amd64.py (line 171)
volatility-3.0-tp2\volatility\plugins\addrspaces\intel.py (line 392)

Change from:
data = self.base.zread(pte_table_addr, 8 * 0x200)
pte_table = struct.unpack("<" + "Q" * 0x200, data)

Change to:
data = self.base.zread(pte_table_addr, 8 * 0x200)
pte_table = struct.unpack("<" + "Q" * (len(data)/8), data)

Original issue reported on code.google.com by apolkosnik on 16 May 2013 at 9:47

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 17 May 2013 at 2:33

[GoogleCodeExporter]

Thanks for this bug report.

What is happening here is that we are trying to read the pte table in one read 
instead of 8 bytes at the time - this is much faster on platforms where IO 
performance is very expensive like windows. The pte table should contain up to 
a maximum of 200 entries.

It seems like in your image the read comes up short and returns a short buffer. 
This should not happen since we are calling zread() which should pad with zeros 
but it seems the physical address space does not implement zread() correctly.

I assume you are using the crash dump address space (from the .dump extension) 
and that is an instance of PagedReader which overrides the zread() method 
making it the same as the read() method.

http://code.google.com/p/volatility/source/browse/branches/scudette/volatility/a
ddrspace.py#357

So I think the solution is actually to remove the zread method from 
PagedReader() so it will use the base class's version which always pads with 
zero.

Can you please test this and see if it fixes the issue?

I actually think the whole distinction between read() and zread() is kind of a 
legacy thing and probably needs to be corrected. I cant think of a single case 
where calling read() instead of zread() was the correct thing to do (i.e. where 
we wanted to read a certain length and actually wanted the read to return less 
data if there was not enough there). It seems like zero padding the data is 
always what we want anyway.  Maybe a pad=True flag can cater for those rare 
cases where we actually need a short read.

Original comment by scude...@gmail.com on 17 May 2013 at 9:25

[GoogleCodeExporter]

I guess you actually meant 
https://code.google.com/p/volatility/source/browse/branches/scudette/volatility/
plugins/addrspaces/standard.py#55

This is where zread() calls read(),  and there is no pad flag in sight. 

I'll try changing that, as currently all the memory dumps from 2008R2sp1 are 
almost unparsable with anything I've tried. I'm not sure if it's due to my 
change, but psxview shows only sane results for psscan out of the 4 methods. 
I'll try to fix zread, and re-run that dump.

Original comment by apolkosnik on 19 May 2013 at 4:23

[GoogleCodeExporter]

Original comment by jamie.l...@gmail.com on 3 Jan 2014 at 9:31

• Changed state: WontFix