July 2009 - Vol-dev - volatilityfoundation.org

by McCash John-GKJN37

Hey Folks, I was just reading Gleeda's blog & CEIC presentation, and was interested to discover that Volatility modules had been written for Linux and Vista. Now I'm wondering why these modules haven't shown up anywhere I can see them, including in the public view of the SVN repository. After digging for a bit, I did see that they (or at least a modified version of the Linux ones) have apparently been incorporated into the Pyflag distribution, but that just caused me more confusion. If they're stable enough to release as part of Pyflag, why aren't they in the public Volatility repository? Also, are you expecting to release an 'official' update anytime soon? The last update available from the main Volatility page is still 1.3_Beta. Is there some defined list of fixes or features that has to be ready before an 'official' 1.3 version is released? Or has that been bypassed, so that current work is really going toward 1.4? Maybe a roadmap section would make a good addition to the main Volatility page. I'm sure there are a lot of people who would be interested in what's going on. Thanks much (Sorry if I sound like I'm ranting, you guys really have done some awesome work!) John ---------------------------------------------------------- Quis custodiet ipsos custodes?... I do!

15 years, 4 months

3
3
0 0

Re: [Vol-dev] decompression of hyberfil.sys

by Andreas Schuster

All, Here's a follow-up on the hiberfil.sys decompression issue. I executed the test plan as it was previously posted to vol-users (see <http://lists.volatilityfoundation.org/pipermail/vol-users/2009-July/000115.…>). As Michael already reported on this list, Volatility and X-Ways Forensics produced identical decompressed images from the original hiberfil.sys. Each of the memory images (VMEM files and decompressed hiberfil.sys) contains 32739 pages. Hibernation is known to preserve only important parts of the system's memory (see <http://technet.microsoft.com/en-us/library/bb457057.aspx>). >From the 32739 pages, only 19158 (59%) were unaltered after the system returned from hibernation mode (prehib.vmem vs posthib.vmem). The decompressed hibernation file matched 18566 pages (57%) of physmem prior to hibernation and 27929 pages (85%) of physmem post hibernation. >From those 19158 pages that are "stable" (unchanged over the whole process), 17998 (94%) are present in the decompressed hibernation file. Of those 3657 pages are filled with zeros. What about the remaining 6%? I suppose these pages are in use by the boot loader, HAL, or parts of the kernel. AAron suggested to analyze the process memory instead of physical memory. A quick stab (using Volatility's memdmp module) produced the following output for a command console: 44.322.816 bytes from prehib.vmem 46.036.628 bytes from hiberfil.sys 49.815.552 bytes from decompressed hiberfil.sys 39.624.704 bytes from posthib.vmem I ran nwdiff on the resulting images and all I can say is that the process environment is unchanged. Obviously, more work is needed to get a meaningful result. I suppose to focus on the user-land portion of the address space, calculate the pages's md5sum, and keep an eye on PTE flags as well. Please keep in mind that the figures above are based on a single execution of the test plan only. Multiple runs, with different memory loads and system memory sizes may yield different results. Cheers, Andreas

15 years, 10 months

1
0
0 0

Timeszones

by Andreas Schuster

Dear developers, I noticed that Volatility displays dates and times in up to three different timezones: 1. UTC (e.g. pslist, sockets, and the corresponding scanner modules) 2. local time of the system under examination (e.g. datetime, ident commands) 3. local time of the examiner's workstation (when using ctime() for formatting) I usually prefer UTC, especially when I have to consolidate timelines across systems that are distributed across different timezones. Using the local time may be a good choice when dealing with less-technical people. So, I don't think there's a "best" option and propose to let the user decide about the timezone that best suits his/her needs. The handling (and output format) should be consistent to avoid any misinterpretation and confusion. In order to provide a consistent interface to users and programmers, I propose to add functions to the framework (or to modify existing functions, respectively): - to switch between the three options in a consistent way (i.e. add an option to the standard parser) - to read timestamps in all applicable formats (mostly KSYSTEM_TIME, but also LARGE_INTEGER with bit shifting) from buffers and address spaces (see forensics/win32/datetime.py) - to produce the timestamp in an easy to read, unambiguous, and sortable format (preferably in accordance with ISO 8601) Before I start with coding, I want to hear your opinion on this. I appreciate any comments. Thanks! Andreas

15 years, 10 months

3
2
0 0

decompression of hyberfil.sys

by Michael Felber , Steufa Chemnitz, IT-Forensik

Hello all, I have posted this twice because the decompression issue should be moved to vol-dev as Aaron suggested. yesterday Andreas did provide a hiberfil.sys for decompression testing. Thanks a lot again. I have processed it twice with X-Ways-Forensics 15.3 SR3 and Volatility (SVN-release). The good news: Both result files are identical. The bad news: I dont have any clue why the decompression of my case relevant hiberfil.sys did not properly work with volatility but did with XWF. If anyone other needs a hiberfil.sys decompressed with XWF for testing, do not hesitate to ask me. We have the most recent releases here. (I am back on the 29th of July) I did compare the vol and the XWF-version of my case files but I cant interpret or explain the differences. What should I look for? BR Michael Michael Felber, StA Finanzamt Chemnitz-Süd Steuerfahndung IT-Forensik Paul-Bertz-Str. 1 D-09120 Chemnitz Germany Fon: +49 371 279 446 Fax. +49 371 279 421

15 years, 10 months

2
1
0 0

_LDR_MODULE

by Andreas Schuster

All, While fixing some bugs in scan2.py, I noticed a reference to _LDR_MODULE. I have never seen that name in a PDB before, possibly it should read _LDR_DATA_TABLE_ENTRY instead. Or is there a subtle difference that I'm not aware of? Both structures are defined in vtypes.py of SVN rev 12. I suggest to remove _LDR_MODULE and change any references to it into _LDR_DATA_TABLE_ENTRY. At least we should add a comment in order to avoid confusion. Any comments on this? Cheers, Andreas

15 years, 10 months

2
1
0 0

Fix to scan2.py (SVN rev 12)

by Andreas Schuster

All, Attached please find a fix for a couple of stupid mistakes (introduced by yours truly) in scan2.py, as of SVN rev. 12. Cheers, Andreas

15 years, 10 months

2
1
0 0

Little enhancements to datetime and thread scanners

by Andreas Schuster

Attached please find two patches for "datetime" and the thread scanner modules. Diffs are against SVN version 12. I modified the modules for my classes, so students could get some additional data to populate their timelines. The "datetime" function now reports the system's time in UTC, too. Both thread scanners now report creation and exit times in UTC. Cheers, Andreas

15 years, 10 months

1
0
0 0

SVN repository

by Jesse Kornblum

My apologies if this has been posted before, but the source code for Volatility is being hosted on Google code, http://code.google.com/p/volatility/ . You can check out a read-only version of code using Subversion using the command: svn checkout http://volatility.googlecode.com/svn/trunk/ volatility- read-only cheers, -- Jesse research(a)jessekornblum.com

15 years, 10 months

1
0
0 0

Patch for big endian systems

by Jesse Kornblum

Attached please find a patch against the SVN version of Volatility that allows the framework to work properly on big endian systems. While I know big endian systems are not the majority users, I think it's easy enough to patch. Most of the changes involve explicitly telling the decode function that the source data was from a little endian endian system. cheers, Here's the original version of the framework on a big endian system: $ python volatility ident -f xp-laptop-2005-07-04-1430.img Image Name: xp-laptop-2005-07-04-1430.img Image Type: UNKNOWN And the patched: $ python volatility ident -f memory-images/xp-laptop-2005-07-04-1430.img Image Name: xp-laptop-2005-07-04-1430.img Image Type: Service Pack 2 VM Type: nopae DTB: 0x39000 Datetime: Mon Jul 04 14:30:32 2005 -- Jesse research(a)jessekornblum.com

15 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Vol-dev July 2009