sleuthkit-developers Mailing List for The Sleuth Kit (Page 27)
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-11-25 13:55:03
|
Feature Requests item #2903736, was opened at 2009-11-25 08:55 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903736&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: ffind -d option Initial Comment: Make an ffind -d option that allows you to specify the block and it finds the metadata address and then the name. This merges 'ifind -d' into ffind. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903736&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-24 22:46:03
|
Feature Requests item #2903408, was opened at 2009-11-24 17:46 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903408&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: ffind -d option Initial Comment: Make an ffind -d option that allows you to specify the block and it finds the metadata address and then the name. This merges 'ifind -d' into ffind. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903408&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-20 21:07:48
|
Bugs item #2900761, was opened at 2009-11-19 16:56 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900761&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: ISO Infinite Loop Initial Comment: Rob Meijer reported an infinite loop issue with ISO CDs. He sent me some logs that I need to parse through and debug. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-20 16:07 Message: Added sanity checks before starting the search for FAT parent directories. The corrupt ISO image is being detected as FAT. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/fatfs_dent.c Transmitting file data .. Committed revision 129. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900761&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-20 20:14:06
|
Bugs item #2900779, was opened at 2009-11-19 17:38 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900779&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: Timeline Tools Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: mactime sorting bug patch Initial Comment: >From Hal Pomeranz: Brian-- I'm attaching a patch for mactime that addresses an issue that's been bugging me for a long time, but that I only just got around to fixing. The problem is that timeline dates from epoch+200000000 (1976-05-03) through epoch+999999999 (2001-09-09) sort *after* the dates starting from epoch+1000000000. If you look at the code, the timeline is sorted alphabetically on the keys from %time2macstr. Those keys are created in read_body() by concatenating "st_{m/a/c}time,$st_ino,$file", so mostly they get sorted by the MACtime value. But it's the same problem you have when you try to sort 1..10 alphabetically-- you get "1, 10, 2, ..." because it's an alpha sort not a numeric sort. The fix is to "zero-fill" the mactime values in the %time2macstr keys so they're a consistent length. Then the alpha sort works fine. As long as I was doing that, I also swapped the order of the last two key fields (now "$st_*time,$file,$st_ino") so that the timeline sorts first on time, and then by filename, and finally by inode number (which should never be used). Sorting by inode number before filename doesn't make much sense to me for human-readable output. Context diff attached... ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-20 15:14 Message: This was already fixed from issue 2596397. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900779&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-20 19:50:49
|
Bugs item #2901365, was opened at 2009-11-20 14:48 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2901365&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: Missing FAT Files Initial Comment: John Lehr reported missing files from 'fls' on a FAT image from a GPS. He sent me the root directory contents and verbose logs. This was reported on the users list on Nov 6. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-20 14:50 Message: Now allow wdate to be 0 in dentry. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/fatfs_dent.c Sending trunk/tsk3/fs/fatfs_meta.c Transmitting file data ... Committed revision 128. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2901365&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-20 19:48:09
|
Bugs item #2901365, was opened at 2009-11-20 14:48 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2901365&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: Missing FAT Files Initial Comment: John Lehr reported missing files from 'fls' on a FAT image from a GPS. He sent me the root directory contents and verbose logs. This was reported on the users list on Nov 6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2901365&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-19 22:51:02
|
Feature Requests item #2900739, was opened at 2009-11-19 16:33 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2900739&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: Provide all metadata Initial Comment: TSK currently provides standard metadata in TSK_FS_META. Different file systems have different types of metadata beyond what is stored in there. The OCFA folks (Rob Meijer et al.) requested that the other metadata be made available in a name/value pair list. Presumably, there would a #define for the name of each file system-specific metadata value and it could be used to map to the corresponding value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2900739&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-19 22:43:25
|
Feature Requests item #2900784, was opened at 2009-11-19 17:43 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2900784&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 Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Use u_char * in API for buffers Initial Comment: Simson requests that the API uses u_char * instead of char *. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2900784&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-19 22:38:04
|
Bugs item #2900779, was opened at 2009-11-19 17:38 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900779&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: Timeline Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: mactime sorting bug patch Initial Comment: >From Hal Pomeranz: Brian-- I'm attaching a patch for mactime that addresses an issue that's been bugging me for a long time, but that I only just got around to fixing. The problem is that timeline dates from epoch+200000000 (1976-05-03) through epoch+999999999 (2001-09-09) sort *after* the dates starting from epoch+1000000000. If you look at the code, the timeline is sorted alphabetically on the keys from %time2macstr. Those keys are created in read_body() by concatenating "st_{m/a/c}time,$st_ino,$file", so mostly they get sorted by the MACtime value. But it's the same problem you have when you try to sort 1..10 alphabetically-- you get "1, 10, 2, ..." because it's an alpha sort not a numeric sort. The fix is to "zero-fill" the mactime values in the %time2macstr keys so they're a consistent length. Then the alpha sort works fine. As long as I was doing that, I also swapped the order of the last two key fields (now "$st_*time,$file,$st_ino") so that the timeline sorts first on time, and then by filename, and finally by inode number (which should never be used). Sorting by inode number before filename doesn't make much sense to me for human-readable output. Context diff attached... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900779&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-19 21:56:30
|
Bugs item #2900761, was opened at 2009-11-19 16:56 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900761&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: ISO Infinite Loop Initial Comment: Rob Meijer reported an infinite loop issue with ISO CDs. He sent me some logs that I need to parse through and debug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900761&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-11 00:25:12
|
Feature Requests item #2895607, was opened at 2009-11-10 19:25 Message generated for change (Tracker Item Submitted) made by jamiebutler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&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: James Butler (jamiebutler) Assigned to: Nobody/Anonymous (nobody) Summary: Identify in NTFS the SID of the owner of a file Initial Comment: The owner SID of files needs to be identified per file. Every file has an associated security identifier which identifies the owner, groups, etc. of the file. More than one file may have the same security identifier if the files share the exact same security descriptor. Using the security identifier of the file (secid), we can lookup its security descriptor within $Secure. Security descriptors are variable length and contained in the $SDS stream within $Secure. The $SII stream of $Secure is an index into the $SDS stream. $SII entries are stored incrementally by the secid. Once we find the secid of the file inside the $SII stream, the $SII entry will tell the offset within the $SDS stream to read the security descriptor. Use the tsk_fs_file_read_owner_sid function within fs_file.c to get the string representation of the owner SID of a file on NTFS. When an NTFS filesystem is opened ntfs_open is called. ntfs_open initializes a pointer to ntfs_lookup_security_id and then calls ntfs_load_secure. ntfs_load_secure opens MFT entry 9, $Secure, and reads in the $SDS and $SII streams. When tsk_fs_file_read_owner_sid is called on a TSK_FS_FILE, the owner SID is returned in its string form. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-10 21:19:17
|
Feature Requests item #2893521, was opened at 2009-11-06 15:15 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2893521&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: Installer Group: None >Status: Closed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Allow libewf/afflib location to be specified Initial Comment: Currently, configure will search in standard locations for libewf and afflib. If a user installs the libraries in their home directory though, it will not be found. Add a feature to configure to allow user to specify the location. For example, some other programs allow the user to specify '--with-LIBXYZ=/my/path'. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-10 16:19 Message: Fixed. --with-libewf=dir and --with-afflib=dir can be used. --without-afflib and --without-libewf should now be used instead of --disable-libewf and --disable-afflib. Sending trunk/INSTALL.txt Sending trunk/configure.ac Transmitting file data .. Committed revision 126. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-09 19:27 Message: I thought that this was part of autoconf by default, but realized that it means something else. Reverted instructions. Working on different fix using AC_ARG_WITH. Sending trunk/INSTALL.txt Transmitting file data . Committed revision 125. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-09 18:46 Message: Added --prefix argument description to INSTALL.txt file as a short-term fix. Sending trunk/INSTALL.txt Transmitting file data . Committed revision 124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2893521&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-10 00:27:19
|
Feature Requests item #2893521, was opened at 2009-11-06 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=2893521&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: Installer Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Allow libewf/afflib location to be specified Initial Comment: Currently, configure will search in standard locations for libewf and afflib. If a user installs the libraries in their home directory though, it will not be found. Add a feature to configure to allow user to specify the location. For example, some other programs allow the user to specify '--with-LIBXYZ=/my/path'. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-09 19:27 Message: I thought that this was part of autoconf by default, but realized that it means something else. Reverted instructions. Working on different fix using AC_ARG_WITH. Sending trunk/INSTALL.txt Transmitting file data . Committed revision 125. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-09 18:46 Message: Added --prefix argument description to INSTALL.txt file as a short-term fix. Sending trunk/INSTALL.txt Transmitting file data . Committed revision 124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2893521&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-09 23:46:32
|
Feature Requests item #2893521, was opened at 2009-11-06 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=2893521&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: Installer Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Allow libewf/afflib location to be specified Initial Comment: Currently, configure will search in standard locations for libewf and afflib. If a user installs the libraries in their home directory though, it will not be found. Add a feature to configure to allow user to specify the location. For example, some other programs allow the user to specify '--with-LIBXYZ=/my/path'. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-09 18:46 Message: Added --prefix argument description to INSTALL.txt file as a short-term fix. Sending trunk/INSTALL.txt Transmitting file data . Committed revision 124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2893521&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-09 23:08:55
|
Bugs item #2857258, was opened at 2009-09-11 18:25 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2857258&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: Accepted Priority: 5 Private: No Submitted By: Rob (robjoyce) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for HFS+ flags Initial Comment: The attached patch prints out the owner and admin flags on HFS+ files. This is particularly important in OS X 10.6 HFS+, which adds an "is compressed" flag for files. (Actually decompressing the file content is more complicated, and not yet implemented.) The patch is against the trunk, 9/10/09. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-09 18:08 Message: Thanks. Checked into trunk (with a few name changes). Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/hfs.c Sending trunk/tsk3/fs/tsk_hfs.h Transmitting file data ... Committed revision 122. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2857258&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-06 21:06:14
|
Bugs item #2890983, was opened at 2009-11-02 17:59 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2890983&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: Time zone on HFS+ volume creation date Initial Comment: Apple TN 1150 says that the volume creation timestamp is in the local time zone, not UTC, for historical reasons. (This is not true of the volume modification time or other timestamps.) hfs.c's fsstat assumes that all the volume timestamps are in UTC. This leads to, at best, the volume creation timestamp being double-corrected for timezone. (e.g., if a volume created at 12:00 EST would have 12:00 set in its volume header, which SK would then read as 12:00 UTC and print out as 08:00 EST.) In general, there's no way to know what the timezone might have been at format time. The attached patch prints the volume creation date in its native form... if the volume was formatted in the same timezone as the investigator's current TZ, the time will be correct. Otherwise, at least we're displaying what's on disk, and not wrongly correcting for some unknown TZ. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-06 16:06 Message: Thanks. Applied to trunk. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/hfs.c Transmitting file data .. Committed revision 121. ---------------------------------------------------------------------- Comment By: Rob (robjoyce) Date: 2009-11-02 18:04 Message: (Patch is against the Nov 2 snapshot.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2890983&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-06 20:56:02
|
Bugs item #2825690, was opened at 2009-07-22 19:49 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2825690&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: blks -A not working Initial Comment: >From John Lehr: Good Morning Group, I have a question about blkls, particularly the –a option. I am creating keyword search files with blkls and srch_strings, and I wanted to distinguish between allocated and unallocated, created one two text files for each type of block (ascii and unicode). For unallocated, I used something like: # blkls partition.dd | srch_strings –t d > text.file This produced a text file of ascii strings with byte offset from unallocated blocks as desired. For allocated, I tried: # blkls –a partition.dd | srch_strings –t d > text.file But, surprisingly, it looks like all blocks were exported from the partition, not just allocated blocks. (I piped blkls through ‘pv’ to meter the output and instead of getting the 83gb of allocated space, I got the whole 221gb partition). Confirmed by RB: Confirmed on 3.0.1/Gentoo: [test@test sleuthtest] dd if=/dev/zero of=ext2.img bs=1024 count=1024 1024+0 records in 1024+0 records out 1048576 bytes (1.0 MB) copied, 0.00636198 s, 165 MB/s [test@test sleuthtest] mkfs.ext2 -q ext2.img [test@test sleuthtest] md5sum ext2.img 3adb3f90e51cde1277036247809a051e ext2.img [test@test sleuthtest] blkls -a ext2.img | md5sum - 3adb3f90e51cde1277036247809a051e - [test@test sleuthtest] blkls -e ext2.img | md5sum - 3adb3f90e51cde1277036247809a051e - [test@test sleuthtest] blkls -A ext2.img | md5sum - b04822bb7365e95e9e73b770c8f44508 - ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-06 15:55 Message: Fixed in trunk. Flags were not being cleared and all files were therefore being searched. Sending trunk/CHANGES.txt Sending trunk/tools/fstools/blkls.cpp Transmitting file data .. Committed revision 120. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2825690&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-06 20:52:06
|
Bugs item #2891285, was opened at 2009-11-03 09:38 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2891285&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: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: unable to read file's content for a file on NTFS system Initial Comment: This issue is specific to NTFS file system only. TSK’s routine “tsk_fs_file_read” returns an error while trying to read content of a file (for "Bitmap Image.bmp" ) by some specific offset. Reading is done as a sequential reading from beginning to an end of a stream. Error message is “tsk_fs_read: Offset is too large for image: 2043904”. Error goes from a point where routine tries to read raw data from a “$Data” attribute – reading from data runs. Seems like error is at the routine where offset is calculated for NTFS for some particular data run. I tried the same set of files but on Ext3 and Fat32 file systems: no errors – content reading was done successfully. I supplied mentioned partitions to a posix-sample application (from a TSK‘s package) – the same result: reading data from a file fails always on NTFS, but succeeded for Ext3 and Fat32. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-06 15:52 Message: Fixed in trunk. Had to do with sanity check on reading last block of file system using the POSIX-style API. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/fs_io.c Transmitting file data .. Committed revision 119. ---------------------------------------------------------------------- Comment By: oncer oncer surname (oncer82) Date: 2009-11-04 04:25 Message: Here is a link to an image to reproduce the issue - http://rapidshare.com/files/302212622/simplefiles_ntfs.dd.html MD5: FEC9AFCB26A8DE34108AEB40854110F2 Problem file is "Bitmap Image.bmp" (inode 64). I've tried ICAT application: it read content of a problem file successfully. But POSIX-SAMPLE application unable to do the same task. But, - ICAT uses "tsk_fs_read_block" function for reading content. - POSIX-SAMPLE uses "tsk_fs_file_read" function for reading content. So, probably issue goes from the "tsk_fs_file_read" function. Also, here are links on Ext and Fat FiIe Systems that contain the same set of files. Applications works successfully with these images. http://rapidshare.com/files/302213151/simplefiles_ext3.dd.html MD5: 48F116F12B2C6DA6FDE2F0112B1DDB73 http://rapidshare.com/files/302213821/simplefiles_fat32.dd.html MD5: 2CB87CC602E90300C4499D93614600AD ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-03 19:23 Message: That error means that it is trying to read past the end of the file system. Can you do the following: - provide the size of the disk image - Use 'icat' to extract the file contents (icat -o OFFSET_OF_FILESYSTEM IMAGE_NAME INODE) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2891285&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-06 20:15:19
|
Feature Requests item #2893521, was opened at 2009-11-06 15:15 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2893521&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: Installer Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Allow libewf/afflib location to be specified Initial Comment: Currently, configure will search in standard locations for libewf and afflib. If a user installs the libraries in their home directory though, it will not be found. Add a feature to configure to allow user to specify the location. For example, some other programs allow the user to specify '--with-LIBXYZ=/my/path'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2893521&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-04 09:25:40
|
Bugs item #2891285, was opened at 2009-11-03 16:38 Message generated for change (Comment added) made by oncer82 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2891285&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: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: unable to read file's content for a file on NTFS system Initial Comment: This issue is specific to NTFS file system only. TSK’s routine “tsk_fs_file_read” returns an error while trying to read content of a file (for "Bitmap Image.bmp" ) by some specific offset. Reading is done as a sequential reading from beginning to an end of a stream. Error message is “tsk_fs_read: Offset is too large for image: 2043904”. Error goes from a point where routine tries to read raw data from a “$Data” attribute – reading from data runs. Seems like error is at the routine where offset is calculated for NTFS for some particular data run. I tried the same set of files but on Ext3 and Fat32 file systems: no errors – content reading was done successfully. I supplied mentioned partitions to a posix-sample application (from a TSK‘s package) – the same result: reading data from a file fails always on NTFS, but succeeded for Ext3 and Fat32. ---------------------------------------------------------------------- Comment By: oncer oncer surname (oncer82) Date: 2009-11-04 11:25 Message: Here is a link to an image to reproduce the issue - http://rapidshare.com/files/302212622/simplefiles_ntfs.dd.html MD5: FEC9AFCB26A8DE34108AEB40854110F2 Problem file is "Bitmap Image.bmp" (inode 64). I've tried ICAT application: it read content of a problem file successfully. But POSIX-SAMPLE application unable to do the same task. But, - ICAT uses "tsk_fs_read_block" function for reading content. - POSIX-SAMPLE uses "tsk_fs_file_read" function for reading content. So, probably issue goes from the "tsk_fs_file_read" function. Also, here are links on Ext and Fat FiIe Systems that contain the same set of files. Applications works successfully with these images. http://rapidshare.com/files/302213151/simplefiles_ext3.dd.html MD5: 48F116F12B2C6DA6FDE2F0112B1DDB73 http://rapidshare.com/files/302213821/simplefiles_fat32.dd.html MD5: 2CB87CC602E90300C4499D93614600AD ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-04 02:23 Message: That error means that it is trying to read past the end of the file system. Can you do the following: - provide the size of the disk image - Use 'icat' to extract the file contents (icat -o OFFSET_OF_FILESYSTEM IMAGE_NAME INODE) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2891285&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-04 08:21:40
|
Bugs item #2848155, was opened at 2009-09-01 04:34 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2848155&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: Mathew Monroe (mathewmonroe) Assigned to: Nobody/Anonymous (nobody) Summary: nt2unixtime truncates time Initial Comment: nt2unixtime() returns a uint32_t instead of a time_t or uint64_t. This is a problem when a file has its time set far in the future as the uint32_t will overflow and indicate the wrong timestamp. ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2009-11-04 09:21 Message: Brian, I have already started working on a library to support multiple date and time formats, for multiple file format libraries. It currently support filetime, fat date/time and only does formatting. If you decide to write your own routines, perhaps we could combine efforts. Joachim ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-10-29 16:45 Message: In one use of the function, the results are stored in a time_t value, which could be a 64-bit value on some systems. However, in the other places, the results are stored in a uint32_t value in TSK_FS_META, which is used across all file systems. I suppose I could change TSK to store all times as time_t. I specified uint32_t in the past so that consistent results would be found on all systems. If I use time_t, then systems that use 64-bit values may give different results than systems that use 32-bit values. ---------------------------------------------------------------------- Comment By: Mathew Monroe (mathewmonroe) Date: 2009-10-29 00:46 Message: It has been a while since I looked at the code, but I remember that nt2unixtime() was called in exactly one place and the results stored in a uint64_t. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-10-28 22:14 Message: Hmmm, not sure of the best way to solve this. time_t is still a 32-bit number on many systems, so simply using that won't solve it. If I use a 64-bit number, then it seems like I'll need to write my own date and time code to convert the value to a printable string (and take day light savings and timezones and such into account)... Unless there is an easier way that I am missing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2848155&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-04 01:13:10
|
Bugs item #2874852, was opened at 2009-10-08 12:07 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2874852&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: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Partition Table Sanity Checking Initial Comment: Currently, TSK stops processing a partition table when it finds a partition that starts outside of the image. Perhaps this should be relaxed so that it reports the results and then the user needs to figure out that it does not fit.... Reported by Simson Garfinkel. Note for Brian: This can be seen in the AV iso image from Simson. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-03 20:13 Message: Fixed in trunk. Sending vs/bsd.c Sending vs/dos.c Sending vs/gpt.c Sending vs/mac.c Sending vs/sun.c Transmitting file data ..... Committed revision 117. Fixed by only checking the first couple of partition table entries. This allows some sanity checking while allowing for some missing sectors. If this is still an issue, we'll need to push down the notion of when we are testing if data is really a given data type versus when it is specified and we can be more liberal when we are told that it is a given type and more conservative with sanity checking when we are guessing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2874852&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-04 00:30:25
|
Feature Requests item #2888281, was opened at 2009-10-28 16:05 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2888281&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: Add sector size autodetect code Initial Comment: It seems that we could add code to try some other sector sizes if autodetection during a file or volume system open fails. For example, in the _open commands, try different sector sizes (4096, etc.) if the default one fails to detect any known file or volume system. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-03 19:30 Message: r116 in trunk does this for mac partitions. Tries 4096 if 512 fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2888281&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-04 00:23:32
|
Bugs item #2891285, was opened at 2009-11-03 09:38 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2891285&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: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: unable to read file's content for a file on NTFS system Initial Comment: This issue is specific to NTFS file system only. TSK’s routine “tsk_fs_file_read” returns an error while trying to read content of a file (for "Bitmap Image.bmp" ) by some specific offset. Reading is done as a sequential reading from beginning to an end of a stream. Error message is “tsk_fs_read: Offset is too large for image: 2043904”. Error goes from a point where routine tries to read raw data from a “$Data” attribute – reading from data runs. Seems like error is at the routine where offset is calculated for NTFS for some particular data run. I tried the same set of files but on Ext3 and Fat32 file systems: no errors – content reading was done successfully. I supplied mentioned partitions to a posix-sample application (from a TSK‘s package) – the same result: reading data from a file fails always on NTFS, but succeeded for Ext3 and Fat32. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-03 19:23 Message: That error means that it is trying to read past the end of the file system. Can you do the following: - provide the size of the disk image - Use 'icat' to extract the file contents (icat -o OFFSET_OF_FILESYSTEM IMAGE_NAME INODE) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2891285&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-11-03 14:38:35
|
Bugs item #2891285, was opened at 2009-11-03 16:38 Message generated for change (Tracker Item Submitted) made by oncer82 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2891285&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: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: unable to read file's content for a file on NTFS system Initial Comment: This issue is specific to NTFS file system only. TSK’s routine “tsk_fs_file_read” returns an error while trying to read content of a file (for "Bitmap Image.bmp" ) by some specific offset. Reading is done as a sequential reading from beginning to an end of a stream. Error message is “tsk_fs_read: Offset is too large for image: 2043904”. Error goes from a point where routine tries to read raw data from a “$Data” attribute – reading from data runs. Seems like error is at the routine where offset is calculated for NTFS for some particular data run. I tried the same set of files but on Ext3 and Fat32 file systems: no errors – content reading was done successfully. I supplied mentioned partitions to a posix-sample application (from a TSK‘s package) – the same result: reading data from a file fails always on NTFS, but succeeded for Ext3 and Fat32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2891285&group_id=55685 |
1 message has been excluded from this view by a project administrator.
