Ok, I'm delighted to say that I've solved it!

I was able to work with the list of File objects from handles --pid=4 and really narrow it down to one likely file on a particular device.
Went and dug that device out of the store and voila, there was the file and it is indeed a TC volume.

Chuffed to bits. Thanks everyone for your help.

I shall do my best to write it up over the weekend and post it on the web somewhere.

Thanks again!

On Fri, Aug 17, 2012 at 3:45 PM, Jamie Levy <jamie.levy@gmail.com> wrote:
Try this filescan patch and see if it helps:

http://code.google.com/p/volatility/issues/detail?id=325



On Fri, Aug 17, 2012 at 8:22 AM, Adam Bridge <adam.bridge@yahoo.com> wrote:
> Today I've been able to work on the actual case rather than my test case.
> I've mainly been making use of handles and symlinkscan.
> Again, my goal is to try and find the "file" which is the TC volume.
>
> I've put my rough notes here: http://bridgey.co.uk/vty-tc.txt.html
> If I'm actually successful I shall write them up with a more tutorial-like
> approach.
>
> I'm pretty much at a point where I'm saying the TC volume is either the
> entire attached Seagate device or at least a file on that device.
> If the latter, I have no idea which file!
>
> Any comments, suggestions, flames or mother-based insults welcome!
>
>
> On Fri, Aug 17, 2012 at 8:33 AM, Adam Bridge <adam.bridge@yahoo.com> wrote:
>>
>> Thanks again for all the comments all. I assume people are suggesting
>> Registry keys such as shellbags and MRUs to look for file from the T:? That
>> might give me some clue as to usage.
>> My primary goal here is to identify the file which is the TC volume.
>>
>> @MHL
>> You're absolutely right - the focus should be on \Device\TrueCryptVolumeT
>> as I really only know bout \Device\HarddiskVolume10 because I "cheatingly"
>> know the name of the TC volume (MyTrueCryptVolume).
>> In my real case, I don't know the name. The problem I've got is that I've
>> run into a bit of a dead end with \Device\TrueCryptVolumeT with respect to
>> identifying the file behind it.
>>
>> Adam
>>
>>
>> On Thu, Aug 16, 2012 at 11:55 PM, Michael Hale Ligh
>> <michael.hale@gmail.com> wrote:
>>>
>>> Adam,
>>>
>>> Shouldn't you be looking for references to \Device\TrueCryptVolumeT\
>>> instead of (or at least in addition to)
>>> \Device\HarddiskVolume10\MyTrueCryptVolume? The TrueCryptVolumeT location is
>>> what's actually mapped at T: as shown by symlinkscan.
>>>
>>> The fact that MyTrueCryptTextFile.txt doesn't show up in the notepad.exe
>>> handles output is normal. Basically what notepad does is opens the file,
>>> maps it into memory, displays the contents in the GUI, then closes handle
>>> (so as not to needlessly consume handles when they're not being used). Thus
>>> by the time you acquire memory, the handle is already closed. When you
>>> modify the text file and click Save, the process re-opens a handle, flushes
>>> the changes, and closes the handle again.
>>>
>>> If you want to test that, use Process Monitor and set up a filter for
>>> notepad.exe. Then open your MyTrueCryptTextFile.txt file and review the APIs
>>> being called. You'll see CreateFile followed by CreateFileMapping, and
>>> finally CloseHandle. This probably varies per application (for example maybe
>>> Microsoft Word always retains an open handle to the document being
>>> modified).
>>>
>>> MHL
>>>
>>> On Thu, Aug 16, 2012 at 5:24 PM, Adam Bridge <adam.bridge@yahoo.com>
>>> wrote:
>>>>
>>>> The only references to HarddiskVolume10 in the handles output are:
>>>>
>>>> 0xfffffa80021a63c0      4             0x2a1c           0x12019f File
>>>> \Device\HarddiskVolume10\MyTrueCryptVolume
>>>> 0xfffffa8003992420   2700              0xba8           0x100081 File
>>>> \Device\HarddiskVolume10\
>>>> 0xfffffa8004672940   2700              0xd3c           0x100081 File
>>>> \Device\HarddiskVolume10\
>>>>
>>>> PID 4 being SYSTEM and 2700 being explorer. I'm assuming you only knew
>>>> it was HarddiskVolume10 because of 'MyTrueCryptVolume'?
>>>> In my real case, I don't know the name of the T/C volume.
>>>>
>>>> Great thinking about userassist. In my test case I did indeed
>>>> double-click a txt file (MyTrueCryptTextFile.txt) which was within the T/C
>>>> volume but sadly it doesn't appear in the userassist output (entirely
>>>> unrelated to this T/C stuff, it's fascinating what does tho!) Interestingly,
>>>> the txt file also doesn't appear in the handles output - even though it was
>>>> open at the time I captured the memory?! (On the test system it is in the
>>>> Notepad jump list.)
>>>>
>>>> Thanks so much for the comments all - I'm learning so much - it's
>>>> awesome!
>>>>
>>>> On Thu, Aug 16, 2012 at 10:10 PM, Jamie Levy <jamie.levy@gmail.com>
>>>> wrote:
>>>>>
>>>>> Are there any files (from handles output) that are on
>>>>> \Device\HarddiskVolume10 ?  In your output this is the location of the
>>>>> TrueCrypt volume.
>>>>>
>>>>> If they double clicked a document or something from that volume, an
>>>>> entry for its LNK file might show up in the UserAssist key, you can
>>>>> run the userassist plugin just to see what shows up in there.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 16, 2012 at 4:28 PM, Adam Bridge <adam.bridge@yahoo.com>
>>>>> wrote:
>>>>> > Thanks so much for the email - extremely useful already.
>>>>> > I'm taking notes so that I can do my best at writing it up at the
>>>>> > end.
>>>>> >
>>>>> > So, with pslist I found one instance of TrueCrypt.exe which had a PID
>>>>> > of
>>>>> > 4920.
>>>>> >
>>>>> > With handles --pid=4920 there was nothing useful - all very much T/C
>>>>> > stuff.
>>>>> > So I did handles without the --pid.
>>>>> > Now, with my test data I of course know the name of the T/C volume
>>>>> > file and
>>>>> > sure enough I could see it:
>>>>> >
>>>>> > Offset(V)             Pid             Handle             Access Type
>>>>> > Details
>>>>> > ------------------ ------ ------------------ ------------------
>>>>> > ---------------- -------
>>>>> > 0xfffffa8002193b30      4             0x269c               0x2a
>>>>> > Process
>>>>> > TrueCrypt.exe(4920)
>>>>> > 0xfffffa80021a63c0      4             0x2a1c           0x12019f File
>>>>> > \Device\HarddiskVolume10\MyTrueCryptVolume # Here!
>>>>> > 0xfffffa8002193b30    796              0x6c0           0x1fffff
>>>>> > Process
>>>>> > TrueCrypt.exe(4920)
>>>>> > 0xfffffa8002193b30    836              0xc28             0x1478
>>>>> > Process
>>>>> > TrueCrypt.exe(4920)
>>>>> > 0xfffffa8002193b30   1144              0xd4c             0x1478
>>>>> > Process
>>>>> > TrueCrypt.exe(4920)
>>>>> > 0xfffffa8001b4f070   2700             0x1084           0x100081 File
>>>>> > \Device\TrueCryptVolumeT\
>>>>> > 0xfffffa8002c7d1c0   2700             0x1118           0x100081 File
>>>>> > \Device\TrueCryptVolumeT\
>>>>> > 0xfffffa8001e51f20   4920              0x324           0x100080 File
>>>>> > \Device\TrueCrypt
>>>>> > 0xfffffa80038e4680   4920              0x330           0x1f0001
>>>>> > Mutant
>>>>> > TrueCryptTaskBarIcon
>>>>> > 0xfffffa8004d5a8d0   3384                0xc           0x100020 File
>>>>> > \Device\TrueCryptVolumeT\
>>>>> >
>>>>> > In my real case I don't know the name of the file - so I wouldn't
>>>>> > know it if
>>>>> > I saw it - especially if it had an innocent name like
>>>>> > "school_work.doc".
>>>>> >
>>>>> > I now know my T/C volume is mounted as T:
>>>>> > I notice that there are 2 PIDs accessing the T:
>>>>> > Look them up in the plist data and they're explorer and notepad
>>>>> > (which is
>>>>> > correct, I'd opened a txt file from the T/C volume).
>>>>> >
>>>>> > So, pretending I hadn't seen 'MyTrueCryptVolume' I tried symlinks and
>>>>> > grep'd
>>>>> > for TrueCrypt:
>>>>> >
>>>>> >
>>>>> > Offset(P)            #Ptr   #Hnd Creation time            From
>>>>> > To
>>>>> > ------------------ ------ ------ ------------------------
>>>>> > --------------------
>>>>> > ------------------------------------------------------------
>>>>> > 0x0000000026b33c80      1      0 2012-08-16 19:12:51
>>>>> > Volume{3d...10a7e8a} \Device\TrueCryptVolumeT
>>>>> > 0x0000000037f51b10      1      0 2012-08-16 18:14:48      TrueCrypt
>>>>> > \Device\TrueCrypt
>>>>> > 0x0000000052ececb0      1      0 2012-08-16 19:12:51      T:
>>>>> > \Device\TrueCryptVolumeT
>>>>> > 0x000000006131c9d0      1      0 2012-08-16 19:12:51      T:
>>>>> > \Device\TrueCryptVolumeT
>>>>> >
>>>>> > So, definitely T: then.
>>>>> >
>>>>> > So I know there's a T/C volume mounted, I know that it's mounted as
>>>>> > the T:
>>>>> > and I know that explorer and notepad have both got handles to it.
>>>>> > I've got one last hurdle to clear: how do I find out the file which
>>>>> > is
>>>>> > behind \Device\TrueCryptVolumeT?
>>>>> >
>>>>> > I filtered handles for File objects from \Device\HarddiskVolume* but
>>>>> > that
>>>>> > left me with ~130 files and without knowing the file name how would I
>>>>> > identify it?
>>>>> >
>>>>> > Thanks again for all the suggestions so far!
>>>>> >
>>>>> >
>>>>> > On Thu, Aug 16, 2012 at 8:04 PM, Andrew Case <atcuno@gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Hello,
>>>>> >>
>>>>> >> So I will assume you are using the latest release of Volatility,
>>>>> >> which
>>>>> >> means the 2.1 command reference will give you information about
>>>>> >> every
>>>>> >> plugin we have:
>>>>> >>
>>>>> >> http://code.google.com/p/volatility/wiki/CommandReference21
>>>>> >>
>>>>> >> The next thing I would do is run the handles plugin [1] and look for
>>>>> >> any reference to the open file. You can filter with the -p option to
>>>>> >> be only the TrueCrypt process that you found in pslist, but if you
>>>>> >> do
>>>>> >> not see any encrypted container referenced there then you may want
>>>>> >> to
>>>>> >> run it across all processes (the default) because we have seen where
>>>>> >> files opened by drivers end up in other processes' handles (e.g.
>>>>> >> SYSTEM).
>>>>> >>
>>>>> >> I think handles would be more helpful to determine if any files were
>>>>> >> opened b/c it will show you exactly what truecrypt had open when the
>>>>> >> machine hibernated. With filescan you would have to already know the
>>>>> >> name of the encrypted container to see if it was ever opened.
>>>>> >>
>>>>> >> Also, MHL suggested using the symlink scan command [2] as this will
>>>>> >> map drive letters to physical device paths. Here is some sample
>>>>> >> output
>>>>> >> for the command:
>>>>> >>
>>>>> >> $ python vol.py -f win7x64cmd.dd --profile=Win7SP1x64 symlinkscan
>>>>> >> Volatile Systems Volatility Framework 2.2_alpha
>>>>> >> Offset(P)            #Ptr   #Hnd Creation time            From
>>>>> >>         To
>>>>> >> ------------------ ------ ------ ------------------------
>>>>> >> --------------------
>>>>> >> ------------------------------------------------------------
>>>>> >> 0x0000000007331840      1      0 2011-12-30 08:26:15      Global
>>>>> >>         \Global??
>>>>> >> 0x0000000013d6a930      1      0 2012-01-10 18:35:28      Z:
>>>>> >>         \Device\LanmanRedirector\;Z:0...000003b08d\10.1.47.238\setup
>>>>> >> 0x0000000023bc0140      1      0 2011-12-30 08:25:30      A:
>>>>> >>         \Device\Floppy0
>>>>> >> 0x000000002ab23430      1      0 2011-12-30 08:25:30      D:
>>>>> >>         \Device\CdRom0
>>>>> >> 0x000000002d3b8c90      1      0 2011-12-30 08:25:26      C:
>>>>> >>         \Device\HarddiskVolume2
>>>>> >>
>>>>> >> And you can see, C: is mapped to HarddiskVolume2. From there you can
>>>>> >> run handles and filter specifically to files opened on that device
>>>>> >> like this:
>>>>> >>
>>>>> >> $ python vol.py -f win7x64cmd.dd --profile=Win7SP1x64 handles -t
>>>>> >> File
>>>>> >> | grep HarddiskVolume2
>>>>> >> Volatile Systems Volatility Framework 2.2_alpha
>>>>> >> 0xfffffa800248e5a0      4               0x5c           0x12008b File
>>>>> >>           \Device\HarddiskVolume2\Windows\System32\wfp\wfpdiag.etl
>>>>> >> 0xfffffa800267f300      4               0xa4           0x13019f File
>>>>> >>
>>>>> >>
>>>>> >> \Device\clfs\Device\HarddiskVolume2\$Extend\$RmMetadata\$TxfLog\$TxfLog
>>>>> >> 0xfffffa800267b540      4               0xa8           0x12019f File
>>>>> >>
>>>>> >>
>>>>> >> \Device\clfs\Device\HarddiskVolume2\$Extend\$RmMetadata\$TxfLog\$TxfLog
>>>>> >> 0xfffffa8002671350      4               0xac           0x13019f File
>>>>> >>
>>>>> >>
>>>>> >> \Device\clfs\Device\HarddiskVolume2\$Extend\$RmMetadata\$TxfLog\$TxfLog
>>>>> >> 0xfffffa80026794e0      4               0xb0           0x12019f File
>>>>> >>
>>>>> >>
>>>>> >> \Device\HarddiskVolume2\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000002
>>>>> >> 0xfffffa8002679c30      4               0xb4                0x1 File
>>>>> >>           \Device\HarddiskVolume2
>>>>> >>
>>>>> >>
>>>>> >> If the combination of handles and symlinkscan does not answer your
>>>>> >> question please write back. Also, it would be interesting if you
>>>>> >> documented your process through this (assuming you can), as I am
>>>>> >> sure
>>>>> >> many other people will encounter this situation.
>>>>> >>
>>>>> >>
>>>>> >> [1]
>>>>> >> http://code.google.com/p/volatility/wiki/CommandReference21#handles
>>>>> >> [2]
>>>>> >>
>>>>> >> http://code.google.com/p/volatility/wiki/CommandReference21#symlinkscan
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> ....
>>>>> >>
>>>>> >> On Thu, Aug 16, 2012 at 8:41 AM, Adam Bridge <adam.bridge@yahoo.com>
>>>>> >> wrote:
>>>>> >> > Hello All,
>>>>> >> >
>>>>> >> > I'm new to Volatility but am a reasonably experienced forensic
>>>>> >> > examiner.
>>>>> >> >
>>>>> >> > I'm working on a hiberfil.sys from a WIN7SP1x64 machine and am
>>>>> >> > trying to
>>>>> >> > determine whether a TrueCrypt volume was mounted and, for bonus
>>>>> >> > points,
>>>>> >> > the
>>>>> >> > path to the TrueCrypt volume file.
>>>>> >> >
>>>>> >> > I've used devicetree and found:
>>>>> >> >
>>>>> >> > DRV 0x23ea15de0 \Driver\truecrypt
>>>>> >> > ---| DEV 0xfffffa800946f080 TrueCryptVolumeG FILE_DEVICE_DISK
>>>>> >> > ---| DEV 0xfffffa8007127ac0 TrueCrypt FILE_DEVICE_UNKNOWN
>>>>> >> >
>>>>> >> > So a good start.
>>>>> >> >
>>>>> >> > Question: Does that tell me that there _IS_ a TrueCrypt volume
>>>>> >> > mounted
>>>>> >> > as
>>>>> >> > the G drive or there _WAS_ a TrueCrypt volume mounted as the G
>>>>> >> > drive, or
>>>>> >> > that there's no way of knowing one way or the other?
>>>>> >> >
>>>>> >> > filescan shows two entries for \TrueCrypt.exe. The only difference
>>>>> >> > between
>>>>> >> > the two (besides a slight difference in #Ptr) is that one has
>>>>> >> > access of:
>>>>> >> >
>>>>> >> > R--rwd
>>>>> >> >
>>>>> >> > and the other:
>>>>> >> >
>>>>> >> > R--r-d
>>>>> >> >
>>>>> >> > What should I be discerning from this? Why does one have a write
>>>>> >> > permission
>>>>> >> > that the other does not?
>>>>> >> >
>>>>> >> > And finally, pslist shows me that TrueCrypt.exe was started but
>>>>> >> > has no
>>>>> >> > exit
>>>>> >> > time.
>>>>> >> >
>>>>> >> > I'm just not really sure where to go next?
>>>>> >> > Can anybody suggest anything?
>>>>> >> >
>>>>> >> > More than happy for someone to tell me to go read X! Just can't
>>>>> >> > find a
>>>>> >> > helpful X to read.
>>>>> >> >
>>>>> >> > Thank you all,
>>>>> >> > AB
>>>>> >> >
>>>>> >> > _______________________________________________
>>>>> >> > Vol-users mailing list
>>>>> >> > Vol-users@volatilityfoundation.org
>>>>> >> > http://lists.volatilesystems.com/mailman/listinfo/vol-users
>>>>> >> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > Vol-users mailing list
>>>>> > Vol-users@volatilityfoundation.org
>>>>> > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3  64C2 196B 2AB5 27A4 AC92
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Vol-users mailing list
>>>> Vol-users@volatilityfoundation.org
>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>
>>>
>>
>
>
> _______________________________________________
> Vol-users mailing list
> Vol-users@volatilesystems.com
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>



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