[Vol-dev] probably a really dump question RE: the new dumpfiles plugin

Jamie Levy jamie.levy at gmail.com
Fri Oct 11 14:01:40 CDT 2013


Actually the "hex number" from the output is the offset of the
_FILE_OBJECT.  Therefore, it is different.

All the best,

-Jamie



On Fri, Oct 11, 2013 at 2:21 PM, McCash John-GKJN37
<john.mccash at motorolasolutions.com> wrote:
> Aaron,
>         That's exactly what I needed! Thanks a ton. But from what Jamie said, I’d still expect the hex number from the filename to match the one from the output... Shouldn't it?
>                 John
>
>
>
> -----Original Message-----
> From: AAron Walters [mailto:awalters at 4tphi.net]
> Sent: Friday, October 11, 2013 12:34 PM
> To: Jamie Levy
> Cc: McCash John-GKJN37; vol-dev at volatilityfoundation.org
> Subject: Re: [Vol-dev] probably a really dump question RE: the new dumpfiles plugin
>
>
>
> Hi John,
>
> If your main goal is to associate output files with their original files, you can also use the -n option.  This option includes the original file name within the output name.  As we finalize the 2.3 release, we will update the documentation.
>
> Hope this helps!
>
> AW
>
>
> On Fri, 11 Oct 2013, Jamie Levy wrote:
>
>> Hi John,
>>
>> So you have:
>>
>> file.<number>.<hex number>.< dat |img |vacb>
>>
>> <number> == PID
>> <hex number> == Offset of SharedCacheMap or _CONTROL_AREA < dat |img
>> |vacb> ==  DataSectionObject, ImageSectionObject or SharedCacheMap
>>
>> If you want more detailed information about the files that are dumped,
>> make sure to the --summary-file option.
>>
>> We'll write up documentation soon.
>>
>> All the best,
>>
>> -Jamie
>>
>>
>>
>>
>> On Fri, Oct 11, 2013 at 11:41 AM, McCash John-GKJN37
>> <john.mccash at motorolasolutions.com> wrote:
>>> Hi,
>>>
>>>                 I’d been looking forward to the new dumpfiles plugin
>>> for a while, so I immediately downloaded it and tried it out as soon
>>> as possible after I saw it had finally been committed to the source tree the other day.
>>> (I’m freely admitting I’m using the thing without any documentation,
>>> since that still hasn’t been committed, and probably have no idea
>>> what I’m really
>>> doing.) Now, I have a dumb question. The names of the dumped files
>>> are all of the format:
>>>
>>>
>>>
>>> file.<number>.<hex number>.< dat |img |vacb>
>>>
>>>
>>>
>>> In addition, the dumping process produces a bunch of output, of the form:
>>>
>>>
>>>
>>> <DataSectionObject|ImageSectionObject|SharedCacheMap>   <hex number>
>>> <number>          <file path>
>>>
>>>
>>>
>>> with no column header or other indication of what exactly these
>>> values refer to. (If I had to guess, maybe the hex value is the data
>>> offset within the
>>> image?)
>>>
>>>
>>>
>>>                 Looking at this format (without knowing for sure
>>> exactly what the numbers are referring to) would lead me to expect
>>> that the <number> and <hex number> fields from the output should
>>> correspond to the ones in the dumped filenames, and thus the file
>>> paths should have some correspondence to the dumped file data, if the
>>> values match up. Not necessarily being the contents of exact file to
>>> which the path corresponds, but being related in some way.
>>>
>>>
>>>
>>>                 But I’m not seeing the same hex value show up
>>> anywhere in the output and in ANY filename…
>>>
>>>
>>>
>>> Trying for a specific correspondence, I went looking through the
>>> dumped files, and was able to positively identify the Software
>>> registry hive. The associated filename was file.4.0x8697a2b8.vacb.
>>> Looking through the output for entries associated with this file identified the following two entries:
>>>
>>>                 DataSectionObject 0x89291f90   4
>>> \Device\HarddiskVolume1\WINDOWS\system32\config\software
>>>
>>>                 SharedCacheMap 0x89291f90   4
>>> \Device\HarddiskVolume1\WINDOWS\system32\config\software
>>>
>>>
>>>
>>> I’m probably just completely misinterpreting the output, but could
>>> somebody throw me a bone?
>>>
>>>
>>>
>>>                                 Thanks much
>>>
>>>                                                 John
>>>
>>>
>>> _______________________________________________
>>> Vol-dev mailing list
>>> Vol-dev at volatilityfoundation.org
>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-dev
>>>
>>
>>
>>
>> --
>> PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3  64C2 196B 2AB5 27A4 AC92
>> _______________________________________________
>> Vol-dev mailing list
>> Vol-dev at volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-dev
>>



-- 
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3  64C2 196B 2AB5 27A4 AC92


More information about the Vol-dev mailing list