Thanks Jamie for the information...

I ran the FileScan plugin as suggested ...

vol.exe -f memdump.mem --profile=Win7SP1x64 --output=text --output-file=fileScan.txt filescan

This resulted in the following line within my fileScan.txt file...

0x000000021d048800 3 1 R--r-- \Device\TrueCryptVolumeK\Test.txt

I then ran Dumpfiles with the following command (using the physical address from the FileScan), but it did not result in any information...

vol.exe -f memdump.mem --profile=Win7SP1x64 --output=text --output-file=dumpFiles_trueCryptFile.txt dumpfiles -Q 0x000000021d048800 -D dumps/

In looking at the above, I realized that the dumpfiles plugin doesn't require the --output-file parameter, so I re-ran the command as...

vol.exe -f memdump.mem --profile=Win7SP1x64 -S dumpFiles_trueCryptFile2.txt dumpfiles -Q 0x000000021d048800 -D dumps/

With both dumpfiles attempts, the text file was blank and "output" directory empty. Both plugins completed quickly (within a couple seconds of processing).

Does this mean that the information is not found in the memory? Or am I running this command in-correctly?

Thank you,

Rob

On Mon, Apr 28, 2014 at 5:32 AM, Jamie Levy <jamie@memoryanalysis.net> wrote:

Hi Robert,

Have you tried using filescan to find the files on the TC volume? In
the original experiment did you leave the TC volume open?

The handles plugin enumerates handles for processes that are found in
the process list by default. It's possible that earlier, the process
that had that handle open to Test.txt was still running and in later
experiments you killed that process, causing it to disappear from the
process list and therefore its handles were not output.

Try filescan to pick up these files and see if you still see them. If
your end goal is to extract them from memory, you can use the dumpfiles
plugin and supply the physical offset of the _FILE_OBJECT (obtained from
filescan) like so:

vol.exe -f memdump.mem --profile=Win7SP1x64 -Q OFFSET -D OUTPUTDIR

All the best,

-Jamie

On 4/27/14 11:02 AM, Robert Merriott wrote:
> Hello
>
> I've been testing volatility and looking through the results. In
> particular, within the Handles extraction, I found the following line...
>
> 0xfffffa8009648800 3544 0x1a78 0x120089 File
> \Device\TrueCryptVolumeK\Test.txt
>
> This is a file that I had stored in a hidden volume. I attempted to
> re-create this type of entry with 3 further memory dumps with no such
> success (No files within TrueCrypt volume). Can anyone advise why this
> filename "Test.txt" was found? I see that a lot of files can be found
> in the Handles extraction, but haven't been able to find any
> documentation on how files are included in this section.
>
> I ran the following command on an 8GB Memory dump which was captured
> via FTK Imager...
>
> vol.exe -f memdump.mem --profile=Win7SP1x64 --output=text
> --output-file=handles-files.txt handles -t File
>
> This result was a total surprise to find. In further testing, I
> attempted to do the following within the hidden volume...
> - Create new files
> - Copy files into the volume
> - Leave files open while closing the volume within TrueCrypt
>
> Thanks,
>
> R
>
>

> _______________________________________________
> Vol-users mailing list
> Vol-users@volatilesystems.com
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

--
Jamie Levy (@gleeda)
Blog: http://volatility-labs.blogspot.com/
GPG: http://pgp.mit.edu/pks/lookup?op=get&search=0x196B2AB527A4AC92
Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92