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@4tphi.net]
Sent: Friday, October 11, 2013 12:34 PM
To: Jamie Levy
Cc: McCash John-GKJN37; vol-dev(a)volatilesystems.com
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(a)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(a)volatilesystems.com
 
http://lists.volatilesystems.com/mailman/listinfo/vol-dev
 
 --
 PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3  64C2 196B 2AB5 27A4 AC92
 _______________________________________________
 Vol-dev mailing list
 Vol-dev(a)volatilesystems.com
 
http://lists.volatilesystems.com/mailman/listinfo/vol-dev