- Vol-dev - volatilityfoundation.org

by Jesse Kornblum

Hi everybody, I've found that if you interrupt the hibernation file restore on Windows XP the header changes from "hibr" to "wake". Unfortunately such hibernation files cannot be processed by Volatility due to a simple check in vutils.py. The code attached patches vutils to allow parsing of these files. -- Jesse

16 years

1
0
0 0

Drop-in replacement for x86.py

by Jesse Kornblum

Hi everybody, Attached please find a drop-in replacement for forensics/x86.py. It's a complete rewrite of the code using the latest edition of the Intel Architectures Software Developer's Manual [1]. The manual, now at revision 031, has changed significantly over the past few years. The current version has a new (and much simpler) approach for finding offsets. The result is cleaner code! Hopefully this will be easier to maintain over the years! I've also added pydoc style documentation for each function. Please let me know what you think, [1] http://www.intel.com/products/processor/manuals/index.htm -- Jesse research(a)jessekornblum.com

16 years, 1 month

1
0
0 0

Simplifying address translation

by Jesse Kornblum

Hi everybody, We might be able to simplify the virtual to physical address translation in the Volatility framework. While it's not always wise to mess with something that works already, making this code clearer would help people trying to learn the framework and about memory forensics in general. The code in question is all in forensics/x86.py. I've attached a drop-in replacement for forensics/x86.py to illustrate the kind of changes I'm proposing [1]. Right now it only works for non-PAE system (e.g. xp-laptop-2005-*). If you like this I can expand it work on PAE systems as well. I was reading the Intel Architectures Software Developer's Manual [2] and took particular note of how they described the lookups for PDEs and PTEs. Using PDEs, for example, Volatility uses the value in CR3 as a base address and add to it an index number multiplied by a size value. The index comes from shifting bits around in the original virtual address. It looks like this: address = [Cr3] + (([vaddr] >> shift) & ((ptrs - 1)) * pointer_size) This calculation is broken into two functions and uses three magic values. The Intel manual takes a different approach. To them the PDE offset just a series of bits grabbed from various sources. In their words: <snip> A PDE is selected using the physical address defined as follows: — Bits 39:32 are all 0. — Bits 31:12 are from CR3. — Bits 11:2 are bits 31:22 of the linear address. — Bits 1:0 are 0. </snip> In other words: address = ([Cr3] & mask) & ([vaddr] & mask >> shift) In Volatility it would look like: pgd_addr = (self.pgd_vaddr & 0xfffff000) | ((vaddr & 0xffc00000) >> 20) I've even included a helper function, bitmask(), that computes bitmasks on the fly. Avoid it might take slightly longer to execute, it would hopefully avoid coding errors. pgd_addr = (self.pgd_vaddr & bitmask(12,31)) | ((vaddr & bitmask(22,31)) >> 20) What do you think? [1] Warning! This code *only* works on non-PAE systems for now. It also contains some code to make Volatility work on big endian machines. [2] http://www.intel.com/products/processor/manuals/index.htm -- Jesse research(a)jessekornblum.com

16 years, 1 month

1
0
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

16 years, 2 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

16 years, 2 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

16 years, 2 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

16 years, 2 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

16 years, 2 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

16 years, 2 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

16 years, 2 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