Great write up Adam! Thanks for sharing the details. I'm sure a lot of people interested in memory analysis as well as disk forensics will find it very useful. When I get a chance this weekend, I'll update our community documentation page [1] with a link to your write-up. 

Tom, yes, it natively supports hibernation files (has for a while though 2.1 introduced support for x64 hiberfil.sys). Also see the supported file formats [2]. 

MHL

[1]. http://code.google.com/p/volatility/wiki/VolatilityDocumentationProject
[2]. http://code.google.com/p/volatility/wiki/FAQ21#What_memory_dump_formats_are_supported

On Fri, Aug 17, 2012 at 10:15 PM, Tom Yarrish <tom@yarrish.com> wrote:
Adam,
Nice write up.

One question for the group.  Does the new version of Volatility
support he hiberfil.sys natively now?  I thought it had to be
converted first?

Tom

On Fri, Aug 17, 2012 at 6:22 PM, Adam Bridge <adam.bridge@yahoo.com> wrote:
> As promised, I have done my best to write up the process I went through to
> successfully identify the file behind the TC volume.
>
> Find it here: http://www.scribd.com/doc/103174530
>
> Thanks,
> Adam
>
>
> On Fri, Aug 17, 2012 at 5:55 PM, Tom Yarrish <tom@yarrish.com> wrote:
>>
>> Please let us know when it's up, I'd like to add it to my "notes" for
>> future reference.
>>
>> Tom
>>
>> On Fri, Aug 17, 2012 at 10:06 AM, Adam Bridge <adam.bridge@yahoo.com>
>> wrote:
>> > 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.volatilityfoundation.org/mailman/listinfo/vol-users
>> >> >>>>> >> >
>> >> >>>>> >
>> >> >>>>> >
>> >> >>>>> >
>> >> >>>>> > _______________________________________________
>> >> >>>>> > Vol-users mailing list
>> >> >>>>> > Vol-users@volatilityfoundation.org
>> >> >>>>> > http://lists.volatilesystems.com/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.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@volatilesystems.com
>> > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>> >
>
>
_______________________________________________
Vol-users mailing list
Vol-users@volatilesystems.com
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users