sleuthkit-developers Mailing List for The Sleuth Kit (Page 28)
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-02 23:04:57
|
Bugs item #2890983, was opened at 2009-11-02 17:59 Message generated for change (Comment added) made by robjoyce 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: Open Resolution: None 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: 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-02 22:59:05
|
Bugs item #2890983, was opened at 2009-11-02 17:59 Message generated for change (Tracker Item Submitted) made by robjoyce 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2890983&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-29 15:58:56
|
Bugs item #2856526, was opened at 2009-09-10 19:29 Message generated for change (Comment added) made by robjoyce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856526&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: istat -b argument does nothing on HFS+ & NTFS Initial Comment: The -b argument to istat (limiting the number of blocks displayed) doesn't work on HFS+ and NTFS. For HFS+, I tried adding the hack of setting fs_file->meta->size in hfs_istat() befure the tsk_fs_file_walk() call -- as is done in fatfs.c and ffs.c -- but it didn't have any effect in the current trunk version. Probably because of the new attr code. But perhaps a better way to fix this, for all file systems, is to just enforce numblocks in the local print_addr_act() functions... this avoids the hack of temporarily changing the file size. The print_addr_act() void* argument can contain a field tracking the number of blocks printed. The downside is that we can't force _more_ blocks to be printed than the file has. ---------------------------------------------------------------------- >Comment By: Rob (robjoyce) Date: 2009-10-29 11:58 Message: Ah, I see. In our case, we didn't care about the block list in istat's output, so we'd do something like '-b 1'. For multi-gigabyte files, istat's normal output is 10s of megabytes (or more) long... a little awkward to deal with, especially when you're calling istat from another process. So it's not critical to us, just convenient. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-10-28 17:07 Message: Quick comment: The original goal of the feature was to force more blocks and not limit them. Specifically it was motivated by Ext2 because it set the size to 0, but the block pointers still existed. Did you find this in the other file systems because you need this feature or because you were just playing with them and noticed that they did not work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856526&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-29 15:45:04
|
Bugs item #2848155, was opened at 2009-08-31 21:34 Message generated for change (Comment added) made by carrier 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: Brian Carrier (carrier) Date: 2009-10-29 10: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-28 18: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 16: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-10-28 23:46:58
|
Bugs item #2848155, was opened at 2009-08-31 22:34 Message generated for change (Comment added) made by mathewmonroe 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: Mathew Monroe (mathewmonroe) Date: 2009-10-28 19: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 17: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-10-28 21:56:42
|
Bugs item #2848155, was opened at 2009-08-31 21:34 Message generated for change (Comment added) made by carrier 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: Brian Carrier (carrier) Date: 2009-10-28 16: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-10-28 21:48:55
|
Bugs item #2817257, was opened at 2009-07-06 00:37 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817257&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: Markin Vlad (markinvv) Assigned to: Nobody/Anonymous (nobody) Summary: bad DATA_RUN Initial Comment: sleuthkit-3.0-2009-6-16 on Linux 2.6.29.4 The mechanism of reading the files using a very bad DATA_RUN works on "large" files (for example, 20 GB). In fact, the library has not read the entire chain of blocks of the file, the program is blocked. If your RAM is limited, "large" file do not get read if it is highly fragmented. Perhaps it makes sense to build DATA_RUN file in the pthread, blocking the main program only if the address of the requested block is not yet available at DATA_RUN. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-10-28 16:48 Message: I'm not sure if I am following the problem here. Are you using the read API that allows you to read at a given offset into a buffer or using the callback methods? I'm not sure what you are referring to with the pthreads and main programs. TSK currently does not have any notion of threading (unfortunately). Can you give more details on this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817257&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-28 21:47:43
|
Bugs item #2856526, was opened at 2009-09-10 18:29 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856526&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: istat -b argument does nothing on HFS+ & NTFS Initial Comment: The -b argument to istat (limiting the number of blocks displayed) doesn't work on HFS+ and NTFS. For HFS+, I tried adding the hack of setting fs_file->meta->size in hfs_istat() befure the tsk_fs_file_walk() call -- as is done in fatfs.c and ffs.c -- but it didn't have any effect in the current trunk version. Probably because of the new attr code. But perhaps a better way to fix this, for all file systems, is to just enforce numblocks in the local print_addr_act() functions... this avoids the hack of temporarily changing the file size. The print_addr_act() void* argument can contain a field tracking the number of blocks printed. The downside is that we can't force _more_ blocks to be printed than the file has. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-10-28 16:07 Message: Quick comment: The original goal of the feature was to force more blocks and not limit them. Specifically it was motivated by Ext2 because it set the size to 0, but the block pointers still existed. Did you find this in the other file systems because you need this feature or because you were just playing with them and noticed that they did not work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856526&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-28 21:45:45
|
Bugs item #2817274, was opened at 2009-07-06 01:46 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817274&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: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Markin Vlad (markinvv) Assigned to: Nobody/Anonymous (nobody) Summary: REENTERANT problem Initial Comment: sleuthkit-3.0-2009-6-16 on Linux 2.6.29.4 The functions of the library to work with FF (libtsk3) not REENTERANT. They are difficult to use in multithreaded applications. For example, I need to simultaneously search the files and read the file. Preferably with the use of one object IMG_INFO and FS_INFO. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-10-28 16:45 Message: Duplicate of 2817264 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817274&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-28 21:43:50
|
Bugs item #2824457, was opened at 2009-07-20 15:10 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2824457&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: Cannot read last block with blkcat Initial Comment: If you try to read the last block of an image with blkcat, the beyond-end-of-disk check in fsk_fs_blkcat fails (it's off by one). The attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-10-28 16:43 Message: Fixed. Thanks. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/dcat_lib.c Transmitting file data .. Committed revision 115. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2824457&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-28 21:40:59
|
Bugs item #2848162, was opened at 2009-08-31 21:43 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2848162&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: Mathew Monroe (mathewmonroe) Assigned to: Nobody/Anonymous (nobody) Summary: tsk_fs_attr_read reads the wrong data Initial Comment: This bug existed in 3.0.1 and 3.0.2 but was temporarily fixed. However, when you refactored the function it seems to have crept back in. Line 1084 of fs_attr.c needs to be: if(data_run_cur->offset + data_run_cur->len <= The < that is there now needs to be a <=. Without this change you will try to read 0 bytes from the datarun before the one you actually want to read. The side effect being that byteoffset_toread is set to 0, causing the read in the correct datarun to fail. This is a critical bug because anyone using TSK to read not a block boundary can get invalid data. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-10-28 16:40 Message: Thanks. Fixed. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/fs_attr.c Transmitting file data .. Committed revision 114. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2848162&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-28 21:12:19
|
Bugs item #2856510, was opened at 2009-09-10 17:51 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856510&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Rob (robjoyce) Assigned to: Nobody/Anonymous (nobody) Summary: Snapshot buid fails on OS X Initial Comment: On Mac OS, libtoolize is called glibtoolize by default. So ./bootstrap fails on line 3. I've changed my ./bootstrap from && libtoolize \ to && ( libtoolize || glibtoolize ) \ Not the most elegant solution, but it works for me and doesn't break other platforms. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-10-28 16:12 Message: Checked in. Thanks. Sending trunk/bootstrap Transmitting file data . Committed revision 112. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856510&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-28 21:05:15
|
Feature Requests item #2888281, was opened at 2009-10-28 16:05 Message generated for change (Tracker Item Submitted) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2888281&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-28 21:03:26
|
Feature Requests item #2888280, was opened at 2009-10-28 16:03 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2888280&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: device sector size from image formats Initial Comment: Add code to get the device sector size from the ewf and aff file formats instead of assuming 512-bytes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2888280&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-28 21:02:36
|
Bugs item #2874854, was opened at 2009-10-08 12:10 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2874854&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: iPod Partition Table Initial Comment: An iPod image seems to be using 4096-byte sectors and TSK does not recognize the Mac partition table. Using '-o 0@4096' does not help. This needs to be resolved. Reported by Simson Garfinkel. There seem to be a couple of issues: - The sector size from the command line should be pushed through all of the code (instead of assuming a 512-byte sector). - It seems that if you give a 0@XXX value for '-o', then it ignores the sector size. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-10-28 16:02 Message: This is now fixed on the trunk. '-b' can be used to specify the sector size and this value is carried into all code instead of always assuming 512. Also removed support for specifying offset using '63@4096' format. The offset is now only a sector and the sector size is given via -b (if it is not 512). Need to add code to query AFFLIB for sector size. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-10-08 12:12 Message: Note that this also seems to apply to the file system in the image that Simson shared. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2874854&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-08 17:12:12
|
Bugs item #2874854, was opened at 2009-10-08 12:10 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2874854&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: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: iPod Partition Table Initial Comment: An iPod image seems to be using 4096-byte sectors and TSK does not recognize the Mac partition table. Using '-o 0@4096' does not help. This needs to be resolved. Reported by Simson Garfinkel. There seem to be a couple of issues: - The sector size from the command line should be pushed through all of the code (instead of assuming a 512-byte sector). - It seems that if you give a 0@XXX value for '-o', then it ignores the sector size. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-10-08 12:12 Message: Note that this also seems to apply to the file system in the image that Simson shared. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2874854&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-08 17:10:05
|
Bugs item #2874854, was opened at 2009-10-08 12:10 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2874854&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: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: iPod Partition Table Initial Comment: An iPod image seems to be using 4096-byte sectors and TSK does not recognize the Mac partition table. Using '-o 0@4096' does not help. This needs to be resolved. Reported by Simson Garfinkel. There seem to be a couple of issues: - The sector size from the command line should be pushed through all of the code (instead of assuming a 512-byte sector). - It seems that if you give a 0@XXX value for '-o', then it ignores the sector size. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2874854&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-10-08 17:07:35
|
Bugs item #2874852, was opened at 2009-10-08 12: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=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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2874852&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-09-11 23:25:12
|
Bugs item #2857258, was opened at 2009-09-11 19:25 Message generated for change (Tracker Item Submitted) made by robjoyce 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2857258&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-09-10 23:29:55
|
Bugs item #2856526, was opened at 2009-09-10 19:29 Message generated for change (Tracker Item Submitted) made by robjoyce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856526&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: istat -b argument does nothing on HFS+ & NTFS Initial Comment: The -b argument to istat (limiting the number of blocks displayed) doesn't work on HFS+ and NTFS. For HFS+, I tried adding the hack of setting fs_file->meta->size in hfs_istat() befure the tsk_fs_file_walk() call -- as is done in fatfs.c and ffs.c -- but it didn't have any effect in the current trunk version. Probably because of the new attr code. But perhaps a better way to fix this, for all file systems, is to just enforce numblocks in the local print_addr_act() functions... this avoids the hack of temporarily changing the file size. The print_addr_act() void* argument can contain a field tracking the number of blocks printed. The downside is that we can't force _more_ blocks to be printed than the file has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856526&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-09-10 22:51:22
|
Bugs item #2856510, was opened at 2009-09-10 18:51 Message generated for change (Tracker Item Submitted) made by robjoyce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856510&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: Rob (robjoyce) Assigned to: Nobody/Anonymous (nobody) Summary: Snapshot buid fails on OS X Initial Comment: On Mac OS, libtoolize is called glibtoolize by default. So ./bootstrap fails on line 3. I've changed my ./bootstrap from && libtoolize \ to && ( libtoolize || glibtoolize ) \ Not the most elegant solution, but it works for me and doesn't break other platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2856510&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-09-01 02:43:43
|
Bugs item #2848162, was opened at 2009-08-31 22:43 Message generated for change (Tracker Item Submitted) made by mathewmonroe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2848162&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: tsk_fs_attr_read reads the wrong data Initial Comment: This bug existed in 3.0.1 and 3.0.2 but was temporarily fixed. However, when you refactored the function it seems to have crept back in. Line 1084 of fs_attr.c needs to be: if(data_run_cur->offset + data_run_cur->len <= The < that is there now needs to be a <=. Without this change you will try to read 0 bytes from the datarun before the one you actually want to read. The side effect being that byteoffset_toread is set to 0, causing the read in the correct datarun to fail. This is a critical bug because anyone using TSK to read not a block boundary can get invalid data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2848162&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-09-01 02:34:40
|
Bugs item #2848155, was opened at 2009-08-31 22:34 Message generated for change (Tracker Item Submitted) made by mathewmonroe 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2848155&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-08-19 14:44:46
|
Bugs item #2840345, was opened at 2009-08-19 09:42 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2840345&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: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Meta tags not consistent for DOS partitions Initial Comment: TSK 3.0 changed the way that it identified unallocated space and added the notion of META volumes. This report identifies a few issues: - Extended volumes in other extended volumes were not marked as META (but the first extended partition is) - Should we be marking the Partition Table as Unallocated (currently we do because it is not inside of an explicit partition) - Should areas inside of extended partitions be considered unallocated even though they are technically allocated to the extended partition. ------------------- From: mj...@gm... Subject: [sleuthkit-users] bug in mmls 3.01 Date: August 8, 2009 5:28:46 PM EDT To: sle...@li... On my disk. I have 3 primary and one extended partition. In the extended partition, I have multiple logical volumes. When looking at the space between logical partitions, mmls version 2.52 shows 1 sector for the partition table on one line and 62 sectors unallocated on the next line. This is normal. However, version 3.01 shows one line (meta) for the partition table, but no line for the unallocated area. Offsets look strange too (lines 10,11). Ver 2.52: 05: 00:03 0156312450 0312581807 0156269358 Win95 Extended (0x0F) 06: ----- 0156312450 0156312450 0000000001 Extended Table (#1) 07: ----- 0156312451 0156312512 0000000062 Unallocated 08: 01:00 0156312513 0208844999 0052532487 Win95 FAT32 (0x0C) 09: 01:01 0208845000 0271498499 0062653500 DOS Extended (0x05) 10: ----- 0208845000 0208845000 0000000001 Extended Table (#2) 11: ----- 0208845001 0208845062 0000000062 Unallocated ver 3.01 05: Meta 0156312450 0312581807 0156269358 Win95 Extended (0x0F) 06: Meta 0156312450 0156312450 0000000001 Extended Table (#1) 07: ----- 0156312450 0156312512 0000000063 Unallocated 08: 01:00 0156312513 0208844999 0052532487 Win95 FAT32 (0x0C) 09: 01:01 0208845000 0271498499 0062653500 DOS Extended (0x05) 10: Meta 0208845000 0208845000 0000000001 Extended Table (#2) 11: 02:00 0208845063 0271498499 0062653437 Linux (0x83) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-08-19 09:44 Message: Resolved first issue of extended partitions not being marked as META. Sending trunk/CHANGES.txt Sending trunk/man/mmls.1 Sending trunk/tsk3/vs/dos.c Transmitting file data ... Committed revision 105. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2840345&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-08-19 14:42:46
|
Bugs item #2840345, was opened at 2009-08-19 09:42 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2840345&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: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Meta tags not consistent for DOS partitions Initial Comment: TSK 3.0 changed the way that it identified unallocated space and added the notion of META volumes. This report identifies a few issues: - Extended volumes in other extended volumes were not marked as META (but the first extended partition is) - Should we be marking the Partition Table as Unallocated (currently we do because it is not inside of an explicit partition) - Should areas inside of extended partitions be considered unallocated even though they are technically allocated to the extended partition. ------------------- From: mj...@gm... Subject: [sleuthkit-users] bug in mmls 3.01 Date: August 8, 2009 5:28:46 PM EDT To: sle...@li... On my disk. I have 3 primary and one extended partition. In the extended partition, I have multiple logical volumes. When looking at the space between logical partitions, mmls version 2.52 shows 1 sector for the partition table on one line and 62 sectors unallocated on the next line. This is normal. However, version 3.01 shows one line (meta) for the partition table, but no line for the unallocated area. Offsets look strange too (lines 10,11). Ver 2.52: 05: 00:03 0156312450 0312581807 0156269358 Win95 Extended (0x0F) 06: ----- 0156312450 0156312450 0000000001 Extended Table (#1) 07: ----- 0156312451 0156312512 0000000062 Unallocated 08: 01:00 0156312513 0208844999 0052532487 Win95 FAT32 (0x0C) 09: 01:01 0208845000 0271498499 0062653500 DOS Extended (0x05) 10: ----- 0208845000 0208845000 0000000001 Extended Table (#2) 11: ----- 0208845001 0208845062 0000000062 Unallocated ver 3.01 05: Meta 0156312450 0312581807 0156269358 Win95 Extended (0x0F) 06: Meta 0156312450 0156312450 0000000001 Extended Table (#1) 07: ----- 0156312450 0156312512 0000000063 Unallocated 08: 01:00 0156312513 0208844999 0052532487 Win95 FAT32 (0x0C) 09: 01:01 0208845000 0271498499 0062653500 DOS Extended (0x05) 10: Meta 0208845000 0208845000 0000000001 Extended Table (#2) 11: 02:00 0208845063 0271498499 0062653437 Linux (0x83) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2840345&group_id=55685 |
1 message has been excluded from this view by a project administrator.
