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

Re: [sleuthkit-users] statically compiling sleuthkit

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

Hmm, seems like the feature expansion over the years has made this less possible. 
- libz is needed by HFS.  You can probably use without-zlib to try to remove that dependency. 
- libdl is needed by sqlite (which is part of the library that used to be entirely static).
- libpthread is needed for lock protection.
- ...

Someone will need to spend some time isolating these types of features if we want to get back back to a purely static version...





On Dec 20, 2013, at 1:56 AM, Kalin KOZHUHAROV <me....@gm...> wrote:

> Hello,
> 
> I remember being able to do this a long time ago, but apparently not any more...
> 
> Any hints on how to compile it statically, so that I can just send fls
> or some other binary to a remote machine?
> 
> # git clone https://github.com/sleuthkit/sleuthkit
> # ./bootstrap
> # ./configure --prefix=/tmp/test --enable-static --disable-shared
> --disable-java --without-afflib --without-libewf
> # make -j4
> # make install
> 
> However
> 
> # file /tmp/test/bin/fls
> /tmp/test/bin/fls: ELF 32-bit LSB executable, Intel 80386, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
> not stripped
> # ldd /tmp/test/bin/fls
>    linux-gate.so.1 (0xf7732000)
>    libz.so.1 => /lib/libz.so.1 (0xf7714000)
>    libdl.so.2 => /lib/libdl.so.2 (0xf7710000)
>    libstdc++.so.6 =>
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.3/libstdc++.so.6 (0xf7624000)
>    libm.so.6 => /lib/libm.so.6 (0xf75fd000)
>    libgcc_s.so.1 =>
> /usr/lib/gcc/i686-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0xf75e0000)
>    libpthread.so.0 => /lib/libpthread.so.0 (0xf75c6000)
>    libc.so.6 => /lib/libc.so.6 (0xf743c000)
>    /lib/ld-linux.so.2 (0xf7733000)
> 
> Alternatively, is there a public DL link with statically linked tools?
> 
> Cheers,
> Kalin.
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] statically compiling sleuthkit

[Kalin K. <me....@gm...>]

Hello,

I remember being able to do this a long time ago, but apparently not any more...

Any hints on how to compile it statically, so that I can just send fls
or some other binary to a remote machine?

# git clone https://github.com/sleuthkit/sleuthkit
# ./bootstrap
# ./configure --prefix=/tmp/test --enable-static --disable-shared
--disable-java --without-afflib --without-libewf
# make -j4
# make install

However

# file /tmp/test/bin/fls
/tmp/test/bin/fls: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
not stripped
# ldd /tmp/test/bin/fls
    linux-gate.so.1 (0xf7732000)
    libz.so.1 => /lib/libz.so.1 (0xf7714000)
    libdl.so.2 => /lib/libdl.so.2 (0xf7710000)
    libstdc++.so.6 =>
/usr/lib/gcc/i686-pc-linux-gnu/4.7.3/libstdc++.so.6 (0xf7624000)
    libm.so.6 => /lib/libm.so.6 (0xf75fd000)
    libgcc_s.so.1 =>
/usr/lib/gcc/i686-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0xf75e0000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xf75c6000)
    libc.so.6 => /lib/libc.so.6 (0xf743c000)
    /lib/ld-linux.so.2 (0xf7733000)

Alternatively, is there a public DL link with statically linked tools?

Cheers,
Kalin.

[sleuthkit-users] viewer for nsf databases

[maría e. d. <dar...@gm...>]

Hello;

I need to check a .nsf database from lotus mail without a Lotus client
installed, somebody knows any tool or viewer for this type of file, mainly
in open source,

Thanks in advance.

-- 
Prof. Ing. María Elena Darahuge
M P Copitec 5100

[sleuthkit-users] Autopsy 3.0.8 : Keyword Research ineffective

[Philippe J. <pjo...@pa...>]

Hello,

I have generated a DD file on a Ubuntu 10.04 VM. (dd if=/dev/sdb1 of=/usr3/essai3.dd)
/dev/sdb1 is EXT3.

