Hi Brian,
There is no such thing as a stupid question; don't worry. To my knowledge nobody
has published much information about doing memory analysis on 64-bit systems, so
the following is mostly conjecture.
When working in 64-bit mode Intel processors use a different method of
translating the virtual addresses used by programs and the operating system into
the physical addresses in RAM where data really lives. As such there are going to
be several differences in the operating system for a) keeping track of where data
lives and b) virtual to physical address translation. You can read much more
about these difference in the Intel Architecture Software Developer's Manuals,
http://www.intel.com/products/processor/manuals/. BTW, Intel will mail you hard
copies of those books for free. Really! As many as you'd like of whichever ones
you'd like. Enjoy!
As for the differences in anything else, like I said, I don't think anybody has
published on those yet. You could be the first!
cheers,
--
Jesse
jessek(a)speakeasy.net
Hi all,
Forgive me if this is a stupid question, i'm a bit new to physical memory
analysis.
Is the structure of physical memory on a 64bit operating system different
than that of a 32bit operating system, and if so does volatility have the
capability to parse 64bit images?
v/r
--
-Brian
> Interesting, I haven't tried Volatility with Python 2.6 yet. Looking
> at the module in question, I don't actually see anywhere that sha is
> used. I'll make a note to look whether we can just remove that.
One of my students noticed this as well. I had asked her to send me
the error message, but I guess she forgot... After she commented out
that line it worked fine.
All the best,
-Jamie
I am trying to develop a step-by-step guide for installation and use of
Volatility and Python in *Windows* as many of our users have a different
knowledge level.
I was wondering if anyone has any "best practice" guidelines for:
1. If you install Python, would it be preferable to change the Path in
Environment Variables to allow Python to be recognized by any directory?
2. Where should I install Volatility to (Python directory, it's own
directory)? Should this directory be "pathed" as well? I am trying to
reduce the complexity of the command line to run the program.
3. Is if preferable to have the memory image in any specific directory?
4. I am getting a warning, although can still get an output. The error is:
"c:\python26\forensics\win32\crashdump.py:31:31: DeprecationWarning: the sha
module is deprecated; use the hashlib module instead
import sha "
Any guidance would be appreciated.
Darren Sabourin
Forensic Analyst
Royal Canadian Mounted Police
Regina, Saskatchewan CANADA
ph. (306) 780-7334
Hi,
when running
python volatility files -f ../mem.dd
I get a correct looking result for the first 8 processes, then I get the
following error:
<-------------------------------------snip
-------------------------------------------->
Pid: 644
Traceback (most recent call last):
File "volatility", line 219, in <module>
main()
File "volatility", line 212, in main
modules[argv[1]].execute(argv[1], argv[2:])
File "/home/chris/tmp/Mem-Image/Volatility-1.3_Beta/vmodules.py", line
62, in execute
self.cmd_execute(module, args)
File "/home/chris/tmp/Mem-Image/Volatility-1.3_Beta/vmodules.py", line
545, in get_open_files
L1_table = handle_entry_object(addr_space, types, L1_entry)
File
"/home/chris/tmp/Mem-Image/Volatility-1.3_Beta/forensics/win32/handles.py",
line 77, in handle_entry_object
['_HANDLE_TABLE_ENTRY', 'Object'], entry_vaddr) & ~0x00000007
TypeError: unsupported operand type(s) for &: 'NoneType' and 'int'
<-------------------------------------snip
-------------------------------------------->
The operating system in the image is a XPSP3, volatility ident shows:
Image Name: ../mem.dd
Image Type: Service Pack 3
VM Type: pae
DTB: 0xa1c000
Datetime: Wed Nov 12 18:39:28 2008
Any ideas what could be the problem ?
Christian
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
I'm trying out Volatility 1.3 Beta on Linux (RedHat Enterprise 5).
I quickly encountered a problem as follows:
[root@HX80722V1 Volatility-1.3_Beta]# python volatility
Traceback (most recent call last):
File "volatility", line 37, in ?
from vmodules import *
File "/usr/local/src/Volatility-1.3_Beta/vmodules.py", line 1938
finally:
^
SyntaxError: invalid syntax
The md5 checksum is correct for the downloaded file.
Is there a fix for this ?
Thanks !
Cameron
Cameron C. Caffee, CPA, GCFA, GCIH
IT Audit Manager
Voice: (804) 786-4882
FAX: (804) 786-2487
Hi everybody,
Jun asked me about a paper I wrote and which Harlan's tools were
based. Although I can't send out the full paper, I can show you a
slide from my talk at the 2007 DoD Cyber Crime Conference athttp://jessekornblum.com/tmp/determine-os.pdf
. The slide shows how you can use the spaces between known values, in
this case between the Eprocess header and the name of the process, to
identify what OS you're working with.
For the record, Volatility looks at each process' Peb, IIRC, which in
turn contains a string naming the Service Pack number. The framework
records how many processes indicate which string (e.g. 7 say "Service
Pack 2" and 2 say (null)). The string encountered the most times is
displayed.
cheers,
--
Jesse
jessek(a)speakeasy.net
Hi,
Suppose that I have a raw memory image of a particular Windows
machine. Is there any way to determine its version? It can be W2k,
WinXP SP2 or SP3 or Vista.
Perhaps we can look into some places into the image to get those
information out?
Thanks,
J
Hi,
I am interested in working with the experimental version that supports Linux memory images and integrates with PyFlag. I would greatly appreciate a copy of the source code with those features (e.g. the version used in the DRFWS 2008 challenge).
Thanks,
Sam
Hi everybody,
Here's a Volatility plugin to first recover the command line for each process and
then find any suspicious ones. I wrote it to get a feel for the framework's
Object model. Please note that the current version of the framework has a (soon
to be corrected) bug that can result in a crash. Don't panic!
The plugin considers a command line to be suspicious if it contains the word
"TrueCrypt" or if it starts with a lower case drive letter. The latter is
indicative of a manually typed command line. I've found it handy to examine
TrueCrypt command lines because they can contain the filename of a mounted
protected volume.
cheers,
--
Jesse
jessek(a)speakeasy.net
