sleuthkit-developers Mailing List for The Sleuth Kit (Page 15)
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...> - 2011-09-21 01:54:26
|
Feature Requests item #3412082, was opened at 2011-09-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=477892&aid=3412082&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: Abstract verbose location Initial Comment: Currently, verbose statements are printed to stderr. It should be abstracted so that they go somewhere else when it is being used as a library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3412082&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-21 01:46:04
|
Feature Requests item #3412078, was opened at 2011-09-20 20:46 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3412078&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 time resolution Initial Comment: Add a way to query the system to find out what the resolution is for the given file system (i.e. some FAT times are to do the day and some are to the 2 seconds). See: https://sourceforge.net/mailarchive/forum.php?thread_name=4E03F6BA-19D2-4D64-A7A9-B42ACCFDE707%40acm.org&forum_name=sleuthkit-users ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3412078&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-20 13:04:22
|
Bugs item #3382081, was opened at 2011-07-29 21:45 Message generated for change (Comment added) made by scudette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3382081&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: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk 3.2.2 missing libstdc++ in static build Initial Comment: The static build of the sleuthkit 3.2.2 is missing the C++ standard library. Bindings that use the static library fail to find __cxa_pure_virtual A work around is run: LDFLAGS=-lstdc++ ./configure LDFLAGS=-lstdc++ make ---------------------------------------------------------------------- Comment By: Michael Cohen (scudette) Date: 2011-09-20 23:04 Message: We have fixed this issue in pytsk by explicitly linking in libstdc++ as a workaround but this should really not be needed because pytsk itself does not require libstdc++. It would be cleaner to have tsk link it instead. ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-09-20 15:05 Message: The issue surfaced when building a static version of pytsk on Ubuntu. http://code.google.com/p/grr/wiki/ServerInstallation A straightforward autoconf/make solution would be to detect and include the library. An alternative solution could be to implement your own __cxa_pure_virtual function From: http://stackoverflow.com/questions/920500/what-is-the-purpose-of-cxa-pure-virtual The __cxa_pure_virtual function is an error handler that is invoked when a pure virtual function is called. If you are writing a C++ application that has pure virtual functions you must supply your own __cxa_pure_virtual error handler function. For example: extern "C" void __cxa_pure_virtual() { while (1); } ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2011-09-20 13:14 Message: Is there a autoconf/automake solution for this? I haven't experienced this problem yet when using the library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3382081&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-20 03:14:40
|
Bugs item #3382081, was opened at 2011-07-29 06:45 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3382081&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: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk 3.2.2 missing libstdc++ in static build Initial Comment: The static build of the sleuthkit 3.2.2 is missing the C++ standard library. Bindings that use the static library fail to find __cxa_pure_virtual A work around is run: LDFLAGS=-lstdc++ ./configure LDFLAGS=-lstdc++ make ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-09-19 22:14 Message: Is there a autoconf/automake solution for this? I haven't experienced this problem yet when using the library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3382081&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-20 02:35:39
|
Bugs item #3184429, was opened at 2011-02-16 22:39 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184429&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: inconsistent 0 time reporting. Initial Comment: John Lehr reported inconsistent behavior with 0-times. fls prints them as 0s and istat displays them as epoch times. We should be consistent and use '0' when possible to not give false impressions. Perhaps make some wrapper methods for returning time strings. fls: d/d 3: DCIM 0000-00-00 00:00:00 (UTC) 0000-00-00 00:00:00 (UTC) 0000-00-00 00:00:00 (UTC) 0000-00-00 00:00:00 (UTC) 32768 0 0 istat: Directory Entry: 3 Allocated File Attributes: Directory Size: 32768 Name: DCIM Directory Entry Times: Written: Wed Dec 31 16:00:00 1969 Accessed: Wed Dec 31 16:00:00 1969 Created: Wed Dec 31 16:00:00 1969 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-09-19 21:35 Message: Make tsk_fs_time_to_str() for consistent reporting. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2011-09-19 21:35 Message: Fixed in trunk. Sending ext2fs.c Sending fatfs.c Sending ffs.c Sending fs_name.c Sending hfs.c Sending iso9660.c Sending ntfs.c Sending tsk_fs_i.h Transmitting file data ........ Committed revision 377. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184429&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-20 02:35:19
|
Bugs item #3184429, was opened at 2011-02-16 22:39 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184429&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: inconsistent 0 time reporting. Initial Comment: John Lehr reported inconsistent behavior with 0-times. fls prints them as 0s and istat displays them as epoch times. We should be consistent and use '0' when possible to not give false impressions. Perhaps make some wrapper methods for returning time strings. fls: d/d 3: DCIM 0000-00-00 00:00:00 (UTC) 0000-00-00 00:00:00 (UTC) 0000-00-00 00:00:00 (UTC) 0000-00-00 00:00:00 (UTC) 32768 0 0 istat: Directory Entry: 3 Allocated File Attributes: Directory Size: 32768 Name: DCIM Directory Entry Times: Written: Wed Dec 31 16:00:00 1969 Accessed: Wed Dec 31 16:00:00 1969 Created: Wed Dec 31 16:00:00 1969 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-09-19 21:35 Message: Fixed in trunk. Sending ext2fs.c Sending fatfs.c Sending ffs.c Sending fs_name.c Sending hfs.c Sending iso9660.c Sending ntfs.c Sending tsk_fs_i.h Transmitting file data ........ Committed revision 377. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184429&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-20 02:29:28
|
Bugs item #3316603, was opened at 2011-06-14 23:07 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3316603&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: Mark Matienzo (anarchivist) Assigned to: Nobody/Anonymous (nobody) Summary: TSK 3.2.2: icat/blkcat fail w/ RAW Mode2/Form1 ISO9660 image Initial Comment: I recently downloaded and built TSK 3.2.2 and I'm trying the functionality that was added in #3213888 to allow for reading of raw ISO9660 images created by software like FTK Imager. I'm seeing this issue only with disks that my imaging software claims were written using Mode 2/Form 1, and I'm seeing it on Sleuthkit that was built both on Mac OS X 10.6.7 and on Ubuntu 11.04. Most of the file system tools like fls seem to work fine, but I am running into problems with icat and blkcat, in the form of an error like the following: Read offset too large for image file (tsk_img_read - [some value larger than file size]) (tsk_fs_file_walk: Error reading block at [block number]) I've attached a log using a sample raw image of a CD that was known written in Mode 2/Form 1. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-09-19 21:29 Message: Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/tsk3/fs/fs_io.c Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fs_io.c Transmitting file data .... Committed revision 375. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3316603&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-19 14:57:26
|
Feature Requests item #3411505, was opened at 2011-09-19 09:57 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3411505&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 name/value hashmap support for attributes Initial Comment: Some file systems have file info that does not fit into the standard FS_META structure. We shoudl add some form of hash map infrastructure that allows us to store extra data. THe first thing we should probably focus on are the other NTFS time values. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3411505&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-19 14:36:39
|
Bugs item #3267504, was opened at 2011-04-01 10:20 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3267504&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Image File Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: parki (lolwutlol) >Assigned to: Raman (rarora05) Summary: split_open > split_close leaks memory Initial Comment: Brian, I've been doing some profiling and found that: split_info->max_off is being malloc'ed at line 372 of split.c But not free'd at split_close(). I haven't looked thoroughly to see if it breaks anything but it looks like a free() at line 322-323 solves it. Also, I haven't experienced it so far, but it looks that code under the condition at line 403 of split.c (checking if an image name is a directory and returning NULL) isn't freeing memory either and would be leaking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3267504&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-17 15:09:17
|
Bugs item #3272339, was opened at 2011-04-03 12:16 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3272339&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Image File Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: error in img_cat usage help Initial Comment: The string "[-b start_sector]" in img_cat.cpp in the function usage() should be "[-s start_sector]". Found in version 3.2.1. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-09-17 10:09 Message: Fixed. Thanks! Sending branches/sleuthkit-3.2/tools/imgtools/img_cat.cpp Sending trunk/tools/imgtools/img_cat.cpp Transmitting file data .. Committed revision 374. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3272339&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-17 15:07:36
|
Bugs item #3314047, was opened at 2011-06-09 00:29 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3314047&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: UTF-8 versions of fs and img type decoding Initial Comment: I've got a few programs that link against TSK and use UTF-8 internally, even on Windows. The attached patch adds UTF-8 versions of tsk_fs_type_toid() and tsk_img_type_toid(). (If you want to avoid duplicate code, the TSK_TCHAR versions could just call these after conversion to char.) Not a big deal, but perhaps these are useful for folks other than just me. Apologies if this is a duplicate; SourceForge didn't appear to add it the first time. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-09-17 10:07 Message: Checked into trunk. Thanks Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fs_types.c Sending trunk/tsk3/fs/tsk_fs.h Sending trunk/tsk3/img/img_types.c Sending trunk/tsk3/img/tsk_img.h Sending trunk/tsk3/vs/mm_types.c Sending trunk/tsk3/vs/tsk_vs.h Transmitting file data ....... Committed revision 373. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3314047&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-17 13:47:53
|
Bugs item #3393960, was opened at 2011-08-18 09:41 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3393960&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: Hash Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Willi Ballenthin (wilbal1087) Assigned to: Nobody/Anonymous (nobody) Summary: hfind does not correctly parse input file on Windows Initial Comment: Platform: Win32 TSK: 3.2.2 source BUG: hfind does not correctly parse input file on Windows DETAILS: hfind accepts the optional argument '-f' and a filename that points to a file containing a list of hashes. The hashes should be separated by newlines. On Linux, the input file is parsed correctly. On Windows, the hashes are not parsed correctly, and the program exits with the error "Invalid argument (hdb_lookup: Invalid hash length". This appears to be due to the use of fgets vs ReadFile on Linux and Windows, respectively. fgets stops reading at a newline (or 100 bytes), while ReadFile reads 100 bytes regardless. A fix for this is to manually look for the newline in the resulting buffer. For example, a potential fix may beto replace the Win32 code around 251 in hfind.cpp: + int done = 0; + int i; + + for (i = 0; i < 100; i++) { + if (FALSE == ReadFile(handle, &buf[i], 1, &nread, NULL)) { + done = 1; + break; + } + if (buf[i] == '\n') { + break; + } + } + if (done) { + break; + } This fix is attached a patch against TSK 3.2.2. Unfortunately, I have not tested the code, as I don't have a Windows dev environment. Also note that the current code may have a security vulnerability due to the same bug. Line 265 in hfind.cpp writes a NULL to buf[strlen(buf) - 1]. If a null is not read by ReadFile, then the write will occur outside the string buffer. I do not know if this is exploitable. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-09-17 08:47 Message: Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/tools/hashtools/hfind.cpp Sending trunk/NEWS.txt Sending trunk/tools/hashtools/hfind.cpp Transmitting file data .... Committed revision 372. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3393960&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-16 20:27:13
|
Bugs item #3405265, was opened at 2011-09-06 17:00 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3405265&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: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Update API-docs license Initial Comment: Fix license in API docs to Attribution-ShareAlike instead of the non-commercial one. http://creativecommons.org/licenses/by-sa/3.0/ ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-09-16 15:27 Message: Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/tsk3/docs/footer.html Sending trunk/NEWS.txt Sending trunk/tsk3/docs/footer.html Transmitting file data .... Committed revision 371. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3405265&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-16 20:23:46
|
Bugs item #3406523, was opened at 2011-09-08 15:12 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3406523&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: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: bug in mactime sanitation of size Initial Comment: Small bug in mactime.base regarding sanitation of size value see patch ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-09-16 15:23 Message: Thanks. Checked in: Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/tools/timeline/mactime.base Sending trunk/NEWS.txt Sending trunk/tools/timeline/mactime.base Transmitting file data .... Committed revision 370. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3406523&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-08 20:15:22
|
Feature Requests item #3406525, was opened at 2011-09-08 22:15 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3406525&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: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: mactime add support for non-numerical uid and gid Initial Comment: Currently mactime only support numerical uid and gid value. Consider making this more tolerant to also allow non-numerical values. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3406525&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-08 20:12:47
|
Bugs item #3406523, was opened at 2011-09-08 22:12 Message generated for change (Settings changed) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3406523&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Timeline Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: bug in mactime sanitation of size Initial Comment: Small bug in mactime.base regarding sanitation of size value see patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3406523&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-08 20:12:25
|
Bugs item #3406523, was opened at 2011-09-08 22:12 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3406523&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: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: bug in mactime sanitation of size Initial Comment: Small bug in mactime.base regarding sanitation of size value see patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3406523&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-09-06 22:00:02
|
Bugs item #3405265, was opened at 2011-09-06 17:00 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3405265&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: Update API-docs license Initial Comment: Fix license in API docs to Attribution-ShareAlike instead of the non-commercial one. http://creativecommons.org/licenses/by-sa/3.0/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3405265&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-08-29 15:53:11
|
Feature Requests item #3400240, was opened at 2011-08-29 15:53 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3400240&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: Hash Database Group: None Status: Open Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: hfind - output file path and file name Initial Comment: hfind supports the md5sum format, but will only accept a raw list of hash values as a lookup file with the -f option. It would be very useful if hfind had an option that would accept the md5sum file (hash values + filepath/filenames) as a lookup file then output only the filepaths/filenames for hashes matched during the database search. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3400240&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-08-27 09:03:53
|
Feature Requests item #3399168, was opened at 2011-08-27 11:03 Message generated for change (Tracker Item Submitted) made by qfab You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=3399168&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: Analysis Techniques Group: None Status: Open Priority: 5 Private: No Submitted By: Fabiano Querceto (qfab) Assigned to: Nobody/Anonymous (nobody) Summary: Indexed keyword search Initial Comment: Hi, i think that with the new version of autopsy (3.x) it should be possible to integrate "Apache Lucene" java components to give the tool the ability to create an index of text data from the drive image/images being examined. A couple of open source projects that does this using lucene can be seen at http://puggle.sourceforge.net and at http://regain.sourceforge.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=3399168&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2011-08-18 14:41:13
|
Bugs item #3393960, was opened at 2011-08-18 14:41 Message generated for change (Tracker Item Submitted) made by wilbal1087 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3393960&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: Hash Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Willi Ballenthin (wilbal1087) Assigned to: Nobody/Anonymous (nobody) Summary: hfind does not correctly parse input file on Windows Initial Comment: Platform: Win32 TSK: 3.2.2 source BUG: hfind does not correctly parse input file on Windows DETAILS: hfind accepts the optional argument '-f' and a filename that points to a file containing a list of hashes. The hashes should be separated by newlines. On Linux, the input file is parsed correctly. On Windows, the hashes are not parsed correctly, and the program exits with the error "Invalid argument (hdb_lookup: Invalid hash length". This appears to be due to the use of fgets vs ReadFile on Linux and Windows, respectively. fgets stops reading at a newline (or 100 bytes), while ReadFile reads 100 bytes regardless. A fix for this is to manually look for the newline in the resulting buffer. For example, a potential fix may beto replace the Win32 code around 251 in hfind.cpp: + int done = 0; + int i; + + for (i = 0; i < 100; i++) { + if (FALSE == ReadFile(handle, &buf[i], 1, &nread, NULL)) { + done = 1; + break; + } + if (buf[i] == '\n') { + break; + } + } + if (done) { + break; + } This fix is attached a patch against TSK 3.2.2. Unfortunately, I have not tested the code, as I don't have a Windows dev environment. Also note that the current code may have a security vulnerability due to the same bug. Line 265 in hfind.cpp writes a NULL to buf[strlen(buf) - 1]. If a null is not read by ReadFile, then the write will occur outside the string buffer. I do not know if this is exploitable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3393960&group_id=55685 |
|
From: Michael C. <scu...@gm...> - 2011-08-17 22:00:46
|
I have hit this unusual bug using the attached test image. This ext2 image contains a second ext2 image inside it. I was calling libtsk3's tsk_fs_file_open() with the following path: /home/image2.img/home/ and it returned to me inode 13. (i.e. I was trying to recurse into the image file). I then verified this with fls (which does not seem to accept a path, only inodes): $ fls recursive.img d/d 11: lost+found r/- * 0: fs2 d/- * 0: f2 d/d 14: home d/d 129: $OrphanFiles $ fls recursive.img 14 r/r 12: image2.img d/- * 0: t # image2.img is a dd image (i.e. a file). I do not expect to be able to list it at all since its a file. But this kind of looks like the contents of the second image but not exactly: $ fls recursive.img 12 d/d 11: lost+found r/- * 0: a.txt d/d 13: home r/r 12: a.txt # But if TSK was actually recursively opening the filesystem I would expect to be able to list inode 13 - but this does not work. $ fls recursive.img 13 $ Also note that the recursive fls is incorrect, since the a.txt file is inside the home directory on image2.img: $ fls /tmp/image2.img d/d 11: lost+found r/- * 0: a.txt d/d 13: home d/d 65: $OrphanFiles $ fls /tmp/image2.img 13 r/r 12: a.txt Now I realize that it is incorrect to try to list a directory when the file type of inode 12 is definitely not a directory but a file. But when using the tsk_fs_file_open() API i really dont know this unless I try to open every intermediate inode along the way (i.e. /home/, /home/image2.img, /home/image2.img/home). Is it possible that TSK is opening the file and trying to parse it as a list of inodes, so the content of the embedded image is confused? Should the tsk_fs_file_open() api fail to recurse into something which is not a directory type? Thanks, Michael |
|
From: SourceForge.net <no...@so...> - 2011-08-15 17:47:31
|
Feature Requests item #3392084, was opened at 2011-08-15 12:47 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3392084&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Image Layer Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Add get_image_names method Initial Comment: Now that TSK is determining how many images there are in a set (i.e. specify only E01 and it finds E02), we shoudl provide a method that returns back the images that were identified. It should probably call into a file-type specific method that knows how to parse the E01 and AFF_INFO-type structs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3392084&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-08-15 17:37:08
|
Feature Requests item #3197980, was opened at 2011-03-02 19:38 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3197980&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Image Layer Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Raman (rarora05) Summary: Specify only first image in split Initial Comment: The user should be able to specify only the first image in a split image or E01 set and TSK will test for the follow in files. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-08-15 12:37 Message: Done for E01 files. Not yet done for split files. Need to change some other ofthe logic in img_open since there are hard coded checks to use the non-split format if only 1 image is specified. Should probably fix in trunk to merge raw.c and split.c. ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-03-04 10:25 Message: Brian, know that libewf v2 comes with a glob functions for this, which can be implemented in the img layer. Regarding split RAW you might want to take a look at libsmraw (libsmio project on SF), which also has a glob function for several split RAW naming schemes, which can be extended if necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3197980&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-08-08 15:23:59
|
Bugs item #3388421, was opened at 2011-08-08 17:23 Message generated for change (Tracker Item Submitted) made by skelm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=3388421&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: Notes / Reports Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: skelm (skelm) Assigned to: Nobody/Anonymous (nobody) Summary: Autopsy not displaying C-time correctly when adding Notes Initial Comment: When adding Notes while analysing a FAT32 file system Autopsy (v2.24) alway sets the c-time to Jan. 1, 1970 while istat (v3.2.2) is correct about this. Two examples: # istat -o 63 image.dd 2938902 Directory Entry: 2938902 Allocated File Attributes: File, Archive Size: 2375 Name: obfusca.ted Directory Entry Times: Written: Tue Oct 25 14:04:12 2005 Accessed: Sun Oct 23 00:00:00 2005 Created: Tue Oct 25 14:04:10 2005 Autopsy output: Volume: vol2 Meta: 2938902 M-time: Tue Oct 25 14:04:12 2005 A-time: Sun Oct 23 00:00:00 2005 C-time: Thu Jan 1 00:00:00 1970 ====================================================== # istat -o 63 image.dd 267897980 Directory Entry: 267897980 Not Allocated File Attributes: File, Archive Size: 193485 Name: 5224E5~1 Directory Entry Times: Written: Mon Oct 24 12:28:40 2005 Accessed: Mon Oct 24 00:00:00 2005 Created: Mon Oct 24 12:27:55 2005 Autopsy output: Volume: vol2 Meta: 267897980 M-time: Mon Oct 24 12:28:40 2005 A-time: Mon Oct 24 00:00:00 2005 C-time: Thu Jan 1 00:00:00 1970 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477897&aid=3388421&group_id=55687 |
1 message has been excluded from this view by a project administrator.