I get 1G file. Then I transfer (Binary copy) it to my Windows XP(SP3) disk.

When Autopsy ingest this file, there is no Keyword hits detected although :

- I KNOW there is a witness non-deleted file which contains a keyword I record in Autopsy Keyword Hits.
- I could list and display my witness file on Autopsy Data Sources tree

Is somebody known this problem ?

Many thanks
Regards

Philippe JOURDIN

Re: [sleuthkit-users] TSK_FS_ATTR_INUSE

[Jon S. <jo...@li...>]

So, to confirm my understanding, such attributes are "sleuthkit
slack", and not actual unallocated/trace attributes, and can be
ignored entirely?

thanks,

Jon


On Thu, Dec 12, 2013 at 5:33 PM, Brian Carrier <ca...@sl...> wrote:
> That means the corresponding TSK_FS_ATTR structure has valid data in it.  The TSK_FS_META and TSK_FS_ATTR structures are re-used in some contexts instead of freeing and reallocating memory.   If that flag isn't set, then don't use the data in the structure.
>
>
>
>
> On Dec 12, 2013, at 4:46 PM, Jon Stewart <jo...@li...> wrote:
>
>> Hello,
>>
>> One of the TSK_FS_ATTR_FLAG_ENUM values is TSK_FS_ATTR_INUSE, and the
>> comment for the value is "data structure is in use". Can anyone on the
>> list elaborate on this value's meaning? When is it not set on an
>> attribute?
>>
>> Thanks!
>>
>> Jon
>> --
>> Jon Stewart, Principal
>> (646) 719-0317 | jo...@li... | Arlington, VA
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>



-- 
Jon Stewart, Principal
(646) 719-0317 | jo...@li... | Arlington, VA

Re: [sleuthkit-users] TSK_VS_PART_INFO slot_num & table_num questions

[Jon S. <jo...@li...>]

Gotcha'. That makes sense, thank you for clarifying.

Both table_num and slot_num are -1 for the virtual "unallocated"
volumes. The addr field seems to be strictly increasing across all
real and virtual partitions alike.


Jon


On Thu, Dec 12, 2013 at 5:29 PM, Brian Carrier <ca...@sl...> wrote:
> Hey Jon,
>
> Disks formatted with DOS partitions can have multiple tables.  There is the primary tables and then extended tables.  The table_num increments for each of those extended tables. Other more sane partitioning systems will only have one table.
>
> Slot number is the entry in the table.   I'd need to review the code for exactly when -1 comes up.  When do you see it?
>
>
>
> On Dec 11, 2013, at 3:06 PM, Jon Stewart <jo...@li...> wrote:
>
>> Hello,
>>
>> In TSK_VS_PART_INFO, what is the difference between slot_num and
>> table_num (or is there none)? Under what conditions could either of
>> these values be equal to -1?
>>
>> thanks
>>
>> Jon
>> --
>> Jon Stewart, Principal
>> (646) 719-0317 | jo...@li... | Arlington, VA
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>



-- 
Jon Stewart, Principal
(646) 719-0317 | jo...@li... | Arlington, VA

Re: [sleuthkit-users] TSK_FS_ATTR_INUSE

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

That means the corresponding TSK_FS_ATTR structure has valid data in it.  The TSK_FS_META and TSK_FS_ATTR structures are re-used in some contexts instead of freeing and reallocating memory.   If that flag isn't set, then don't use the data in the structure.




On Dec 12, 2013, at 4:46 PM, Jon Stewart <jo...@li...> wrote:

> Hello,
> 
> One of the TSK_FS_ATTR_FLAG_ENUM values is TSK_FS_ATTR_INUSE, and the
> comment for the value is "data structure is in use". Can anyone on the
> list elaborate on this value's meaning? When is it not set on an
> attribute?
> 
> Thanks!
> 
> Jon
> -- 
> Jon Stewart, Principal
> (646) 719-0317 | jo...@li... | Arlington, VA
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] TSK_VS_PART_INFO slot_num & table_num questions

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

