sleuthkit-developers Mailing List for The Sleuth Kit (Page 14)
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(22) |
Feb
(39) |
Mar
(8) |
Apr
(17) |
May
(10) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(4) |
| 2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(9) |
Jul
(14) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
| 2009 |
Jan
(7) |
Feb
(10) |
Mar
(10) |
Apr
(19) |
May
(16) |
Jun
(3) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(16) |
Nov
(35) |
Dec
(30) |
| 2010 |
Jan
(4) |
Feb
(24) |
Mar
(25) |
Apr
(31) |
May
(11) |
Jun
(9) |
Jul
(11) |
Aug
(31) |
Sep
(11) |
Oct
(10) |
Nov
(15) |
Dec
(3) |
| 2011 |
Jan
(8) |
Feb
(17) |
Mar
(14) |
Apr
(2) |
May
(4) |
Jun
(4) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(8) |
Nov
(16) |
Dec
(1) |
| 2012 |
Jan
(9) |
Feb
(2) |
Mar
(3) |
Apr
(13) |
May
(10) |
Jun
(7) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(3) |
| 2013 |
Jan
(16) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(18) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
| 2015 |
Jan
(5) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(23) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: SourceForge.net <no...@so...> - 2011-12-07 17:58:50
|
Bugs item #3453765, was opened at 2011-12-07 09:58 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3453765&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: make tsk_fs_time_to_str buffer longer Initial Comment: Currently, tsk_fs_time_to_str requires that a 32-byte buffer (or greater) be passed in. This is true for most platforms, but it seems that Windows will make long versions of the timzeone (Eastern Standard) instead of (EST). So, the buffer size needs to be increased in all the places that call it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3453765&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-11-24 13:09:27
|
Bugs item #3441763, was opened at 2011-11-24 03:56 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441763&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: Error in verbose output Initial Comment: tsk3/fs/iso9660.c:2329 if (tsk_verbose) { tsk_fprintf(stderr, "iso9660_open img_info: %lu" " ftype: %" PRIu8 " test: %" PRIu8 "\n", (uintptr_t) img_info, ftype, test); } The %lu in this code should be %jd on Linux. Otherwise it prints an incorrect value on a 64-bit platform. ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2011-11-24 05:09 Message: sk3/fs/ntfs_dent.c:1001 rec_len = (uint32_t) (idxalloc_len - (uintptr_t) idxrec_p - (uintptr_t) idxalloc); if (tsk_verbose) tsk_fprintf(stderr, "ntfs_dir_open_meta: Processing final index record (len: %" PRIu32 ")\n", rec_len); calculation of rec_len seems to return a negative value ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-11-24 05:04 Message: tsk3/fs/ntfs_dent.c:456 "ntfs_proc_idxentry: Entry Details of %s: Str Len: %" PRIu16 " Len to end after current: %" PRIu64 " flags: %x\n", fs_name->name, tsk_getu16(fs->endian, a_idxe->strlen), (uint64_t) (endaddr_alloc - (uintptr_t) a_idxe - tsk_getu16(fs->endian, a_idxe->idxlen)), fs_name->flags); Please check the %" PRIu64 " value calculation it seems to turn negative on a 64-bit platform. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441763&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-11-24 13:04:54
|
Bugs item #3441763, was opened at 2011-11-24 03:56 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441763&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: Error in verbose output Initial Comment: tsk3/fs/iso9660.c:2329 if (tsk_verbose) { tsk_fprintf(stderr, "iso9660_open img_info: %lu" " ftype: %" PRIu8 " test: %" PRIu8 "\n", (uintptr_t) img_info, ftype, test); } The %lu in this code should be %jd on Linux. Otherwise it prints an incorrect value on a 64-bit platform. ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2011-11-24 05:04 Message: tsk3/fs/ntfs_dent.c:456 "ntfs_proc_idxentry: Entry Details of %s: Str Len: %" PRIu16 " Len to end after current: %" PRIu64 " flags: %x\n", fs_name->name, tsk_getu16(fs->endian, a_idxe->strlen), (uint64_t) (endaddr_alloc - (uintptr_t) a_idxe - tsk_getu16(fs->endian, a_idxe->idxlen)), fs_name->flags); Please check the %" PRIu64 " value calculation it seems to turn negative on a 64-bit platform. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441763&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-11-24 11:56:49
|
Bugs item #3441763, was opened at 2011-11-24 03:56 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441763&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: Error in verbose output Initial Comment: tsk3/fs/iso9660.c:2329 if (tsk_verbose) { tsk_fprintf(stderr, "iso9660_open img_info: %lu" " ftype: %" PRIu8 " test: %" PRIu8 "\n", (uintptr_t) img_info, ftype, test); } The %lu in this code should be %jd on Linux. Otherwise it prints an incorrect value on a 64-bit platform. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441763&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-11-24 11:54:38
|
Bugs item #3441760, was opened at 2011-11-24 03:45 Message generated for change (Settings changed) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441760&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) >Summary: Building TSK 3.2.3 without g++ Initial Comment: Configure does not complain if g++ is missing. Ubuntu 10.04.3 LTS /usr/bin/ld: auto/.libs/libtskauto.a(auto.o): relocation R_X86_64_32S against `vtable for TskAuto' can not be used when making a shared object; recompile with -fPIC auto/.libs/libtskauto.a(auto.o): could not read symbols: Bad value ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-11-24 03:54 Message: The latter one seems to be introduced by an instable build tree caused by running make without g++. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441760&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-11-24 11:54:09
|
Bugs item #3441760, was opened at 2011-11-24 03:45 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441760&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple issues building TSK 3.2.3 Initial Comment: Configure does not complain if g++ is missing. Ubuntu 10.04.3 LTS /usr/bin/ld: auto/.libs/libtskauto.a(auto.o): relocation R_X86_64_32S against `vtable for TskAuto' can not be used when making a shared object; recompile with -fPIC auto/.libs/libtskauto.a(auto.o): could not read symbols: Bad value ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2011-11-24 03:54 Message: The latter one seems to be introduced by an instable build tree caused by running make without g++. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441760&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-11-24 11:45:11
|
Bugs item #3441760, was opened at 2011-11-24 03:45 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441760&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple issues building TSK 3.2.3 Initial Comment: Configure does not complain if g++ is missing. Ubuntu 10.04.3 LTS /usr/bin/ld: auto/.libs/libtskauto.a(auto.o): relocation R_X86_64_32S against `vtable for TskAuto' can not be used when making a shared object; recompile with -fPIC auto/.libs/libtskauto.a(auto.o): could not read symbols: Bad value ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441760&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-11-23 15:15:13
|
Bugs item #3441497, was opened at 2011-11-23 07:15 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441497&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: Device access broken on WINAPI? Initial Comment: Neither with the pre-compiled and a cygwin compiled tsk 3.2.3 am I able to access devices on windows. Tried multiple devices. Platform is 64-bit Win7. Error of pre-compiled version: A device attached to the system is not functioning. In the Cygwin version the device size detection seems to fail. Hard-coding the size in the function in img/raw.c provides a work-around for the moment. I'll see what I can find and add it to this tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441497&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2011-11-17 20:46:59
|
Over the years, I have heard from many folks who say they are going to start working on Ext4 support and in most cases I don't hear from them again. Likely because adding a file system is a big undertaking. I know of the partial patch for Ext4 (http://www.williballenthin.com/ext4/index.html), but it still seems to need some attention to have all of the basics covered. Github allows easier group coding and integration. If there is interest, we can make a new project/branch on github dedicated to this effort and those that are interested in working on it can self organize and figure out who is working on what. Github makes it easier to merge in the changes that occur on the master sleuthkit branch. If you are interested in joining such a group, e-mail me off list and we can go from there. thanks, brian |
|
From: SourceForge.net <no...@so...> - 2011-11-16 17:51:52
|
Bugs item #3438515, was opened at 2011-11-15 13:50 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3438515&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: SegFault in v3.2.3 addressing image segments with wiild card Initial Comment: J. Metz libewf2 patch applied: $ mmls -V image_118871.E?? The Sleuth Kit ver 3.2.3 $ mmls image_118871.E?? Segmentation fault $ mmls -v image_118871.E?? tsk_img_open: Type: 0 NumImg: 10 Img1: image_118871.E01 Error opening AFF/AFD/AFM file aff_open: Success Segmentation fault $ mmls -v image_118871.E01 tsk_img_open: Type: 0 NumImg: 1 Img1: image_118871.E01 Error opening AFF/AFD/AFM file aff_open: Success tsk_img_findFiles: image_118871.E01 found tsk_img_findFiles: image_118871.E02 found tsk_img_findFiles: image_118871.E03 found tsk_img_findFiles: image_118871.E04 found tsk_img_findFiles: image_118871.E05 found tsk_img_findFiles: image_118871.E06 found tsk_img_findFiles: image_118871.E07 found tsk_img_findFiles: image_118871.E08 found tsk_img_findFiles: image_118871.E09 found tsk_img_findFiles: image_118871.E10 found tsk_img_findFiles: 10 total images found tsk_img_findFiles: image_118871.E01 found tsk_img_findFiles: image_118871.E02 found tsk_img_findFiles: image_118871.E03 found tsk_img_findFiles: image_118871.E04 found tsk_img_findFiles: image_118871.E05 found tsk_img_findFiles: image_118871.E06 found tsk_img_findFiles: image_118871.E07 found tsk_img_findFiles: image_118871.E08 found tsk_img_findFiles: image_118871.E09 found tsk_img_findFiles: image_118871.E10 found dos_load_prim: Table Sector: 0 ewf_read: byte offset: 0 len: 65536 dos_load_prim_table: Testing FAT/NTFS conditions load_pri:0:0 Start: 2048 Size: 29360128 Type: 39 load_pri:0:1 Start: 29362176 Size: 204800 Type: 7 load_pri:0:2 Start: 29566976 Size: 595572736 Type: 7 load_pri:0:3 Start: 0 Size: 0 Type: 0 bsd_load_table: Table Sector: 1 gpt_load_table: Sector: 0 sun_load_table: Trying sector: 0 sun_load_table: Trying sector: 1 mac_load_table: Sector: 1 mac_load: Missing initial magic value mac_open: Trying 4096-byte sector size instead of 512-byte mac_load_table: Sector: 1 mac_load: Missing initial magic value DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000002047 0000002048 Unallocated 02: 00:00 0000002048 0029362175 0029360128 Unknown Type (0x27) 03: 00:01 0029362176 0029566975 0000204800 NTFS (0x07) 04: 00:02 0029566976 0625139711 0595572736 NTFS (0x07) 05: ----- 0625139712 0625142447 0000002736 Unallocated ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-11-16 09:51 Message: It's a bug in my patch, I've updated the version on the libewf site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3438515&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-11-15 21:50:16
|
Bugs item #3438515, was opened at 2011-11-15 13:50 Message generated for change (Tracker Item Submitted) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3438515&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: SegFault in v3.2.3 addressing image segments with wiild card Initial Comment: J. Metz libewf2 patch applied: $ mmls -V image_118871.E?? The Sleuth Kit ver 3.2.3 $ mmls image_118871.E?? Segmentation fault $ mmls -v image_118871.E?? tsk_img_open: Type: 0 NumImg: 10 Img1: image_118871.E01 Error opening AFF/AFD/AFM file aff_open: Success Segmentation fault $ mmls -v image_118871.E01 tsk_img_open: Type: 0 NumImg: 1 Img1: image_118871.E01 Error opening AFF/AFD/AFM file aff_open: Success tsk_img_findFiles: image_118871.E01 found tsk_img_findFiles: image_118871.E02 found tsk_img_findFiles: image_118871.E03 found tsk_img_findFiles: image_118871.E04 found tsk_img_findFiles: image_118871.E05 found tsk_img_findFiles: image_118871.E06 found tsk_img_findFiles: image_118871.E07 found tsk_img_findFiles: image_118871.E08 found tsk_img_findFiles: image_118871.E09 found tsk_img_findFiles: image_118871.E10 found tsk_img_findFiles: 10 total images found tsk_img_findFiles: image_118871.E01 found tsk_img_findFiles: image_118871.E02 found tsk_img_findFiles: image_118871.E03 found tsk_img_findFiles: image_118871.E04 found tsk_img_findFiles: image_118871.E05 found tsk_img_findFiles: image_118871.E06 found tsk_img_findFiles: image_118871.E07 found tsk_img_findFiles: image_118871.E08 found tsk_img_findFiles: image_118871.E09 found tsk_img_findFiles: image_118871.E10 found dos_load_prim: Table Sector: 0 ewf_read: byte offset: 0 len: 65536 dos_load_prim_table: Testing FAT/NTFS conditions load_pri:0:0 Start: 2048 Size: 29360128 Type: 39 load_pri:0:1 Start: 29362176 Size: 204800 Type: 7 load_pri:0:2 Start: 29566976 Size: 595572736 Type: 7 load_pri:0:3 Start: 0 Size: 0 Type: 0 bsd_load_table: Table Sector: 1 gpt_load_table: Sector: 0 sun_load_table: Trying sector: 0 sun_load_table: Trying sector: 1 mac_load_table: Sector: 1 mac_load: Missing initial magic value mac_open: Trying 4096-byte sector size instead of 512-byte mac_load_table: Sector: 1 mac_load: Missing initial magic value DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000002047 0000002048 Unallocated 02: 00:00 0000002048 0029362175 0029360128 Unknown Type (0x27) 03: 00:01 0029362176 0029566975 0000204800 NTFS (0x07) 04: 00:02 0029566976 0625139711 0595572736 NTFS (0x07) 05: ----- 0625139712 0625142447 0000002736 Unallocated ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3438515&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2011-11-15 15:09:59
|
For those who want to start playing around with Autopsy 3, it is on github: https://github.com/sleuthkit/autopsy The docs on the wiki have also been updated. http://wiki.sleuthkit.org/index.php?title=Autopsy_Developer%27s_Guide The Design doc provides a very brief skeleton view of the code with links to Javadocs for the actual code: http://wiki.sleuthkit.org/index.php?title=Autopsy_3_Design thanks, brian |
|
From: SourceForge.net <no...@so...> - 2011-11-11 15:46:26
|
Feature Requests item #3436562, was opened at 2011-11-11 07:46 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3436562&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Auto Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: New DB to support resident files Initial Comment: It would be nice if the new DB schema would allow queries to map resident files to their file. fs_file_layout is byte-oriented, so this could work if TSK provided the specific byte-offset of resident files (a request that has come up a few times before). The challenge is that the same byte sequence would be in fs_file_layout twice. Once for $MFT and another for the resident file... This could be confusing. But, it is also possible for there to be multiple overlapping carved files, so perhaps there isn't a requirement that fs_file_layout have only one entry for a given byte sequence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3436562&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2011-11-11 15:42:40
|
Right. Resident files don't have entries in fs_Blocks because they don't have blocks allocated to them. The only way to really map it in the current version is to get the offset in the MFT and figure out the MFT entry by dividing the offset by 1024. You can them map the MFT entry to a file name... The next release of loaddb uses an entirely new schema and the fs_blocks table is gone. it has been replaced by a structure that maps byte runs to a file (to allow for carved files outside of a file system). Currently, we don't map resident files into this though because the files don't have data explicitly allocated to them. I'll make a tracker story though to see if there is a clean solution to this problem. thanks, brian On Nov 11, 2011, at 1:25 AM, Andrew Case wrote: > Hello, > > I was writing as I am attempting to write a script that can take an offset in a partition, such as the location of a file found by Scalpel, and then automatically determine which file in the filesystem it belongs to (if any). > > My algorithm is to get the partition offset, divide by the block size (to get the block number), and use this as the starting block in tsk_fs_blocks, and then use that information to query in tsk_fs_files.This works very well except for the case of small (resident) files that are stored in the MFT. For these files, the resulting report, which lists the file names, says that the hit was found in the MFT instead of the actual file. I looked into the issue and it seems that no tsk_fs_blocks row is created for resident files. > > So I am kind of stuck at this point.... I don't see a way using only the information in tsk_loaddb to handle this situation, and would greatly appreciate any pointers... > > Thanks, > Andrew > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
|
From: Andrew C. <at...@gm...> - 2011-11-11 06:25:12
|
Hello, I was writing as I am attempting to write a script that can take an offset in a partition, such as the location of a file found by Scalpel, and then automatically determine which file in the filesystem it belongs to (if any). My algorithm is to get the partition offset, divide by the block size (to get the block number), and use this as the starting block in tsk_fs_blocks, and then use that information to query in tsk_fs_files.This works very well except for the case of small (resident) files that are stored in the MFT. For these files, the resulting report, which lists the file names, says that the hit was found in the MFT instead of the actual file. I looked into the issue and it seems that no tsk_fs_blocks row is created for resident files. So I am kind of stuck at this point.... I don't see a way using only the information in tsk_loaddb to handle this situation, and would greatly appreciate any pointers... Thanks, Andrew |
|
From: SourceForge.net <no...@so...> - 2011-11-08 23:29:48
|
Bugs item #3435161, was opened at 2011-11-08 15:29 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3435161&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Not consistent OrphanFiles and attributes Initial Comment: In FAT, $OrphanFiles has a single attribute with size 0. In NTFS, it has no attributes and therefore processAttributes() in TskAuto does nothing with it (meaning it doesn't get added to the DB in AutoDB). This should be consistent. Not sure if the answer is to always have an empty attribute or make sure that we properly document that there could be no attribute (and modify processAttributes() accordingly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3435161&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-11-08 22:37:32
|
Bugs item #3435140, was opened at 2011-11-08 14:37 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3435140&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: NTFS istat & Orphan Files Initial Comment: NTFS istat does not work when run on an OrphanFile folder. This call: if (ntfs_dinode_lookup(ntfs, (char *) mft, inum)) { free(mft); return 1; } Fails for the virtual folder. It should continue on and skip any parts that require mft access. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3435140&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-10-25 16:52:12
|
Bugs item #3382081, was opened at 2011-07-29 13:45 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3382081&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk 3.2.2 missing libstdc++ in static build Initial Comment: The static build of the sleuthkit 3.2.2 is missing the C++ standard library. Bindings that use the static library fail to find __cxa_pure_virtual A work around is run: LDFLAGS=-lstdc++ ./configure LDFLAGS=-lstdc++ make ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2011-10-25 18:52 Message: Proposed fix add the following statement to configure.ac: AC_CHECK_LIB(stdc++, main) ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-10-25 17:49 Message: The same issue shows up when building a deb package, in this case as warnings. dpkg-shlibdeps: warning: symbol __cxa_pure_virtual used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol __gxx_personality_v0 used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol _ZTVN10__cxxabiv120__si_class_type_infoE used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol _ZdlPv used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol _ZTVN10__cxxabiv117__class_type_infoE used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. ---------------------------------------------------------------------- Comment By: Michael Cohen (scudette) Date: 2011-09-20 15:04 Message: We have fixed this issue in pytsk by explicitly linking in libstdc++ as a workaround but this should really not be needed because pytsk itself does not require libstdc++. It would be cleaner to have tsk link it instead. ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-09-20 07:05 Message: The issue surfaced when building a static version of pytsk on Ubuntu. http://code.google.com/p/grr/wiki/ServerInstallation A straightforward autoconf/make solution would be to detect and include the library. An alternative solution could be to implement your own __cxa_pure_virtual function From: http://stackoverflow.com/questions/920500/what-is-the-purpose-of-cxa-pure-virtual The __cxa_pure_virtual function is an error handler that is invoked when a pure virtual function is called. If you are writing a C++ application that has pure virtual functions you must supply your own __cxa_pure_virtual error handler function. For example: extern "C" void __cxa_pure_virtual() { while (1); } ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2011-09-20 05:14 Message: Is there a autoconf/automake solution for this? I haven't experienced this problem yet when using the library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3382081&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-10-25 15:49:17
|
Bugs item #3382081, was opened at 2011-07-29 13:45 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3382081&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk 3.2.2 missing libstdc++ in static build Initial Comment: The static build of the sleuthkit 3.2.2 is missing the C++ standard library. Bindings that use the static library fail to find __cxa_pure_virtual A work around is run: LDFLAGS=-lstdc++ ./configure LDFLAGS=-lstdc++ make ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2011-10-25 17:49 Message: The same issue shows up when building a deb package, in this case as warnings. dpkg-shlibdeps: warning: symbol __cxa_pure_virtual used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol __gxx_personality_v0 used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol _ZTVN10__cxxabiv120__si_class_type_infoE used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol _ZdlPv used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol _ZTVN10__cxxabiv117__class_type_infoE used by debian/sleuthkit/usr/lib/libtsk3.so.3.4.0 found in none of the libraries. ---------------------------------------------------------------------- Comment By: Michael Cohen (scudette) Date: 2011-09-20 15:04 Message: We have fixed this issue in pytsk by explicitly linking in libstdc++ as a workaround but this should really not be needed because pytsk itself does not require libstdc++. It would be cleaner to have tsk link it instead. ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-09-20 07:05 Message: The issue surfaced when building a static version of pytsk on Ubuntu. http://code.google.com/p/grr/wiki/ServerInstallation A straightforward autoconf/make solution would be to detect and include the library. An alternative solution could be to implement your own __cxa_pure_virtual function From: http://stackoverflow.com/questions/920500/what-is-the-purpose-of-cxa-pure-virtual The __cxa_pure_virtual function is an error handler that is invoked when a pure virtual function is called. If you are writing a C++ application that has pure virtual functions you must supply your own __cxa_pure_virtual error handler function. For example: extern "C" void __cxa_pure_virtual() { while (1); } ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2011-09-20 05:14 Message: Is there a autoconf/automake solution for this? I haven't experienced this problem yet when using the library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3382081&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-10-24 07:55:56
|
Bugs item #3427689, was opened at 2011-10-24 09:55 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3427689&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Image File Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk 3.2.3 memory leak on error in ewf.c Initial Comment: There seems to be memory leakage in the recent changes to ewf.c in the error path. See the TSK 3.2.3 patch on: https://sourceforge.net/projects/libewf/files/patches%20for%203rd%20party%20software/sleuthkit/ For a fix. Note that this patch includes the libewf v2 API support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3427689&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-10-20 17:02:32
|
Bugs item #3425301, was opened at 2011-10-18 09:29 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3425301&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ettore (santakruz) Assigned to: Brian Carrier (carrier) Summary: Autopsy Initial Comment: Autopsy ver. 3.0 Beta hangs and close itself when it starts to process image and generates database. No message was been showed, just the files 'hs_err_pid7692.log' you can find in attachment. Win7 Enterprise x64 , JRE 1.6.0.27, ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-10-20 12:02 Message: Does this happen on all images, or just certain ones? We're going to add a feature to the next version to enable verbose logging to get more details on what was going on when it crashed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3425301&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-10-20 15:51:45
|
Bugs item #3425301, was opened at 2011-10-18 16:29 Message generated for change (Settings changed) made by santakruz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3425301&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ettore (santakruz) >Assigned to: Brian Carrier (carrier) Summary: Autopsy Initial Comment: Autopsy ver. 3.0 Beta hangs and close itself when it starts to process image and generates database. No message was been showed, just the files 'hs_err_pid7692.log' you can find in attachment. Win7 Enterprise x64 , JRE 1.6.0.27, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3425301&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-10-18 14:29:34
|
Bugs item #3425301, was opened at 2011-10-18 16:29 Message generated for change (Tracker Item Submitted) made by santakruz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3425301&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ettore (santakruz) Assigned to: Nobody/Anonymous (nobody) Summary: Autopsy Initial Comment: Autopsy ver. 3.0 Beta hangs and close itself when it starts to process image and generates database. No message was been showed, just the files 'hs_err_pid7692.log' you can find in attachment. Win7 Enterprise x64 , JRE 1.6.0.27, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3425301&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2011-10-12 21:06:56
|
FYI: I made the transition today for the codebase to be hosted on github instead of a private subversion repo. For the git users out there, clone away. https://github.com/sleuthkit/sleuthkit |
|
From: SourceForge.net <no...@so...> - 2011-10-10 19:04:41
|
Feature Requests item #3154664, was opened at 2011-01-10 23:27 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3154664&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Image Layer Group: None Status: Open Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: libewf version 2 support Initial Comment: Although libewf version 2 is still in alpha version. With this tracker the changes necessary for version 2 API support with backwards compatibility for current stable of libewf. The patch only changes tsk3/img/ewf.[ch] not the configure.ac detection of libewf. ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2011-10-10 21:04 Message: related trackers: 3367368, 2919095 Update for TSK 3.2.3 https://sourceforge.net/projects/libewf/files/patches%20for%203rd%20party%20software/sleuthkit/ Also know that there is a bug in TSK 3.2.3 ewf.c see the mail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3154664&group_id=55685 |
1 message has been excluded from this view by a project administrator.
