sleuthkit-developers Mailing List for The Sleuth Kit (Page 24)
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: Brian C. <ca...@sl...> - 2010-03-19 13:28:17
|
Hi RB, In general, I support the idea of supporting as many types of formats as people need so that the process can be as automated as possible for the user (instead of needing to do a lot of conversions). That being said, I think that how they get implemented (i.e. built into TSK or linked in with a specific library) will be different in each case. If there isn't a portable and easy to incorporate version of the libntfs sparse image format and it is relatively easy, then it may be easier to manually incorporate in. But, if there is a library that works on the platforms that people care about, then maybe that is the easiest... thanks, brian On Mar 18, 2010, at 12:46 PM, RB wrote: > There's a good bit of traffic lately about Sleuthkit supporting > "synthetic" images of various types, and I'm curious what others' > opinion is. I personally am of two minds - on one hand, most of these > images have other tools available that makes them accessible by > Sleuthkit (if in Linux only), and duplicating their efforts seems > backwards. On the other hand, I recognize the value of having that > integrated support, particularly for platforms that may not have the > same depth of facilities available. > > Some formats would be relatively trivial to duplicate - ntfsclone's > "special" format is simple, but isn't part of the core libntfs so > would have to be a standalone implementation. VMDK is more complex, > but is technically "supported" if indirectly. I like the idea of a > one-stop shop, particularly since I'm looking at using Sleuthkit more > and more on Windows, but sit the fence as to whether the duplication > is meritable. Thoughts? > > > RB > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
|
From: SourceForge.net <no...@so...> - 2010-03-18 17:42:26
|
Bugs item #2972721, was opened at 2010-03-18 12:38 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2972721&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: sorter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: lookup fails on listing mode on some systems Initial Comment: Some systems get a hash lookup error because the "length" is too long: Invalid argument (hdb_lookup: Invalid hash length: 4afdaf202c34d9912cc6cd8806a66014 -) The reason is because the "-" is not being removed. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-18 12:42 Message: Fixed by adding the cleanup check to the '-l' processing code. Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tools/sorter/sorter.base Sending trunk/NEWS.txt Sending trunk/tools/sorter/sorter.base Transmitting file data .... Committed revision 179. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2972721&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-18 17:38:32
|
Bugs item #2972721, was opened at 2010-03-18 12: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=2972721&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: sorter Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: lookup fails on listing mode on some systems Initial Comment: Some systems get a hash lookup error because the "length" is too long: Invalid argument (hdb_lookup: Invalid hash length: 4afdaf202c34d9912cc6cd8806a66014 -) The reason is because the "-" is not being removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2972721&group_id=55685 |
|
From: RB <ao...@gm...> - 2010-03-18 16:46:40
|
There's a good bit of traffic lately about Sleuthkit supporting "synthetic" images of various types, and I'm curious what others' opinion is. I personally am of two minds - on one hand, most of these images have other tools available that makes them accessible by Sleuthkit (if in Linux only), and duplicating their efforts seems backwards. On the other hand, I recognize the value of having that integrated support, particularly for platforms that may not have the same depth of facilities available. Some formats would be relatively trivial to duplicate - ntfsclone's "special" format is simple, but isn't part of the core libntfs so would have to be a standalone implementation. VMDK is more complex, but is technically "supported" if indirectly. I like the idea of a one-stop shop, particularly since I'm looking at using Sleuthkit more and more on Windows, but sit the fence as to whether the duplication is meritable. Thoughts? RB |
|
From: SourceForge.net <no...@so...> - 2010-03-18 14:40:49
|
Bugs item #2969376, was opened at 2010-03-12 08:18 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2969376&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: Invalid Priority: 5 Private: No Submitted By: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: initializing TSK directly from Physical Drive Initial Comment: I am initializing TSK directly from Physical device. Everything works fine under Windows. I use string like "\\.\PHYSICALDRIVE0" for initializing. But, i unable to initialize TSK properly under Linux ("/dev/sda1"). I use "tsk_img_open_sing" first, and than "tsk_vs_open" to get list of Partitions on a Hard Drive. "tsk_vs_open" fails under Linux. Actually, is this normal initializing TSK directly from Physical device? ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-18 09:40 Message: If you are processing 'sda1", then you should use tsk_fs_open because the 1 partition should contain a file system. If you want to process the volume, then you should be opening "/dev/sda". ---------------------------------------------------------------------- Comment By: oncer oncer surname (oncer82) Date: 2010-03-12 09:36 Message: Fails at case when first partition is NTFS and second is some Linux specific (this does not have matter). Fails on "tsk_vs_dos_open" function when loading primary table "dos_load_prim_table". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2969376&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-18 14:37:13
|
Feature Requests item #2972620, was opened at 2010-03-18 09:37 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2972620&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 Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Remove some 0 time entries Initial Comment: Look into methods for suppressing some of the 0 date entries in the timeline output of mactime. Specifically, this came up because not all file systems have a created date, so they have lots of Jan, 1970 entries for 'b' times. Perhaps, some flags or file system-specific settings should exist to suppress some of the times... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2972620&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-12 14:36:57
|
Bugs item #2969376, was opened at 2010-03-12 15:18 Message generated for change (Comment added) made by oncer82 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2969376&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: initializing TSK directly from Physical Drive Initial Comment: I am initializing TSK directly from Physical device. Everything works fine under Windows. I use string like "\\.\PHYSICALDRIVE0" for initializing. But, i unable to initialize TSK properly under Linux ("/dev/sda1"). I use "tsk_img_open_sing" first, and than "tsk_vs_open" to get list of Partitions on a Hard Drive. "tsk_vs_open" fails under Linux. Actually, is this normal initializing TSK directly from Physical device? ---------------------------------------------------------------------- Comment By: oncer oncer surname (oncer82) Date: 2010-03-12 16:36 Message: Fails at case when first partition is NTFS and second is some Linux specific (this does not have matter). Fails on "tsk_vs_dos_open" function when loading primary table "dos_load_prim_table". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2969376&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-12 13:18:32
|
Bugs item #2969376, was opened at 2010-03-12 15:18 Message generated for change (Tracker Item Submitted) made by oncer82 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2969376&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: initializing TSK directly from Physical Drive Initial Comment: I am initializing TSK directly from Physical device. Everything works fine under Windows. I use string like "\\.\PHYSICALDRIVE0" for initializing. But, i unable to initialize TSK properly under Linux ("/dev/sda1"). I use "tsk_img_open_sing" first, and than "tsk_vs_open" to get list of Partitions on a Hard Drive. "tsk_vs_open" fails under Linux. Actually, is this normal initializing TSK directly from Physical device? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2969376&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-04 07:21:18
|
Feature Requests item #2288736, was opened at 2008-11-15 08:48 Message generated for change (Comment added) made by negin99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=2288736&group_id=55687 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Better reports Initial Comment: Generate HTML or some other non-ASCII form of reports. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-04 10:51 Message: Hi! I'm eager to help with this issue but I have some questions about it: First, do you mean the reports that generated in file analysis mode? (ASCII, HEX, ASCII string) and second, would you please explain more in detail which format is preferable and give me some hints? Thanks a lot in advance and hope that I could help. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=2288736&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2010-02-21 02:10:43
|
Bugs item #2955899, was opened at 2010-02-20 20:54 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2955899&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: NTFS META_USED flag not always correct Initial Comment: The TSK_FS_META_FLAG_USED flag is not always correct when doing a meta_walk with NTFS because the attributes may have been used from a previous file and marked as not used. The current code just checks for the existence, not the flags. This effects orphan file finding. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-02-20 21:10 Message: Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/ntfs.c Sending trunk/NEWS.txt Sending trunk/tsk3/fs/ntfs.c Transmitting file data .... Committed revision 177. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2955899&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-21 01:54:30
|
Bugs item #2955899, was opened at 2010-02-20 20:54 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2955899&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: NTFS META_USED flag not always correct Initial Comment: The TSK_FS_META_FLAG_USED flag is not always correct when doing a meta_walk with NTFS because the attributes may have been used from a previous file and marked as not used. The current code just checks for the existence, not the flags. This effects orphan file finding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2955899&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-21 01:53:03
|
Bugs item #2955898, was opened at 2010-02-20 20:50 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2955898&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 Orphan Files Initial Comment: If a file system has no deleted file names, then no orphan files will be found. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-02-20 20:53 Message: Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/fs_dir.c Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fs_dir.c Transmitting file data .... Committed revision 176. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2955898&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-21 01:50:43
|
Bugs item #2955898, was opened at 2010-02-20 20:50 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2955898&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 Orphan Files Initial Comment: If a file system has no deleted file names, then no orphan files will be found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2955898&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-21 01:49:31
|
Bugs item #2954707, was opened at 2010-02-18 22:20 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954707&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: More ISO9660 missing files Initial Comment: While debugging issue 2954703, I came across some other issues with the same image. Specifically, in the 'dists' directory, the unstable entry is not being shown. It seems to be lost because of a conflict. This directory has "link" files that have 0 size and have the same starting block as another file. The lookup code is having problems with this.... A new design is needed for the ISO code. Perhaps multiple volume descriptors should not be supported and instead we use only one and use the byte offset of the directory entry as a lookup method. We could also store more simple data that simply matches the TSK determined inode number to the offset (and vice versa). ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-02-20 20:49 Message: Fixed by changing method that multiple volume descriptors are loaded. Files found from the other volume descriptors are treated as orphan files. offset of metadata is used to correlate directory names with "inode address". Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/iso9660.c Sending branches/sleuthkit-3.1/tsk3/fs/iso9660_dent.c Sending branches/sleuthkit-3.1/tsk3/fs/tsk_iso9660.h Sending trunk/tsk3/fs/iso9660.c Sending trunk/tsk3/fs/iso9660_dent.c Sending trunk/tsk3/fs/tsk_iso9660.h Transmitting file data ....... Committed revision 174. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954707&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-19 03:20:19
|
Bugs item #2954707, was opened at 2010-02-18 22:20 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954707&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: More ISO9660 missing files Initial Comment: While debugging issue 2954703, I came across some other issues with the same image. Specifically, in the 'dists' directory, the unstable entry is not being shown. It seems to be lost because of a conflict. This directory has "link" files that have 0 size and have the same starting block as another file. The lookup code is having problems with this.... A new design is needed for the ISO code. Perhaps multiple volume descriptors should not be supported and instead we use only one and use the byte offset of the directory entry as a lookup method. We could also store more simple data that simply matches the TSK determined inode number to the offset (and vice versa). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954707&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-19 03:14:44
|
Bugs item #2954703, was opened at 2010-02-18 22:08 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954703&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 ISO9660 file Initial Comment: Suhanov Maxim reported: I have tested TSK 3.1.0 with SMART-Ubuntu-2010-01-20.iso (http://asrdata2.com/) image and found that "fls" does not list all files listed by "ls" after mounting. Here is an output from both tools: $ fls -a /mnt/sda6/ISO/SMART-Ubuntu-2010-01-20.iso 1 d/d 1: . d/d 0: .. r/r 14: base_installable r/r 16: cd_type r/r 17: info r/r 18: release_notes_url $ ls -la итого 6 dr-xr-xr-x 2 root root 2048 2009-10-29 00:14 ./ dr-xr-xr-x 10 root root 2048 2010-01-20 01:52 ../ -r--r--r-- 1 root root 0 2009-10-29 00:14 base_installable -r--r--r-- 1 root root 37 2009-10-29 00:14 casper-uuid-generic -r--r--r-- 1 root root 15 2009-10-29 00:14 cd_type -r--r--r-- 1 root root 54 2009-10-29 00:14 info -r--r--r-- 1 root root 77 2009-10-29 00:14 release_notes_url "casper-uuid-generic" is missing in "fls" output. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-02-18 22:14 Message: Issue was because the previous file in the directory has zero size, but it claims to start at the same block as the missing file. Because of the lookup code, they was a conflict and it was lost. Fixed in both 3.1 branch and the trunk. Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/fs_dir.c Sending branches/sleuthkit-3.1/tsk3/fs/iso9660.c Sending branches/sleuthkit-3.1/tsk3/fs/iso9660_dent.c Sending branches/sleuthkit-3.1/tsk3/fs/tsk_iso9660.h Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fs_dir.c Sending trunk/tsk3/fs/iso9660.c Sending trunk/tsk3/fs/iso9660_dent.c Sending trunk/tsk3/fs/tsk_iso9660.h Transmitting file data .......... Committed revision 173. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954703&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-19 03:08:07
|
Bugs item #2954703, was opened at 2010-02-18 22:08 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954703&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 ISO9660 file Initial Comment: Suhanov Maxim reported: I have tested TSK 3.1.0 with SMART-Ubuntu-2010-01-20.iso (http://asrdata2.com/) image and found that "fls" does not list all files listed by "ls" after mounting. Here is an output from both tools: $ fls -a /mnt/sda6/ISO/SMART-Ubuntu-2010-01-20.iso 1 d/d 1: . d/d 0: .. r/r 14: base_installable r/r 16: cd_type r/r 17: info r/r 18: release_notes_url $ ls -la итого 6 dr-xr-xr-x 2 root root 2048 2009-10-29 00:14 ./ dr-xr-xr-x 10 root root 2048 2010-01-20 01:52 ../ -r--r--r-- 1 root root 0 2009-10-29 00:14 base_installable -r--r--r-- 1 root root 37 2009-10-29 00:14 casper-uuid-generic -r--r--r-- 1 root root 15 2009-10-29 00:14 cd_type -r--r--r-- 1 root root 54 2009-10-29 00:14 info -r--r--r-- 1 root root 77 2009-10-29 00:14 release_notes_url "casper-uuid-generic" is missing in "fls" output. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954703&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-18 21:38:35
|
Feature Requests item #2954460, was opened at 2010-02-18 16:38 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2954460&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 Group: None Status: Open Priority: 1 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: remove day of week from mactime output Initial Comment: It was suggested to remove the day of the week from the output. It wastes space and if you use -y and -m then it breaks external sorting (YYY-MM-DD (day_of_week) HH:MM:SS). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2954460&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-18 21:16:13
|
Bugs item #2954448, was opened at 2010-02-18 16:16 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954448&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Incorporate Debian fixes Initial Comment: The Debian package manager (Cristian Greco) fixed some typos and compile errors. Work them into the code: http://git.debian.org/?p=forensics/sleuthkit.git;a=summary ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954448&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-13 01:41:39
|
Bugs item #2950986, was opened at 2010-02-12 20:41 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950986&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: 7 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: HFS directories have 0 size Initial Comment: The size of a directory needs to be figured out. HFS doesn't store this info and TSK doesn't estimate it. This impacts Autopsy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950986&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-02-13 01:28:50
|
Bugs item #2470936, was opened at 2008-12-27 06:45 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=550912&aid=2470936&group_id=77673 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: Fixed Priority: 5 Private: No Submitted By: .FUF (fuf_bugs) Assigned to: Nobody/Anonymous (nobody) Summary: mac-robber fails on large files Initial Comment: mac-robber fails on large files Output (mac-robber): class|host|start_time body|Desktop|1230377643 md5|file|st_dev|st_ino|st_mode|st_ls|st_nlink|st_uid|st_gid|st_rdev|st_size|st_atime|st_mtime|st_ctime|st_blksize|st_blocks 0|./NSRL|2054|32374785|16877|drwxr-xr-x|3|1000|1000|0|4096|1230377605|1230377433|1230377433|4096|8 0|./NSRL/ISO|2054|32833537|16877|drwxr-xr-x|2|1000|1000|0|4096|1230377635|1230377634|1230377634|4096|8 0|./NSRL/ISO/RDS_222_C.iso|2054|32374791|33188|-rw-r--r--|1|1000|1000|0|313772032|1229853658|1229822385|1229853832|4096|613448 0|./NSRL/ISO/RDS_222_D.iso|2054|32374792|33188|-rw-r--r--|1|1000|1000|0|314124288|1229853734|1229822465|1229853832|4096|614136 0|./NSRL/ISO/RDS_222_A.iso|2054|32374790|33188|-rw-r--r--|1|1000|1000|0|313739264|1229853472|1229822427|1229853832|4096|613384 0|./NSRL/ISO/1.dat|2054|13|33188|-rw-r--r--|1|0|0|0|2147481600|1230377626|1230377484|1230377634|4096|4198408 0|./NSRL/ISO/RDS_222_B.iso|2054|32374789|33188|-rw-r--r--|1|1000|1000|0|314032128|1229853571|1229822459|1229853832|4096|613952 lstat error: ./NSRL/ISO/a.dat Output (ls -l): -rw-r--r-- 1 root root 2147481600 Дек 27 14:31 1.dat -rw-r--r-- 1 fuf fuf 313739264 Дек 21 04:20 RDS_222_A.iso -rw-r--r-- 1 fuf fuf 314032128 Дек 21 04:20 RDS_222_B.iso -rw-r--r-- 1 fuf fuf 313772032 Дек 21 04:19 RDS_222_C.iso -rw-r--r-- 1 fuf fuf 314124288 Дек 21 04:21 RDS_222_D.iso -rw-r--r-- 1 root root 2147483648 Дек 27 14:29 a.dat ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-02-12 20:28 Message: Fixed by providing a Linux compile target that adds the needed large file flags. Sending trunk/Makefile Sending trunk/README Transmitting file data .. Committed revision 8. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-02-12 13:53 Message: This works fine on my Mac: ls -l [...] -rw-r--r-- 1 carrier staff 3145728000 Feb 12 13:49 test-file mac-robber: 0|tmp/test-file|0|-rw-r--r--|501|20|3145728000|1266000517|1266000581|1266000581|0 I suppose that if this were on a Linux system, then the needed large file size compile flags would be needed.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=550912&aid=2470936&group_id=77673 |
|
From: SourceForge.net <no...@so...> - 2010-02-12 18:39:50
|
Bugs item #2932385, was opened at 2010-01-14 17:17 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2932385&group_id=55687 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Sorter error Initial Comment: Reported by Suhanov Maxim: And I also found another bug in "Sort Files by Type" feature in new Autopsy: when not selecting "Extension and File Type Validation" checkbox and then clicking "OK" the following message appears: "Incorrect file system type (-f ntfs)". Here is an output: " ... http://localhost:9999/autopsy Keep this process running and use <ctrl-c> to exit Can't ignore signal CHLD, forcing to default. Unsupported image type: -n usage: /usr/local/bin/fsstat [-tvV] [-f fstype] [-i imgtype] [-b dev_sector_size] [-o imgoffset] image -t: display type only -i imgtype: The format of the image file (use '-i list' for supported types) -b dev_sector_size: The size (in bytes) of the device sectors -f fstype: File system type (use '-f list' for supported types) -o imgoffset: The offset of the file system in the image (in sectors) -v: verbose output to stderr -V: Print version Can't ignore signal CHLD, forcing to default. Unsupported image type: -s usage: /usr/local/bin/fsstat [-tvV] [-f fstype] [-i imgtype] [-b dev_sector_size] [-o imgoffset] image -t: display type only -i imgtype: The format of the image file (use '-i list' for supported types) -b dev_sector_size: The size (in bytes) of the device sectors -f fstype: File system type (use '-f list' for supported types) -o imgoffset: The offset of the file system in the image (in sectors) -v: verbose output to stderr -V: Print version " ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-02-12 13:39 Message: Sending trunk/CHANGES.txt Sending trunk/lib/Appsort.pm Transmitting file data .. Committed revision 28. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2932385&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2010-02-12 18:36:39
|
Bugs item #2779244, was opened at 2009-04-23 01:25 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2779244&group_id=55687 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: .FUF (fuf_bugs) Assigned to: Brian Carrier (carrier) Summary: Autopsy looks for sorter configs in wrong path. Initial Comment: Autopsy looks for sorter configs in wrong path. lib/Appsort.pm: my $config = "$::TSKDIR/../share/tsk/sorter/images.sort"; Should be: lib/Appsort.pm: my $config = "$::TSKDIR/../share/tsk3/sorter/images.sort"; ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-02-12 13:36 Message: Sending trunk/CHANGES.txt Sending trunk/lib/Appsort.pm Transmitting file data .. Committed revision 28. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2779244&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2010-02-12 18:34:26
|
Bugs item #2950693, was opened at 2010-02-12 11:52 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2950693&group_id=55687 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 1 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: keywords with quotes not seen Initial Comment: when a keyword search is done with " in the word, it is lost in the "previous search list" because the quotes need to be escaped: <input type="SUBMIT" value=""foo"|ascii (0)"><br></form> need to verify that escaping in that page will result in the correct search afterwards. reported by Stefan Kelm. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-02-12 13:34 Message: Sending CHANGES.txt Sending lib/Kwsrch.pm Transmitting file data .. Committed revision 27. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=2950693&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2010-02-12 17:45:34
|
Bugs item #2944673, was opened at 2010-02-02 10:25 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2944673&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: Fixed Priority: 7 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: mac-robber needs updating Initial Comment: mac-robber needs to be updated to reflect the new body format. Reported by Andrew Hoog and Steve Bonds. Patch from Andrew: ahoog@wintermute:~/src/mac-robber-1.00$ diff /home/ahoog/mac-robber.c mac-robber.c 108c108,109 < printf("MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime\n"); --- > printf("md5|file|st_dev|st_ino|st_mode|st_ls|st_nlink|st_uid|st_gid|"); > printf("st_rdev|st_size|st_atime|st_mtime|st_ctime|st_blksize|st_blocks\n"); 286,291c287,297 < printf("0|%s|0|%s%s%s|%d|%d|%lu|%lu|%lu|0|%lu\n", < curpath, ls, ((sp.st_mode & S_IFMT) == S_IFLNK)?" -> ":"", < ((sp.st_mode & S_IFMT) == S_IFLNK)?linkpath:"", < (int)sp.st_uid, (int)sp.st_gid, (unsigned long)sp.st_size, < (unsigned long)sp.st_atime, (unsigned long)sp.st_mtime, < (unsigned long)sp.st_ctime); --- > printf("0|%s|%d|%lu|%lu|%s%s%s|%d|%d|%d|%d|%lu|%lu|%lu|%lu|%lu|%lu\n", > curpath, (int)sp.st_dev, (unsigned long)sp.st_ino, > (unsigned long)sp.st_mode, ls, > ((sp.st_mode & S_IFMT) == S_IFLNK)?" -> ":"", > ((sp.st_mode & S_IFMT) == S_IFLNK)?linkpath:"", > (int)sp.st_nlink, > (int)sp.st_uid, (int)sp.st_gid, (int)sp.st_rdev, > (unsigned long)sp.st_size, (unsigned long)sp.st_atime, > (unsigned long)sp.st_mtime, (unsigned long)sp.st_ctime, > (unsigned long)sp.st_blksize, (unsigned long)sp.st_blocks); > ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-02-12 12:45 Message: Fixed in 1.01 release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2944673&group_id=55685 |
1 message has been excluded from this view by a project administrator.