Hey Jon,

Disks formatted with DOS partitions can have multiple tables.  There is the primary tables and then extended tables.  The table_num increments for each of those extended tables. Other more sane partitioning systems will only have one table. 

Slot number is the entry in the table.   I'd need to review the code for exactly when -1 comes up.  When do you see it?



On Dec 11, 2013, at 3:06 PM, Jon Stewart <jo...@li...> wrote:

> Hello,
> 
> In TSK_VS_PART_INFO, what is the difference between slot_num and
> table_num (or is there none)? Under what conditions could either of
> these values be equal to -1?
> 
> thanks
> 
> Jon
> -- 
> Jon Stewart, Principal
> (646) 719-0317 | jo...@li... | Arlington, VA
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] TSK_FS_ATTR_INUSE

[Jon S. <jo...@li...>]

Hello,

One of the TSK_FS_ATTR_FLAG_ENUM values is TSK_FS_ATTR_INUSE, and the
comment for the value is "data structure is in use". Can anyone on the
list elaborate on this value's meaning? When is it not set on an
attribute?

Thanks!

Jon
-- 
Jon Stewart, Principal
(646) 719-0317 | jo...@li... | Arlington, VA

[sleuthkit-users] TSK_VS_PART_INFO slot_num & table_num questions

[Jon S. <jo...@li...>]

Hello,

In TSK_VS_PART_INFO, what is the difference between slot_num and
table_num (or is there none)? Under what conditions could either of
these values be equal to -1?

thanks

Jon
-- 
Jon Stewart, Principal
(646) 719-0317 | jo...@li... | Arlington, VA

[sleuthkit-users] Any sleuth kit consultants out there?

[Carl Y. <ca...@yo...>]

I have a dd dump of a dual-boot filesystem (OSX-HFS/Win7-NTFS) that may or
may not contain an accidentally-deleted encrypted volume (a .dmg image)
containing 250 bitcoins on it. I have the password to the encrypted volume
if it is recoverable. I'm wondering if anyone out there has the expertise
or knows someone with the necessary expertise to help me try to recover
this. I'm an experienced software engineer but have little experience with
low-level filesystems and data recovery. If you have recommendations for
other forums I should hit up, please send those as well.

Thanks in advance for your time.

--Carl

Re: [sleuthkit-users] Autopsy Survey #2: Keyword Search Snippits

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

Brian,

> My vote is to keep snippets.  

I agree with John here.

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] Autopsy Survey: Directory Contents Count

[Simson G. <si...@ac...>]

Thanks for the explanation.

Given the additional information, I believe that you should leave it as it is. There are two directory entries, they are “.” and “..”.  If the two directory entries are “foo” and “bar” then that indicates that something is weird about the file system and further investigation is needed. 

Simson


On Dec 6, 2013, at 11:50 AM, Brian Carrier <ca...@sl...> wrote:

> Hi Simson,
> 
> There were actually two motivations for the question.    One was the presentation question (which has workarounds as you suggest) and the other was that this will add some addl. complexity / database calls to the code and we wanted to make sure people actually wanted it.  At a high-level, there is a bunch of lazy loading going on and the tree doesn't know details about the contents of the folder.  It needs to tell the table how many it will display and it would need to display a different number for itself.  Folders and file systems may have "." and ".." or not, so we can't blindly subtract 2.  So, we need to do an extra query for each folder to get the 2nd count.  Not rocket science, just added complexity and time that I'd prefer to avoid if people really don't care about the feature.
> 
> brian
> 
> 
> 
> On Dec 6, 2013, at 10:34 AM, Simson Garfinkel <si...@ac...> wrote:
> 
>> Since the results are not being parsed, we have some flexibility.
>> 
>> Have you thought about having them reported as “0 (+2)” and “3 (+2)” ? 
>> 
>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Brian Carrier [mailto:ca...@sl...]
>>>> Sent: Thursday, December 05, 2013 5:51 PM
>>>> To: sle...@li... users
>>>> Subject: [sleuthkit-users] Autopsy Survey: Directory Contents Count
>>>> 
>>>> Currently, the tree on the left of Autopsy shows the number of items in the
>>>> directory.  If there is a "." or ".." entry in the directory, they are included in
>>>> the count.  In our last training course, someone suggested that we should
>>>> not include those entries in the number so that a directory with no files or
>>>> sub-folders shows up as "0" in the tree except "2".   I'm a bit torn on this one
>>>> because they are in fact entries in the database and some could also get
>>>> confused that there are more rows in the table than what was reported.
>>>> 
>>>> Thoughts? Do you want the number in the tree to include the "." and ".." or
>>>> not?
>>>> 
>>>> brian
>>>> 
>>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK 
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
> 

