sleuthkit-developers Mailing List for The Sleuth Kit (Page 29)
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: RB <ao...@gm...> - 2009-08-18 14:27:39
|
On Tue, Aug 18, 2009 at 08:00, Stefano Guidobaldi<ste...@ya...> wrote: > Problem is, I don't find anything in TSK that tells me which physical blocks > of hdd are allocated to a certain filename. Is there a way to retrieve this > information? You'll need to map physical blocks to inodes (using ifind), then inodes to filenames (using ffind). > TSK gives me the inode metadata structure of every file, which could be > useful, but totally useless in case the filesystem table of the original hdd > is corrupted. In that case, you may not have file names any more to link back to depending on the filesystem and type of corruption. |
|
From: Michael C. <scu...@gm...> - 2009-08-18 14:17:02
|
On Tue, Aug 18, 2009 at 10:00 AM, Stefano Guidobaldi<ste...@ya...> wrote: Hi Stefano, > I have a problem in performing a new feature in PhotoRec. > Photorec carves file from corrupted hard drives and saves them in default > directories named "recup_dir.*". > It saves file in the format "f0000000.extension", where number represents > the offset of the file from the start of the disk image, divided by > blocksize. This scheme might lead to problems when dealing with very small resident files as they might be at different disk offsets, but within the same block (so they get the same name). Resident files live in the MFT and are not block aligned. Similarly filesystems like Reiser are not block aligned btw. > Now, I'm trying to use TSK in order to retrieve filenames from hdd, and > then, writing some code in PhotoRec, I intend to add the feature of saving > files with their own name, not the "f00000000.ext" stuff. > > Problem is, I don't find anything in TSK that tells me which physical blocks > of hdd are allocated to a certain filename. Is there a way to retrieve this > information? Essentially you need to build a big table of all allocated blocks in all reachanble files (do an filesystem walk, open each file, and get its block allocation) and map them back to the filename (or more correctly the inode). Then you can resolve which file contains any given block? Here is something similar written using the python bindings: http://code.google.com/p/aff4/source/browse/python/fsbuilder.py > TSK gives me the inode metadata structure of every file, which could be > useful, but totally useless in case the filesystem table of the original hdd > is corrupted. If the filesystem is corrupted you will not have block allocation or filename information, so you may not be able to resolve the filename. > Thanks for the suggestions, Thanks for working on photorec - great tool!!! Michael. |
|
From: Stefano G. <ste...@ya...> - 2009-08-18 14:00:47
|
Hello,
I have a problem in performing a new feature in PhotoRec.
Photorec carves file from corrupted hard drives and saves them in default directories named "recup_dir.*".
It saves file in the format "f0000000.extension", where number represents the offset of the file from the start of the disk image, divided by blocksize.
Now, I'm trying to use TSK in order to retrieve filenames from hdd, and then, writing some code in PhotoRec, I intend to add the feature of saving files with their own name, not the "f00000000.ext" stuff.
Problem is, I don't find anything in TSK that tells me which physical blocks of hdd are allocated to a certain filename. Is there a way to retrieve this information?
TSK gives me the inode metadata structure of every file, which could be useful, but totally useless in case the filesystem table of the original hdd is corrupted.
Thanks for the suggestions,
Stefano
|
|
From: SourceForge.net <no...@so...> - 2009-07-23 00:52:10
|
Feature Requests item #2825693, was opened at 2009-07-22 19:52 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2825693&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: blk_calc for allocated blocks Initial Comment: blk_calc can map unallocated to the image, but not allocated only back to the image (i.e. from blkls -a). It could have that feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2825693&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-07-23 00:49:25
|
Bugs item #2825690, was opened at 2009-07-22 19:49 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2825690&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: blks -A not working Initial Comment: >From John Lehr: Good Morning Group, I have a question about blkls, particularly the –a option. I am creating keyword search files with blkls and srch_strings, and I wanted to distinguish between allocated and unallocated, created one two text files for each type of block (ascii and unicode). For unallocated, I used something like: # blkls partition.dd | srch_strings –t d > text.file This produced a text file of ascii strings with byte offset from unallocated blocks as desired. For allocated, I tried: # blkls –a partition.dd | srch_strings –t d > text.file But, surprisingly, it looks like all blocks were exported from the partition, not just allocated blocks. (I piped blkls through ‘pv’ to meter the output and instead of getting the 83gb of allocated space, I got the whole 221gb partition). Confirmed by RB: Confirmed on 3.0.1/Gentoo: [test@test sleuthtest] dd if=/dev/zero of=ext2.img bs=1024 count=1024 1024+0 records in 1024+0 records out 1048576 bytes (1.0 MB) copied, 0.00636198 s, 165 MB/s [test@test sleuthtest] mkfs.ext2 -q ext2.img [test@test sleuthtest] md5sum ext2.img 3adb3f90e51cde1277036247809a051e ext2.img [test@test sleuthtest] blkls -a ext2.img | md5sum - 3adb3f90e51cde1277036247809a051e - [test@test sleuthtest] blkls -e ext2.img | md5sum - 3adb3f90e51cde1277036247809a051e - [test@test sleuthtest] blkls -A ext2.img | md5sum - b04822bb7365e95e9e73b770c8f44508 - ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2825690&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-07-22 02:17:56
|
Feature Requests item #2206331, was opened at 2008-10-28 22:56 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206331&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: 7 Private: No Submitted By: Brian Carrier (carrier) >Assigned to: Brian Carrier (carrier) Summary: Indirect block support in UFS/ExtX Initial Comment: TSK 3 no longer allows indirect blocks to be found from 'ifind' or displayed in 'istat'. It could be by adding the indirect blocks to another attribute. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-07-21 21:15 Message: Added using another attriibute type. Checked into trunk. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/ext2fs.c Sending trunk/tsk3/fs/ffs.c Sending trunk/tsk3/fs/fs_attrlist.c Sending trunk/tsk3/fs/ifind_lib.c Sending trunk/tsk3/fs/tsk_fs.h Sending trunk/tsk3/fs/unix_misc.c Transmitting file data ....... Committed revision 103. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206331&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-07-20 20:11:04
|
Bugs item #2824457, was opened at 2009-07-20 16:10 Message generated for change (Tracker Item Submitted) made by robjoyce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2824457&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: Rob (robjoyce) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot read last block with blkcat Initial Comment: If you try to read the last block of an image with blkcat, the beyond-end-of-disk check in fsk_fs_blkcat fails (it's off by one). The attached patch fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2824457&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-07-14 00:58:39
|
Bugs item #2821031, was opened at 2009-07-13 19:56 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2821031&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: missing body fields Initial Comment: For unallocated files with no metadata structure, TSK is missing a 0 for the new body format. From: jsm...@go... Subject: [sleuthkit-users] fls: missing field Date: July 12, 2009 2:38:53 PM EDT To: sle...@li... Reply-To: jsm...@gm... Hi When running fls against one of my Ext3 partitions I notice that 34 out of 17512 entries are missing one of the 'body file' format fields. $ fls -V The Sleuth Kit ver 3.0.1 $ sudo fls -r -m / /dev/sda4 > fls.out According to the wiki http://wiki.sleuthkit.org/index.php?title=Body_file The 3.X output has the following fields: MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime Example output: ... 0|/Dir1/SubDir1/FileA (deleted)|9551913|r/rrwxrwx---|1000|1000|0|1199618002|1199765794|1199765794|0 0|/Dir1/SubDir2/FileB|2769344|r/rrwxr-xr-x|1000|1000|73350|1239210630|1234051666|1235248434|0 ... 0|/Dir1/FileC (deleted)|0|r/----------|0|0|0|0|0|0 0|/Dir1/FileD (deleted)|0|d/----------|0|0|0|0|0|0 ... The last two entries have 10 fields instead of 11. It is difficult to identify which field is missing in each case as most values are zeroes. Do you know which field is missing and why? Other info: $ sudo istat /dev/sda4 0 Metadata address is too small for image (1) $ sudo ils /dev/sda4 0 class|host|device|start_time ils|myhost||1247422110 st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_crtime|st_mode|st_nlink|st_size Invalid walk range (extXfs_inode_walk: end inode: 0) Thank you JS ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-07-13 19:58 Message: Sending CHANGES.txt Sending tsk3/fs/fs_name.c Transmitting file data .. Committed revision 102. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2821031&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-07-14 00:56:12
|
Bugs item #2821031, was opened at 2009-07-13 19:56 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2821031&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: missing body fields Initial Comment: For unallocated files with no metadata structure, TSK is missing a 0 for the new body format. From: jsm...@go... Subject: [sleuthkit-users] fls: missing field Date: July 12, 2009 2:38:53 PM EDT To: sle...@li... Reply-To: jsm...@gm... Hi When running fls against one of my Ext3 partitions I notice that 34 out of 17512 entries are missing one of the 'body file' format fields. $ fls -V The Sleuth Kit ver 3.0.1 $ sudo fls -r -m / /dev/sda4 > fls.out According to the wiki http://wiki.sleuthkit.org/index.php?title=Body_file The 3.X output has the following fields: MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime Example output: ... 0|/Dir1/SubDir1/FileA (deleted)|9551913|r/rrwxrwx---|1000|1000|0|1199618002|1199765794|1199765794|0 0|/Dir1/SubDir2/FileB|2769344|r/rrwxr-xr-x|1000|1000|73350|1239210630|1234051666|1235248434|0 ... 0|/Dir1/FileC (deleted)|0|r/----------|0|0|0|0|0|0 0|/Dir1/FileD (deleted)|0|d/----------|0|0|0|0|0|0 ... The last two entries have 10 fields instead of 11. It is difficult to identify which field is missing in each case as most values are zeroes. Do you know which field is missing and why? Other info: $ sudo istat /dev/sda4 0 Metadata address is too small for image (1) $ sudo ils /dev/sda4 0 class|host|device|start_time ils|myhost||1247422110 st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_crtime|st_mode|st_nlink|st_size Invalid walk range (extXfs_inode_walk: end inode: 0) Thank you JS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2821031&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-07-06 06:46:02
|
Bugs item #2817274, was opened at 2009-07-06 10:46 Message generated for change (Tracker Item Submitted) made by markinvv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817274&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: Markin Vlad (markinvv) Assigned to: Nobody/Anonymous (nobody) Summary: REENTERANT problem Initial Comment: sleuthkit-3.0-2009-6-16 on Linux 2.6.29.4 The functions of the library to work with FF (libtsk3) not REENTERANT. They are difficult to use in multithreaded applications. For example, I need to simultaneously search the files and read the file. Preferably with the use of one object IMG_INFO and FS_INFO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817274&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-07-06 06:05:43
|
Bugs item #2817264, was opened at 2009-07-06 10:05 Message generated for change (Tracker Item Submitted) made by markinvv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817264&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: Markin Vlad (markinvv) Assigned to: Nobody/Anonymous (nobody) Summary: REENTERANT problem Initial Comment: sleuthkit-3.0-2009-6-16 on Linux 2.6.29.4 The functions of the library to work with FF (libtsk3) not REENTERANT. They are difficult to use in multithreaded applications. For example, I need to simultaneously search the files and read the file. Preferably with the use of one object IMG_INFO and FS_INFO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817264&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-07-06 05:37:21
|
Bugs item #2817257, was opened at 2009-07-06 09:37 Message generated for change (Tracker Item Submitted) made by markinvv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817257&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: Markin Vlad (markinvv) Assigned to: Nobody/Anonymous (nobody) Summary: bad DATA_RUN Initial Comment: sleuthkit-3.0-2009-6-16 on Linux 2.6.29.4 The mechanism of reading the files using a very bad DATA_RUN works on "large" files (for example, 20 GB). In fact, the library has not read the entire chain of blocks of the file, the program is blocked. If your RAM is limited, "large" file do not get read if it is highly fragmented. Perhaps it makes sense to build DATA_RUN file in the pthread, blocking the main program only if the address of the requested block is not yet available at DATA_RUN. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2817257&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-06-08 15:29:03
|
Feature Requests item #2803014, was opened at 2009-06-08 10:29 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2803014&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Resident and Compressed File Offsets in callback Initial Comment: Simson proposed that file_walk pass the actual offsets for resident files (even though the attribute is somewhere in that sector and the specific offset is not given). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2803014&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-06-01 21:31:41
|
Feature Requests item #2206337, was opened at 2008-10-28 22:58 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206337&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: Closed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Support for unsupported AFFlib types Initial Comment: AFFLIB may support image types that have not officially been tested with TSK. It could be useful to have a special type that is give on the command line (such as "afflib") that allows AFFLIB to use whatever features it has. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-06-01 16:31 Message: Fixed along with request 2677107. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206337&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-06-01 21:26:21
|
Feature Requests item #2206265, was opened at 2008-10-28 22:30 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206265&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: sigfind use imglayer Initial Comment: sigfind should use the img layer so that it can read eo1 and aff files. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-06-01 16:26 Message: Sending trunk/CHANGES.txt Sending trunk/tools/srchtools/sigfind.cpp Transmitting file data .. Committed revision 101. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206265&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-29 17:38:23
|
Feature Requests item #2206355, was opened at 2008-10-28 23:05 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206355&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: Disk Group: None >Status: Deleted Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: DCO Detection Initial Comment: diskstat could report DCO existence. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-29 12:38 Message: removed disktools from TSK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206355&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-29 17:37:42
|
Feature Requests item #2206357, was opened at 2008-10-28 23:07 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206357&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: Disk Group: None >Status: Deleted Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Add 48-bit ATA command support Initial Comment: diskstat could support 48-bit ATA commands. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-29 12:37 Message: Removed disktools from TSK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206357&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-29 17:36:55
|
Feature Requests item #2790367, was opened at 2009-05-11 18:19 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2790367&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: Closed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Move 'stat' until after all tests Initial Comment: In img_open() , it would be easier for different image types if the 'stat' was moved to exist only if all image types failed. This allows some "image types" to not need to use actual files that exist (i.e. urls, encoded data, etc.). ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-29 12:36 Message: Sending trunk/CHANGES.txt Sending trunk/tsk3/img/img_open.c Sending trunk/tsk3/img/img_types.c Sending trunk/tsk3/img/raw.c Transmitting file data .... Committed revision 100. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2790367&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-29 17:06:57
|
Feature Requests item #2677107, was opened at 2009-03-09 20:34 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2677107&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Michael Cohen (scudette) Assigned to: Nobody/Anonymous (nobody) Summary: Sleuthkit restricts AFF support Initial Comment: The AFF library has a vnode interface allowing it to transparently support multiple image types, however in Sleuthkit we have code like (aff.c): else if (type == AF_IDENTIFY_AFF) { img_info->itype = TSK_IMG_TYPE_AFF_AFF; } else if (type == AF_IDENTIFY_AFD) { img_info->itype = TSK_IMG_TYPE_AFF_AFD; } else if (type == AF_IDENTIFY_AFM) { img_info->itype = TSK_IMG_TYPE_AFF_AFM; } else { tsk_error_reset(); tsk_errno = TSK_ERR_IMG_MAGIC; snprintf(tsk_errstr, TSK_ERRSTR_L, "aff_open: Not an AFF, AFD, or AFM file"); free(aff_info); if (tsk_verbose) tsk_fprintf(stderr, "Not an AFF/AFD/AFM file\n"); return NULL; } etc This does not allow afflib to present other types of images than those which sleuthkit specifically knows about. Sleuthkit should just trap errors from afflib and allow it to handle everything else by itself. I realise this might interfere with sleuthkit's own support for ewf etc. So maybe this should only be allowed where the -i switch is specifically given to use afflib. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-29 12:06 Message: Sending trunk/CHANGES.txt Sending trunk/tsk3/img/aff.c Sending trunk/tsk3/img/img_open.c Sending trunk/tsk3/img/img_types.c Sending trunk/tsk3/img/tsk_img.h Sending trunk/xcode/sleuthkit.xcodeproj/project.pbxproj Transmitting file data ...... Committed revision 99. Specify "afflib" as the image type to get support for all AFFLIB formats. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-03-23 22:52 Message: I think the way I want to resolve this is to create a special image file type that enables the non-tested AFF formats. In general, I do not want to enable features that I am not sure how well they work and am not sure how much they have been tested because any bugs that existing in the image library will likely be reported as TSK bugs, which I then need to debug. Therefore, my plan is to allow the stable formats to be included in the autodetection methods and force the users to "opt-in" to the newer formats. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2677107&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-27 04:36:13
|
Feature Requests item #2797170, was opened at 2009-05-26 21:36 Message generated for change (Tracker Item Submitted) made by xchatty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2797170&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: xchatty (xchatty) Assigned to: Nobody/Anonymous (nobody) Summary: tsk_fs_make_ls should return its buffer Initial Comment: It would be nice if it returned a string value of the "ls" buffer, rather than void, so that the call could just be put in a printf functional-style, and save a line of code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2797170&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-27 04:35:03
|
Feature Requests item #2797169, was opened at 2009-05-26 21:35 Message generated for change (Tracker Item Submitted) made by xchatty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2797169&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: xchatty (xchatty) Assigned to: Nobody/Anonymous (nobody) Summary: please add tsk_fs_make_ls to library Initial Comment: tsk_fs_make_ls should be in the library, rather than in fls, so that it can be used in other programs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2797169&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-26 17:26:49
|
Bugs item #2796945, was opened at 2009-05-26 11:48 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2796945&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: infinite loop in fs_attr Initial Comment: >From Simson Garfinkel: I seem to have found an infinite loop in sleuthkit-trunk-2009.5.4 The problems comes when setting the TSK_FS_FILE_WALK_FLAG_AONLY flag when calling tsk_fs_file_walk. The problem seems to be in tsk_fs_attr_walk_res in fs_attr.c: Here is the code at line 695: /* Allocate a buffer that is at most a block size in length */ if ((a_flags & TSK_FS_FILE_WALK_FLAG_AONLY) == 0) { buf_len = (size_t) fs_attr->size; if (buf_len > fs->block_size) buf_len = fs->block_size; if ((buf = tsk_malloc(buf_len)) == NULL) { return 1; } } Because TSK_FS_FILE_WALK_FLAG_AONLY is set, buf_len is set to 0. But then in this loop, read_len is set to buf_len: for (off = 0; off < fs_attr->size; off += read_len) { => if (fs_attr->size - off > buf_len) read_len = buf_len; else read_len = (size_t) (fs_attr->size - off); if (buf) { // wipe rest of buffer if we are not going to read into all of it if (read_len != buf_len) memset(&buf[read_len], 0, buf_len - read_len); memcpy(buf, &fs_attr->rd.buf[off], read_len); } retval = a_action(fs_attr->fs_file, off, 0, buf, read_len, myflags, a_ptr); if (retval != TSK_WALK_CONT) break; } The problem is that buf_len is 0, so we have an infinite loop. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-26 12:26 Message: Sending CHANGES.txt Sending tsk3/fs/fs_attr.c Transmitting file data .. Committed revision 98. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2796945&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-26 16:48:54
|
Bugs item #2796945, was opened at 2009-05-26 11:48 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2796945&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: infinite loop in fs_attr Initial Comment: >From Simson Garfinkel: I seem to have found an infinite loop in sleuthkit-trunk-2009.5.4 The problems comes when setting the TSK_FS_FILE_WALK_FLAG_AONLY flag when calling tsk_fs_file_walk. The problem seems to be in tsk_fs_attr_walk_res in fs_attr.c: Here is the code at line 695: /* Allocate a buffer that is at most a block size in length */ if ((a_flags & TSK_FS_FILE_WALK_FLAG_AONLY) == 0) { buf_len = (size_t) fs_attr->size; if (buf_len > fs->block_size) buf_len = fs->block_size; if ((buf = tsk_malloc(buf_len)) == NULL) { return 1; } } Because TSK_FS_FILE_WALK_FLAG_AONLY is set, buf_len is set to 0. But then in this loop, read_len is set to buf_len: for (off = 0; off < fs_attr->size; off += read_len) { => if (fs_attr->size - off > buf_len) read_len = buf_len; else read_len = (size_t) (fs_attr->size - off); if (buf) { // wipe rest of buffer if we are not going to read into all of it if (read_len != buf_len) memset(&buf[read_len], 0, buf_len - read_len); memcpy(buf, &fs_attr->rd.buf[off], read_len); } retval = a_action(fs_attr->fs_file, off, 0, buf, read_len, myflags, a_ptr); if (retval != TSK_WALK_CONT) break; } The problem is that buf_len is 0, so we have an infinite loop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2796945&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-11 23:20:03
|
Feature Requests item #2790367, was opened at 2009-05-11 18:19 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2790367&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: Move 'stat' until after all tests Initial Comment: In img_open() , it would be easier for different image types if the 'stat' was moved to exist only if all image types failed. This allows some "image types" to not need to use actual files that exist (i.e. urls, encoded data, etc.). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2790367&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2009-05-08 14:48:09
|
Bugs item #2596153, was opened at 2009-02-13 09:47 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2596153&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: tsk_img_open arguments Initial Comment: >From Simson Garfinkel: tsk_img_open_utf8 is prototyped: extern TSK_IMG_INFO *tsk_img_open_utf8(int num_img, const char **images, TSK_IMG_TYPE_ENUM type); where images is, I guess, argv. The problem is that getopt() prototypes argv this way: getopt(int argc, char * const argv[], const char *optstring); Passing argv to tsk_img_open_utf8 produces this error: error: invalid conversion from ‘char* const*’ to ‘const char**’ I can fix this with a cast, but perhaps tsk_img_open_utf8 should be changed to match. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-05-08 09:47 Message: win32 code also fixed. Sending trunk/tsk3/img/img_open.c Transmitting file data . Committed revision 95. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-05-08 07:54 Message: Fixed for Unix systems. Still need to do for Win32 arguments. Sending trunk/tests/fs_attrlist_apis.cpp Sending trunk/tests/fs_fname_apis.cpp Sending trunk/tests/read_apis.cpp Sending trunk/tools/fstools/blkcalc.cpp Sending trunk/tools/fstools/blkcat.cpp Sending trunk/tools/fstools/blkls.cpp Sending trunk/tools/fstools/blkstat.cpp Sending trunk/tools/fstools/ffind.cpp Sending trunk/tools/fstools/fls.cpp Sending trunk/tools/fstools/fscheck.cpp Sending trunk/tools/fstools/fsstat.cpp Sending trunk/tools/fstools/icat.cpp Sending trunk/tools/fstools/ifind.cpp Sending trunk/tools/fstools/ils.cpp Sending trunk/tools/fstools/istat.cpp Sending trunk/tools/fstools/jcat.cpp Sending trunk/tools/fstools/jls.cpp Sending trunk/tools/imgtools/img_cat.cpp Sending trunk/tools/imgtools/img_stat.cpp Sending trunk/tools/vstools/mmcat.cpp Sending trunk/tools/vstools/mmls.cpp Sending trunk/tools/vstools/mmstat.cpp Sending trunk/tsk3/img/aff.c Sending trunk/tsk3/img/aff.h Sending trunk/tsk3/img/ewf.c Sending trunk/tsk3/img/ewf.h Sending trunk/tsk3/img/img_io.c Sending trunk/tsk3/img/img_open.c Sending trunk/tsk3/img/raw.c Sending trunk/tsk3/img/split.c Sending trunk/tsk3/img/split.h Sending trunk/tsk3/img/tsk_img.h Transmitting file data ................................ Committed revision 94. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2596153&group_id=55685 |
1 message has been excluded from this view by a project administrator.
