sleuthkit-developers Mailing List for The Sleuth Kit (Page 16)
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-07-29 11:45:42
|
Bugs item #3382081, was opened at 2011-07-29 13:45 Message generated for change (Tracker Item Submitted) made by jbmetz 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3382081&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-07-19 13:33:11
|
Bugs item #3371321, was opened at 2011-07-19 08:33 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3371321&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: fsstat Ext3 percent used inodes bug Initial Comment: From July 12 posting to users list by KillBOy PowerHed: Hi list, I was playing about this morning and found what looks like a bug in fsstat output, a quick search didn't turn anything up... Distro: Fedora 15 x86_64 TSK ver: 3.2.2 Installed via: package Specific tool: fsstat Description: free inodes percentage for group 1 mangled Example output: #---------------------------------------------------------# [me@host Downloads]$ dd if=/dev/zero of=10mbfs bs=1024 count=10000 10000+0 records in 10000+0 records out 10240000 bytes (10 MB) copied, 0.0400749 s, 256 MB/s [me@host Downloads]$ mkfs.ext3 10mbfs mke2fs 1.41.14 (22-Dec-2010) 10mbfs is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=0 blocks, Stripe width=0 blocks 2512 inodes, 10000 blocks 500 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=10485760 2 block groups 8192 blocks per group, 8192 fragments per group 1256 inodes per group Superblock backups stored on blocks: 8193 Writing inode tables: done Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 26 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. [me@host Downloads]$ fsstat 10mbfs FILE SYSTEM INFORMATION -------------------------------------------- File System Type: Ext3 Volume Name: Volume ID: f46660d78d1567ba834c52c467bf01c6 Last Written at: Wed Jul 13 07:54:08 2011 Last Checked at: Wed Jul 13 07:54:08 2011 Last Mounted at: emptyUnmounted properly Last mounted on: Source OS: Linux Dynamic Structure Compat Features: Journal, Ext Attributes, Resize Inode, Dir Index InCompat Features: Filetype, Read Only Compat Features: Sparse Super, Journal ID: 00 Journal Inode: 8 METADATA INFORMATION -------------------------------------------- Inode Range: 1 - 2513 Root Directory: 2 Free Inodes: 2501 CONTENT INFORMATION -------------------------------------------- Block Range: 0 - 9999 Block Size: 1024 Reserved Blocks Before Block Groups: 1 Free Blocks: 8556 BLOCK GROUP INFORMATION -------------------------------------------- Number of Block Groups: 2 Inodes per group: 1256 Blocks per group: 8192 Group: 0: Inode Range: 1 - 1256 Block Range: 1 - 8192 Layout: Super Block: 1 - 1 Group Descriptor Table: 2 - 2 Data bitmap: 42 - 42 Inode bitmap: 43 - 43 Inode Table: 44 - 200 Data Blocks: 201 - 8192 Free Inodes: 1245 (99%) Free Blocks: 6949 (84%) Total Directories: 2 Group: 1: Inode Range: 1257 - 2512 Block Range: 8193 - 9999 Layout: Super Block: 8193 - 8193 Group Descriptor Table: 8194 - 8194 Data bitmap: 8234 - 8234 Inode bitmap: 8235 - 8235 Inode Table: 8236 - 8392 Data Blocks: 8393 - 9999 Free Inodes: 1256 (125600%) Free Blocks: 1607 (88%) Total Directories: 0 [me@host Downloads]$ fsstat -V The Sleuth Kit ver 3.2.2 #---------------------------------------------------------# cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3371321&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-07-14 16:18:39
|
Feature Requests item #3367368, was opened at 2011-07-14 17:18 Message generated for change (Tracker Item Submitted) made by ochoudary You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3367368&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 Priority: 5 Private: No Submitted By: Omar Choudary (ochoudary) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for libewf that works with sleuth kit version 3.2.2 Initial Comment: This is an updated patch for libewf version 2 support (ID: 3154664). This makes the alpha version of libewf work with version 3.2.2 of the sleuth kit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3367368&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-06-27 17:58:06
|
Feature Requests item #3197980, was opened at 2011-03-02 19:38 Message generated for change (Settings changed) 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: 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-06-24 12:09:21
|
Bugs item #3327454, was opened at 2011-06-24 07:09 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3327454&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: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: AFF support on windows Initial Comment: The aff_open method needs to be modified to convert TSK_TCHAR to a char on Windows so that we can open images. It will be a lossy conversion and will fail for non-latin file names, but there is no wide version for AFF on windows. We should give an error if the name being converted is using the upper byte in a UTF-16 character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3327454&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-06-15 04:07:01
|
Bugs item #3316603, was opened at 2011-06-15 00:07 Message generated for change (Tracker Item Submitted) made by anarchivist 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3316603&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-06-09 05:29:26
|
Bugs item #3314047, was opened at 2011-06-09 01:29 Message generated for change (Tracker Item Submitted) made by robjoyce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3314047&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-05-18 02:04:11
|
Bugs item #3303679, was opened at 2011-05-17 21:01 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3303679&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: Invalid UTF-8 in deleted FAT files Initial Comment: When looking for deleted FAT directory entries in unallocated space, some random data passes the possible checks and is considered a FAT entry. The name is copied directly into the FS_NAME buffer, which is not correct because the buffer should be only valid UTF-8 and we dont' know what this data is going to be. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-05-17 21:04 Message: Fixed by not allowing non-ASCII names for deleted SHORT names. Unicode names are not effected. Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/tsk3/fs/fatfs_meta.c Sending branches/sleuthkit-3.2/tsk3/fs/tsk_fatfs.h Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fatfs_meta.c Sending trunk/tsk3/fs/tsk_fatfs.h Transmitting file data ...... Committed revision 335. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3303679&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-05-18 02:01:47
|
Bugs item #3303679, was opened at 2011-05-17 21: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=3303679&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: Invalid UTF-8 in deleted FAT files Initial Comment: When looking for deleted FAT directory entries in unallocated space, some random data passes the possible checks and is considered a FAT entry. The name is copied directly into the FS_NAME buffer, which is not correct because the buffer should be only valid UTF-8 and we dont' know what this data is going to be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3303679&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-05-18 01:59:56
|
Bugs item #3303678, was opened at 2011-05-17 20:58 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3303678&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: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Image type in DB is always 0 Initial Comment: The image type in the SQLite DB is always 0. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-05-17 20:59 Message: Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/tsk3/auto/auto_db.cpp Sending trunk/NEWS.txt Sending trunk/tsk3/auto/auto_db.cpp Transmitting file data .... Committed revision 334. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3303678&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-05-18 01:58:43
|
Bugs item #3303678, was opened at 2011-05-17 20:58 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3303678&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: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Image type in DB is always 0 Initial Comment: The image type in the SQLite DB is always 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3303678&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-04-03 17:16:30
|
Bugs item #3272339, was opened at 2011-04-03 19:16 Message generated for change (Tracker Item Submitted) made by jbmetz 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3272339&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-04-01 15:20:38
|
Bugs item #3267504, was opened at 2011-04-01 17:20 Message generated for change (Tracker Item Submitted) made by lolwutlol 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: Nobody/Anonymous (nobody) 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-03-21 12:30:01
|
Bugs item #3220237, was opened at 2011-03-17 16:51 Message generated for change (Comment added) made by robklpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3220237&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: rob@klpd (robklpd) Assigned to: Nobody/Anonymous (nobody) Summary: NULL attribute 'name' in 3.2.0 and 3.2.1 Initial Comment: In the 2.3 release of OCFA libtsk is used by the tsklf module. This module was working OK in the 3.1 version of libtsk. Now with the 3.2 releases tskfs seems to have broken as a result of the fact that the attribute name now has become a NULL character pointer instead of a pointer to a real name. Currently tskfs uses the name info to determine if it is handling the main content of the file, or some other attribute. The following is code from tskfs that has broken as a result of this problem: //Helper function for constructor for processing data attribute. attributetype TskFsInode::processAttribute(const TSK_FS_ATTR *attribute,std::string name) { if (attribute->size == 0) { return ATTR_NODATA; } if (((attribute->name) && ( (std::string(attribute->name) == "$Data")))||(attribute->type == TSK_FS_ATTR_TYPE_DEFAULT)) { //Process normal data attribute. if (name =="EFS0.TMP") { //Special marker for EFS0.TMP file. ocfa::misc::metautil::addMetaToMap(mMeta,"specialmarker", new ocfa::misc::ScalarMetaValue(ocfa::misc::Scalar("efs-crypto-temp"))); } return ATTR_PRIMARY; } if ((attribute->name) && (std::string(attribute->name)) == "$I30") { return ATTR_NODATA; } if (attribute->type == TSK_FS_ATTR_TYPE_NTFS_BITMAP) { return ATTR_NODATA; } if (attribute->flags & TSK_FS_ATTR_NONRES) { //All non resident attributes are processed as data attributes. return ATTR_DATA; } else { switch (attribute->type) { case TSK_FS_ATTR_TYPE_NTFS_SI: if (mVerboseMeta) { //Only process SI information in verbose meta mode. processNtfsStandardInfo(attribute); } //fall trough OK. case TSK_FS_ATTR_TYPE_NTFS_FNAME: //fall trough OK. case TSK_FS_ATTR_TYPE_NTFS_VVER: return ATTR_NODATA; default: return ATTR_DATA; } } } Currently this means that ATTR_PRIMARY is no longer recognized correctly by the code above, and tskfs processes NTFS images severely wrong. ---------------------------------------------------------------------- >Comment By: rob@klpd (robklpd) Date: 2011-03-21 13:30 Message: I've added a small piece of code that demonstrates the difference between the two versions of libtsk. This code has an hardcoded image name for an ntfs partition image and a hardcoded inumber for a file with an alternate stream. Also added two output files for this code, one generated with the 3.1 and one with the 3.2 version of libtsk. These files show that the old libtsk named its steam '$Data' and its altstreams something user defined. The new libtsk returns NULL for the name of the primary stream. Currently the OCFA tskfs module uses the magic '$Data' name to distinguish between the primary stream and any alternative stream, and for this reason the tskfs module breaks completely by this bug/feature, mis-qualifying all normal files as empty files with an alternative stream. So possibly this might actualy be a bug in tskfs, but with no reliable cross-versionalternative way to distinguish between the primary and alternate streams, it appears on first sight to be a libtsk bug. ---------------------------------------------------------------------- Comment By: rob@klpd (robklpd) Date: 2011-03-18 12:33 Message: Added the 3 possibly relevant OCFA tskfs module files so the libtsk calls can easily be seen in the sequence that led to the given symptoms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3220237&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-19 18:04:52
|
Bugs item #3226705, was opened at 2011-03-19 21:04 Message generated for change (Tracker Item Submitted) made by msuhanov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3226705&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: msuhanov (msuhanov) Assigned to: Nobody/Anonymous (nobody) Summary: TSK 3.2.1 and NTFS problems Initial Comment: TSK 3.2.1 cannot understand NTFS file systems created using non-standard sector size. Sample file system image: http://anti-forensics.ru/tsk3/ntfs-undetectable.rar $ file ntfs-undetectable.dd ntfs-undetectable.dd: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", Bytes/sector 2048, sectors/cluster 2, reserved sectors 0, Media descriptor 0xf8, dos < 4.0 BootSector (0x80) $ fls ntfs-undetectable.dd Cannot determine file system type $ ntfsls ntfs-undetectable.dd test.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3226705&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-18 11:33:18
|
Bugs item #3220237, was opened at 2011-03-17 16:51 Message generated for change (Comment added) made by robklpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3220237&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: rob@klpd (robklpd) Assigned to: Nobody/Anonymous (nobody) Summary: NULL attribute 'name' in 3.2.0 and 3.2.1 Initial Comment: In the 2.3 release of OCFA libtsk is used by the tsklf module. This module was working OK in the 3.1 version of libtsk. Now with the 3.2 releases tskfs seems to have broken as a result of the fact that the attribute name now has become a NULL character pointer instead of a pointer to a real name. Currently tskfs uses the name info to determine if it is handling the main content of the file, or some other attribute. The following is code from tskfs that has broken as a result of this problem: //Helper function for constructor for processing data attribute. attributetype TskFsInode::processAttribute(const TSK_FS_ATTR *attribute,std::string name) { if (attribute->size == 0) { return ATTR_NODATA; } if (((attribute->name) && ( (std::string(attribute->name) == "$Data")))||(attribute->type == TSK_FS_ATTR_TYPE_DEFAULT)) { //Process normal data attribute. if (name =="EFS0.TMP") { //Special marker for EFS0.TMP file. ocfa::misc::metautil::addMetaToMap(mMeta,"specialmarker", new ocfa::misc::ScalarMetaValue(ocfa::misc::Scalar("efs-crypto-temp"))); } return ATTR_PRIMARY; } if ((attribute->name) && (std::string(attribute->name)) == "$I30") { return ATTR_NODATA; } if (attribute->type == TSK_FS_ATTR_TYPE_NTFS_BITMAP) { return ATTR_NODATA; } if (attribute->flags & TSK_FS_ATTR_NONRES) { //All non resident attributes are processed as data attributes. return ATTR_DATA; } else { switch (attribute->type) { case TSK_FS_ATTR_TYPE_NTFS_SI: if (mVerboseMeta) { //Only process SI information in verbose meta mode. processNtfsStandardInfo(attribute); } //fall trough OK. case TSK_FS_ATTR_TYPE_NTFS_FNAME: //fall trough OK. case TSK_FS_ATTR_TYPE_NTFS_VVER: return ATTR_NODATA; default: return ATTR_DATA; } } } Currently this means that ATTR_PRIMARY is no longer recognized correctly by the code above, and tskfs processes NTFS images severely wrong. ---------------------------------------------------------------------- >Comment By: rob@klpd (robklpd) Date: 2011-03-18 12:33 Message: Added the 3 possibly relevant OCFA tskfs module files so the libtsk calls can easily be seen in the sequence that led to the given symptoms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3220237&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-17 15:51:40
|
Bugs item #3220237, was opened at 2011-03-17 16:51 Message generated for change (Tracker Item Submitted) made by robklpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3220237&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: rob@klpd (robklpd) Assigned to: Nobody/Anonymous (nobody) Summary: NULL attribute 'name' in 3.2.0 and 3.2.1 Initial Comment: In the 2.3 release of OCFA libtsk is used by the tsklf module. This module was working OK in the 3.1 version of libtsk. Now with the 3.2 releases tskfs seems to have broken as a result of the fact that the attribute name now has become a NULL character pointer instead of a pointer to a real name. Currently tskfs uses the name info to determine if it is handling the main content of the file, or some other attribute. The following is code from tskfs that has broken as a result of this problem: //Helper function for constructor for processing data attribute. attributetype TskFsInode::processAttribute(const TSK_FS_ATTR *attribute,std::string name) { if (attribute->size == 0) { return ATTR_NODATA; } if (((attribute->name) && ( (std::string(attribute->name) == "$Data")))||(attribute->type == TSK_FS_ATTR_TYPE_DEFAULT)) { //Process normal data attribute. if (name =="EFS0.TMP") { //Special marker for EFS0.TMP file. ocfa::misc::metautil::addMetaToMap(mMeta,"specialmarker", new ocfa::misc::ScalarMetaValue(ocfa::misc::Scalar("efs-crypto-temp"))); } return ATTR_PRIMARY; } if ((attribute->name) && (std::string(attribute->name)) == "$I30") { return ATTR_NODATA; } if (attribute->type == TSK_FS_ATTR_TYPE_NTFS_BITMAP) { return ATTR_NODATA; } if (attribute->flags & TSK_FS_ATTR_NONRES) { //All non resident attributes are processed as data attributes. return ATTR_DATA; } else { switch (attribute->type) { case TSK_FS_ATTR_TYPE_NTFS_SI: if (mVerboseMeta) { //Only process SI information in verbose meta mode. processNtfsStandardInfo(attribute); } //fall trough OK. case TSK_FS_ATTR_TYPE_NTFS_FNAME: //fall trough OK. case TSK_FS_ATTR_TYPE_NTFS_VVER: return ATTR_NODATA; default: return ATTR_DATA; } } } Currently this means that ATTR_PRIMARY is no longer recognized correctly by the code above, and tskfs processes NTFS images severely wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3220237&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-15 18:47:37
|
Feature Requests item #3213888, was opened at 2011-03-15 13:39 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3213888&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: Closed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Support RAW CD images Initial Comment: Some tools, FTK Imager for example, will create a RAW image of a CD. It includes the lower-level data before and after the user data in each sector. We should support it. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-03-15 13:47 Message: Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/tsk3/fs/fs_io.c Sending branches/sleuthkit-3.2/tsk3/fs/iso9660.c Sending branches/sleuthkit-3.2/tsk3/fs/iso9660_dent.c Sending branches/sleuthkit-3.2/tsk3/fs/tsk_fs.h Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fs_io.c Sending trunk/tsk3/fs/iso9660.c Sending trunk/tsk3/fs/iso9660_dent.c Sending trunk/tsk3/fs/tsk_fs.h Transmitting file data .......... Committed revision 323. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3213888&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-15 18:38:20
|
Bugs item #3213886, was opened at 2011-03-15 13: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=3213886&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: ISO9660 hang on directory holes Initial Comment: The code to advance through directory holes in ISO9660 was not advancing properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3213886&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-10 01:26:11
|
Bugs item #3200998, was opened at 2011-03-05 20:46 Message generated for change (Comment added) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3200998&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: Invalid Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: hfind doesn't recognize hash db it created Initial Comment: I downloaded the latests NSRL set, concatenated the NSRLFile.txt, and removed repeated hashes with uniq. I created an nsrl-md5 db with 'hfind -i nsrl-mdr NSRLFile.txt' resulting in a NSRLFile.txt.uniq-md5.idx that contains two pipe delimited columns, the first '00000000000000000000000000000000000000000|nsrl' When I attempt a hash comparison with hfind or sorter, i get the following error: 'Cannot determine hash database type (hdb_open: Error determining DB type)' Sleuthkit 3.2.1, Debian Testing ---------------------------------------------------------------------- >Comment By: John Lehr (jlehr) Date: 2011-03-09 17:26 Message: hfind improperly deployed by user. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3200998&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-06 18:55:43
|
Bugs item #3201488, was opened at 2011-03-06 19:55 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3201488&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: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: NTFS incorrect enforcement of fs_attr->nrd.initsize Initial Comment: TSK 3.2.1 on Linux (Fedora Core) When running icat on an unmounted Windows 7 NTFS volume (using a Linux device handle) several files in the "System Volume Information" return 0-byte (or invalid) content. The information istat returns about the corresponding MFT entry is correct; also the data run information. data run: 00000000: 43 2c c9 00 a0 3b 60 01 C,...;`. verbose output of icat: ntfs_make_data_run: Len idx: 0 cur: 44 (2c) tot: 44 (2c) ntfs_make_data_run: Len idx: 1 cur: 201 (c9) tot: 51500 (c92c) ntfs_make_data_run: Len idx: 2 cur: 0 (0) tot: 51500 (c92c) ntfs_make_data_run: Off idx: 0 cur: 160 (a0) tot: 160 (a0) ntfs_make_data_run: Off idx: 1 cur: 59 (3b) tot: 15264 (3ba0) ntfs_make_data_run: Off idx: 2 cur: 96 (60) tot: 6306720 (603ba0) ntfs_make_data_run: Off idx: 3 cur: 1 (1) tot: 23083936 (1603ba0) ntfs_make_data_run: Signed addr_offset: 23083936 Previous address: 0 in tsk_fs_file_walk_nonres() it hits: else if ((off >= fs_attr->nrd.initsize) where initsize = 0; non-resident data: 00000000: 00 00 00 00 00 00 00 00 2b c9 00 00 00 00 00 00 ........ +....... 00000010: 40 00 00 00 00 00 00 00 00 c0 92 0c 00 00 00 00 @....... ........ 00000020: 00 c0 92 0c 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ data first VCN : 0 data last VCN : 51499 data runs offset : 64 compression unit size : 0 padding : 0x00000000 allocated data size : 210944000 data size : 210944000 initialized data size : 0 (0x00000000) The code is acting as designed but the limitation of fs_attr->nrd.initsize does not seem to be a correct one because the file does contain data of size 210944000 at the offset the data run is referring to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3201488&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-06 18:19:56
|
Feature Requests item #3201467, was opened at 2011-03-06 19:19 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3201467&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: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: change verbose output of tsk_fs_file_walk_type Initial Comment: in tsk 3.2.1 the function name in the verbose output of tsk_fs_file_walk_type() is "tsk_fs_file_walk" please consider changing this into "tsk_fs_file_walk_type" (see attached patch) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3201467&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-06 04:46:30
|
Bugs item #3200998, was opened at 2011-03-05 20:46 Message generated for change (Tracker Item Submitted) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3200998&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: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: hfind doesn't recognize hash db it created Initial Comment: I downloaded the latests NSRL set, concatenated the NSRLFile.txt, and removed repeated hashes with uniq. I created an nsrl-md5 db with 'hfind -i nsrl-mdr NSRLFile.txt' resulting in a NSRLFile.txt.uniq-md5.idx that contains two pipe delimited columns, the first '00000000000000000000000000000000000000000|nsrl' When I attempt a hash comparison with hfind or sorter, i get the following error: 'Cannot determine hash database type (hdb_open: Error determining DB type)' Sleuthkit 3.2.1, Debian Testing ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3200998&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-04 15:50:01
|
Feature Requests item #3199725, was opened at 2011-03-04 16:50 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3199725&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: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: libqcow support Initial Comment: Please consider adding support for libqcow to support QEMU copy-on-write (QCOW) images. The attached patch contains the changes necessary for adding basic libqcow support to sleutkit 3.2.1 An alpha version of libqcow can be found on the libqcow SF project site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3199725&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-04 15:40:29
|
Feature Requests item #3154655, was opened at 2011-01-10 23:12 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3154655&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: None >Status: Closed Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf/make m4 directory Initial Comment: As indicated by recent versions of autoconf/make please use a sub-directory for M4 scripts. The attached patch makes the necessary changes for this. ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2011-03-04 16:40 Message: The patch seems to be implemented in TSK 3.2.1 thanks for that. ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-01-10 23:38 Message: BTW you'll need to add the m4 sub-directory by hand. It is not included in the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3154655&group_id=55685 |
1 message has been excluded from this view by a project administrator.