Re: [sleuthkit-users] Autopsy Survey #2: Keyword Search Snippits

[Lehr, J. <jl...@sl...>]

My vote is to keep snippets.  It is essential in weeding out 'false' hits.  User option to disable is handy when snippets are not essential, but I would prefer to see them by default.

---------------------------------
John Lehr
Evidence Technician
San Luis Obispo Police Department
________________________________________
From: Brian Carrier [ca...@sl...]
Sent: Friday, December 06, 2013 8:56
To: sle...@li... users
Subject: [sleuthkit-users] Autopsy Survey #2: Keyword Search Snippits

Currently, Autopsy will display a "snippit" of each keyword search hit that shows the text around each keyword hit in the table view.  After debugging some reports that keyword searching was taking longer than expected, the snippit code is the culprit.   A search that has a couple of thousand hits can take 8 seconds from "enter" to a displayed list w/out snippits and 68 seconds with snippits.   Other users are seeing that their searches take minutes.

We're obviously looking to see if we can still incorporate snippits in a more efficient manner, but I wanted to throw the question out there if the snippits were essential or not.  If we can't find a more efficient method, do people want to wait a minute (or several) to have the snippits or would you rather that we disable that feature?  We can obviously make this a user option, but we'll still need to know the default value based on what most people want.

Votes?

thanks,
brian




------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

[sleuthkit-users] Autopsy Survey #2: Keyword Search Snippits

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

Currently, Autopsy will display a "snippit" of each keyword search hit that shows the text around each keyword hit in the table view.  After debugging some reports that keyword searching was taking longer than expected, the snippit code is the culprit.   A search that has a couple of thousand hits can take 8 seconds from "enter" to a displayed list w/out snippits and 68 seconds with snippits.   Other users are seeing that their searches take minutes. 

We're obviously looking to see if we can still incorporate snippits in a more efficient manner, but I wanted to throw the question out there if the snippits were essential or not.  If we can't find a more efficient method, do people want to wait a minute (or several) to have the snippits or would you rather that we disable that feature?  We can obviously make this a user option, but we'll still need to know the default value based on what most people want.

Votes?

thanks,
brian

Re: [sleuthkit-users] Autopsy Survey: Directory Contents Count

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

Hi Simson,

There were actually two motivations for the question.    One was the presentation question (which has workarounds as you suggest) and the other was that this will add some addl. complexity / database calls to the code and we wanted to make sure people actually wanted it.  At a high-level, there is a bunch of lazy loading going on and the tree doesn't know details about the contents of the folder.  It needs to tell the table how many it will display and it would need to display a different number for itself.  Folders and file systems may have "." and ".." or not, so we can't blindly subtract 2.  So, we need to do an extra query for each folder to get the 2nd count.  Not rocket science, just added complexity and time that I'd prefer to avoid if people really don't care about the feature.

brian



On Dec 6, 2013, at 10:34 AM, Simson Garfinkel <si...@ac...> wrote:

