sleuthkit-developers Mailing List for The Sleuth Kit (Page 22)
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(22) |
Feb
(39) |
Mar
(8) |
Apr
(17) |
May
(10) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(4) |
| 2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(9) |
Jul
(14) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
| 2009 |
Jan
(7) |
Feb
(10) |
Mar
(10) |
Apr
(19) |
May
(16) |
Jun
(3) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(16) |
Nov
(35) |
Dec
(30) |
| 2010 |
Jan
(4) |
Feb
(24) |
Mar
(25) |
Apr
(31) |
May
(11) |
Jun
(9) |
Jul
(11) |
Aug
(31) |
Sep
(11) |
Oct
(10) |
Nov
(15) |
Dec
(3) |
| 2011 |
Jan
(8) |
Feb
(17) |
Mar
(14) |
Apr
(2) |
May
(4) |
Jun
(4) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(8) |
Nov
(16) |
Dec
(1) |
| 2012 |
Jan
(9) |
Feb
(2) |
Mar
(3) |
Apr
(13) |
May
(10) |
Jun
(7) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(3) |
| 2013 |
Jan
(16) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(18) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
| 2015 |
Jan
(5) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(23) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: SourceForge.net <no...@so...> - 2010-05-17 02:39:03
|
Bugs item #2993804, was opened at 2010-04-28 15:25 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993804&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: tsk_fs_file_read() can go past end of file Initial Comment: - Add check if offset is past end of file >From Michael Cohen to dev list: Hi All, Im currently putting my finishing touches on the new tsk3.x python bindings and i noticed some slightly weird behaviour. When calling tsk_fs_file_read you can specify flags which are of type enum TSK_FS_FILE_READ_FLAG_ENUM this enum can take on two values: TSK_FS_FILE_READ_FLAG_SLACK Allow read access into slack space. (value 0x01) TSK_FS_FILE_READ_FLAG_NOID Ignore the Id argument given in the API (use only the type). (value 0x02) A notable exception is the default case of actually reading the file until the end of the file but not including the slack. Indeed if i try to read past the end of the file it always gives me the slack even if i specify 0 for flags (which is technically not a valid value for this enum). I am currently working around this by pulling the size of the file and making sure not to read past it and into the slack. This is the behabiour i can see (my file is 385865 bytes long): 1) tsk_fs_file_read( offset =0, length = 10m) -> 385865 2) tsk_fs_file_read( offset =385865, length = 10m) -> 7351 (which is the slack) 3) tsk_fs_file_read( offset =393216) -> -1 Should there be a default value for flags (say 0x00) which actually stops reading at the end of the file? (in the above step 2 should fail?) Michael. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-05-16 21:39 Message: Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tests/read_apis.cpp Sending branches/sleuthkit-3.1/tsk3/fs/fs_attr.c Sending branches/sleuthkit-3.1/tsk3/fs/ntfs.c Sending trunk/NEWS.txt Sending trunk/tests/read_apis.cpp Sending trunk/tsk3/fs/fs_attr.c Sending trunk/tsk3/fs/ntfs.c Transmitting file data ........ Committed revision 203. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993804&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-05-15 02:41:06
|
Bugs item #2999567, was opened at 2010-05-10 14:50 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2999567&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: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: ifind displays 'all' inodes by default Initial Comment: ifind is displaying all inodes by default, as though the '-a' argument is provided. In otherwords, 'ifind <image> <inode>' results in the same output as 'ifind -a <image> <inode>'. This makes scripting more difficult. This behavior is occurring in an NTFS partition selected from an ewf disk image with sleuthkit v3.1.1 in Ubuntu 9.10 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-05-14 21:41 Message: Thanks! Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/ifind_lib.c Sending trunk/NEWS.txt Sending trunk/tsk3/fs/ifind_lib.c Transmitting file data .... Committed revision 202. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2999567&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-05-10 19:50:45
|
Bugs item #2999567, was opened at 2010-05-10 12:50 Message generated for change (Tracker Item Submitted) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2999567&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: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: ifind displays 'all' inodes by default Initial Comment: ifind is displaying all inodes by default, as though the '-a' argument is provided. In otherwords, 'ifind <image> <inode>' results in the same output as 'ifind -a <image> <inode>'. This makes scripting more difficult. This behavior is occurring in an NTFS partition selected from an ewf disk image with sleuthkit v3.1.1 in Ubuntu 9.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2999567&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-29 10:12:02
|
Bugs item #2994088, was opened at 2010-04-29 13:12 Message generated for change (Tracker Item Submitted) made by oncer82 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2994088&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: no flag set for NTFS encrypted/compressed file. Initial Comment: I analize NTFS dd-image content with TSK. Deal with TSK_FS_FILE instances opened for each found File. There are a lot of files that are Compressed or Encrypted by NTFS on a partition, and there are no any flag set (i suppose this should be TSK_FS_META_FLAG_COMP set) for such files that indicates on a fact that they are compressed. Is this correct behavior ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2994088&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2010-04-28 20:27:32
|
Thanks Michael. I added bug tracker entries for both of these. The new ENUM settings will probably be added to the next major release. I'll fix the offset for the next minor release. On Apr 26, 2010, at 10:51 AM, Michael Cohen wrote: > Hi All, > Im currently putting my finishing touches on the new tsk3.x python > bindings and i noticed some slightly weird behaviour. > > When calling tsk_fs_file_read you can specify flags which are of type > enum TSK_FS_FILE_READ_FLAG_ENUM this enum can take on two values: > > TSK_FS_FILE_READ_FLAG_SLACK Allow read access into slack space. (value 0x01) > TSK_FS_FILE_READ_FLAG_NOID Ignore the Id argument given in the API > (use only the type). (value 0x02) > > A notable exception is the default case of actually reading the file > until the end of the file but not including the slack. > > Indeed if i try to read past the end of the file it always gives me > the slack even if i specify 0 for flags (which is technically not a > valid value for this enum). I am currently working around this by > pulling the size of the file and making sure not to read past it and > into the slack. > > This is the behabiour i can see (my file is 385865 bytes long): > > 1) tsk_fs_file_read( offset =0, length = 10m) -> 385865 > 2) tsk_fs_file_read( offset =385865, length = 10m) -> 7351 (which is the slack) > 3) tsk_fs_file_read( offset =393216) -> -1 > > Should there be a default value for flags (say 0x00) which actually > stops reading at the end of the file? (in the above step 2 should > fail?) > > Michael. > > ------------------------------------------------------------------------------ > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
|
From: SourceForge.net <no...@so...> - 2010-04-28 20:26:44
|
Bugs item #2993806, was opened at 2010-04-28 15:26 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993806&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: Add enum value for no flags Initial Comment: Some of the enums don't have a setting for no flags (such as TSK_FS_FILE_READ_FLAG_ENUM). Add a setting that represents no flags. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993806&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-28 20:25:45
|
Bugs item #2993804, was opened at 2010-04-28 15:25 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993804&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: tsk_fs_file_read() can go past end of file Initial Comment: - Add check if offset is past end of file >From Michael Cohen to dev list: Hi All, Im currently putting my finishing touches on the new tsk3.x python bindings and i noticed some slightly weird behaviour. When calling tsk_fs_file_read you can specify flags which are of type enum TSK_FS_FILE_READ_FLAG_ENUM this enum can take on two values: TSK_FS_FILE_READ_FLAG_SLACK Allow read access into slack space. (value 0x01) TSK_FS_FILE_READ_FLAG_NOID Ignore the Id argument given in the API (use only the type). (value 0x02) A notable exception is the default case of actually reading the file until the end of the file but not including the slack. Indeed if i try to read past the end of the file it always gives me the slack even if i specify 0 for flags (which is technically not a valid value for this enum). I am currently working around this by pulling the size of the file and making sure not to read past it and into the slack. This is the behabiour i can see (my file is 385865 bytes long): 1) tsk_fs_file_read( offset =0, length = 10m) -> 385865 2) tsk_fs_file_read( offset =385865, length = 10m) -> 7351 (which is the slack) 3) tsk_fs_file_read( offset =393216) -> -1 Should there be a default value for flags (say 0x00) which actually stops reading at the end of the file? (in the above step 2 should fail?) Michael. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993804&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-28 20:13:28
|
Bugs item #2993767, was opened at 2010-04-28 14:01 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993767&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: 9 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: Slow FAT OrphanFile Listing Initial Comment: Jamie Butler and Aaron LeMasters reported that they had a FAT32 image that seemed to be getting into an infinite loop and was not stopping. Debugging showed that it was occurring while listing the contents of the OrphanFiles directory. Specifically: - The orphanFiles were found relatively quickly, but when they were recursed into, TSK found a directory. It then proceeded to search for its parent directory. This started a dir_walk from the root, which went into $OrphanFiles. This data was not cached and therefore another search was conducted. - After the second orphanFile hunt, the hunt for the parent directory continued and it did not find the parent directory because it was looking for allocated files only. It doesn't seem to be as much of a problem with infinite loops as much of as a problem with way too many tree traverses. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-04-28 15:13 Message: - Parent search now looks for deleted entries. - Orphan directory contents are now cached. Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/fatfs_dent.c Sending branches/sleuthkit-3.1/tsk3/fs/fs_dir.c Sending branches/sleuthkit-3.1/tsk3/fs/fs_name.c Sending branches/sleuthkit-3.1/tsk3/fs/tsk_fs.h Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fatfs_dent.c Sending trunk/tsk3/fs/fs_dir.c Sending trunk/tsk3/fs/fs_name.c Sending trunk/tsk3/fs/tsk_fs.h Transmitting file data .......... Committed revision 200. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993767&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-28 19:52:31
|
Feature Requests item #2993792, was opened at 2010-04-28 14:52 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2993792&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: tsk_fs_realloc that wipes data Initial Comment: The current tsk_fs_malloc will memset the buffer. realloc() doesn't. One should be created that does... tsk_fs_dir_realloc() now has code that does the wiping by itself because one image ran into problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2993792&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-28 19:01:39
|
Bugs item #2993767, was opened at 2010-04-28 14:01 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993767&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: 9 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: Slow FAT OrphanFile Listing Initial Comment: Jamie Butler and Aaron LeMasters reported that they had a FAT32 image that seemed to be getting into an infinite loop and was not stopping. Debugging showed that it was occurring while listing the contents of the OrphanFiles directory. Specifically: - The orphanFiles were found relatively quickly, but when they were recursed into, TSK found a directory. It then proceeded to search for its parent directory. This started a dir_walk from the root, which went into $OrphanFiles. This data was not cached and therefore another search was conducted. - After the second orphanFile hunt, the hunt for the parent directory continued and it did not find the parent directory because it was looking for allocated files only. It doesn't seem to be as much of a problem with infinite loops as much of as a problem with way too many tree traverses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993767&group_id=55685 |
|
From: Michael C. <scu...@gm...> - 2010-04-26 14:51:09
|
Hi All, Im currently putting my finishing touches on the new tsk3.x python bindings and i noticed some slightly weird behaviour. When calling tsk_fs_file_read you can specify flags which are of type enum TSK_FS_FILE_READ_FLAG_ENUM this enum can take on two values: TSK_FS_FILE_READ_FLAG_SLACK Allow read access into slack space. (value 0x01) TSK_FS_FILE_READ_FLAG_NOID Ignore the Id argument given in the API (use only the type). (value 0x02) A notable exception is the default case of actually reading the file until the end of the file but not including the slack. Indeed if i try to read past the end of the file it always gives me the slack even if i specify 0 for flags (which is technically not a valid value for this enum). I am currently working around this by pulling the size of the file and making sure not to read past it and into the slack. This is the behabiour i can see (my file is 385865 bytes long): 1) tsk_fs_file_read( offset =0, length = 10m) -> 385865 2) tsk_fs_file_read( offset =385865, length = 10m) -> 7351 (which is the slack) 3) tsk_fs_file_read( offset =393216) -> -1 Should there be a default value for flags (say 0x00) which actually stops reading at the end of the file? (in the above step 2 should fail?) Michael. |
|
From: SourceForge.net <no...@so...> - 2010-04-23 18:31:32
|
Bugs item #2991487, was opened at 2010-04-23 12:45 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2991487&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 files with zeroed content Initial Comment: Jamie Butler and Aaron LeMasters reported that an NTFS file had zeros in it instead of content. They tracked it down to the INITSIZE code in tsk_fs_attr_read() and found that commenting it out solved the problem. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-04-23 13:31 Message: Fixed error in the offset calculation. Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/fs_attr.c Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fs_attr.c Transmitting file data .... Committed revision 198. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2991487&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-23 17:45:27
|
Bugs item #2991487, was opened at 2010-04-23 12:45 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2991487&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 files with zeroed content Initial Comment: Jamie Butler and Aaron LeMasters reported that an NTFS file had zeros in it instead of content. They tracked it down to the INITSIZE code in tsk_fs_attr_read() and found that commenting it out solved the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2991487&group_id=55685 |
|
From: Al M. <alp...@gm...> - 2010-04-21 21:50:34
|
On Fri, Apr 16, 2010 at 3:15 PM, Brian Carrier <ca...@sl...> wrote: > On Apr 13, 2010, at 3:34 PM, Al MailingList wrote: > >> Sorry it took a while. >> >> Ran it, >> >> Got something along the lines of: >> >> Side bye side configuration information for fls.exe contains errors. >> Apllication has failed to start... >> Side bye side configuration information for Libewf.dll contains >> errors. Application has failed to start... >> >> At least one delay - load dependency was not found >> At least one module has a unresolved import due to a missing export >> function in a delay-load dependent module >> >> Msjava.dll error opening file the system cannot find the file specified (2) >> >> And Msjava.dll had a little error symbol next to it and was red. >> > > Strange. I don't have Msjava.dll listed as a dependency when I run depends.exe on my system. If I sort the modules by name in the bottom of the window and copy them out, I get the below list. Can you do a similar thing and maybe we can find out what is different. To be clear, you are using the executables from the sleuthkit.org website and you didn't compile these manually, right? > > thanks, > brian > > > > ACTIVEDS.DLL > ADSLDPC.DLL ... > XMLLITE.DLL > ZLIB1.DLL > > Gah. Sorry about this Brian, but the machine has been rebuilt by another team and is back in service I think :( I was using the executables, not building from source. I grabbed the latest - 3.1.1 from the web site. When I had the issue mentioned with those, I went back to 3.0.1 which worked fine. It does seem very odd that you don't have the same dependencies..... Maybe someone else will see a similar issue and report it? Apologies. Al |
|
From: SourceForge.net <no...@so...> - 2010-04-21 15:19:59
|
Feature Requests item #2990458, was opened at 2010-04-21 10:19 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2990458&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: 64-bit Windows execs Initial Comment: Rob Lee requested a 64-bit build of the executables for Windows to help with this: http://blogs.sans.org/computer-forensics/2010/03/16/shadow-timelines-and-other-shadowvolumecopy-digital-forensics-techniques-with-the-sleuthkit-on-windows/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2990458&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-21 13:23:55
|
Feature Requests item #2990416, was opened at 2010-04-21 15:23 Message generated for change (Tracker Item Submitted) made by wlet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2990416&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: Wlet (wlet) Assigned to: Nobody/Anonymous (nobody) Summary: Please add XFS Support Initial Comment: Hi, please add XFS support for TSK. Thanks in advance. wlet ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2990416&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2010-04-21 01:53:37
|
Thanks Aaron. I checked these in. This NULL reference actually isn't an issue because the previous if() takes care of that case, but I rewrote it to make it more clear.
Thanks!
brian
On Apr 19, 2010, at 6:00 AM, Aaron Burghardt wrote:
> Hi,
>
> I ran Xcode's static analyzer on TSK and it flagged this error:
>
> .../sleuthkit/xcode/../tsk3/fs/ntfs_dent.c:123:31: warning: Dereference of null pointer
> prev->next = map;
> ^
>
> The context is below, which is appears to be a legitimate error:
>
> else {
> NTFS_PAR_MAP *prev = NULL;
> // somewhere in the middle of the list
> for (tmp = ntfs->orphan_map; tmp; tmp = tmp->next) {
> if (tmp->par_addr > par) {
> map->next = tmp;
> prev->next = map;
> break;
> }
> prev = tmp;
> }
>
> // at the end of the list
> if (map->next == NULL)
> prev->next = map;
> }
>
>
> Regards,
>
> Aaron
>
>
> ------------------------------------------------------------------------------
> 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: Aaron B. <aar...@gm...> - 2010-04-19 10:00:40
|
Hi,
I ran Xcode's static analyzer on TSK and it flagged this error:
.../sleuthkit/xcode/../tsk3/fs/ntfs_dent.c:123:31: warning: Dereference of null pointer
prev->next = map;
^
The context is below, which is appears to be a legitimate error:
else {
NTFS_PAR_MAP *prev = NULL;
// somewhere in the middle of the list
for (tmp = ntfs->orphan_map; tmp; tmp = tmp->next) {
if (tmp->par_addr > par) {
map->next = tmp;
prev->next = map;
break;
}
prev = tmp;
}
// at the end of the list
if (map->next == NULL)
prev->next = map;
}
Regards,
Aaron
|
|
From: Aaron B. <aar...@gm...> - 2010-04-19 09:53:01
|
Hi,
I got the following warning from Xcode's Clang compiler (I included all the detail to show the excellent error reporting from Clang. View with a monospace font). The variable "r" is declared as TSKConversionResult, which is an enum. sizeof() an enum on Mac OS X is 32-bits for both 32-bit and 64-bit architectures, but I don't know about other platforms.
Aaron
sleuthkit/xcode/../tsk3/fs/hfs_dent.c:127:10:{127:9-128:72}{127:9-128:72}: warning: conversion specifies type 'unsigned char' but the argument has type 'unsigned int' [-Wformat]
snprintf(tsk_errstr, TSK_ERRSTR_L,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sleuthkit/xcode/../tsk3/fs/hfs_dent.c:128:60: note: instantiated from:
"hfs_uni2ascii: unicode conversion failed (%" PRIu8 ")", r);
~~~^~~~~ ~
In file included from sleuthkit/xcode/../tsk3/fs/hfs_dent.c:72:
In file included from sleuthkit/xcode/../tsk3/fs/tsk_fs_i.h:39:
In file included from sleuthkit/xcode/../tsk3/base/tsk_base_i.h:26:
In file included from sleuthkit/xcode/../tsk3/base/tsk_base.h:52:
In file included from sleuthkit/xcode/../tsk3/tsk_incs.h:8:
/usr/include/inttypes.h:60:52: note: instantiated from:
# define PRIu8 __PRI_8_LENGTH_MODIFIER__ "u"
^
|
|
From: Brian C. <ca...@sl...> - 2010-04-17 00:03:26
|
Thanks for the report. It is now fixed in the 3.1 branch and trunk. On Apr 15, 2010, at 2:57 PM, BIT Sección Técnica wrote: > I found a bug in the command mmls -B, when you used this command the size in GB is always 0. > > I'd like to know how to solve this problem if it is possible. > > Another question is what is happening with delete HFS files, can sleuth kit retrieve or show this kind of files?. > > Thank you very much. > > ------------------------------------------------------------------------------ > 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-04-17 00:02:20
|
Bugs item #2978574, was opened at 2010-03-29 07:54 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2978574&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Wlet (wlet) Assigned to: Nobody/Anonymous (nobody) Summary: Feature Request: Please add XFS Support Initial Comment: Hi, please add XFS Support for TSK. THX wlet ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-04-16 19:02 Message: This is a feature request. Please add it to that tracker. https://sourceforge.net/tracker/?atid=477892&group_id=55685 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2978574&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-17 00:00:54
|
Bugs item #2988330, was opened at 2010-04-16 08:58 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2988330&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: NTFS.c offset error: Initial Comment: >From Jamie Butler: Line 3128 in ntfs_proc_sii should be for (sii_buffer_offset = 0; sii_buffer_offset < sii_buffer->size; sii_buffer_offset += ntfs->idx_rsize_b) AND NOT for (sii_buffer_offset = 0; sii_buffer_offset < sii_buffer->size; sii_buffer_offset += ntfs->csize_b) { csize_b and idx_rsize_b are not necessarily the same number. This can cause a GPF. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-04-16 19:00 Message: Fixed. Thanks. 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 193. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2988330&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-16 23:12:34
|
Bugs item #2988619, was opened at 2010-04-16 18:08 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2988619&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: Brian Carrier (carrier) Summary: mmls -B errors Initial Comment: >From BIT Sección Técnica on sleuthkit-dev: I found a bug in the command mmls -B, when you used this command the size in GB is always 0. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-04-16 18:12 Message: Thanks! Fixed. Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tools/vstools/mmls.cpp Sending trunk/NEWS.txt Sending trunk/tools/vstools/mmls.cpp Transmitting file data .... Committed revision 192. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2988619&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-16 23:08:36
|
Bugs item #2988619, was opened at 2010-04-16 18: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=2988619&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: Brian Carrier (carrier) Summary: mmls -B errors Initial Comment: >From BIT Sección Técnica on sleuthkit-dev: I found a bug in the command mmls -B, when you used this command the size in GB is always 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2988619&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2010-04-16 14:15:20
|
On Apr 13, 2010, at 3:34 PM, Al MailingList wrote: > Sorry it took a while. > > Ran it, > > Got something along the lines of: > > Side bye side configuration information for fls.exe contains errors. > Apllication has failed to start... > Side bye side configuration information for Libewf.dll contains > errors. Application has failed to start... > > At least one delay - load dependency was not found > At least one module has a unresolved import due to a missing export > function in a delay-load dependent module > > Msjava.dll error opening file the system cannot find the file specified (2) > > And Msjava.dll had a little error symbol next to it and was red. > Strange. I don't have Msjava.dll listed as a dependency when I run depends.exe on my system. If I sort the modules by name in the bottom of the window and copy them out, I get the below list. Can you do a similar thing and maybe we can find out what is different. To be clear, you are using the executables from the sleuthkit.org website and you didn't compile these manually, right? thanks, brian ACTIVEDS.DLL ADSLDPC.DLL ADVAPI32.DLL ADVPACK.DLL APPHELP.DLL ATL.DLL AUTHZ.DLL BROWSEUI.DLL CABINET.DLL CDFVIEW.DLL CERTCLI.DLL CFGMGR32.DLL CLUSAPI.DLL COMCTL32.DLL COMDLG32.DLL CREDUI.DLL CRYPT32.DLL CRYPTUI.DLL CSCDLL.DLL DBGHELP.DLL DEVMGR.DLL DHCPCSVC.DLL DNSAPI.DLL DOT3API.DLL DOT3DLG.DLL DUSER.DLL EAPOLQEC.DLL EAPPCFG.DLL EAPPPRXY.DLL EFSADU.DLL ESENT.DLL FLS.EXE GDI32.DLL GDIPLUS.DLL HLINK.DLL HNETCFG.DLL IEFRAME.DLL IERTUTIL.DLL IESHIMS.DLL IEUI.DLL IMAGEHLP.DLL IMGUTIL.DLL IMM32.DLL INETCOMM.DLL IPHLPAPI.DLL KERNEL32.DLL LIBEWF.DLL LINKINFO.DLL LZ32.DLL MFC42U.DLL MLANG.DLL MOBSYNC.DLL MPR.DLL MPRAPI.DLL MPRUI.DLL MSASN1.DLL MSFEEDS.DLL MSGINA.DLL MSHTML.DLL MSI.DLL MSIMG32.DLL MSLS31.DLL MSOERT2.DLL MSRATING.DLL MSSIGN32.DLL MSVCP60.DLL MSVCR90.DLL MSVCRT.DLL MSWSOCK.DLL NETAPI32.DLL NETCFGX.DLL NETMAN.DLL NETPLWIZ.DLL NETRAP.DLL NETSHELL.DLL NETUI0.DLL NETUI1.DLL NETUI2.DLL NORMALIZ.DLL NTDLL.DLL NTDSAPI.DLL NTLANMAN.DLL OCCACHE.DLL ODBC32.DLL OLE32.DLL OLEACC.DLL OLEAUT32.DLL OLEDLG.DLL OLEPRO32.DLL ONEX.DLL POWRPROF.DLL PRINTUI.DLL PSAPI.DLL QUERY.DLL QUTIL.DLL RASAPI32.DLL RASDLG.DLL RASMAN.DLL REGAPI.DLL RPCRT4.DLL RTUTILS.DLL SAMLIB.DLL SCECLI.DLL SECUR32.DLL SETUPAPI.DLL SHDOCVW.DLL SHELL32.DLL SHLWAPI.DLL SHSVCS.DLL TAPI32.DLL URLMON.DLL USER32.DLL USERENV.DLL USP10.DLL UTILDLL.DLL UXTHEME.DLL VERSION.DLL W32TOPL.DLL WER.DLL WINHTTP.DLL WININET.DLL WINMM.DLL WINSCARD.DLL WINSPOOL.DRV WINSTA.DLL WINTRUST.DLL WLDAP32.DLL WMI.DLL WS2_32.DLL WS2HELP.DLL WSOCK32.DLL WTSAPI32.DLL WZCDLG.DLL WZCSAPI.DLL WZCSVC.DLL XMLLITE.DLL ZLIB1.DLL |
1 message has been excluded from this view by a project administrator.
