sleuthkit-developers Mailing List for The Sleuth Kit (Page 21)
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(22) |
Feb
(39) |
Mar
(8) |
Apr
(17) |
May
(10) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(4) |
| 2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(9) |
Jul
(14) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
| 2009 |
Jan
(7) |
Feb
(10) |
Mar
(10) |
Apr
(19) |
May
(16) |
Jun
(3) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(16) |
Nov
(35) |
Dec
(30) |
| 2010 |
Jan
(4) |
Feb
(24) |
Mar
(25) |
Apr
(31) |
May
(11) |
Jun
(9) |
Jul
(11) |
Aug
(31) |
Sep
(11) |
Oct
(10) |
Nov
(15) |
Dec
(3) |
| 2011 |
Jan
(8) |
Feb
(17) |
Mar
(14) |
Apr
(2) |
May
(4) |
Jun
(4) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(8) |
Nov
(16) |
Dec
(1) |
| 2012 |
Jan
(9) |
Feb
(2) |
Mar
(3) |
Apr
(13) |
May
(10) |
Jun
(7) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(3) |
| 2013 |
Jan
(16) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(18) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
| 2015 |
Jan
(5) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(23) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Brian C. <ca...@sl...> - 2010-07-22 00:35:35
|
Hi Jon, What is the use case for this identifier? Are you saying that a path is not unique because you could have the same path in different file systems in a disk image? You could use the file system offset as part of the path to make it unique? That being said, sure we could make an identifier for each name. What should it report for orphan files though (files that have a metadata structure, but no name)? brian On Jul 21, 2010, at 1:37 PM, Jon wrote: > Would it be possible to add a field to TSK_FS_NAME for the byte offset > of the record, either from the start of the volume or from the start > of the disk (whichever is easier)? > > "addr" works as a good unique identifier for TSK_FS_META structs, and > something similar for TSK_FS_NAME would be helpful. Paths aren't > necessarily unique, and a segmented scheme using the parent > directory's path/inum with the index number of the TSK_FS_NAME record > is not stable... a new version of TSK might figure out a way to > recover more files in a directory (hypothetically) and now the index > number may be shifted to a different record. Reporting the byte offset > of the record would be more stable and have the added benefit of > letting people quickly find the raw data in a hex editor, for > validation/inspection. > > Thoughts? > > Jon > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
|
From: Jon <jo...@li...> - 2010-07-21 18:00:43
|
Would it be possible to add a field to TSK_FS_NAME for the byte offset of the record, either from the start of the volume or from the start of the disk (whichever is easier)? "addr" works as a good unique identifier for TSK_FS_META structs, and something similar for TSK_FS_NAME would be helpful. Paths aren't necessarily unique, and a segmented scheme using the parent directory's path/inum with the index number of the TSK_FS_NAME record is not stable... a new version of TSK might figure out a way to recover more files in a directory (hypothetically) and now the index number may be shifted to a different record. Reporting the byte offset of the record would be more stable and have the added benefit of letting people quickly find the raw data in a hex editor, for validation/inspection. Thoughts? Jon |
|
From: SourceForge.net <no...@so...> - 2010-07-18 09:27:22
|
Bugs item #3031168, was opened at 2010-07-18 13:57 Message generated for change (Tracker Item Submitted) made by negin99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3031168&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: Negin Ahmadian (negin99) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with Ext3 recovered files and directories Initial Comment: Hi! I tried TSK with a test image of 4.9MB Ext3 file system. This image has five deleted files and two directories (see attached excel file for files' description). The files rang from single block files to multiple blocks. No data structures were also modified. They were created in Fedora 8.0, deleted in Fedora 8.0 and imaged in Fedora 8.0. After deletion, size of all the deleted files becomes 0 and they will not be accessible. (CR01-1 picture shows what happens, there is no link available for dir1!) I tried FAT images and it seems that they work fine. All of the deleted files could be recovered after deletion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3031168&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-07-08 19:28:49
|
Bugs item #3026994, was opened at 2010-07-08 14:28 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&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: mingw compile errors Initial Comment: >From Simson Garfinkel: Version 3.1.3 generates these compilation errors with mingw running on Linux: fs_fname_apis.cpp: In function `int test_fat12()': fs_fname_apis.cpp:366: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_fname_apis.cpp: In function `int test_ntfs_fe()': fs_fname_apis.cpp:404: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat12()': read_apis.cpp:210: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)'fs_attrlist_apis.cpp: In function `int test_fat12()': fs_attrlist_apis.cpp:202: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_slack()': read_apis.cpp:249: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_attrlist_apis.cpp: In function `int test_ntfs_fe()': fs_attrlist_apis.cpp:241: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_recover()': read_apis.cpp:343: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_slack_ads()': read_apis.cpp:483: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_fe()': read_apis.cpp:644: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_comp()': read_apis.cpp:682: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' These are all trivially fixed by putting a (const TSK_TCHAR *) before the fname arguments. I am also seeing these errors which are not so trivial to fix: ewf.c: In function `ewf_open': ewf.c:147: warning: implicit declaration of function `libewf_check_file_signature_wide' ewf.c:163: warning: implicit declaration of function `libewf_open_wide' ewf.c:163: warning: assignment makes pointer from integer without a cast hfs_dent.c: In function `hfs_uni2ascii': hfs_dent.c:121: warning: dereferencing type-punned pointer will break strict-aliasing rules hfs_dent.c:122: warning: dereferencing type-punned pointer will break strict-aliasing rules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-07-08 19:18:43
|
Feature Requests item #3026989, was opened at 2010-07-08 14:18 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3026989&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: specify range in img_cat (patch included) Initial Comment: Simson submitted a patch to specify range in img_cat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3026989&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-07-01 02:00:25
|
Bugs item #3023481, was opened at 2010-06-30 13:35 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&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: icat exporting error, FAT Initial Comment: icat of any deleted file in a FAT16 partition only export 4kb of file. The Sleuth Kit ver 3.1.3b1 Ubuntu 10.04 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-06-30 21:00 Message: Can you run 'istat' on the file? It will tell you if the file is recoverable or not. ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2010-06-30 17:52 Message: more information: in a fat32 file system with 32kb clusters, icat recovered 32kb of the deleted file. Thus, the bug appears to be that icat extracts only one cluster of deleted files from fat32. ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2010-06-30 16:05 Message: Correction, Fat32 Partition: FILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT32 OEM Name: MSDOS5.0 Volume ID: 0x861f3d71 Volume Label (Boot Sector): NO NAME Volume Label (Root Directory): CRUZER File System Type Label: FAT32 Next Free Sector (FS Info): 90352 Free Sector Count (FS Info): 5609032 Sectors before file system: 63 File System Layout (in sectors) Total Range: 0 - 15695441 * Reserved: 0 - 35 ** Boot Sector: 0 ** FS Info Sector: 1 ** Backup Boot Sector: 6 * FAT 0: 36 - 15333 * FAT 1: 15334 - 30631 * Data Area: 30632 - 15695441 ** Cluster Area: 30632 - 15695439 *** Root Directory: 30632 - 30639 ** Non-clustered: 15695440 - 15695441 METADATA INFORMATION -------------------------------------------- Range: 2 - 250636966 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 4096 Total Cluster Range: 2 - 1958102 Further study shows that regular files are extracted correctly with icat and the issue is limited to deleted files over 4.0 K. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-07-01 01:54:04
|
Bugs item #3023606, was opened at 2010-06-30 20:41 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023606&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: Corrupt ext2 listing Initial Comment: To the users list: Hello everyone, I have found a problem with a specific image file (.E01 format) with The Sleuth Kit, version 3.1.2. I work in a Ubuntu GNU/Linux environment, version 10.04 LTS (Lucid Lynx). The image file I am working with includes a partition with a EXT2 file system. When I use the fls utility in a specific folder of this image, the contents are not retrieved right (fls -v -o 63 image.E* 524447). I have seen in the source code in the function named ext2fs_dent_parse_block (file tsk3/fs/ext2fs_dent.c), that the variable minreclen is calculated using the namelen variable (minreclen = EXT2FS_DIRSIZ_lcl(namelen), this is, 11 bytes plus the name length, aligned on 4 bytes boundaries). Shouldn't it be calculated using the reclen variable ? In the case I am working with, there are some bytes in the end of a specific record that are not used in the name, so the record is 28 bytes long: the header (8 bytes), the name length is 14 characters, and there are 6 extra unused bytes unitl the next entry, so using the record length is better than using the name length + 8 bytes. In my case the ext2 linked list directory was like this (each entry in a line): 9f 00 08 00 0c 00 01 02 2e 00 00 00 8e 00 08 00 0c 00 02 02 2e 2e 00 00 a1 00 08 00 1c 00 0e 01 73 74 79 6c 65 73 68 65 65 74 2e 63 73 73 35 33 64 36 64 00 a0 00 08 00 cc 0f 0a 01 62 61 6e 6e 65 72 2e 63 73 73 00 00 a1 00 08 00 b8 0f 17 01 73 74 79 6c 65 73 68 65 65 74 2e 63 73 73 3b 34 39 39 35 33 64 36 64 00 00 00 00 The fls utility retrieved 3 entries in this folder (the first one was "stylesheet.css", and "stylesheet.css;49953d6d" as the third one. The second one, the name should be "banner.css", wasn't displayed right (the name was "^^^bann", and the rest of metadata was wrong). If I change the minreclen calculation to "minreclen=reclen", the three entries are displayed right. Regards, Jordi Gilabert Vall ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-06-30 20:53 Message: Added else statement to update minreclen if no entry could exist in unused space. Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/ext2fs_dent.c Sending branches/sleuthkit-3.1/tsk3/fs/ffs_dent.c Sending trunk/NEWS.txt Sending trunk/tsk3/fs/ext2fs_dent.c Sending trunk/tsk3/fs/ffs_dent.c Transmitting file data ...... Committed revision 215. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023606&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-07-01 01:41:15
|
Bugs item #3023606, was opened at 2010-06-30 20:41 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023606&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: Brian Carrier (carrier) Summary: Corrupt ext2 listing Initial Comment: To the users list: Hello everyone, I have found a problem with a specific image file (.E01 format) with The Sleuth Kit, version 3.1.2. I work in a Ubuntu GNU/Linux environment, version 10.04 LTS (Lucid Lynx). The image file I am working with includes a partition with a EXT2 file system. When I use the fls utility in a specific folder of this image, the contents are not retrieved right (fls -v -o 63 image.E* 524447). I have seen in the source code in the function named ext2fs_dent_parse_block (file tsk3/fs/ext2fs_dent.c), that the variable minreclen is calculated using the namelen variable (minreclen = EXT2FS_DIRSIZ_lcl(namelen), this is, 11 bytes plus the name length, aligned on 4 bytes boundaries). Shouldn't it be calculated using the reclen variable ? In the case I am working with, there are some bytes in the end of a specific record that are not used in the name, so the record is 28 bytes long: the header (8 bytes), the name length is 14 characters, and there are 6 extra unused bytes unitl the next entry, so using the record length is better than using the name length + 8 bytes. In my case the ext2 linked list directory was like this (each entry in a line): 9f 00 08 00 0c 00 01 02 2e 00 00 00 8e 00 08 00 0c 00 02 02 2e 2e 00 00 a1 00 08 00 1c 00 0e 01 73 74 79 6c 65 73 68 65 65 74 2e 63 73 73 35 33 64 36 64 00 a0 00 08 00 cc 0f 0a 01 62 61 6e 6e 65 72 2e 63 73 73 00 00 a1 00 08 00 b8 0f 17 01 73 74 79 6c 65 73 68 65 65 74 2e 63 73 73 3b 34 39 39 35 33 64 36 64 00 00 00 00 The fls utility retrieved 3 entries in this folder (the first one was "stylesheet.css", and "stylesheet.css;49953d6d" as the third one. The second one, the name should be "banner.css", wasn't displayed right (the name was "^^^bann", and the rest of metadata was wrong). If I change the minreclen calculation to "minreclen=reclen", the three entries are displayed right. Regards, Jordi Gilabert Vall ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023606&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-06-30 22:52:59
|
Bugs item #3023481, was opened at 2010-06-30 11:35 Message generated for change (Comment added) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&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: icat exporting error, FAT Initial Comment: icat of any deleted file in a FAT16 partition only export 4kb of file. The Sleuth Kit ver 3.1.3b1 Ubuntu 10.04 ---------------------------------------------------------------------- >Comment By: John Lehr (jlehr) Date: 2010-06-30 15:52 Message: more information: in a fat32 file system with 32kb clusters, icat recovered 32kb of the deleted file. Thus, the bug appears to be that icat extracts only one cluster of deleted files from fat32. ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2010-06-30 14:05 Message: Correction, Fat32 Partition: FILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT32 OEM Name: MSDOS5.0 Volume ID: 0x861f3d71 Volume Label (Boot Sector): NO NAME Volume Label (Root Directory): CRUZER File System Type Label: FAT32 Next Free Sector (FS Info): 90352 Free Sector Count (FS Info): 5609032 Sectors before file system: 63 File System Layout (in sectors) Total Range: 0 - 15695441 * Reserved: 0 - 35 ** Boot Sector: 0 ** FS Info Sector: 1 ** Backup Boot Sector: 6 * FAT 0: 36 - 15333 * FAT 1: 15334 - 30631 * Data Area: 30632 - 15695441 ** Cluster Area: 30632 - 15695439 *** Root Directory: 30632 - 30639 ** Non-clustered: 15695440 - 15695441 METADATA INFORMATION -------------------------------------------- Range: 2 - 250636966 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 4096 Total Cluster Range: 2 - 1958102 Further study shows that regular files are extracted correctly with icat and the issue is limited to deleted files over 4.0 K. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-06-30 21:05:31
|
Bugs item #3023481, was opened at 2010-06-30 11:35 Message generated for change (Comment added) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&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: icat exporting error, FAT Initial Comment: icat of any deleted file in a FAT16 partition only export 4kb of file. The Sleuth Kit ver 3.1.3b1 Ubuntu 10.04 ---------------------------------------------------------------------- >Comment By: John Lehr (jlehr) Date: 2010-06-30 14:05 Message: Correction, Fat32 Partition: FILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT32 OEM Name: MSDOS5.0 Volume ID: 0x861f3d71 Volume Label (Boot Sector): NO NAME Volume Label (Root Directory): CRUZER File System Type Label: FAT32 Next Free Sector (FS Info): 90352 Free Sector Count (FS Info): 5609032 Sectors before file system: 63 File System Layout (in sectors) Total Range: 0 - 15695441 * Reserved: 0 - 35 ** Boot Sector: 0 ** FS Info Sector: 1 ** Backup Boot Sector: 6 * FAT 0: 36 - 15333 * FAT 1: 15334 - 30631 * Data Area: 30632 - 15695441 ** Cluster Area: 30632 - 15695439 *** Root Directory: 30632 - 30639 ** Non-clustered: 15695440 - 15695441 METADATA INFORMATION -------------------------------------------- Range: 2 - 250636966 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 4096 Total Cluster Range: 2 - 1958102 Further study shows that regular files are extracted correctly with icat and the issue is limited to deleted files over 4.0 K. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-06-30 18:35:05
|
Bugs item #3023481, was opened at 2010-06-30 11:35 Message generated for change (Tracker Item Submitted) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&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: icat exporting error, FAT Initial Comment: icat of any deleted file in a FAT16 partition only export 4kb of file. The Sleuth Kit ver 3.1.3b1 Ubuntu 10.04 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-06-17 21:13:03
|
Feature Requests item #3017764, was opened at 2010-06-17 21:13 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3017764&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Naming the default $DATA as "$Data" Initial Comment: Currently, TSK assigns the name "$Data" to a file's default $DATA attribute. However, this makes it difficult to distinguish the file's default $DATA attribute from an ADS named "$Data". For exaple, you can actually name a stream "$Data" like this: C:\> echo 1 > host.txt:$Data Now when you use fls, it shows something like this: ++++ r/r 201337-128-1: host.txt ++++ r/r 201337-128-3: host.txt A lot of people rely on grepping fls output for ":" to identify streams, but if the stream is actually named "$Data" then fls won't show it as such. One thing you could do is apply the "$Data" name inside the tsk_fs_name_print function if a $DATA attribute doesn't have a name. That way, the structure member fs_attr->name contains the original name (which would just be "" in the default case) so that applications can tell it apart from an ADS named "$Data". Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3017764&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-06-13 04:11:16
|
Feature Requests item #2206306, was opened at 2008-10-29 07:13 Message generated for change (Comment added) made by negin99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: function to map name to inode Initial Comment: A more formal function should exist to map the name to an inode / metadata address. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-06-13 08:41 Message: Unfortunately, as I mentioned, the attachment option is disabled and there was no way to attach my files here. I think only the creator of an artifact is allowed to attach files. Sorry that I forced to add new artifact and add my files there. I'm eagerly waiting to receive your opinions. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-06-13 00:11 Message: You can add it here as an attachment. Please make sure that it is up to date with either the trunk code or the sleuthkit-3.1 branch code in the SVN repository. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-06-09 16:15 Message: I could prepare the first version according to your comments. But I couldn't find an option to upload my files here! Should I add new artifact? ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-05-27 17:56 Message: I would say that the requirements for the function should be: - Can handle an unlimited number of names (i.e. it does not return only the first 10 names). In most cases, there will be only one or two names, but if there is a limit than it could be a data hiding technique. - Does not use global variables so that this can be used in a multi-threaded environment. You could create a new struct that stores the number of names found and a list of the names along with a function to free the data allocated to the struct. The caller than needs to free the struct when they are done with the contents. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 11:02 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 11:02 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-03-31 02:19 Message: There is the tsk_fs_ffind() method in tsk3/fs/ffind_lib.c that is not very library friendly and will print the names of the files that use a given metadata address. It would be nicer to have a more general approach that either returns a list of the names or that has a callback so that other programs can find out the names of a metadata address without needing to print the data. tsk_fs_ifind_data() has similar needs for improvement because it too prints the metadata addresses that point to blocks instead of somehow returning the value to the caller and letting it decide how to handle the data (print, process, etc.). tsk_fs_path2inum() was made more library friendly and returns the metadata address, but this is an easier problem because there is only one value that a name can point to. The challenge with mapping blocks to metadata and metadata to a name is that there could be multiple values. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-30 18:04 Message: Dear Mr.Carrier, Would you please explain more about this issue? What is its usability? Could you please give me an example. Actually I'm doing my graduate thesis about digital forensics field and need to implement some new features for an open source tool. I've chosen Autopsy and TSK. I read each requested feature detail carefully but couldn't decide what to implement yet. I'm familiar with etx3 file system and TSK data structures. I want to know if you could give me a suggestion. Thanks a lot in advance. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-06-13 04:04:26
|
Feature Requests item #3015367, was opened at 2010-06-13 08:34 Message generated for change (Tracker Item Submitted) made by negin99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3015367&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: Negin Ahmadian (negin99) Assigned to: Nobody/Anonymous (nobody) Summary: 2206306 request modified files Initial Comment: Here are the modified files for 2206306 request. Its aim is to make ffind function more library friendly by passing the result as a struct and not by printing on the screen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3015367&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-06-12 19:41:09
|
Feature Requests item #2206306, was opened at 2008-10-28 22:43 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: function to map name to inode Initial Comment: A more formal function should exist to map the name to an inode / metadata address. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-06-12 14:41 Message: You can add it here as an attachment. Please make sure that it is up to date with either the trunk code or the sleuthkit-3.1 branch code in the SVN repository. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-06-09 06:45 Message: I could prepare the first version according to your comments. But I couldn't find an option to upload my files here! Should I add new artifact? ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-05-27 08:26 Message: I would say that the requirements for the function should be: - Can handle an unlimited number of names (i.e. it does not return only the first 10 names). In most cases, there will be only one or two names, but if there is a limit than it could be a data hiding technique. - Does not use global variables so that this can be used in a multi-threaded environment. You could create a new struct that stores the number of names found and a list of the names along with a function to free the data allocated to the struct. The caller than needs to free the struct when they are done with the contents. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 01:32 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 01:32 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-03-30 16:49 Message: There is the tsk_fs_ffind() method in tsk3/fs/ffind_lib.c that is not very library friendly and will print the names of the files that use a given metadata address. It would be nicer to have a more general approach that either returns a list of the names or that has a callback so that other programs can find out the names of a metadata address without needing to print the data. tsk_fs_ifind_data() has similar needs for improvement because it too prints the metadata addresses that point to blocks instead of somehow returning the value to the caller and letting it decide how to handle the data (print, process, etc.). tsk_fs_path2inum() was made more library friendly and returns the metadata address, but this is an easier problem because there is only one value that a name can point to. The challenge with mapping blocks to metadata and metadata to a name is that there could be multiple values. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-30 08:34 Message: Dear Mr.Carrier, Would you please explain more about this issue? What is its usability? Could you please give me an example. Actually I'm doing my graduate thesis about digital forensics field and need to implement some new features for an open source tool. I've chosen Autopsy and TSK. I read each requested feature detail carefully but couldn't decide what to implement yet. I'm familiar with etx3 file system and TSK data structures. I want to know if you could give me a suggestion. Thanks a lot in advance. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-06-09 11:45:26
|
Feature Requests item #2206306, was opened at 2008-10-29 07:13 Message generated for change (Comment added) made by negin99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: function to map name to inode Initial Comment: A more formal function should exist to map the name to an inode / metadata address. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-06-09 16:15 Message: I could prepare the first version according to your comments. But I couldn't find an option to upload my files here! Should I add new artifact? ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-05-27 17:56 Message: I would say that the requirements for the function should be: - Can handle an unlimited number of names (i.e. it does not return only the first 10 names). In most cases, there will be only one or two names, but if there is a limit than it could be a data hiding technique. - Does not use global variables so that this can be used in a multi-threaded environment. You could create a new struct that stores the number of names found and a list of the names along with a function to free the data allocated to the struct. The caller than needs to free the struct when they are done with the contents. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 11:02 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 11:02 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-03-31 02:19 Message: There is the tsk_fs_ffind() method in tsk3/fs/ffind_lib.c that is not very library friendly and will print the names of the files that use a given metadata address. It would be nicer to have a more general approach that either returns a list of the names or that has a callback so that other programs can find out the names of a metadata address without needing to print the data. tsk_fs_ifind_data() has similar needs for improvement because it too prints the metadata addresses that point to blocks instead of somehow returning the value to the caller and letting it decide how to handle the data (print, process, etc.). tsk_fs_path2inum() was made more library friendly and returns the metadata address, but this is an easier problem because there is only one value that a name can point to. The challenge with mapping blocks to metadata and metadata to a name is that there could be multiple values. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-30 18:04 Message: Dear Mr.Carrier, Would you please explain more about this issue? What is its usability? Could you please give me an example. Actually I'm doing my graduate thesis about digital forensics field and need to implement some new features for an open source tool. I've chosen Autopsy and TSK. I read each requested feature detail carefully but couldn't decide what to implement yet. I'm familiar with etx3 file system and TSK data structures. I want to know if you could give me a suggestion. Thanks a lot in advance. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-06-07 03:51:35
|
Feature Requests item #3012324, was opened at 2010-06-07 03:51 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3012324&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Move name mangling out of library to CLI tools Initial Comment: All of the file systems (except HFS+, but I need to add it there) have a variation of this code: for (i = 0; fs_name->name[i] != '\0'; i++) { if (TSK_IS_CNTRL(fs_name->name[i])) fs_name->name[i] = '^'; } where TSK_IS_CNTRL is defined as: #define TSK_IS_CNTRL(x) (((x) < 0x20) && ((x) >= 0x00)) This code should be moved to fls and other programs that display filenames. The API should not name mangle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3012324&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-05-27 13:26:56
|
Feature Requests item #2206306, was opened at 2008-10-28 22:43 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: function to map name to inode Initial Comment: A more formal function should exist to map the name to an inode / metadata address. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-05-27 08:26 Message: I would say that the requirements for the function should be: - Can handle an unlimited number of names (i.e. it does not return only the first 10 names). In most cases, there will be only one or two names, but if there is a limit than it could be a data hiding technique. - Does not use global variables so that this can be used in a multi-threaded environment. You could create a new struct that stores the number of names found and a list of the names along with a function to free the data allocated to the struct. The caller than needs to free the struct when they are done with the contents. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 01:32 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 01:32 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-03-30 16:49 Message: There is the tsk_fs_ffind() method in tsk3/fs/ffind_lib.c that is not very library friendly and will print the names of the files that use a given metadata address. It would be nicer to have a more general approach that either returns a list of the names or that has a callback so that other programs can find out the names of a metadata address without needing to print the data. tsk_fs_ifind_data() has similar needs for improvement because it too prints the metadata addresses that point to blocks instead of somehow returning the value to the caller and letting it decide how to handle the data (print, process, etc.). tsk_fs_path2inum() was made more library friendly and returns the metadata address, but this is an easier problem because there is only one value that a name can point to. The challenge with mapping blocks to metadata and metadata to a name is that there could be multiple values. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-30 08:34 Message: Dear Mr.Carrier, Would you please explain more about this issue? What is its usability? Could you please give me an example. Actually I'm doing my graduate thesis about digital forensics field and need to implement some new features for an open source tool. I've chosen Autopsy and TSK. I read each requested feature detail carefully but couldn't decide what to implement yet. I'm familiar with etx3 file system and TSK data structures. I want to know if you could give me a suggestion. Thanks a lot in advance. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-05-27 06:32:41
|
Feature Requests item #2206306, was opened at 2008-10-29 07:13 Message generated for change (Comment added) made by negin99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: function to map name to inode Initial Comment: A more formal function should exist to map the name to an inode / metadata address. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 11:02 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 11:02 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-03-31 02:19 Message: There is the tsk_fs_ffind() method in tsk3/fs/ffind_lib.c that is not very library friendly and will print the names of the files that use a given metadata address. It would be nicer to have a more general approach that either returns a list of the names or that has a callback so that other programs can find out the names of a metadata address without needing to print the data. tsk_fs_ifind_data() has similar needs for improvement because it too prints the metadata addresses that point to blocks instead of somehow returning the value to the caller and letting it decide how to handle the data (print, process, etc.). tsk_fs_path2inum() was made more library friendly and returns the metadata address, but this is an easier problem because there is only one value that a name can point to. The challenge with mapping blocks to metadata and metadata to a name is that there could be multiple values. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-30 18:04 Message: Dear Mr.Carrier, Would you please explain more about this issue? What is its usability? Could you please give me an example. Actually I'm doing my graduate thesis about digital forensics field and need to implement some new features for an open source tool. I've chosen Autopsy and TSK. I read each requested feature detail carefully but couldn't decide what to implement yet. I'm familiar with etx3 file system and TSK data structures. I want to know if you could give me a suggestion. Thanks a lot in advance. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-05-27 06:32:26
|
Feature Requests item #2206306, was opened at 2008-10-29 07:13 Message generated for change (Comment added) made by negin99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: function to map name to inode Initial Comment: A more formal function should exist to map the name to an inode / metadata address. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-27 11:02 Message: Thanks for the info. I decided to implement the request with returning a list of file names. But I want to know which is more suitable according to the TSK architecture: defining a static length string array or returning one single char* string? Thanks in advance for your soon answer. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-03-31 02:19 Message: There is the tsk_fs_ffind() method in tsk3/fs/ffind_lib.c that is not very library friendly and will print the names of the files that use a given metadata address. It would be nicer to have a more general approach that either returns a list of the names or that has a callback so that other programs can find out the names of a metadata address without needing to print the data. tsk_fs_ifind_data() has similar needs for improvement because it too prints the metadata addresses that point to blocks instead of somehow returning the value to the caller and letting it decide how to handle the data (print, process, etc.). tsk_fs_path2inum() was made more library friendly and returns the metadata address, but this is an easier problem because there is only one value that a name can point to. The challenge with mapping blocks to metadata and metadata to a name is that there could be multiple values. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-30 18:04 Message: Dear Mr.Carrier, Would you please explain more about this issue? What is its usability? Could you please give me an example. Actually I'm doing my graduate thesis about digital forensics field and need to implement some new features for an open source tool. I've chosen Autopsy and TSK. I read each requested feature detail carefully but couldn't decide what to implement yet. I'm familiar with etx3 file system and TSK data structures. I want to know if you could give me a suggestion. Thanks a lot in advance. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-05-25 02:59:02
|
Bugs item #3006733, was opened at 2010-05-24 21:55 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3006733&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: FAT Performance Problems Initial Comment: To the Users List: Hi! This version still has performance problems with fls on FAT. When listing the contents of a root directory (D:\) everything is ok. When listing the contents of a first subdirectory (D:\sub1) everything is ok. When listing the contents of a second subdirectory (D:\sub1\sub2) it scans the whole disk. --- Suhanov Maxim An image was provided: http://anti-forensics.ru/tsk3/fat_big.dd.rar Simson helped to confirm this. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-05-24 21:58 Message: Thanks for the image! Issue was caused because tsk_fs_dir_walk_lcl was not stopping even when the callback asked it to. This caused problems when TSK needed to hunt for the parent directory in a FAT file system and it got stuck looking for orphan files each time. Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/fs_dir.c Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fs_dir.c Transmitting file data .... Committed revision 206. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3006733&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-05-25 02:55:41
|
Bugs item #3006733, was opened at 2010-05-24 21:55 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3006733&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: Brian Carrier (carrier) Summary: FAT Performance Problems Initial Comment: To the Users List: Hi! This version still has performance problems with fls on FAT. When listing the contents of a root directory (D:\) everything is ok. When listing the contents of a first subdirectory (D:\sub1) everything is ok. When listing the contents of a second subdirectory (D:\sub1\sub2) it scans the whole disk. --- Suhanov Maxim An image was provided: http://anti-forensics.ru/tsk3/fat_big.dd.rar Simson helped to confirm this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3006733&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-05-22 09:31:45
|
Feature Requests item #2288736, was opened at 2008-11-15 08:48 Message generated for change (Comment added) made by negin99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=2288736&group_id=55687 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Better reports Initial Comment: Generate HTML or some other non-ASCII form of reports. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-05-22 14:01 Message: Dear Mr.Carrier, Have you received any feedbacks regarding the reports' format yet? Waiting to receive your answer. Best, Negin ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-03-24 05:40 Message: Yea, the request was meant to cover all of the reports. The file analysis mode is a good place to start. I would open the question to the users on sleuthkit-users to see what they would like to see. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-04 10:51 Message: Hi! I'm eager to help with this issue but I have some questions about it: First, do you mean the reports that generated in file analysis mode? (ASCII, HEX, ASCII string) and second, would you please explain more in detail which format is preferable and give me some hints? Thanks a lot in advance and hope that I could help. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=2288736&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2010-05-17 02:49:24
|
Bugs item #2994088, was opened at 2010-04-29 05:12 Message generated for change (Comment added) made by carrier 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 ? ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-05-16 21:49 Message: Can you provide a sample or more examples? I have an image here with compressed files that are properly taggged. What version of WIndows created the file system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2994088&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2010-05-17 02:39:57
|
The read issue is fixed. Thanks. On Apr 28, 2010, at 4:27 PM, Brian Carrier wrote: > 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 > > > ------------------------------------------------------------------------------ > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
1 message has been excluded from this view by a project administrator.
