sleuthkit-developers Mailing List for The Sleuth Kit (Page 30)
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...> - 2009-05-08 12:54:59
|
Bugs item #2596153, was opened at 2009-02-13 09:47 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2596153&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: tsk_img_open arguments Initial Comment: >From Simson Garfinkel: tsk_img_open_utf8 is prototyped: extern TSK_IMG_INFO *tsk_img_open_utf8(int num_img, const char **images, TSK_IMG_TYPE_ENUM type); where images is, I guess, argv. The problem is that getopt() prototypes argv this way: getopt(int argc, char * const argv[], const char *optstring); Passing argv to tsk_img_open_utf8 produces this error: error: invalid conversion from ‘char* const*’ to ‘const char**’ I can fix this with a cast, but perhaps tsk_img_open_utf8 should be changed to match. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-08 07:54 Message: Fixed for Unix systems. Still need to do for Win32 arguments. Sending trunk/tests/fs_attrlist_apis.cpp Sending trunk/tests/fs_fname_apis.cpp Sending trunk/tests/read_apis.cpp Sending trunk/tools/fstools/blkcalc.cpp Sending trunk/tools/fstools/blkcat.cpp Sending trunk/tools/fstools/blkls.cpp Sending trunk/tools/fstools/blkstat.cpp Sending trunk/tools/fstools/ffind.cpp Sending trunk/tools/fstools/fls.cpp Sending trunk/tools/fstools/fscheck.cpp Sending trunk/tools/fstools/fsstat.cpp Sending trunk/tools/fstools/icat.cpp Sending trunk/tools/fstools/ifind.cpp Sending trunk/tools/fstools/ils.cpp Sending trunk/tools/fstools/istat.cpp Sending trunk/tools/fstools/jcat.cpp Sending trunk/tools/fstools/jls.cpp Sending trunk/tools/imgtools/img_cat.cpp Sending trunk/tools/imgtools/img_stat.cpp Sending trunk/tools/vstools/mmcat.cpp Sending trunk/tools/vstools/mmls.cpp Sending trunk/tools/vstools/mmstat.cpp Sending trunk/tsk3/img/aff.c Sending trunk/tsk3/img/aff.h Sending trunk/tsk3/img/ewf.c Sending trunk/tsk3/img/ewf.h Sending trunk/tsk3/img/img_io.c Sending trunk/tsk3/img/img_open.c Sending trunk/tsk3/img/raw.c Sending trunk/tsk3/img/split.c Sending trunk/tsk3/img/split.h Sending trunk/tsk3/img/tsk_img.h Transmitting file data ................................ Committed revision 94. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2596153&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-08 03:31:25
|
Bugs item #2367426, was opened at 2008-11-30 17:55 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2367426&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: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: Fix NTFS VDL Slack bug Initial Comment: NTFS non-resident streams have a value that stores how much of the stream has been initialized. This is not currently being processed by TSK. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-07 22:31 Message: Fixed rest of issue so that "slack" flags to icat or the read API commands will still return the uninitialized space. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/fs_attr.c Transmitting file data .. Committed revision 93. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-05-06 23:49 Message: Completed first step, which is to return 0s after initialized part of file. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/fatfs_meta.c Sending trunk/tsk3/fs/fs_attr.c Sending trunk/tsk3/fs/hfs.c Sending trunk/tsk3/fs/iso9660.c Sending trunk/tsk3/fs/ntfs.c Sending trunk/tsk3/fs/tsk_fs.h Sending trunk/tsk3/fs/tsk_fs_i.h Sending trunk/tsk3/fs/unix_misc.c Transmitting file data ......... Committed revision 92. Still need to part 2, which is to show uninitialized file contents if slack flag is given. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2367426&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-07 04:50:05
|
Bugs item #2367426, was opened at 2008-11-30 17:55 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2367426&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: Fix NTFS VDL Slack bug Initial Comment: NTFS non-resident streams have a value that stores how much of the stream has been initialized. This is not currently being processed by TSK. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-05-06 23:49 Message: Completed first step, which is to return 0s after initialized part of file. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/fatfs_meta.c Sending trunk/tsk3/fs/fs_attr.c Sending trunk/tsk3/fs/hfs.c Sending trunk/tsk3/fs/iso9660.c Sending trunk/tsk3/fs/ntfs.c Sending trunk/tsk3/fs/tsk_fs.h Sending trunk/tsk3/fs/tsk_fs_i.h Sending trunk/tsk3/fs/unix_misc.c Transmitting file data ......... Committed revision 92. Still need to part 2, which is to show uninitialized file contents if slack flag is given. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2367426&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-06 04:38:01
|
Bugs item #2645156, was opened at 2009-02-27 07:17 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2645156&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: Charlie Daly (charliedaly) >Assigned to: Brian Carrier (carrier) Summary: FAT16 slack space not collected by blkls Initial Comment: blkls (Sleuth Kit ver 3.0.1) does not correctly collect slack space from a particular FAT16 partition. Image: http://polya.computing.dcu.ie/FATimage.dd of a virtual 1G drive and a FAT16 partition. There are a few directories and files. The command blkls -s -o 63 FATimage | xxd -a | less does not correctly collect the slack space. Using dls (Sleuth Kit ver 2.52) does collect the slack space correctly. Highest regards, Charlie ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-05 23:37 Message: allocsize set too small and then found issues with special files not being properly reset. Fix checked into trunk: Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/dls_lib.c Sending trunk/tsk3/fs/fatfs_dent.c Sending trunk/tsk3/fs/fatfs_meta.c Sending trunk/tsk3/fs/fs_attr.c Sending trunk/tsk3/fs/fs_dir.c Transmitting file data ...... Committed revision 91. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2645156&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-05 13:58:15
|
Bugs item #2786963, was opened at 2009-05-04 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=2786963&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: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS Compression Infinite loop Initial Comment: >From Jamie Butler: When reading a NTFS compressed file on the filesystem, TSK calls ntfs_file_read_special in ntfs.c. This function uncompresses the data in the file starting at the offset requested and places up to a_len bytes into a_buf. The bug occurs on files whose size are not evenly divisible by 512. On the last read of the file, more bytes may be returned than were in the original file. The original code uses buf_idx to keep track of how many bytes have been read and that variable is incremented by cpylen each time through the loop. It looks like this: else if (comp.uncomp_idx - byteoffset < a_len - buf_idx) { cpylen = comp.uncomp_idx - byteoffset; } else { cpylen = a_len - buf_idx; } memcpy(&a_buf[buf_idx], &comp.uncomp_buf[byteoffset], cpylen); // reset this in case we need to also read from the next run byteoffset = 0; buf_idx += cpylen; comp_unit_idx = 0; However, at the end of the last read of a file, buf_idx plus the starting offset in the file may actually be greater than the size of the file. This can cause problems and depending on how the function is called, it can send programs into infinite read loops of the file. Instead, cpylen and hence buf_idx should never be greater than the size of the file when added to offset. The fix is: else if (comp.uncomp_idx - byteoffset < a_len - buf_idx) { cpylen = comp.uncomp_idx - byteoffset; } else { cpylen = a_len - buf_idx; } // Make sure not to return more bytes than are in the file if (cpylen > (a_fs_attr->fs_file->meta->size - (a_offset + buf_idx))) { cpylen = (a_fs_attr->fs_file->meta->size - (a_offset + buf_idx)); } memcpy(&a_buf[buf_idx], &comp.uncomp_buf[byteoffset], cpylen); // reset this in case we need to also read from the next run byteoffset = 0; buf_idx += cpylen; comp_unit_idx = 0; ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-05 08:57 Message: I checked this in last night into the trunk as r89. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2786963&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-05 00:31:49
|
Bugs item #2786963, was opened at 2009-05-04 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=2786963&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 Compression Infinite loop Initial Comment: >From Jamie Butler: When reading a NTFS compressed file on the filesystem, TSK calls ntfs_file_read_special in ntfs.c. This function uncompresses the data in the file starting at the offset requested and places up to a_len bytes into a_buf. The bug occurs on files whose size are not evenly divisible by 512. On the last read of the file, more bytes may be returned than were in the original file. The original code uses buf_idx to keep track of how many bytes have been read and that variable is incremented by cpylen each time through the loop. It looks like this: else if (comp.uncomp_idx - byteoffset < a_len - buf_idx) { cpylen = comp.uncomp_idx - byteoffset; } else { cpylen = a_len - buf_idx; } memcpy(&a_buf[buf_idx], &comp.uncomp_buf[byteoffset], cpylen); // reset this in case we need to also read from the next run byteoffset = 0; buf_idx += cpylen; comp_unit_idx = 0; However, at the end of the last read of a file, buf_idx plus the starting offset in the file may actually be greater than the size of the file. This can cause problems and depending on how the function is called, it can send programs into infinite read loops of the file. Instead, cpylen and hence buf_idx should never be greater than the size of the file when added to offset. The fix is: else if (comp.uncomp_idx - byteoffset < a_len - buf_idx) { cpylen = comp.uncomp_idx - byteoffset; } else { cpylen = a_len - buf_idx; } // Make sure not to return more bytes than are in the file if (cpylen > (a_fs_attr->fs_file->meta->size - (a_offset + buf_idx))) { cpylen = (a_fs_attr->fs_file->meta->size - (a_offset + buf_idx)); } memcpy(&a_buf[buf_idx], &comp.uncomp_buf[byteoffset], cpylen); // reset this in case we need to also read from the next run byteoffset = 0; buf_idx += cpylen; comp_unit_idx = 0; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2786963&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-27 03:21:37
|
Bugs item #1482131, was opened at 2006-05-04 16:07 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=1482131&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: Disk Tools Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: disk_stat does not work with USB Initial Comment: If ATA drive is connected via USB, then disk_stat does not detect HPA. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=1482131&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-27 03:21:27
|
Bugs item #1482133, was opened at 2006-05-04 16:08 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=1482133&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: Disk Tools Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: disk_stat and SATA Initial Comment: disk_stat does not detect HPA on SATA drive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=1482133&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-27 03:21:26
|
Bugs item #1482134, was opened at 2006-05-04 16:08 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=1482134&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: Disk Tools Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: disk_stat and large disks Initial Comment: disk_stat does not detect HPA in disks that are larger than 130 GB. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=1482134&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-27 03:20:14
|
Bugs item #2351405, was opened at 2008-11-26 11:30 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2351405&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: Disk Tools Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: disk_stat results incorrect Initial Comment: Just something I thought might be of interest to the group. The newest version of hdparm has some interesting developments. >From http://freshmeat.net/projects/hdparm/?branch_id=4062&release_id=288158: *"Changes:* Support for Device Configuration Overlay was added, with the new flags "--dco-freeze", "--dco-identify", and "--dco-restore"." I have compared results from disk_stat with hdparm --dco-identify command on my home machine. On my main O/S drive disk_stat reports one less sector than hdparm, I guess that disk_stat is counting from zero and hdparm counting from one. On my storage drive, something curious occurs: hdparm --dco-identify reports "Real max sectors" as 488397168 Disk_stat on the same disk gives the following output: Maximum Disk Sector: 268435454 Maximum User Sector: 488397167 Again, there is one sector difference between the max number of sectors reported by disk_stat and hdparm, but I don't understand how the Maximum User Sectors can be larger than the Maximum Disk Sectors. If I understood Issue #20 of the sleuthkit Informer correctly, the Maximum User Sector is the number of sectors visible to the user, the Maximum Disk Sector is the Maximum User Sector + the number of sectors in the HPA. Can anyone explain the disk_stat output above? I am using disk_stat version 3.0.0b3 Thanks Adrian Shaw ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-26 22:19 Message: Removed disktools from TSK. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2008-11-26 11:32 Message: Because hdparm now shows much of the data displayed by disk_stat and there are several open bugs on disk_stat that have not been fixed, I'm beginning to be think that disktools should be abandoned unless someone else picks up responsibility for them... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2351405&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-23 12:46:58
|
Bugs item #2779244, was opened at 2009-04-23 10:25 Message generated for change (Settings changed) made by fuf_bugs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2779244&group_id=55687 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: .FUF (fuf_bugs) >Assigned to: Brian Carrier (carrier) Summary: Autopsy looks for sorter configs in wrong path. Initial Comment: Autopsy looks for sorter configs in wrong path. lib/Appsort.pm: my $config = "$::TSKDIR/../share/tsk/sorter/images.sort"; Should be: lib/Appsort.pm: my $config = "$::TSKDIR/../share/tsk3/sorter/images.sort"; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2779244&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2009-04-23 06:25:22
|
Bugs item #2779244, was opened at 2009-04-23 10:25 Message generated for change (Tracker Item Submitted) made by fuf_bugs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2779244&group_id=55687 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: .FUF (fuf_bugs) Assigned to: Nobody/Anonymous (nobody) Summary: Autopsy looks for sorter configs in wrong path. Initial Comment: Autopsy looks for sorter configs in wrong path. lib/Appsort.pm: my $config = "$::TSKDIR/../share/tsk/sorter/images.sort"; Should be: lib/Appsort.pm: my $config = "$::TSKDIR/../share/tsk3/sorter/images.sort"; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2779244&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2009-04-22 02:51:37
|
Bugs item #2706862, was opened at 2009-03-23 13:29 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2706862&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 (robjoyce) Assigned to: Nobody/Anonymous (nobody) Summary: Handle uninitialized mode bits in HFS+ Initial Comment: According to Apple TN1150 (http://developer.apple.com/technotes/tn/tn1150.html#HFSPlusPermissions), it's legal for the permissions structure to be uninitialized. In the current SleuthKit trunk, the inode type never gets set in this case. (In SleuthKit 3.0.1, hfs_dinode_copy actually throws an error when this occurs.) The attached patch sets the inode type to directory or file as appropriate if it's initially empty (based on the catalog node type). It also sets the owner UID and GID to 99 ("unknown"), which are what the Mac OS HFS+ implementation does when it sees uninitialized permission structures. (You could reasonably argue SleuthKit shouldn't do the latter, although I think it's better than conflating root (UID/GID 0) versus "uninitialized".) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-21 21:51 Message: Variation of patch checked into trunk. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/hfs.c Transmitting file data .. Committed revision 81. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2706862&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-22 01:00:28
|
Bugs item #2777633, was opened at 2009-04-21 11:47 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2777633&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: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: FAT create time can be off by 1 second Initial Comment: TSK is currently ignoring the hundreds of a second value in the creation time of FAT files. This value can be used to make the creation time accurate to the second instead of being accurate to "2 seconds". Reported by Eoghan Casey. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-21 20:00 Message: Fixed and checked into trunk. Sending CHANGES.txt Sending tsk3/fs/fatfs_meta.c Sending tsk3/fs/tsk_fatfs.h Transmitting file data ... Committed revision 79. Note that we still do not show the millisecond resolution, we just corrected the second resolution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2777633&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-22 00:16:15
|
Bugs item #2778170, was opened at 2009-04-21 19:02 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2778170&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: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect read size of NTFS resident files Initial Comment: fs_read_attr() for resident files relies on the buffer size and not the file size for calculating how much data to read. It should use the file size. Patch supplied by Jamie Butler: if (a_len + a_offset > a_fs_attr->rd.buf_size) read_len = a_fs_attr->rd.buf_size - (size_t) a_offset; else read_len = a_len; should be: if (a_offset > a_fs_attr->size) { return 0; } if (a_len + a_offset > a_fs_attr->size) read_len = a_fs_attr->size - a_offset; else read_len = a_len; ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-21 19:16 Message: Checked into root. Sending CHANGES.txt Sending tsk3/fs/fs_attr.c Transmitting file data .. Committed revision 78. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2778170&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-22 00:02:53
|
Bugs item #2778170, was opened at 2009-04-21 19:02 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2778170&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: Incorrect read size of NTFS resident files Initial Comment: fs_read_attr() for resident files relies on the buffer size and not the file size for calculating how much data to read. It should use the file size. Patch supplied by Jamie Butler: if (a_len + a_offset > a_fs_attr->rd.buf_size) read_len = a_fs_attr->rd.buf_size - (size_t) a_offset; else read_len = a_len; should be: if (a_offset > a_fs_attr->size) { return 0; } if (a_len + a_offset > a_fs_attr->size) read_len = a_fs_attr->size - a_offset; else read_len = a_len; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2778170&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-21 16:47:21
|
Bugs item #2777633, was opened at 2009-04-21 11:47 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2777633&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: FAT create time can be off by 1 second Initial Comment: TSK is currently ignoring the hundreds of a second value in the creation time of FAT files. This value can be used to make the creation time accurate to the second instead of being accurate to "2 seconds". Reported by Eoghan Casey. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2777633&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-13 20:39:49
|
Bugs item #2677069, was opened at 2009-03-09 20:20 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2677069&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: Media Management Tools Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Aaron Burghardt (aburgh) Assigned to: Nobody/Anonymous (nobody) Summary: GPT Partitions not detected Initial Comment: When using tsk_vs_open() with TSK_VS_TYPE_DETECT to open an image and detect the volume system, GPT partition schemes are not detected. Currently, the code detects GPT's DOS safety partition scheme, then finds the GPT partition scheme but considers that an error. A simple patch is attached which discards the DOS volume system when a GPT volume system is also detected. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-13 15:39 Message: My initial patch did not work. I checked in another one that I was able to verify with the help of an image from Simson Garfinkel. Sending mm_open.c Transmitting file data . Committed revision 77. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-04-11 16:08 Message: Checked in a variation of this patch into the trunk that does some additional sanity checking on the DOS partition. Sending CHANGES.txt Sending tsk3/vs/mm_open.c Transmitting file data .. Committed revision 72. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2677069&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-12 04:33:49
|
Bugs item #2662168, was opened at 2009-03-04 11:02 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2662168&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Rob (robjoyce) Assigned to: Nobody/Anonymous (nobody) Summary: Alignment errors when reading raw devices in Mac OS X Initial Comment: When running any SleuthKit tools against /dev/rdisk* in Mac OS X, you get kernel[0]: disk0: alignment error. messages in syslog. The tools work fine, despite the errors. Tracking it down, it turns out to be the lseek(...,SEEK_END) in tsk3/img/raw.c that tries to determine the file's size. There's already some Mac-specific code there to get the size of raw disk devices... the attached patch simply avoids the lseek() test if it's a character device on a Mac. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-11 23:33 Message: Checked into trunk. Sending CHANGES.txt Sending tsk3/img/raw.c Transmitting file data .. Committed revision 76. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2662168&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-12 04:20:01
|
Bugs item #2725799, was opened at 2009-04-01 17:13 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2725799&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 (robjoyce) Assigned to: Nobody/Anonymous (nobody) Summary: ifind on win32 can use wrong endianness Initial Comment: In tsk3/fs/ifind_lib.c, tsk_fs_ifind_path() has code to translate the TSK_TCHAR path argument to UTF-8 on Windows. It does so by calling tsk_UTF16toUTF8(fs->endian, ...), but this assumes that the TSK_TCHAR has the same endianness as the filesystem. The upshot is that ifind fails when searching for a file in a big-endian file system on Windows. (This is 3.0.1 and the current trunk as well.) e.g.: > fls.exe ufs.dd d/d 7936: hello [...] > ifind.exe -n hello ufs.dd File not found > ifind.exe -n . ufs.dd File not found So it looks like we need to use some constant/code/#define/whatever for "local endianness" instead of fs->endian. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-11 23:20 Message: Checked into trunk. Made new unicode conversion method. Sending CHANGES.txt Sending tsk3/base/tsk_base_i.h Sending tsk3/base/tsk_unicode.c Sending tsk3/fs/fls_lib.c Sending tsk3/fs/ifind_lib.c Sending tsk3/img/img_open.c Transmitting file data ...... Committed revision 75. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2725799&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-12 03:34:55
|
Bugs item #2655831, was opened at 2009-03-02 18:41 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2655831&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: sorter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: sorter does not know Ext2 Ext3 types Initial Comment: Sorter is hard coded for some file system types and it does not know about the shortened ext2 and ext3 names. Using ext by itself works though. From: Vinogratzky Date: February 27, 2009 2:28:28 AM EST To: sle...@li... Subject: [sleuthkit-users] sorter error:Unknown file system type: -f ext3 Hi, root@maus:~$ sorter -V The Sleuth Kit ver 3.0.1 root@maus:~$ sorter -s -d sorter_dir/ sda2.dd Unknown file system type: -f ext3 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-11 22:34 Message: Fixed in trunk and also added support for ufs1, ufs2, iso, and hfs. Sending CHANGES.txt Sending tools/sorter/sorter.base Transmitting file data .. Committed revision 74. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2655831&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-11 21:08:32
|
Bugs item #2677069, was opened at 2009-03-09 20:20 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2677069&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: Media Management Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Aaron Burghardt (aburgh) Assigned to: Nobody/Anonymous (nobody) Summary: GPT Partitions not detected Initial Comment: When using tsk_vs_open() with TSK_VS_TYPE_DETECT to open an image and detect the volume system, GPT partition schemes are not detected. Currently, the code detects GPT's DOS safety partition scheme, then finds the GPT partition scheme but considers that an error. A simple patch is attached which discards the DOS volume system when a GPT volume system is also detected. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-11 16:08 Message: Checked in a variation of this patch into the trunk that does some additional sanity checking on the DOS partition. Sending CHANGES.txt Sending tsk3/vs/mm_open.c Transmitting file data .. Committed revision 72. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2677069&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-11 04:42:10
|
Bugs item #2734458, was opened at 2009-04-05 09:33 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2734458&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: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: NTFS file listing is slow Initial Comment: With TSK 3+, TSK is searching the MFT for every directory being listed to find unallocated entries that point to that directory as its parent. This turns out to be very slow for large file systems. The results should be cached so that each time a directory is listed, it does not need to rescan the MFT. Reported by Eamonn Saunders. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-04-10 23:42 Message: Fixed in trunk. Sending CHANGES.txt Sending tsk3/fs/ntfs.c Sending tsk3/fs/ntfs_dent.c Sending tsk3/fs/tsk_ntfs.h Transmitting file data .... Committed revision 71. Added a cache map so that inode_walk is done only once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2734458&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-05 14:33:23
|
Bugs item #2734458, was opened at 2009-04-05 09:33 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2734458&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 file listing is slow Initial Comment: With TSK 3+, TSK is searching the MFT for every directory being listed to find unallocated entries that point to that directory as its parent. This turns out to be very slow for large file systems. The results should be cached so that each time a directory is listed, it does not need to rescan the MFT. Reported by Eamonn Saunders. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2734458&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-04-01 22:14:08
|
Bugs item #2725799, was opened at 2009-04-01 18:13 Message generated for change (Tracker Item Submitted) made by robjoyce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2725799&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 (robjoyce) Assigned to: Nobody/Anonymous (nobody) Summary: ifind on win32 can use wrong endianness Initial Comment: In tsk3/fs/ifind_lib.c, tsk_fs_ifind_path() has code to translate the TSK_TCHAR path argument to UTF-8 on Windows. It does so by calling tsk_UTF16toUTF8(fs->endian, ...), but this assumes that the TSK_TCHAR has the same endianness as the filesystem. The upshot is that ifind fails when searching for a file in a big-endian file system on Windows. (This is 3.0.1 and the current trunk as well.) e.g.: > fls.exe ufs.dd d/d 7936: hello [...] > ifind.exe -n hello ufs.dd File not found > ifind.exe -n . ufs.dd File not found So it looks like we need to use some constant/code/#define/whatever for "local endianness" instead of fs->endian. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2725799&group_id=55685 |
1 message has been excluded from this view by a project administrator.
