sleuthkit-developers Mailing List for The Sleuth Kit (Page 19)
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...> - 2010-10-21 03:06:50
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&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: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-20 22:06 Message: Looked at the attribute list cluster and the IDX_ALLOC entries have an ID of 0. The BITMAP entries have an ID value set, but the DATA attributes don't either. But, DATA is defined in the base MFT entry. IDX_ALLOC aren't. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-20 21:55 Message: Note that Stefan Kelm reported this same error back in Sept. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-19 22:49 Message: The base MFT entry didn't have any details about the IDX_ALLOC entries. Requested the ATTRLIST block for more details to see if the id is in there. The verbose log shows that all entries in ATTRLIST have an ID of 0. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-21 02:55:46
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&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: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-20 21:55 Message: Note that Stefan Kelm reported this same error back in Sept. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-19 22:49 Message: The base MFT entry didn't have any details about the IDX_ALLOC entries. Requested the ATTRLIST block for more details to see if the id is in there. The verbose log shows that all entries in ATTRLIST have an ID of 0. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-20 03:49:52
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&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: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-19 22:49 Message: The base MFT entry didn't have any details about the IDX_ALLOC entries. Requested the ATTRLIST block for more details to see if the id is in there. The verbose log shows that all entries in ATTRLIST have an ID of 0. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-19 04:01:45
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&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: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-10-18 23:01 Message: Issue seems to be because the $Secure file is VERY fragmented and has lots of attrlists. There are two NTFS_ATYPE_IDXALLOC attributes and they both have an ID of 0 in the attrlist entries. So, we get a collision when the second one is added to the runs of the first one (because they have the same type and id). Sent a request to get MFT entry 9 to see if there is ID info that we are dropping.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-10-16 00:31:35
|
Bugs item #3088447, was opened at 2010-10-15 19:31 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&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: Brian Carrier (carrier) Summary: NTFS error about adding attribute sequence Initial Comment: Adam Dershowitz reported: General file system error (fs_attr_add_run: error adding additional run (9): No filler entry for 0. Final 176) ( - proc_attrseq: put run- proc_attrlist) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3088447&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-18 14:07:05
|
Bugs item #3070159, was opened at 2010-09-18 09:07 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3070159&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: Parse each directory block on its own Initial Comment: The current design of many of the file systems is that they load the directory and then parse it. It should be updated to parse each block as it is loaded. See issue 3052302 for example of how this can cause problems. In this case, the directory is not loaded because it requires too much memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3070159&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-18 14:05:16
|
Bugs item #3052302, was opened at 2010-08-24 08:56 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Rob J Meijer (ghede) Assigned to: Brian Carrier (carrier) Summary: segfault in UFS1 file system with corrupt inodes. Initial Comment: When processing inode 10240 of the ufs filesystem on the partition-3 image of the ntfs-auto-detect images in the dftt testset, a segfault occurs. Using fls the segfault can be reproduces: fls -f ufs 10-ntfs-part3.dd 10240 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-09-18 09:05 Message: Further investigation shows that the corrupt inode was created by the overlapping NTFS file system. The inode table for this cyl group starts in block 20120 and the UFS file system has a 2K block size. That maps to sector 80480. On the NTFS side of the house, that maps to the $UpCase (MFT entry 10) file. The crash occurred because of a little bug in tsk_malloc where it tried to memset even if the malloc failed... Fixed: Sending trunk/NEWS.txt Sending trunk/tsk3/base/mymalloc.c Transmitting file data .. Committed revision 256. ---------------------------------------------------------------------- Comment By: Rob J Meijer (ghede) Date: 2010-08-25 02:56 Message: The versions I've tested this bug exists are 3.1.1 and 3.1.3. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-24 20:44 Message: The problem actually appears to be with inode 5296. It has a massive size and what appears to be a lot of invalid metadata. perhaps this inode was not initialized. UFS2 has a feature of not initializing inodes, perhaps UFS1 does as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-18 13:29:53
|
Bugs item #3023481, was opened at 2010-06-30 13:35 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: icat exporting error, FAT Initial Comment: icat of any deleted file in a FAT16 partition only export 4kb of file. The Sleuth Kit ver 3.1.3b1 Ubuntu 10.04 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-09-18 08:29 Message: Closing this since the issue was likely that non-recoverable files were trying to be exported. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-13 11:18 Message: If you still have the image, can you run 'istat' on the files that are not recovering as much as you expect (and not 'fsstat' on the full file system). Because of the way that FAT deletes files, TSK can't always figure out where the file used to be. It tries to guess where it was, but if it can't figure it out then it will only recover the first cluster of the file (which is stored in the directory entry). ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-06-30 21:00 Message: Can you run 'istat' on the file? It will tell you if the file is recoverable or not. ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2010-06-30 17:52 Message: more information: in a fat32 file system with 32kb clusters, icat recovered 32kb of the deleted file. Thus, the bug appears to be that icat extracts only one cluster of deleted files from fat32. ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2010-06-30 16:05 Message: Correction, Fat32 Partition: FILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT32 OEM Name: MSDOS5.0 Volume ID: 0x861f3d71 Volume Label (Boot Sector): NO NAME Volume Label (Root Directory): CRUZER File System Type Label: FAT32 Next Free Sector (FS Info): 90352 Free Sector Count (FS Info): 5609032 Sectors before file system: 63 File System Layout (in sectors) Total Range: 0 - 15695441 * Reserved: 0 - 35 ** Boot Sector: 0 ** FS Info Sector: 1 ** Backup Boot Sector: 6 * FAT 0: 36 - 15333 * FAT 1: 15334 - 30631 * Data Area: 30632 - 15695441 ** Cluster Area: 30632 - 15695439 *** Root Directory: 30632 - 30639 ** Non-clustered: 15695440 - 15695441 METADATA INFORMATION -------------------------------------------- Range: 2 - 250636966 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 4096 Total Cluster Range: 2 - 1958102 Further study shows that regular files are extracted correctly with icat and the issue is limited to deleted files over 4.0 K. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-18 13:28:01
|
Bugs item #3052302, was opened at 2010-08-24 08:56 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&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: Rob J Meijer (ghede) Assigned to: Brian Carrier (carrier) >Summary: segfault in UFS1 file system with corrupt inodes. Initial Comment: When processing inode 10240 of the ufs filesystem on the partition-3 image of the ntfs-auto-detect images in the dftt testset, a segfault occurs. Using fls the segfault can be reproduces: fls -f ufs 10-ntfs-part3.dd 10240 ---------------------------------------------------------------------- Comment By: Rob J Meijer (ghede) Date: 2010-08-25 02:56 Message: The versions I've tested this bug exists are 3.1.1 and 3.1.3. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-24 20:44 Message: The problem actually appears to be with inode 5296. It has a massive size and what appears to be a lot of invalid metadata. perhaps this inode was not initialized. UFS2 has a feature of not initializing inodes, perhaps UFS1 does as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-18 13:26:17
|
Bugs item #3051400, was opened at 2010-08-23 05:19 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&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: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Rob J Meijer (ghede) Assigned to: Nobody/Anonymous (nobody) Summary: Invalid UTF8 sequences as file/dir names. Initial Comment: When processing the hda5 image from the honeynet test images ( http://old.honeynet.org/misc/files/challenge-images.tar ) the directory with inode 32169 when invoked with tsk_fs_dir_open_meta, produces multiple names that contain invalid UTF8 sequences. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-09-18 08:26 Message: TSK is displaying what is in the image. For example, I get this on my OS X system: fls honeypot.hda5.dd 32169 [...] r/r 32179: Error.gif r/r 32180: Exportova?.gif r/r 32181: Fehler.gif [...] Looking inside of the directory, I see: # icat honeypot.hda5.dd 32169| xxd 0000000: a97d 0000 0c00 0102 2e00 0000 89f5 0000 .}.............. [...] 00000e0: 4572 726f 722e 6769 6600 0000 b47d 0000 Error.gif....}.. 00000f0: 1800 0e01 4578 706f 7274 6f76 61bb 2e67 ....Exportova..g 0000100: 6966 0000 b57d 0000 1400 0a01 4665 686c if...}......Fehl The 0xbb that is causing the problems in the later conversion is in the image. TSK is not adding it. The likely problem is this image isn't storing its names in UTF-8. Ext2 file systems can use any single-byte encoding (I think), but file system doesn't store what encoding it uses. The local system's encoding settings are used. TSK assumes that the file system uses UTF-8 since most Linux systems use that. These images are old and could have been created on a system that didn't use UTF-8. I'm marking this as "Won't Fix" though because the fix would be to add encoding detection into the processing and this would apply only to a limited number of old disk images. All recent images use a standard encoding in them. Thanks for the report! ---------------------------------------------------------------------- Comment By: Rob J Meijer (ghede) Date: 2010-08-25 03:48 Message: Seems like the simplest way to reproduce this is: fls honeypot.hda5.dd 32169|iconv ---------------------------------------------------------------------- Comment By: Rob J Meijer (ghede) Date: 2010-08-25 03:02 Message: I tested this with the 3.1.1 and the 3.1.3 version. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-23 08:19 Message: Meaning that they are invalid in the image and TSK simply shows you the invalid sequences or that they are valid in the image and TSK makes them invalid. Is this in 3.1 or the trunk? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-11 04:05:16
|
Bugs item #3052302, was opened at 2010-08-24 08:56 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&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: Rob J Meijer (ghede) >Assigned to: Brian Carrier (carrier) Summary: segfault in tfk_fs_dir_open_meta Initial Comment: When processing inode 10240 of the ufs filesystem on the partition-3 image of the ntfs-auto-detect images in the dftt testset, a segfault occurs. Using fls the segfault can be reproduces: fls -f ufs 10-ntfs-part3.dd 10240 ---------------------------------------------------------------------- Comment By: Rob J Meijer (ghede) Date: 2010-08-25 02:56 Message: The versions I've tested this bug exists are 3.1.1 and 3.1.3. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-24 20:44 Message: The problem actually appears to be with inode 5296. It has a massive size and what appears to be a lot of invalid metadata. perhaps this inode was not initialized. UFS2 has a feature of not initializing inodes, perhaps UFS1 does as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-11 04:03:34
|
Bugs item #3026994, was opened at 2010-07-08 14:28 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&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: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: mingw compile errors Initial Comment: >From Simson Garfinkel: Version 3.1.3 generates these compilation errors with mingw running on Linux: fs_fname_apis.cpp: In function `int test_fat12()': fs_fname_apis.cpp:366: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_fname_apis.cpp: In function `int test_ntfs_fe()': fs_fname_apis.cpp:404: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat12()': read_apis.cpp:210: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)'fs_attrlist_apis.cpp: In function `int test_fat12()': fs_attrlist_apis.cpp:202: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_slack()': read_apis.cpp:249: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_attrlist_apis.cpp: In function `int test_ntfs_fe()': fs_attrlist_apis.cpp:241: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_recover()': read_apis.cpp:343: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_slack_ads()': read_apis.cpp:483: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_fe()': read_apis.cpp:644: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_comp()': read_apis.cpp:682: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' These are all trivially fixed by putting a (const TSK_TCHAR *) before the fname arguments. I am also seeing these errors which are not so trivial to fix: ewf.c: In function `ewf_open': ewf.c:147: warning: implicit declaration of function `libewf_check_file_signature_wide' ewf.c:163: warning: implicit declaration of function `libewf_open_wide' ewf.c:163: warning: assignment makes pointer from integer without a cast hfs_dent.c: In function `hfs_uni2ascii': hfs_dent.c:121: warning: dereferencing type-punned pointer will break strict-aliasing rules hfs_dent.c:122: warning: dereferencing type-punned pointer will break strict-aliasing rules ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-09-10 23:03 Message: Addressed hfs_dent issues (I think): Sending trunk/tsk3/fs/hfs_dent.c Transmitting file data . Committed revision 250. The libewf warnings could be because of how mingw defines wide characters and such... Need to try this setup. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-19 15:26 Message: First part of patch is in: Sending trunk/tests/fs_attrlist_apis.cpp Sending trunk/tests/fs_fname_apis.cpp Sending trunk/tests/read_apis.cpp Transmitting file data ... Committed revision 238. Need to look at ewf_open warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-10 16:07:06
|
Bugs item #2950687, was opened at 2010-02-12 11:38 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950687&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: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: Windows binaries not working. Initial Comment: >From Gregg Gunsch: Per the instruction on the bug tracker page, I'm sending this to the sleuthkit-users list first. Does anybody else see this problem or know of a simple solution? sleuth-win32-3.1.0.zip: On some machines in our relatively homogeneous computer lab, attempting to run TSK tools yields the following error message: "The system cannot execute the specified program" My limited research seems to indicate that an incorrect version of a system DLL could be the culprit (e.g., older kernel32.dll) but I haven't been able to pin down a difference between working and non-working machines, even with Dependency Walker. The files were extracted from the .zip archive and placed into a directory in "C:\Program Files", preserving the hierarchy found in the archive. The path was added to the environment variable, and the commands are being found (e.g., "which istat" locates it). They just aren't successfully being run. I even tried copying the DLLs that came with TSK into the system32 folder, but no help. We are running WinXP Pro, SP2 and SP3. Some SP2 machines run TSK just fine, as do the SP3 versions (and yes, I'm in the process of updating them all). I've also hashed the TSK files on a working system and compared to those on a non-working machine - they are identical. Is there a way to produce a more portable collection of executables that are less target-system dependent? Is there something I should be doing with the manifest so that the dependencies are satisfied? Should I be compiling the source myself instead of using the build in the .zip file? It's been years since I've done development, and a lot seems to have changed, so there may be some simple steps that I'm just overlooking right now. Thanks for your assistance, [[ other offline e-mails exist. Other versions of visual studio are on the machine ]] ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-09-10 11:07 Message: Dan Jerger reported that installing the VS 2008 redist dlls helped: http://www.microsoft.com/downloads/details.aspx?FamilyID=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en It's still not clear why this is needed though because these dlls are included with TSK... But, they are not officially installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950687&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-10 03:34:00
|
Feature Requests item #3017764, was opened at 2010-06-17 16:13 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3017764&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 Group: None >Status: Closed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Brian Carrier (carrier) Summary: Naming the default $DATA as "$Data" Initial Comment: Currently, TSK assigns the name "$Data" to a file's default $DATA attribute. However, this makes it difficult to distinguish the file's default $DATA attribute from an ADS named "$Data". For exaple, you can actually name a stream "$Data" like this: C:\> echo 1 > host.txt:$Data Now when you use fls, it shows something like this: ++++ r/r 201337-128-1: host.txt ++++ r/r 201337-128-3: host.txt A lot of people rely on grepping fls output for ":" to identify streams, but if the stream is actually named "$Data" then fls won't show it as such. One thing you could do is apply the "$Data" name inside the tsk_fs_name_print function if a $DATA attribute doesn't have a name. That way, the structure member fs_attr->name contains the original name (which would just be "" in the default case) so that applications can tell it apart from an ADS named "$Data". Thanks. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-09-09 22:33 Message: No longer add default name. Changed other checks and made policy that fs_attr->name is NULL if there is no name for the attribute. Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fs_attr.c Sending trunk/tsk3/fs/fs_attrlist.c Sending trunk/tsk3/fs/fs_name.c Sending trunk/tsk3/fs/ntfs.c Sending trunk/tsk3/fs/ntfs_dent.c Sending trunk/tsk3/fs/tsk_fs.h Transmitting file data ....... Committed revision 247. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3017764&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-10 02:03:52
|
Feature Requests item #2941805, was opened at 2010-01-28 15:15 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2941805&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 Group: None >Status: Closed Priority: 5 Private: No Submitted By: Rob (robjoyce) Assigned to: Brian Carrier (carrier) Summary: Show case sensitive flag in HFSX fsstat Initial Comment: The attached patch prints the case-sensitivity flag in fsstat when analyzing an HFSX volume. (It also removes an errant space in File System Version.) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-09-09 21:03 Message: Sending trunk/NEWS.txt Sending trunk/tsk3/fs/hfs.c Transmitting file data ... Committed revision 246. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2941805&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-09-10 01:55:12
|
Feature Requests item #3026989, was opened at 2010-07-08 14:18 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3026989&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: Closed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: specify range in img_cat (patch included) Initial Comment: Simson submitted a patch to specify range in img_cat. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-09-09 20:55 Message: Sending trunk/NEWS.txt Sending trunk/man/img_cat.1 Sending trunk/tools/imgtools/img_cat.cpp Transmitting file data ... Committed revision 245. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3026989&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-28 19:29:07
|
Feature Requests item #3055062, was opened at 2010-08-28 21:29 Message generated for change (Tracker Item Submitted) made by atomikramp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3055062&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 Group: None Status: Open Priority: 5 Private: No Submitted By: Francesco (atomikramp) Assigned to: Nobody/Anonymous (nobody) Summary: Ext4 support Initial Comment: Ext4 is quickly becoming the default choice for many linux distributions installations, especially on desktop oriented distros. it would be cool to have support for such filesystem on TSK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3055062&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-25 08:48:39
|
Bugs item #3051400, was opened at 2010-08-23 12:19 Message generated for change (Comment added) made by ghede You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&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: Rob J Meijer (ghede) Assigned to: Nobody/Anonymous (nobody) Summary: Invalid UTF8 sequences as file/dir names. Initial Comment: When processing the hda5 image from the honeynet test images ( http://old.honeynet.org/misc/files/challenge-images.tar ) the directory with inode 32169 when invoked with tsk_fs_dir_open_meta, produces multiple names that contain invalid UTF8 sequences. ---------------------------------------------------------------------- >Comment By: Rob J Meijer (ghede) Date: 2010-08-25 10:48 Message: Seems like the simplest way to reproduce this is: fls honeypot.hda5.dd 32169|iconv ---------------------------------------------------------------------- Comment By: Rob J Meijer (ghede) Date: 2010-08-25 10:02 Message: I tested this with the 3.1.1 and the 3.1.3 version. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-23 15:19 Message: Meaning that they are invalid in the image and TSK simply shows you the invalid sequences or that they are valid in the image and TSK makes them invalid. Is this in 3.1 or the trunk? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-25 08:02:28
|
Bugs item #3051400, was opened at 2010-08-23 12:19 Message generated for change (Comment added) made by ghede You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&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: Rob J Meijer (ghede) Assigned to: Nobody/Anonymous (nobody) Summary: Invalid UTF8 sequences as file/dir names. Initial Comment: When processing the hda5 image from the honeynet test images ( http://old.honeynet.org/misc/files/challenge-images.tar ) the directory with inode 32169 when invoked with tsk_fs_dir_open_meta, produces multiple names that contain invalid UTF8 sequences. ---------------------------------------------------------------------- >Comment By: Rob J Meijer (ghede) Date: 2010-08-25 10:02 Message: I tested this with the 3.1.1 and the 3.1.3 version. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-23 15:19 Message: Meaning that they are invalid in the image and TSK simply shows you the invalid sequences or that they are valid in the image and TSK makes them invalid. Is this in 3.1 or the trunk? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-25 07:56:00
|
Bugs item #3052302, was opened at 2010-08-24 15:56 Message generated for change (Comment added) made by ghede You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&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: Rob J Meijer (ghede) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in tfk_fs_dir_open_meta Initial Comment: When processing inode 10240 of the ufs filesystem on the partition-3 image of the ntfs-auto-detect images in the dftt testset, a segfault occurs. Using fls the segfault can be reproduces: fls -f ufs 10-ntfs-part3.dd 10240 ---------------------------------------------------------------------- >Comment By: Rob J Meijer (ghede) Date: 2010-08-25 09:56 Message: The versions I've tested this bug exists are 3.1.1 and 3.1.3. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-25 03:44 Message: The problem actually appears to be with inode 5296. It has a massive size and what appears to be a lot of invalid metadata. perhaps this inode was not initialized. UFS2 has a feature of not initializing inodes, perhaps UFS1 does as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-25 01:44:31
|
Bugs item #3052302, was opened at 2010-08-24 08:56 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&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: Rob J Meijer (ghede) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in tfk_fs_dir_open_meta Initial Comment: When processing inode 10240 of the ufs filesystem on the partition-3 image of the ntfs-auto-detect images in the dftt testset, a segfault occurs. Using fls the segfault can be reproduces: fls -f ufs 10-ntfs-part3.dd 10240 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-24 20:44 Message: The problem actually appears to be with inode 5296. It has a massive size and what appears to be a lot of invalid metadata. perhaps this inode was not initialized. UFS2 has a feature of not initializing inodes, perhaps UFS1 does as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-24 13:56:05
|
Bugs item #3052302, was opened at 2010-08-24 15:56 Message generated for change (Tracker Item Submitted) made by ghede You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&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: Rob J Meijer (ghede) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in tfk_fs_dir_open_meta Initial Comment: When processing inode 10240 of the ufs filesystem on the partition-3 image of the ntfs-auto-detect images in the dftt testset, a segfault occurs. Using fls the segfault can be reproduces: fls -f ufs 10-ntfs-part3.dd 10240 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3052302&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-23 16:04:38
|
Feature Requests item #3051616, was opened at 2010-08-23 10:42 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3051616&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 Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Orphan FAT files have SFN Initial Comment: When orphan files are recovered from unallocated clusters in a FAT file system, only the short name is given. It would be nice if the long name were given too. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-23 11:04 Message: For future reference, an example of this is in the FAT partition of the fe_test image (entry 583). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3051616&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-23 15:58:20
|
Feature Requests item #3051626, was opened at 2010-08-23 10:58 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3051626&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 Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Search for NTFS Orphan Files from previous file system. Initial Comment: The orphan files in NTFS currently are only based on an existing MFT. We could also scan the unallocated clusters in the file system for traces of previous MFT entries from a format operation. Challenges: - How to number them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3051626&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-23 15:42:07
|
Feature Requests item #3051616, was opened at 2010-08-23 10:42 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3051616&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 Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Orphan FAT files have SFN Initial Comment: When orphan files are recovered from unallocated clusters in a FAT file system, only the short name is given. It would be nice if the long name were given too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3051616&group_id=55685 |
1 message has been excluded from this view by a project administrator.
