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.volatilityfoundation.org/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