> Since the results are not being parsed, we have some flexibility.
> 
> Have you thought about having them reported as “0 (+2)” and “3 (+2)” ? 
> 
> 
>> 
>> 
>>> -----Original Message-----
>>> From: Brian Carrier [mailto:ca...@sl...]
>>> Sent: Thursday, December 05, 2013 5:51 PM
>>> To: sle...@li... users
>>> Subject: [sleuthkit-users] Autopsy Survey: Directory Contents Count
>>> 
>>> Currently, the tree on the left of Autopsy shows the number of items in the
>>> directory.  If there is a "." or ".." entry in the directory, they are included in
>>> the count.  In our last training course, someone suggested that we should
>>> not include those entries in the number so that a directory with no files or
>>> sub-folders shows up as "0" in the tree except "2".   I'm a bit torn on this one
>>> because they are in fact entries in the database and some could also get
>>> confused that there are more rows in the table than what was reported.
>>> 
>>> Thoughts? Do you want the number in the tree to include the "." and ".." or
>>> not?
>>> 
>>> brian
>>> 
>>> 
> 
> 
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK 
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy Survey: Directory Contents Count

[Simson G. <si...@ac...>]

Since the results are not being parsed, we have some flexibility.

Have you thought about having them reported as “0 (+2)” and “3 (+2)” ? 


> 
> 
>> -----Original Message-----
>> From: Brian Carrier [mailto:ca...@sl...]
>> Sent: Thursday, December 05, 2013 5:51 PM
>> To: sle...@li... users
>> Subject: [sleuthkit-users] Autopsy Survey: Directory Contents Count
>> 
>> Currently, the tree on the left of Autopsy shows the number of items in the
>> directory.  If there is a "." or ".." entry in the directory, they are included in
>> the count.  In our last training course, someone suggested that we should
>> not include those entries in the number so that a directory with no files or
>> sub-folders shows up as "0" in the tree except "2".   I'm a bit torn on this one
>> because they are in fact entries in the database and some could also get
>> confused that there are more rows in the table than what was reported.
>> 
>> Thoughts? Do you want the number in the tree to include the "." and ".." or
>> not?
>> 
>> brian
>> 
>> 

Re: [sleuthkit-users] Autopsy Survey: Directory Contents Count

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

I say leave them in (vote to include).  One of the original strengths of TSK/Autopsy is that the tools themselves simply show the data without showing/hiding things for sake of "false clarity".  If an examiner cannot look at the count and the contents of the directory and figure out the relationship...well then.

I still lament the inclusion of "ifind -p" functionality in "fls -d" for NTFS file systems for that very reason...  ;-)


