Hello all,
finally I found time to test the new version 2.0. It looks great even if I
became familiar with the old structure.
I tried to use it on an 64Bit-Win7 with Python64. This seems not to work but
after installing the x(86)-architecture it does.
However when starting v2.0 with I get the following error message:
*** Failed to import volatility.plugins.registry.lsadump (ImportError: DLL
load failed: %1 ist keine zulõssige Win32-Anwendung [transl.: %1 is no valid
win32 application]
What went wrong?
Regards
Michael
Mike - thanks so much for replying
***************************************************************************************************
This is the terminal output for the lipo commands:
qbl-mbp:~ qubyte$ lipo -info /usr/local/lib/libewf.dylib
Non-fat file: /usr/local/lib/libewf.dylib is architecture: x86_64
qbl-mbp:~ qubyte$ lipo -info `which python`
Architectures in the fat file:
/Library/Frameworks/Python.framework/Versions/2.6/bin/python are: ppc i386
***************************************************************************************************
Output from from the versioner command:
qbl-mbp:volatility2.0 qubyte$ VERSIONER_PYTHON_PREFER_32_BIT=yes python
vol.py -h
Volatile Systems Volatility Framework 2.0
*** Failed to import volatility.plugins.addrspaces.ewf (OSError:
dlopen(/usr/local/lib/libewf.dylib, 6): no suitable image found. Did find:
/usr/local/lib/libewf.dylib: mach-o, but wrong architecture)
I have also cc'd Joachim Metz on this in case he has some insight. Joachim
- in case you have time to read this i am encountering this error with
libewf and volatility 2.0 when running volatitlity (mac ox 10.6.8 with
libewf 20100226; this version of libewf is used to due to TSK 3.2.2):
*** Failed to import volatility.plugins.addrspaces.ewf (OSError:
dlopen(/usr/local/lib/libewf.dylib, 6): no suitable image found. Did find:
/usr/local/lib/libewf.dylib: mach-o, but wrong architecture)
Thanks to the vol group and joachim for taking the time to read this! I
look forward to the next set of ideas! :)
Cheers
Shafik
On Tue, Aug 9, 2011 at 11:00 AM, <vol-users-request(a)volatilityfoundation.org>wrote:
> lipo -info `which python`
Hello List!
I have been fighting with this issue since volatility 1.4 RC1. I am not
able to figure out why it cannot locate the correct libewf library. I have
uninstalled and reinstalled from source the libewf 20100226 stable version.
Can anyone assist me with this
Terminal output:
qbl-mbp:volatility2.0 qubyte$ python vol.py -h
Volatile Systems Volatility Framework 2.0
*** Failed to import volatility.plugins.addrspaces.ewf (OSError:
dlopen(/usr/local/lib/libewf.dylib, 6): no suitable image found. Did find:
/usr/local/lib/libewf.dylib: mach-o, but wrong architecture)
Usage: Volatility - A memory forensics analysis platform.
OS: Mac OS X 10.6.8
Python:
qbl-mbp:~ qubyte$ python
Python 2.6.6 (r266:84374, Aug 31 2010, 11:00:51)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Any help would be greatly appreciated...and please dont assume that I know
my well around terminal shell..I am still a newbie and learning lots!
Thanks!
Shafik
__________________________________
Shafik Punja
BSc, A+, CISSP, Network+, ACE, CCE
Senior Technical Officer
*QuByte Logic Ltd*
612-500 Country Hills Blvd NE, Suite #404
Calgary, AB CANADA T3K 5K3
ph: 403.909.6120
em: shafghp(a)gmail.com or shafik(a)qubytelogic.com
wp: http://www.qubytelogic.com
All
I've had great success using recipes out of the Malware Analyst Cookbook. I particularly like the recipe involving mutantscandb and compare the mutexes in a binary under investigation with those in my sqlite3 database.
Can anyone tell me how to trace the observed suspicious mutexes in a mutantscandb scan with the process/binary that owns that mutex?
Jim
~~~~~~~~~~~~~~~~~~~~~~
ACK and you shall receive
Hi all,
I'm using "Volatility-1.3_Beta" in a college project. I have a question
regarding the 'memdmp' module.
I use a 1GB memory dump from Windows XP SP2. Dumped using the tool win32dd.
After extracting the list of running processes, I dump the addressable
memory for each process using the command:
python volatility memdmp -f *my_1GB_memory_dump *-p 1234
The output for each process is a very large PID.dmp. On average each PID.dmp
is about 200MB.
So, after extracting the memory for the first 5 processes (out of a total of
64 processes), I have already exceeded the size of the RAM dump (1 GB).
I know that some processes will use DLL's and that this may become part of
the addressable memory for that process.
But can anyone explain to me why the dump files are so large? Is it possible
to just extract memory for each process so that the total is approx. equal
to the RAM dump?
Looking at the code for mem_dump, I can see:
File: vmodules.py
mem_dump(...)
...
entries = process_address_space.get_available_pages()
for entry in entries:
data = process_address_space.read(entry[0],entry[1])
ohandle.write("%s"%data)
File: forensics/x86.py
def get_available_pages(self):
page_list = []
pgd_curr = self.pgd_vaddr
for i in range(0,ptrs_per_pgd):
start = (i * ptrs_per_pgd * ptrs_per_pte * 4)
entry = self.read_long_phys(pgd_curr)
pgd_curr = pgd_curr + 4
if self.entry_present(entry) and self.page_size_flag(entry):
page_list.append([start, 0x400000])
elif self.entry_present(entry):
pte_curr = entry & ~((1 << page_shift)-1)
for j in range(0,ptrs_per_pte):
pte_entry = self.read_long_phys(pte_curr)
pte_curr = pte_curr + 4
if self.entry_present(pte_entry):
page_list.append([start + j * 0x1000, 0x1000])
return page_list
I'm not a Python programmer, but it appears that the method:
get_available_pages() is searching across the 4KB page files, looking for
physical addresses belonging to the specific process. Then the data at these
physical addresses is extracted. The lower level details of these commands
are currently beyond my reach.
Any help is greatly appreciated,
Regards,
Derek.
vol-users: I wanted to give you the inside track on registering for OMFW.
Tomorrow, I will be posting the announcement to the Volatility tumblr for
wider distribution. Pre-registration is required and space is limited, so
register early.
https://www.volatilityfoundation.org/default/omfw
Volatile memory forensics (ie., RAM forensics) has proven one of the most
exciting and important topics to the future of digital investigations. It
has dramatically transformed the way we perform digital investigations and
helped provide a path for addressing many of the challenges we currently
face.
OMFW is the only digital forensics workshop focused on providing a venue
for the most advanced digital investigators. It is intended for those
people who realize that the only real defense against a creative technical
human adversary is a creative technical human analyst. No shady vendors
trying to describe how they re-implemented open source tools or boisterous
trainers attempting to discuss topics they only superficially understand.
This is your opportunity to learn directly from an international cadre of
pioneering researchers and practitioners who have been shaping the field
of memory analysis since its inception. Through a series of invited talks
and panel discussions you will have the opportunity to engage this
exciting community. At the end of the day, the attendees will have the
opportunity to work through a challenging memory analysis skills exercise
with the assistance of your expert speakers. Join with industry leaders to
discuss the latest advancements in memory forensics and the importance of
open source initiatives. This is your opportunity to help shape the future
of memory forensics!
AW
