sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.

Re: [sleuthkit-users] Hex Viewer Survey

[RB <ao...@gm...>]

On Fri, Nov 22, 2013 at 11:21 AM, Brian Carrier <ca...@sl...>wrote:

> I was in Barry's camp with preferring xxd-style (#1) and was about to
> change it.
>

Ha, I was headed there myself.  %!xxd FTW.

Re: [sleuthkit-users] Hex Viewer Survey

[Grundy B. J T. <Bar...@ti...>]

I'm not really much of an Autopsy user, but I would prefer to see option #1.  After years of using xxd, I think the second option would cause some sort of cognitive disconnect or something.  And I'd leave a ton of smudges on my screen while counting with my finger.

/*******************************************
Barry J. Grundy
Assistant Special Agent in Charge
Digital Forensic Support Group  
Electronic Crimes and Intelligence Division
Treasury Inspector General for Tax Administration
(301) 210-8741 (w)
(202) 527-5778 (c)
Bar...@ti...
********************************************\


> -----Original Message-----
> From: Brian Carrier [mailto:ca...@sl...]
> Sent: Friday, November 22, 2013 1:06 PM
> To: sle...@li... users
> Subject: [sleuthkit-users] Hex Viewer Survey
> 
> Survey question while fixing a bug in the hex viewer area of Autopsy. Would
> people prefer output that looked like:
> 
> 1)  0x00000000: ffff ffff ffff ffff ffff ffff ffff ffff   ................
> 2)  0x00000000: ff ff ff ff ff ff ff ff   ff ff ff ff ff ff ff ff   ................
> 
> Different tools use both of these.  Any preferences from this group on which
> Autopsy uses moving forward?    1 or 2?
> 
> 
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription Software experts and
> developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clk
> trk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Hex Viewer Survey

[Brian C. <ca...@sl...>]

And there you have it.  Many more replies came to me directly with #2 being the strong preference (which is what Autopsy has always had).

I was in Barry's camp with preferring xxd-style (#1) and was about to change it.  

We'll keep it as #2, but someday maybe we'll make it an option to switch between the two.

thanks for the feedback all!


On Nov 22, 2013, at 1:16 PM, Derrick Karpo <dk...@gm...> wrote:

> Option #2 is my preference but could use either.  I prefer the visual
> separation of the bytes.
> 
> Derrick
> 
> 
> On Fri, Nov 22, 2013 at 11:05 AM, Brian Carrier <ca...@sl...> wrote:
>> Survey question while fixing a bug in the hex viewer area of Autopsy. Would people prefer output that looked like:
>> 
>> 1)  0x00000000: ffff ffff ffff ffff ffff ffff ffff ffff   ................
>> 2)  0x00000000: ff ff ff ff ff ff ff ff   ff ff ff ff ff ff ff ff   ................
>> 
>> Different tools use both of these.  Any preferences from this group on which Autopsy uses moving forward?    1 or 2?
>> 
>> 
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
> 
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing 
> conversations that shape the rapidly evolving mobile landscape. Sign up now. 
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Hex Viewer Survey

[Derrick K. <dk...@gm...>]

Option #2 is my preference but could use either.  I prefer the visual
separation of the bytes.

Derrick


On Fri, Nov 22, 2013 at 11:05 AM, Brian Carrier <ca...@sl...> wrote:
> Survey question while fixing a bug in the hex viewer area of Autopsy. Would people prefer output that looked like:
>
> 1)  0x00000000: ffff ffff ffff ffff ffff ffff ffff ffff   ................
> 2)  0x00000000: ff ff ff ff ff ff ff ff   ff ff ff ff ff ff ff ff   ................
>
> Different tools use both of these.  Any preferences from this group on which Autopsy uses moving forward?    1 or 2?
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Hex Viewer Survey

[Keith W. <kwa...@gm...>]

I vote for 2
On Nov 22, 2013 11:09 AM, "Brian Carrier" <ca...@sl...> wrote:

> Survey question while fixing a bug in the hex viewer area of Autopsy.
> Would people prefer output that looked like:
>
> 1)  0x00000000: ffff ffff ffff ffff ffff ffff ffff ffff   ................
> 2)  0x00000000: ff ff ff ff ff ff ff ff   ff ff ff ff ff ff ff ff
> ................
>
> Different tools use both of these.  Any preferences from this group on
> which Autopsy uses moving forward?    1 or 2?
>
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

[sleuthkit-users] Hex Viewer Survey

[Brian C. <ca...@sl...>]

Survey question while fixing a bug in the hex viewer area of Autopsy. Would people prefer output that looked like:

1)  0x00000000: ffff ffff ffff ffff ffff ffff ffff ffff   ................
2)  0x00000000: ff ff ff ff ff ff ff ff   ff ff ff ff ff ff ff ff   ................

Different tools use both of these.  Any preferences from this group on which Autopsy uses moving forward?    1 or 2?

Re: [sleuthkit-users] Autopsy: Can't search in unallocated space of a partition

[Brian C. <ca...@sl...>]

Hi Dennis,

Sorry for the late reply on this. I'm finally getting back to all of the e-mails that occurred during OSDFCon the prep time before it. 

It should have found the strings and I just verified it on a test image.  A couple of things to mention here:
- Autopsy does case insensitive, exact matches.  Meaning that if you search for "forensic", then it will not find "forensics". It will find "FORENSIC" though. We are going to change the behavior in the future to make these substring matches easier.  Currently, you need to make a regular expression search and do something like ".*forensic.*".  The ".*" are wild cards before and after the word. Not sure if that is related to what you are seeing or not.
- One thing to help debug is if the text was properly extracted.  If you know where the string is in unallocated space, then you can look at the virtual unallocated file that Autopsy/TSK created for that region of unallocated space.  The virtual files are located in the "$Unalloc" folder for each file system and have names of the following syntax:

Unalloc_InternalID_StartByteOffset_EndByteOffset

If you know the byte offset of the string relative to the start of the disk, then find the Unalloc file that it is located in and view its contents.  The "Strings" tab shows the output of running strings on the content and the "Text" tab shows you want is in the SOLR keyword index.

If none of these helped, let me know and we can proceed with more steps.

thanks,
brian


On Nov 6, 2013, at 3:36 PM, Dennis <in...@ba...> wrote:

> Dear all, 
> 
> I am currently giving autopsy a test ride on one of my test images. I
> use this test image in some of my forensic classes but I ran into a
> problem.
> 
> My Setup 
>   Windows 8 64 Bit 
>   Autopsy V 3.0.6 
> 
> Image Details: t
>   320 GB EWF Image
> 
> Case Setup / Activated Ingest Modules
>   Recent Activities
>   Hash Lookup
>   EXIF Image Parser 
>   Keyword Search 
> 
> And of course the checkbox for "process unallocated space" was
> activated. 
> 	
> My Scenario
> I know that a HTML fragment is available in the unallocated space of one
> partition. This HTML fragment contains the string "secret secret".
> Therefore, I just ran a search for the string secret but the search did
> not yield any results in the unallocated space. 
> 
> I double checked that the string was inside the unallocated space by
> mounting the image via fuse (DFF) and running the command 
> 	string -f -t d * | grep secret 
> inside the NTFS unallocated folder. This resulted in roughly 20 - 30
> hits. 
> 
> Question
> Is this a known bug? Is the search in the unallocated space not yet
> supported? How can I investigate what is going wrong?
> 
> Kind regards
> Dennis  
> 
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy 3.0.8 Logs

[Brian C. <ca...@sl...>]

Hey Hoyt,

Go Help -> About and in that window the user directory is listed.  In there, is the 'var/log' folder. 

brian

On Nov 20, 2013, at 3:38 PM, Hoyt Harness <hoy...@gm...> wrote:

> Okay, I'm an idiot. Where are the logs stored in 3.0.8? I can't find a dev folder.
> 
> -- 
> Hoyt
> -----------------
> There are 11 kinds of people - those who think binary jokes are funny, those who don't, ...and those who don't know binary.
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing 
> conversations that shape the rapidly evolving mobile landscape. Sign up now. 
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk_______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] bitcoin forensics

[Notyor B. <vol...@gm...>]

hello guys,
for my master for research project, i want work on two project.one is
android devices analyzing and malware detection. otherone is bitcoin system
forensics. iw ant ask u guys, what is your idea to work on bitcoin
forensics? do u think its needed to work on bitcoin as its getting popular
now? is there enough information to work on it?
thank u

[sleuthkit-users] Autopsy 3.0.8 Logs

[Hoyt H. <hoy...@gm...>]

Okay, I'm an idiot. Where are the logs stored in 3.0.8? I can't find a dev
folder.

-- 
Hoyt
-----------------
There are 11 kinds of people - those who think binary jokes are funny,
those who don't, ...and those who don't know binary.

Re: [sleuthkit-users] Autopsy: Can't search in unallocated space of a partition

[Dennis <in...@ba...>]

Simson, 

thanks for the reply. 

regarding 1) I know that the string is in the unallocated space of the
partition due to an EnCASE analysis of the image and I have double
checked this with the method outlined in my initial email using fuse,
string and grep command. 

regarding 2) I already had a look at bulk_extractor but I thought that
Autopsy should have found the string as well that was the reason for
starting this thread to investigate. 
Some thoughts - better to say wild guesses -  that I have: 
- character encoding problem (ANSI vs UTF8 vs UTF16 with its different
endianness)
- not fully index the unallocated space. 

Kind regards
Dennis 


Kind regards
Dennis 

Am Sonntag, den 17.11.2013, 06:54 -0500 schrieb Simson Garfinkel:
> Dennis —
> 
> 1. Perhaps the string is not in unallocated space.
> 
> 2. For your application below, bulk_extractor with ‘-f’ might give better results. I realize that your goal is to test Autopsy, but I’m not really sure why you want to do that.  bulk_extractor with identify_filenames.py will tell you which files the strings came from.
> 
> Simson
> 
> 
> On Nov 17, 2013, at 5:43 AM, Dennis <in...@ba...> wrote:
> 
> > Hi, 
> > 
> > the image was created with FTK Imager (3.1). I did not activate
> > compression for the E01 image. 
> > 
> > Kind regards
> > Dennis 
> > 
> > Am Donnerstag, den 14.11.2013, 10:00 +0800 schrieb Notyor Buizines:
> >> what command did u use for taking image of hard disk?
> >> 
> >> 
> >> 
> >> On Thu, Nov 7, 2013 at 4:36 AM, Dennis <in...@ba...> wrote:
> >>        Dear all,
> >> 
> >>        I am currently giving autopsy a test ride on one of my test
> >>        images. I
> >>        use this test image in some of my forensic classes but I ran
> >>        into a
> >>        problem.
> >> 
> >>        My Setup
> >>           Windows 8 64 Bit
> >>           Autopsy V 3.0.6
> >> 
> >>        Image Details: t
> >>           320 GB EWF Image
> >> 
> >>        Case Setup / Activated Ingest Modules
> >>           Recent Activities
> >>           Hash Lookup
> >>           EXIF Image Parser
> >>           Keyword Search
> >> 
> >>        And of course the checkbox for "process unallocated space" was
> >>        activated.
> >> 
> >>        My Scenario
> >>        I know that a HTML fragment is available in the unallocated
> >>        space of one
> >>        partition. This HTML fragment contains the string "secret
> >>        secret".
> >>        Therefore, I just ran a search for the string secret but the
> >>        search did
> >>        not yield any results in the unallocated space.
> >> 
> >>        I double checked that the string was inside the unallocated
> >>        space by
> >>        mounting the image via fuse (DFF) and running the command
> >>                string -f -t d * | grep secret
> >>        inside the NTFS unallocated folder. This resulted in roughly
> >>        20 - 30
> >>        hits.
> >> 
> >>        Question
> >>        Is this a known bug? Is the search in the unallocated space
> >>        not yet
> >>        supported? How can I investigate what is going wrong?
> >> 
> >>        Kind regards
> >>        Dennis
> >> 
> >> 
> >>        ------------------------------------------------------------------------------
> >>        November Webinars for C, C++, Fortran Developers
> >>        Accelerate application performance with scalable programming
> >>        models. Explore
> >>        techniques for threading, error checking, porting, and tuning.
> >>        Get the most
> >>        from the latest Intel processors and coprocessors. See
> >>        abstracts and register
> >>        http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> >>        _______________________________________________
> >>        sleuthkit-users mailing list
> >>        https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> >>        http://www.sleuthkit.org
> >> 
> >> 
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> > Free app hosting. Or install the open source package on any LAMP server.
> > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> 

Re: [sleuthkit-users] pst file digest

[Joachim M. <joa...@gm...>]

Just FYI if you convert PST/OST to EML (RFC-822  / RFC-2822) it will be
lossy conversion.
It also won't be able to represent non mail messages (IPM as PST refers to
it) into EML files.
If you need to convert it, Outlook MSG files are a better option or just
interpret them native.

Re: [sleuthkit-users] Autopsy: Can't search in unallocated space of a partition

[Dennis <in...@ba...>]

Hi, 

the image was created with FTK Imager (3.1). I did not activate
compression for the E01 image. 

Kind regards
Dennis 

Am Donnerstag, den 14.11.2013, 10:00 +0800 schrieb Notyor Buizines:
> what command did u use for taking image of hard disk?
> 
> 
> 
> On Thu, Nov 7, 2013 at 4:36 AM, Dennis <in...@ba...> wrote:
>         Dear all,
>         
>         I am currently giving autopsy a test ride on one of my test
>         images. I
>         use this test image in some of my forensic classes but I ran
>         into a
>         problem.
>         
>         My Setup
>            Windows 8 64 Bit
>            Autopsy V 3.0.6
>         
>         Image Details: t
>            320 GB EWF Image
>         
>         Case Setup / Activated Ingest Modules
>            Recent Activities
>            Hash Lookup
>            EXIF Image Parser
>            Keyword Search
>         
>         And of course the checkbox for "process unallocated space" was
>         activated.
>         
>         My Scenario
>         I know that a HTML fragment is available in the unallocated
>         space of one
>         partition. This HTML fragment contains the string "secret
>         secret".
>         Therefore, I just ran a search for the string secret but the
>         search did
>         not yield any results in the unallocated space.
>         
>         I double checked that the string was inside the unallocated
>         space by
>         mounting the image via fuse (DFF) and running the command
>                 string -f -t d * | grep secret
>         inside the NTFS unallocated folder. This resulted in roughly
>         20 - 30
>         hits.
>         
>         Question
>         Is this a known bug? Is the search in the unallocated space
>         not yet
>         supported? How can I investigate what is going wrong?
>         
>         Kind regards
>         Dennis
>         
>         
>         ------------------------------------------------------------------------------
>         November Webinars for C, C++, Fortran Developers
>         Accelerate application performance with scalable programming
>         models. Explore
>         techniques for threading, error checking, porting, and tuning.
>         Get the most
>         from the latest Intel processors and coprocessors. See
>         abstracts and register
>         http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>         _______________________________________________
>         sleuthkit-users mailing list
>         https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>         http://www.sleuthkit.org
> 
> 

Re: [sleuthkit-users] pst file digest

[Luis G. 'P. <po...@lg...>]

Hi all,

As part of a forensic framework that relies on sleuthkit (the revealer toolkit - https://code.google.com/p/revealertoolkit/ ), I wrote some code that parses certain mail types (for PST/OST I use pffextract from libpff) and produces HTML output for every message, extracts the attachments, etc. in fact it goes further than that, because it parses every possible file type (for instance extracts compressed files, extracts strings from every possible file…) allowing for a nice search. I stopped working actively in the project when I changed my job nearly one year ago, but it is a nice bunch of code.

The particular file is https://code.google.com/p/revealertoolkit/source/browse/branches/pope-search/RVT/RVTscripts/RVT_parse.pm

In sub RVT_sanitize_libpff_item () (line 1948) we parse the output of libpff and generate our own representation, very nice for visualization, and for launching keyword searches. In addition, DBX, MBOX, MSG and EMLs are processed as well. The different attachments are also extracted / parsed as much as possible til text strings can be obtained from them.

The thing is a little bit experimental, but if anyone wants to give it a try, I can lend a hand.

Best regards

Pope




El 08/11/2013, a las 19:11, Greg Freemyer <gre...@gm...> escribió:

> I try to get my clients to let me send them EML files.  EML is an open
> standard (RFC-822  / RFC-2822).
> 
> Various email clients can read them but not Outlook so I do get some
> pushback.  The big advantage is the attachments are embedded.  X-Ways
> as an example exports emails originating in PSTs as EML files.  I
> don't know what FTK and/or EnCase do.
> 
> Further EMLs maintain much of the internal metadata as internal
> metadata.  (date sent, subject, to, from, cc, bcc)
> 
> Greg
> --
> Greg Freemyer
> 
> 
> On Fri, Nov 8, 2013 at 9:16 AM, MATT PIERCE <mat...@ad...> wrote:
>> Thank you guys for your suggestions.  I would really find a native parser
>> useful.  With the ability to import logical files into a case now half the
>> workflow is there.   Being able to parse a number of pst’s against a keyword
>> list is what I need to do.  Python isn’t my strength so I’ll have to ask
>> around.  There are several commercial products but they are both expensive
>> and incomplete in their features.  The report part is also a consideration.
>> Just locating the relevant data would be useful.  Having a list of locations
>> in a pst were relevant keywords exist would be great.  Being able to carve
>> message files out intact and/or export messages as a pdf would be amazing.
>> 
>> 
>> 
>>>> Hi Matt - we are currently looking into pst parsing libraries and
>> 
>>>> hope to have something in the next couple of months to make the
>> 
>>>> Mbox parser a more generic email parser
>> 
>> 
>> 
>> That is good news.  I rely heavily on libpff for now, although I’ve not had
>> any success in doing a complete examination without having to resort to
>> native outlook and sectool to process p12/pfx certificates.  If someone can
>> come up with an answer to that (or have I missed an existing one?), that
>> would be most helpful.
>> 
>> 
>> 
>> Admittedly I don’t spend enough time on PST testing, but since it’s a big
>> chunk of our casework, I’ll need to start.
>> 
>> 
>> 
>> /*******************************************
>> 
>> Barry J. Grundy
>> 
>> Assistant Special Agent in Charge
>> 
>> Digital Forensic Support Group
>> 
>> Electronic Crimes and Intelligence Division
>> 
>> Treasury Inspector General for Tax Administration
>> 
>> (301) 210-8741 (w)
>> 
>> (202) 527-5778 (c)
>> 
>> Bar...@ti...
>> 
>> ********************************************\
>> 
>> 
>> 
>> From: Jason Letourneau [mailto:jle...@ba...]
>> Sent: Thursday, November 07, 2013 8:14 PM
>> To: MATT PIERCE
>> Cc: sle...@li...
>> Subject: Re: [sleuthkit-users] pst file digest
>> 
>> 
>> 
>> Hi Matt - we are currently looking into pst parsing libraries and hope to
>> have something in the next couple of months to make the Mbox parser a more
>> generic email parser
>> 
>> 
>> 
>> Jason
>> 
>> On Thursday, November 7, 2013, MATT PIERCE wrote:
>> 
>> I'm curious if there is any work on a plugin to digest pst files.  I'm often
>> getting hit with eDiscovery requests to search multiple PST files for a
>> series of key words.  Libpff has a few tools that can work with a pst to a
>> degree but it would be very nice to be able to use them with Autopsy's
>> workflow.
>> 
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models. Explore
>> techniques for threading, error checking, porting, and tuning. Get the most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>> 
>> 
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models. Explore
>> techniques for threading, error checking, porting, and tuning. Get the most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>> 
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] pst file digest

[Greg F. <gre...@gm...>]

I try to get my clients to let me send them EML files.  EML is an open
standard (RFC-822  / RFC-2822).

Various email clients can read them but not Outlook so I do get some
pushback.  The big advantage is the attachments are embedded.  X-Ways
as an example exports emails originating in PSTs as EML files.  I
don't know what FTK and/or EnCase do.

Further EMLs maintain much of the internal metadata as internal
metadata.  (date sent, subject, to, from, cc, bcc)

Greg
--
Greg Freemyer


On Fri, Nov 8, 2013 at 9:16 AM, MATT PIERCE <mat...@ad...> wrote:
> Thank you guys for your suggestions.  I would really find a native parser
> useful.  With the ability to import logical files into a case now half the
> workflow is there.   Being able to parse a number of pst’s against a keyword
> list is what I need to do.  Python isn’t my strength so I’ll have to ask
> around.  There are several commercial products but they are both expensive
> and incomplete in their features.  The report part is also a consideration.
> Just locating the relevant data would be useful.  Having a list of locations
> in a pst were relevant keywords exist would be great.  Being able to carve
> message files out intact and/or export messages as a pdf would be amazing.
>
>
>
>>>Hi Matt - we are currently looking into pst parsing libraries and
>
>>>hope to have something in the next couple of months to make the
>
>>>Mbox parser a more generic email parser
>
>
>
> That is good news.  I rely heavily on libpff for now, although I’ve not had
> any success in doing a complete examination without having to resort to
> native outlook and sectool to process p12/pfx certificates.  If someone can
> come up with an answer to that (or have I missed an existing one?), that
> would be most helpful.
>
>
>
> Admittedly I don’t spend enough time on PST testing, but since it’s a big
> chunk of our casework, I’ll need to start.
>
>
>
> /*******************************************
>
> Barry J. Grundy
>
> Assistant Special Agent in Charge
>
> Digital Forensic Support Group
>
> Electronic Crimes and Intelligence Division
>
> Treasury Inspector General for Tax Administration
>
> (301) 210-8741 (w)
>
> (202) 527-5778 (c)
>
> Bar...@ti...
>
> ********************************************\
>
>
>
> From: Jason Letourneau [mailto:jle...@ba...]
> Sent: Thursday, November 07, 2013 8:14 PM
> To: MATT PIERCE
> Cc: sle...@li...
> Subject: Re: [sleuthkit-users] pst file digest
>
>
>
> Hi Matt - we are currently looking into pst parsing libraries and hope to
> have something in the next couple of months to make the Mbox parser a more
> generic email parser
>
>
>
> Jason
>
> On Thursday, November 7, 2013, MATT PIERCE wrote:
>
> I'm curious if there is any work on a plugin to digest pst files.  I'm often
> getting hit with eDiscovery requests to search multiple PST files for a
> series of key words.  Libpff has a few tools that can work with a pst to a
> degree but it would be very nice to be able to use them with Autopsy's
> workflow.
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] Autopsy 3.08 - Excel timeline

[Alex <ix...@gm...>]

Alex <ix...@gm...> wrote:
>Just tried the HTML report. Same behaviour.
>
>-A
>
>Brian Carrier <ca...@sl...> wrote:
>>Does the HTML report work OK?    The Excel report and HTML report
>share
>>the same backend code, but one outputs in Excel and the other in HTML.
>
>>
>>On Oct 25, 2013, at 8:28 AM, Alex <ix...@gm...> wrote:
>>
>>> Hi
>>> 
>>> Generating a bodyfile appears to work as expected, but Excel file
>>generation hangs at "now processing Web cookies", at which point the
>>CPU goes idle and the machine just waits there (I gave it 8 hours
>>overnight).
>>> 
>>> 64-bit version on Windows 7
>>> 
>>> How could I troubleshoot this? 
>>> 
>>> Thanks
>>> 
>>>
>>Alex------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>most from 
>>> the latest Intel processors and coprocessors. See abstracts and
>>register >
>>>
>>http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk_______________________________________________
>>> sleuthkit-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org

Any tips on troubleshooting this? Noone else seeing this behaviour?

Alex

Re: [sleuthkit-users] pst file digest

[Stefan K. <sk...@bf...>]

> The library is "mailbox."

Awesome, Alex, thanks for the swift reply.

Cheers,

	Stefan.

-- 
Stefan Kelm                   <sk...@bf...>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstrasse 100             Tel: +49-721-96201-1
D-76133 Karlsruhe             Fax: +49-721-96201-99

Re: [sleuthkit-users] pst file digest

[Alex N. <ajn...@cs...>]

Hi Stefan,

The library is "mailbox."

http://docs.python.org/3.3/library/mailbox.html

I've used it on .mbox, .pst, and individual email files (the last, as found
in Apple Mail).

It might have problems with non-ASCII personal names in email headers.  The
RFCs I've seen say that names, if used, should be ASCII (e.g. "My Name <
my...@me...>") (822, 2822), but I've seen a drive with some Israeli
correspondence cause this library to fail because the name was in Hebrew.
 Maybe that has been fixed in the last year.

--Alex




On Fri, Nov 8, 2013 at 3:14 AM, Stefan Kelm <sk...@bf...> wrote:

> Hi Alex,
>
> > If you're able to program a bit, Python has a PST library that works
> > decently, after you extract the files with Autopsy.
>
> What's the name of that library, please?
>
> Cheers,
>
>         Stefan.
>
> --
> Stefan Kelm                   <sk...@bf...>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstrasse 100             Tel: +49-721-96201-1
> D-76133 Karlsruhe             Fax: +49-721-96201-99
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] pst file digest

[MATT P. <mat...@ad...>]

Thank you guys for your suggestions.  I would really find a native parser useful.  With the ability to import logical files into a case now half the workflow is there.   Being able to parse a number of pst's against a keyword list is what I need to do.  Python isn't my strength so I'll have to ask around.  There are several commercial products but they are both expensive and incomplete in their features.  The report part is also a consideration. Just locating the relevant data would be useful.  Having a list of locations in a pst were relevant keywords exist would be great.  Being able to carve message files out intact and/or export messages as a pdf would be amazing.

>>Hi Matt - we are currently looking into pst parsing libraries and
>>hope to have something in the next couple of months to make the
>>Mbox parser a more generic email parser

That is good news.  I rely heavily on libpff for now, although I've not had any success in doing a complete examination without having to resort to native outlook and sectool to process p12/pfx certificates.  If someone can come up with an answer to that (or have I missed an existing one?), that would be most helpful.

Admittedly I don't spend enough time on PST testing, but since it's a big chunk of our casework, I'll need to start.

/*******************************************
Barry J. Grundy
Assistant Special Agent in Charge
Digital Forensic Support Group
Electronic Crimes and Intelligence Division
Treasury Inspector General for Tax Administration
(301) 210-8741 (w)
(202) 527-5778 (c)
Bar...@ti...<mailto:Bar...@ti...>
********************************************\

From: Jason Letourneau [mailto:jle...@ba...]
Sent: Thursday, November 07, 2013 8:14 PM
To: MATT PIERCE
Cc: sle...@li...<mailto:sle...@li...>
Subject: Re: [sleuthkit-users] pst file digest

Hi Matt - we are currently looking into pst parsing libraries and hope to have something in the next couple of months to make the Mbox parser a more generic email parser

Jason

On Thursday, November 7, 2013, MATT PIERCE wrote:
I'm curious if there is any work on a plugin to digest pst files.  I'm often getting hit with eDiscovery requests to search multiple PST files for a series of key words.  Libpff has a few tools that can work with a pst to a degree but it would be very nice to be able to use them with Autopsy's workflow.

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: [sleuthkit-users] pst file digest

[Grundy B. J T. <Bar...@ti...>]

>>Hi Matt - we are currently looking into pst parsing libraries and
>>hope to have something in the next couple of months to make the
>>Mbox parser a more generic email parser

That is good news.  I rely heavily on libpff for now, although I've not had any success in doing a complete examination without having to resort to native outlook and sectool to process p12/pfx certificates.  If someone can come up with an answer to that (or have I missed an existing one?), that would be most helpful.

Admittedly I don't spend enough time on PST testing, but since it's a big chunk of our casework, I'll need to start.

/*******************************************
Barry J. Grundy
Assistant Special Agent in Charge
Digital Forensic Support Group
Electronic Crimes and Intelligence Division
Treasury Inspector General for Tax Administration
(301) 210-8741 (w)
(202) 527-5778 (c)
Bar...@ti...
********************************************\

From: Jason Letourneau [mailto:jle...@ba...]
Sent: Thursday, November 07, 2013 8:14 PM
To: MATT PIERCE
Cc: sle...@li...
Subject: Re: [sleuthkit-users] pst file digest

Hi Matt - we are currently looking into pst parsing libraries and hope to have something in the next couple of months to make the Mbox parser a more generic email parser

Jason

On Thursday, November 7, 2013, MATT PIERCE wrote:
I'm curious if there is any work on a plugin to digest pst files.  I'm often getting hit with eDiscovery requests to search multiple PST files for a series of key words.  Libpff has a few tools that can work with a pst to a degree but it would be very nice to be able to use them with Autopsy's workflow.

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: [sleuthkit-users] pst file digest

[Stefan K. <sk...@bf...>]

Hi Alex,

> If you're able to program a bit, Python has a PST library that works
> decently, after you extract the files with Autopsy.

What's the name of that library, please?

Cheers,

	Stefan.

-- 
Stefan Kelm                   <sk...@bf...>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstrasse 100             Tel: +49-721-96201-1
D-76133 Karlsruhe             Fax: +49-721-96201-99

Re: [sleuthkit-users] pst file digest

[Alex N. <ajn...@cs...>]

If you're able to program a bit, Python has a PST library that works
decently, after you extract the files with Autopsy.

(This might re-spark a conversation from OSDFCon this week on how nice it'd
be if Python were supported in Autopsy. (This might be intentional.))

--Alex


On Thursday, November 7, 2013, MATT PIERCE wrote:

> I'm curious if there is any work on a plugin to digest pst files.  I'm
> often getting hit with eDiscovery requests to search multiple PST files for
> a series of key words.  Libpff has a few tools that can work with a pst to
> a degree but it would be very nice to be able to use them with Autopsy's
> workflow.
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] pst file digest

[Jason L. <jle...@ba...>]

Hi Matt - we are currently looking into pst parsing libraries and hope to
have something in the next couple of months to make the Mbox parser a more
generic email parser

Jason

On Thursday, November 7, 2013, MATT PIERCE wrote:

> I'm curious if there is any work on a plugin to digest pst files.  I'm
> often getting hit with eDiscovery requests to search multiple PST files for
> a series of key words.  Libpff has a few tools that can work with a pst to
> a degree but it would be very nice to be able to use them with Autopsy's
> workflow.
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

[sleuthkit-users] pst file digest

[MATT P. <mat...@ad...>]

I'm curious if there is any work on a plugin to digest pst files.  I'm often getting hit with eDiscovery requests to search multiple PST files for a series of key words.  Libpff has a few tools that can work with a pst to a degree but it would be very nice to be able to use them with Autopsy's workflow.

[sleuthkit-users] Autopsy: Can't search in unallocated space of a partition

[Dennis <in...@ba...>]

Dear all, 

I am currently giving autopsy a test ride on one of my test images. I
use this test image in some of my forensic classes but I ran into a
problem.

My Setup 
   Windows 8 64 Bit 
   Autopsy V 3.0.6 

Image Details: t
   320 GB EWF Image

Case Setup / Activated Ingest Modules
   Recent Activities
   Hash Lookup
   EXIF Image Parser 
   Keyword Search 

And of course the checkbox for "process unallocated space" was
activated. 
 	
My Scenario
I know that a HTML fragment is available in the unallocated space of one
partition. This HTML fragment contains the string "secret secret".
Therefore, I just ran a search for the string secret but the search did
not yield any results in the unallocated space. 

I double checked that the string was inside the unallocated space by
mounting the image via fuse (DFF) and running the command 
	string -f -t d * | grep secret 
inside the NTFS unallocated folder. This resulted in roughly 20 - 30
hits. 

Question
Is this a known bug? Is the search in the unallocated space not yet
supported? How can I investigate what is going wrong?

Kind regards
Dennis