/*******************************************
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: Thursday, December 05, 2013 5:51 PM
> To: sle...@li... users
> Subject: [sleuthkit-users] Autopsy Survey: Directory Contents Count
> 
> Currently, the tree on the left of Autopsy shows the number of items in the
> directory.  If there is a "." or ".." entry in the directory, they are included in
> the count.  In our last training course, someone suggested that we should
> not include those entries in the number so that a directory with no files or
> sub-folders shows up as "0" in the tree except "2".   I'm a bit torn on this one
> because they are in fact entries in the database and some could also get
> confused that there are more rows in the table than what was reported.
> 
> Thoughts? Do you want the number in the tree to include the "." and ".." or
> not?
> 
> brian
> 
> 
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.cl
> ktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy Survey: Directory Contents Count

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

I'm voting for including '.' and '..' in the count.  They are valid
entries and it can be left to the operator to explain them as Hoyt
said.

Derrick


On Thu, Dec 5, 2013 at 3:51 PM, Brian Carrier <ca...@sl...> wrote:
> Currently, the tree on the left of Autopsy shows the number of items in the directory.  If there is a "." or ".." entry in the directory, they are included in the count.  In our last training course, someone suggested that we should not include those entries in the number so that a directory with no files or sub-folders shows up as "0" in the tree except "2".   I'm a bit torn on this one because they are in fact entries in the database and some could also get confused that there are more rows in the table than what was reported.
>
> Thoughts? Do you want the number in the tree to include the "." and ".." or not?
>
> brian
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy Survey: Directory Contents Count

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

I'm okay with counting those. If I need to enumerate a directory with that
count, it's easy enough to subtract two and explain it with a statement in
the narrative report.


On Thu, Dec 5, 2013 at 4:51 PM, Brian Carrier <ca...@sl...> wrote:

> Currently, the tree on the left of Autopsy shows the number of items in
> the directory.  If there is a "." or ".." entry in the directory, they are
> included in the count.  In our last training course, someone suggested that
> we should not include those entries in the number so that a directory with
> no files or sub-folders shows up as "0" in the tree except "2".   I'm a bit
> torn on this one because they are in fact entries in the database and some
> could also get confused that there are more rows in the table than what was
> reported.
>
> Thoughts? Do you want the number in the tree to include the "." and ".."
> or not?
>
> brian
>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>



-- 
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.

[sleuthkit-users] Autopsy Survey: Directory Contents Count

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

Currently, the tree on the left of Autopsy shows the number of items in the directory.  If there is a "." or ".." entry in the directory, they are included in the count.  In our last training course, someone suggested that we should not include those entries in the number so that a directory with no files or sub-folders shows up as "0" in the tree except "2".   I'm a bit torn on this one because they are in fact entries in the database and some could also get confused that there are more rows in the table than what was reported.

Thoughts? Do you want the number in the tree to include the "." and ".." or not?  

brian

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

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

I can't take any credit. it was our one of our engineers, Jeffrey Wallace!



On Dec 5, 2013, at 5:23 AM, IX4 SVS <ix...@gm...> wrote:

> Fantastic - thanks for squashing this bug Brian!
> 
> Alex
> 
> 
> On Wed, Dec 4, 2013 at 10:57 PM, Brian Carrier <ca...@sl...> wrote:
> To circle back on this for others who are seeing this, the problem was introduced when we started to sort the table entries instead of random order.  The sorting was far from optimal. The fix has been checked in.  In our test image, the report now takes a couple of minutes when it used to never finish.
> 
> New release will be out next week.
> 
> 
> 
> On Nov 8, 2013, at 12:48 PM, Alex <ix...@gm...> wrote:
> 
> > 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
> > ------------------------------------------------------------------------------
> > 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
> 
> 
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK 
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&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

[IX4 S. <ix...@gm...>]

Fantastic - thanks for squashing this bug Brian!

Alex


On Wed, Dec 4, 2013 at 10:57 PM, Brian Carrier <ca...@sl...>wrote:

> To circle back on this for others who are seeing this, the problem was
> introduced when we started to sort the table entries instead of random
> order.  The sorting was far from optimal. The fix has been checked in.  In
> our test image, the report now takes a couple of minutes when it used to
> never finish.
>
> New release will be out next week.
>
>
>
> On Nov 8, 2013, at 12:48 PM, Alex <ix...@gm...> wrote:
>
> > 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
> >
> ------------------------------------------------------------------------------
> > 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

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

To circle back on this for others who are seeing this, the problem was introduced when we started to sort the table entries instead of random order.  The sorting was far from optimal. The fix has been checked in.  In our test image, the report now takes a couple of minutes when it used to never finish.

New release will be out next week.



On Nov 8, 2013, at 12:48 PM, Alex <ix...@gm...> wrote:

> 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
> ------------------------------------------------------------------------------
> 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] OSDFCon Recap and new modules

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

It's taken me a month to get this e-mail out. Sorry about that.  

I hope everyone enjoyed OSDFCon.  It keeps getting bigger and better each year.  This year we had over 400 people register and had lots of great talks. The slides are online:

    http://basistech.sites.hubspot.com/osdf-2013-slides

Basis Technology sponsored the first Autopsy module writing challenge. Congratulations to Willi Ballenthin for first prize for his registry viewer / ingest modules and to Petter Bjelland for his sdhash-based fuzzy hashing module. More details of the submissions are here:

    http://info.basistech.com/blog/bid/326560/OSDFCon-Autopsy-Module-Development-Contest-Results

We'll be doing this again for next year, so start developing.

We also had the first 2-day Autopsy training course and got a lot of positive feedback from it.  We'll be doing it again March 19 & 20 in Herndon, VA (near Dulles).

    http://www.basistech.com/digital-forensics/training/

thanks,
brian