sleuthkit-developers Mailing List for The Sleuth Kit (Page 26)
Brought to you by:
carrier
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(22) |
Feb
(39) |
Mar
(8) |
Apr
(17) |
May
(10) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(4) |
2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(9) |
Jul
(14) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
2009 |
Jan
(7) |
Feb
(10) |
Mar
(10) |
Apr
(19) |
May
(16) |
Jun
(3) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(16) |
Nov
(35) |
Dec
(30) |
2010 |
Jan
(4) |
Feb
(24) |
Mar
(25) |
Apr
(31) |
May
(11) |
Jun
(9) |
Jul
(11) |
Aug
(31) |
Sep
(11) |
Oct
(10) |
Nov
(15) |
Dec
(3) |
2011 |
Jan
(8) |
Feb
(17) |
Mar
(14) |
Apr
(2) |
May
(4) |
Jun
(4) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(8) |
Nov
(16) |
Dec
(1) |
2012 |
Jan
(9) |
Feb
(2) |
Mar
(3) |
Apr
(13) |
May
(10) |
Jun
(7) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(3) |
2013 |
Jan
(16) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
2014 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(18) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
2015 |
Jan
(5) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
2016 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(23) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: SourceForge.net <no...@so...> - 2009-12-18 02:05:26
|
Feature Requests item #2206341, was opened at 2008-10-28 22:59 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206341&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: AFF Crypto support Initial Comment: AFF supports encrypted files and the password and such can be given in the file name. Test if this works with TSK and if it needs new features. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-17 21:05 Message: This has been tested to work. The trunk now has code to give proper error if incorrect password is given (instead of trying to open the image as raw). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206341&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-18 02:02:55
|
Feature Requests item #2797170, was opened at 2009-05-26 23:36 Message generated for change (Comment added) made by carrier 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: Deleted 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. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-17 21:02 Message: I think this would be too confusing because the buffer is passed by the caller and it could result in some people trying to free it twice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2797170&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-18 02:00:49
|
Feature Requests item #2797169, was opened at 2009-05-26 23:35 Message generated for change (Comment added) made by carrier 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: Closed 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. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-17 21:00 Message: Done. Renamed to tsk_fs_meta_make_ls and added length as an argument. Sending trunk/tsk3/fs/ext2fs.c Sending trunk/tsk3/fs/ffs.c Sending trunk/tsk3/fs/fs_name.c Sending trunk/tsk3/fs/hfs.c Sending trunk/tsk3/fs/ils_lib.c Sending trunk/tsk3/fs/tsk_fs.h Sending trunk/tsk3/fs/tsk_fs_i.h Transmitting file data ....... Committed revision 147. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2797169&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-14 18:07:17
|
Bugs item #2912227, was opened at 2009-12-10 15:12 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2912227&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: Rob (robjoyce) Assigned to: Nobody/Anonymous (nobody) Summary: Image offset error message has wrong sector size Initial Comment: This is pretty trivial: In istat.cpp, if the supplied sector offset it too large (line 195), the error message uses img->size / 512 instead of img->size / img->sector_size. I imagine there might be a couple other places where this occurs too. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-12-14 13:07 Message: Fixed (along with several other examples). Thanks. 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/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/vstools/mmcat.cpp Sending trunk/tools/vstools/mmls.cpp Sending trunk/tools/vstools/mmstat.cpp Sending trunk/tsk3/fs/fatfs.c Sending trunk/tsk3/fs/rawfs.c Sending trunk/tsk3/img/img_open.c Transmitting file data ................... Committed revision 144. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2912227&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-14 18:07:03
|
Bugs item #2912227, was opened at 2009-12-10 15:12 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2912227&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: Image offset error message has wrong sector size Initial Comment: This is pretty trivial: In istat.cpp, if the supplied sector offset it too large (line 195), the error message uses img->size / 512 instead of img->size / img->sector_size. I imagine there might be a couple other places where this occurs too. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-14 13:07 Message: Fixed (along with several other examples). Thanks. 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/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/vstools/mmcat.cpp Sending trunk/tools/vstools/mmls.cpp Sending trunk/tools/vstools/mmstat.cpp Sending trunk/tsk3/fs/fatfs.c Sending trunk/tsk3/fs/rawfs.c Sending trunk/tsk3/img/img_open.c Transmitting file data ................... Committed revision 144. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2912227&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-14 16:23:11
|
Bugs item #2914255, was opened at 2009-12-14 11:23 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2914255&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: Add version info as #define Initial Comment: Add the version into one of the .h files so that programs can use #ifdef statements to handle API changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2914255&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-10 20:12:57
|
Bugs item #2912227, was opened at 2009-12-10 15:12 Message generated for change (Tracker Item Submitted) made by robjoyce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2912227&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: Image offset error message has wrong sector size Initial Comment: This is pretty trivial: In istat.cpp, if the supplied sector offset it too large (line 195), the error message uses img->size / 512 instead of img->size / img->sector_size. I imagine there might be a couple other places where this occurs too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2912227&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-08 02:12:51
|
Feature Requests item #2895607, was opened at 2009-11-10 19:25 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Group: None >Status: Closed Priority: 5 Private: No Submitted By: James Butler (jamiebutler) Assigned to: Nobody/Anonymous (nobody) Summary: Identify in NTFS the SID of the owner of a file Initial Comment: The owner SID of files needs to be identified per file. Every file has an associated security identifier which identifies the owner, groups, etc. of the file. More than one file may have the same security identifier if the files share the exact same security descriptor. Using the security identifier of the file (secid), we can lookup its security descriptor within $Secure. Security descriptors are variable length and contained in the $SDS stream within $Secure. The $SII stream of $Secure is an index into the $SDS stream. $SII entries are stored incrementally by the secid. Once we find the secid of the file inside the $SII stream, the $SII entry will tell the offset within the $SDS stream to read the security descriptor. Use the tsk_fs_file_read_owner_sid function within fs_file.c to get the string representation of the owner SID of a file on NTFS. When an NTFS filesystem is opened ntfs_open is called. ntfs_open initializes a pointer to ntfs_lookup_security_id and then calls ntfs_load_secure. ntfs_load_secure opens MFT entry 9, $Secure, and reads in the $SDS and $SII streams. When tsk_fs_file_read_owner_sid is called on a TSK_FS_FILE, the owner SID is returned in its string form. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-07 21:12 Message: Fixed the missing error messages and changed the error handing of load_secure so that it could load FS w/no security info. Sending trunk/tsk3/fs/ntfs.c Transmitting file data . Committed revision 142. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-12-01 17:49 Message: Thanks. This has been added to the trunk. I changed it up a bit and moved some code around. For example, I moved the NTFS code from fs_file into ntfs.c and changed some of the NTFS functions, but most of it is the same. I'm keeping this open as a reminder to go in an add some more error statements into ntfs.c Sending trunk/tsk3/fs/fs_attrlist.c Sending trunk/tsk3/fs/fs_file.c Sending trunk/tsk3/fs/ntfs.c Sending trunk/tsk3/fs/tsk_fs.h Sending trunk/tsk3/fs/tsk_fs_i.h Sending trunk/tsk3/fs/tsk_ntfs.h Transmitting file data ...... Committed revision 135. ---------------------------------------------------------------------- Comment By: James Butler (jamiebutler) Date: 2009-11-25 17:12 Message: Sorry, here is that function. #define MIN(a, b) ((a) < (b) ? (a) : (b)) /** * \internal * Search the attribute list of TSK_FS_ATTR structures for an entry with a given * type (no ID) and a given name. If more than one entry with the same type exists, * the one with the lowest ID will be returned. * * @param a_fs_attrlist Data list structure to search in * @param a_type Type of attribute to find * @param name Name of the attribute to find * * @return NULL is returned on error and if an entry could not be found. * tsk_errno will be set to TSK_ERR_FS_ATTR_NOTFOUND if entry could not be found. */ const TSK_FS_ATTR * tsk_fs_attrlist_get_name_type(const TSK_FS_ATTRLIST * a_fs_attrlist, TSK_FS_ATTR_TYPE_ENUM a_type, char *name) { TSK_FS_ATTR *fs_attr_cur; TSK_FS_ATTR *fs_attr_ok = NULL; if ((!a_fs_attrlist) || (name == NULL)) { tsk_error_reset(); tsk_errno = TSK_ERR_FS_ARG; snprintf(tsk_errstr, TSK_ERRSTR_L, "tsk_fs_attrlist_get: Null list pointer"); tsk_errstr2[0] = '\0'; return NULL; } for (fs_attr_cur = a_fs_attrlist->head; fs_attr_cur; fs_attr_cur = fs_attr_cur->next) { if ((fs_attr_cur->flags & TSK_FS_ATTR_INUSE) && (fs_attr_cur->type == a_type) && (!strncmp(fs_attr_cur->name, name, MIN(fs_attr_cur->name_size, strlen(name)))) ) { /* If we are looking for NTFS $Data, * then return default when we see it */ if ((fs_attr_cur->type == TSK_FS_ATTR_TYPE_NTFS_DATA) && (fs_attr_cur->name_size > 5) && (strncmp(fs_attr_cur->name, "$Data", 5) == 0)) { return fs_attr_cur; } // make sure we return the lowest if multiple exist if ((fs_attr_ok == NULL) || (fs_attr_ok->id > fs_attr_cur->id)) fs_attr_ok = fs_attr_cur; } } if (!fs_attr_ok) { tsk_errno = TSK_ERR_FS_ATTR_NOTFOUND; snprintf(tsk_errstr, TSK_ERRSTR_L, "tsk_fs_attrlist_get: Attribute %d not found", a_type); return NULL; } else { return fs_attr_ok; } } ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-25 11:01 Message: Jamie, did you create a tsk_fs_attrlist_get_name_type() function as well? It is being called from the new NTFS code, but it is not defined in TSK and I didn't see it in the patch. thanks. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-25 10:30 Message: Applied memory leak patches into fs_file.c: Sending fs/fs_file.c Transmitting file data . Committed revision 131. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-04 02:47:37
|
Feature Requests item #2908516, was opened at 2009-12-03 21:47 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2908516&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: HFS Hot files Initial Comment: Show users which files are in the Hot Files B-Tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2908516&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-04 02:44:57
|
Feature Requests item #2908514, was opened at 2009-12-03 21:44 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2908514&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Finish HFS+ features Initial Comment: Add: - Resource fork support - Soft links - Hard links ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2908514&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-04 02:41:18
|
Feature Requests item #2908510, was opened at 2009-12-03 21:41 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2908510&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: Make temporal data more granular Initial Comment: TSK currently ignores temporal data that is smaller than 1 second. We should be storing that data somewhere (in a separate variable) and allowing the user to use it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2908510&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-04 02:39:22
|
Feature Requests item #2351426, was opened at 2008-11-26 11:37 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2351426&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Timeline Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Include mactime with Windows binaries Initial Comment: mactime could be included with the Windows binaries. Some installation issues need to be figured out because the 'make' process currently locates perl and adds that to the top of the mactime script. It was suggested that PAR could help... I haven't looked into it yet. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-03 21:39 Message: >From RB: On Nov 19, 2009, at 5:33 PM, RB wrote: On Thu, Nov 19, 2009 at 15:05, Brian Carrier <ca...@sl...> wrote: then I can make it happen. For example, what needs to happen for the script to find Perl.exe? Does the user have to edit the first line of the file to point to their installation? Do they need to run it as "perl mactime"? Generally speaking, yes - it's up to the Perl distribution to insert itself into %PATH%, and they typically do a good job of that. The ubiquitous "#!" from UNIX is relatively meaningless in that world, IIRC, so unless the user has also associated .pl scripts with perl.exe (another thing I've seen done), you'll have to invoke Perl first. Steps to make this happen: - update the release process to set the version in the script - Update the doc on using mactime on windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2351426&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-04 02:36:48
|
Feature Requests item #2367458, was opened at 2008-11-30 18:00 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2367458&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Group: None >Status: Closed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Process NTFS Security Attribute Initial Comment: Display the security settings for a file. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-03 21:36 Message: This has been addressed by the patch in Issue 2895607. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2367458&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-04 02:27:17
|
Bugs item #2905750, was opened at 2009-11-29 16:33 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2905750&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: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: reading data from compressed file on NTFS Initial Comment: This issue is reprodusable when trying to read content of a compressed file on NTFS with using tsk_fs_file_read funstion. Bug is reproduced on an alive OS while trying to read content of a C:\WINDOWS\ie7\inetres.adm file. Function tsk_fs_file_read continues reading data even when an offset from where to read data is past file's boundary. Function continues returning data without any error. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-03 21:27 Message: I confirmed that the code does not return -1 when offset is past the end of the file. 0 was returned instead. This was inconsistent with the reading functionality of the image layer, which returns -1 in that case. All file system code was updated to return -1 when an offset is given past the end of the allocated file size. Thanks! Sending trunk/tsk3/base/tsk_base.h Sending trunk/tsk3/base/tsk_error.c Sending trunk/tsk3/fs/fs_attr.c Sending trunk/tsk3/fs/fs_file.c Sending trunk/tsk3/fs/ntfs.c Sending trunk/tsk3/fs/tsk_fs.h Transmitting file data ...... Committed revision 138. ---------------------------------------------------------------------- Comment By: oncer oncer surname (oncer82) Date: 2009-11-29 16:35 Message: Windows XP, search pak 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2905750&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-02 03:12:25
|
Bugs item #2907248, was opened at 2009-12-01 22:10 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2907248&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: crash in image layer caching Initial Comment: Reported from Simson Garfinkel: (gdb) run -o63 ~/0411.iso Starting program: /Users/simsong/domex/src/dist/sleuthkit-3.1.0b1/tools/fstools/fls -o63 ~/0411.iso Reading symbols for shared libraries .+++++++++. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000001007f9ff0 0x00007fffffe00f40 in __memcpy () (gdb) where #0 0x00007fffffe00f40 in __memcpy () #1 0x0000000100004580 in __inline_memcpy_chk (__dest=0x100801e00, __src=0x1001ce014, __len=18446744073709519360) at _string.h:58 #2 0x0000000100004285 in tsk_img_read (a_img_info=0x10018e000, a_off=97792, a_buf=0x100801e00 "", a_len=1536) at img_io.c:71 #3 0x000000010003e8e6 in tsk_fs_read (a_fs=0x1002007a0, a_off=65536, a_buf=0x100801e00 "", a_len=1536) at fs_io.c:63 #4 0x00000001000364a2 in ffs_open (img_info=0x10018e000, offset=32256, ftype=TSK_FS_TYPE_FFS_DETECT) at ffs.c:1963 #5 0x000000010003ffc8 in tsk_fs_open_img (a_img_info=0x10018e000, a_offset=32256, a_ftype=TSK_FS_TYPE_DETECT) at fs_open.c:157 #6 0x0000000100001457 in main (argc=<value temporarily unavailable, due to optimizations>, argv1=0x7fff5fbfef80) at fls.cpp:263 (gdb) up #1 0x0000000100004580 in __inline_memcpy_chk (__dest=0x100801e00, __src=0x1001ce014, __len=18446744073709519360) at _string.h:58 58 return __builtin___memcpy_chk (__dest, __src, __len, __darwin_obsz0(__dest)); Current language: auto; currently c (gdb) up #2 0x0000000100004285 in tsk_img_read (a_img_info=0x10018e000, a_off=97792, a_buf=0x100801e00 "", a_len=1536) at img_io.c:71 71 memcpy(a_buf, (gdb) list 65,75 65 if (tsk_verbose) 66 fprintf(stderr, 67 "tsk_img_read: Read found in cache %d\n", i); 68 */ 69 70 // We found it... 71 memcpy(a_buf, 72 &a_img_info->cache[i][a_off - 73 a_img_info->cache_off[i]], len2); 74 retval = (ssize_t) len2; 75 (gdb) p a_buf $1 = 0x100801e00 "" (gdb) p i $2 = 3 (gdb) p a_off $3 = 97792 (gdb) p a_img_info->cache_off[i] $4 = 32256 (gdb) p len2 $5 = 18446744073709519360 (gdb) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-01 22:12 Message: Fixed. Issue was with length calculation when reading past end of image. Sending trunk/tsk3/img/img_io.c Transmitting file data . Committed revision 136. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2907248&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-02 03:10:13
|
Bugs item #2907248, was opened at 2009-12-01 22:10 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2907248&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: crash in image layer caching Initial Comment: Reported from Simson Garfinkel: (gdb) run -o63 ~/0411.iso Starting program: /Users/simsong/domex/src/dist/sleuthkit-3.1.0b1/tools/fstools/fls -o63 ~/0411.iso Reading symbols for shared libraries .+++++++++. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000001007f9ff0 0x00007fffffe00f40 in __memcpy () (gdb) where #0 0x00007fffffe00f40 in __memcpy () #1 0x0000000100004580 in __inline_memcpy_chk (__dest=0x100801e00, __src=0x1001ce014, __len=18446744073709519360) at _string.h:58 #2 0x0000000100004285 in tsk_img_read (a_img_info=0x10018e000, a_off=97792, a_buf=0x100801e00 "", a_len=1536) at img_io.c:71 #3 0x000000010003e8e6 in tsk_fs_read (a_fs=0x1002007a0, a_off=65536, a_buf=0x100801e00 "", a_len=1536) at fs_io.c:63 #4 0x00000001000364a2 in ffs_open (img_info=0x10018e000, offset=32256, ftype=TSK_FS_TYPE_FFS_DETECT) at ffs.c:1963 #5 0x000000010003ffc8 in tsk_fs_open_img (a_img_info=0x10018e000, a_offset=32256, a_ftype=TSK_FS_TYPE_DETECT) at fs_open.c:157 #6 0x0000000100001457 in main (argc=<value temporarily unavailable, due to optimizations>, argv1=0x7fff5fbfef80) at fls.cpp:263 (gdb) up #1 0x0000000100004580 in __inline_memcpy_chk (__dest=0x100801e00, __src=0x1001ce014, __len=18446744073709519360) at _string.h:58 58 return __builtin___memcpy_chk (__dest, __src, __len, __darwin_obsz0(__dest)); Current language: auto; currently c (gdb) up #2 0x0000000100004285 in tsk_img_read (a_img_info=0x10018e000, a_off=97792, a_buf=0x100801e00 "", a_len=1536) at img_io.c:71 71 memcpy(a_buf, (gdb) list 65,75 65 if (tsk_verbose) 66 fprintf(stderr, 67 "tsk_img_read: Read found in cache %d\n", i); 68 */ 69 70 // We found it... 71 memcpy(a_buf, 72 &a_img_info->cache[i][a_off - 73 a_img_info->cache_off[i]], len2); 74 retval = (ssize_t) len2; 75 (gdb) p a_buf $1 = 0x100801e00 "" (gdb) p i $2 = 3 (gdb) p a_off $3 = 97792 (gdb) p a_img_info->cache_off[i] $4 = 32256 (gdb) p len2 $5 = 18446744073709519360 (gdb) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2907248&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-12-01 22:49:27
|
Feature Requests item #2895607, was opened at 2009-11-10 19:25 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&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: James Butler (jamiebutler) Assigned to: Nobody/Anonymous (nobody) Summary: Identify in NTFS the SID of the owner of a file Initial Comment: The owner SID of files needs to be identified per file. Every file has an associated security identifier which identifies the owner, groups, etc. of the file. More than one file may have the same security identifier if the files share the exact same security descriptor. Using the security identifier of the file (secid), we can lookup its security descriptor within $Secure. Security descriptors are variable length and contained in the $SDS stream within $Secure. The $SII stream of $Secure is an index into the $SDS stream. $SII entries are stored incrementally by the secid. Once we find the secid of the file inside the $SII stream, the $SII entry will tell the offset within the $SDS stream to read the security descriptor. Use the tsk_fs_file_read_owner_sid function within fs_file.c to get the string representation of the owner SID of a file on NTFS. When an NTFS filesystem is opened ntfs_open is called. ntfs_open initializes a pointer to ntfs_lookup_security_id and then calls ntfs_load_secure. ntfs_load_secure opens MFT entry 9, $Secure, and reads in the $SDS and $SII streams. When tsk_fs_file_read_owner_sid is called on a TSK_FS_FILE, the owner SID is returned in its string form. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-12-01 17:49 Message: Thanks. This has been added to the trunk. I changed it up a bit and moved some code around. For example, I moved the NTFS code from fs_file into ntfs.c and changed some of the NTFS functions, but most of it is the same. I'm keeping this open as a reminder to go in an add some more error statements into ntfs.c Sending trunk/tsk3/fs/fs_attrlist.c Sending trunk/tsk3/fs/fs_file.c Sending trunk/tsk3/fs/ntfs.c Sending trunk/tsk3/fs/tsk_fs.h Sending trunk/tsk3/fs/tsk_fs_i.h Sending trunk/tsk3/fs/tsk_ntfs.h Transmitting file data ...... Committed revision 135. ---------------------------------------------------------------------- Comment By: James Butler (jamiebutler) Date: 2009-11-25 17:12 Message: Sorry, here is that function. #define MIN(a, b) ((a) < (b) ? (a) : (b)) /** * \internal * Search the attribute list of TSK_FS_ATTR structures for an entry with a given * type (no ID) and a given name. If more than one entry with the same type exists, * the one with the lowest ID will be returned. * * @param a_fs_attrlist Data list structure to search in * @param a_type Type of attribute to find * @param name Name of the attribute to find * * @return NULL is returned on error and if an entry could not be found. * tsk_errno will be set to TSK_ERR_FS_ATTR_NOTFOUND if entry could not be found. */ const TSK_FS_ATTR * tsk_fs_attrlist_get_name_type(const TSK_FS_ATTRLIST * a_fs_attrlist, TSK_FS_ATTR_TYPE_ENUM a_type, char *name) { TSK_FS_ATTR *fs_attr_cur; TSK_FS_ATTR *fs_attr_ok = NULL; if ((!a_fs_attrlist) || (name == NULL)) { tsk_error_reset(); tsk_errno = TSK_ERR_FS_ARG; snprintf(tsk_errstr, TSK_ERRSTR_L, "tsk_fs_attrlist_get: Null list pointer"); tsk_errstr2[0] = '\0'; return NULL; } for (fs_attr_cur = a_fs_attrlist->head; fs_attr_cur; fs_attr_cur = fs_attr_cur->next) { if ((fs_attr_cur->flags & TSK_FS_ATTR_INUSE) && (fs_attr_cur->type == a_type) && (!strncmp(fs_attr_cur->name, name, MIN(fs_attr_cur->name_size, strlen(name)))) ) { /* If we are looking for NTFS $Data, * then return default when we see it */ if ((fs_attr_cur->type == TSK_FS_ATTR_TYPE_NTFS_DATA) && (fs_attr_cur->name_size > 5) && (strncmp(fs_attr_cur->name, "$Data", 5) == 0)) { return fs_attr_cur; } // make sure we return the lowest if multiple exist if ((fs_attr_ok == NULL) || (fs_attr_ok->id > fs_attr_cur->id)) fs_attr_ok = fs_attr_cur; } } if (!fs_attr_ok) { tsk_errno = TSK_ERR_FS_ATTR_NOTFOUND; snprintf(tsk_errstr, TSK_ERRSTR_L, "tsk_fs_attrlist_get: Attribute %d not found", a_type); return NULL; } else { return fs_attr_ok; } } ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-25 11:01 Message: Jamie, did you create a tsk_fs_attrlist_get_name_type() function as well? It is being called from the new NTFS code, but it is not defined in TSK and I didn't see it in the patch. thanks. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-25 10:30 Message: Applied memory leak patches into fs_file.c: Sending fs/fs_file.c Transmitting file data . Committed revision 131. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-11-29 21:35:23
|
Bugs item #2905750, was opened at 2009-11-29 23:33 Message generated for change (Comment added) made by oncer82 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2905750&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: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: reading data from compressed file on NTFS Initial Comment: This issue is reprodusable when trying to read content of a compressed file on NTFS with using tsk_fs_file_read funstion. Bug is reproduced on an alive OS while trying to read content of a C:\WINDOWS\ie7\inetres.adm file. Function tsk_fs_file_read continues reading data even when an offset from where to read data is past file's boundary. Function continues returning data without any error. ---------------------------------------------------------------------- >Comment By: oncer oncer surname (oncer82) Date: 2009-11-29 23:35 Message: Windows XP, search pak 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2905750&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-11-29 21:33:01
|
Bugs item #2905750, was opened at 2009-11-29 23:33 Message generated for change (Tracker Item Submitted) made by oncer82 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2905750&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: oncer oncer surname (oncer82) Assigned to: Nobody/Anonymous (nobody) Summary: reading data from compressed file on NTFS Initial Comment: This issue is reprodusable when trying to read content of a compressed file on NTFS with using tsk_fs_file_read funstion. Bug is reproduced on an alive OS while trying to read content of a C:\WINDOWS\ie7\inetres.adm file. Function tsk_fs_file_read continues reading data even when an offset from where to read data is past file's boundary. Function continues returning data without any error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2905750&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-11-25 22:12:20
|
Feature Requests item #2895607, was opened at 2009-11-10 19:25 Message generated for change (Comment added) made by jamiebutler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&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: James Butler (jamiebutler) Assigned to: Nobody/Anonymous (nobody) Summary: Identify in NTFS the SID of the owner of a file Initial Comment: The owner SID of files needs to be identified per file. Every file has an associated security identifier which identifies the owner, groups, etc. of the file. More than one file may have the same security identifier if the files share the exact same security descriptor. Using the security identifier of the file (secid), we can lookup its security descriptor within $Secure. Security descriptors are variable length and contained in the $SDS stream within $Secure. The $SII stream of $Secure is an index into the $SDS stream. $SII entries are stored incrementally by the secid. Once we find the secid of the file inside the $SII stream, the $SII entry will tell the offset within the $SDS stream to read the security descriptor. Use the tsk_fs_file_read_owner_sid function within fs_file.c to get the string representation of the owner SID of a file on NTFS. When an NTFS filesystem is opened ntfs_open is called. ntfs_open initializes a pointer to ntfs_lookup_security_id and then calls ntfs_load_secure. ntfs_load_secure opens MFT entry 9, $Secure, and reads in the $SDS and $SII streams. When tsk_fs_file_read_owner_sid is called on a TSK_FS_FILE, the owner SID is returned in its string form. ---------------------------------------------------------------------- >Comment By: James Butler (jamiebutler) Date: 2009-11-25 17:12 Message: Sorry, here is that function. #define MIN(a, b) ((a) < (b) ? (a) : (b)) /** * \internal * Search the attribute list of TSK_FS_ATTR structures for an entry with a given * type (no ID) and a given name. If more than one entry with the same type exists, * the one with the lowest ID will be returned. * * @param a_fs_attrlist Data list structure to search in * @param a_type Type of attribute to find * @param name Name of the attribute to find * * @return NULL is returned on error and if an entry could not be found. * tsk_errno will be set to TSK_ERR_FS_ATTR_NOTFOUND if entry could not be found. */ const TSK_FS_ATTR * tsk_fs_attrlist_get_name_type(const TSK_FS_ATTRLIST * a_fs_attrlist, TSK_FS_ATTR_TYPE_ENUM a_type, char *name) { TSK_FS_ATTR *fs_attr_cur; TSK_FS_ATTR *fs_attr_ok = NULL; if ((!a_fs_attrlist) || (name == NULL)) { tsk_error_reset(); tsk_errno = TSK_ERR_FS_ARG; snprintf(tsk_errstr, TSK_ERRSTR_L, "tsk_fs_attrlist_get: Null list pointer"); tsk_errstr2[0] = '\0'; return NULL; } for (fs_attr_cur = a_fs_attrlist->head; fs_attr_cur; fs_attr_cur = fs_attr_cur->next) { if ((fs_attr_cur->flags & TSK_FS_ATTR_INUSE) && (fs_attr_cur->type == a_type) && (!strncmp(fs_attr_cur->name, name, MIN(fs_attr_cur->name_size, strlen(name)))) ) { /* If we are looking for NTFS $Data, * then return default when we see it */ if ((fs_attr_cur->type == TSK_FS_ATTR_TYPE_NTFS_DATA) && (fs_attr_cur->name_size > 5) && (strncmp(fs_attr_cur->name, "$Data", 5) == 0)) { return fs_attr_cur; } // make sure we return the lowest if multiple exist if ((fs_attr_ok == NULL) || (fs_attr_ok->id > fs_attr_cur->id)) fs_attr_ok = fs_attr_cur; } } if (!fs_attr_ok) { tsk_errno = TSK_ERR_FS_ATTR_NOTFOUND; snprintf(tsk_errstr, TSK_ERRSTR_L, "tsk_fs_attrlist_get: Attribute %d not found", a_type); return NULL; } else { return fs_attr_ok; } } ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-25 11:01 Message: Jamie, did you create a tsk_fs_attrlist_get_name_type() function as well? It is being called from the new NTFS code, but it is not defined in TSK and I didn't see it in the patch. thanks. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-25 10:30 Message: Applied memory leak patches into fs_file.c: Sending fs/fs_file.c Transmitting file data . Committed revision 131. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-11-25 16:01:36
|
Feature Requests item #2895607, was opened at 2009-11-10 19:25 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&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: James Butler (jamiebutler) Assigned to: Nobody/Anonymous (nobody) Summary: Identify in NTFS the SID of the owner of a file Initial Comment: The owner SID of files needs to be identified per file. Every file has an associated security identifier which identifies the owner, groups, etc. of the file. More than one file may have the same security identifier if the files share the exact same security descriptor. Using the security identifier of the file (secid), we can lookup its security descriptor within $Secure. Security descriptors are variable length and contained in the $SDS stream within $Secure. The $SII stream of $Secure is an index into the $SDS stream. $SII entries are stored incrementally by the secid. Once we find the secid of the file inside the $SII stream, the $SII entry will tell the offset within the $SDS stream to read the security descriptor. Use the tsk_fs_file_read_owner_sid function within fs_file.c to get the string representation of the owner SID of a file on NTFS. When an NTFS filesystem is opened ntfs_open is called. ntfs_open initializes a pointer to ntfs_lookup_security_id and then calls ntfs_load_secure. ntfs_load_secure opens MFT entry 9, $Secure, and reads in the $SDS and $SII streams. When tsk_fs_file_read_owner_sid is called on a TSK_FS_FILE, the owner SID is returned in its string form. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-25 11:01 Message: Jamie, did you create a tsk_fs_attrlist_get_name_type() function as well? It is being called from the new NTFS code, but it is not defined in TSK and I didn't see it in the patch. thanks. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-25 10:30 Message: Applied memory leak patches into fs_file.c: Sending fs/fs_file.c Transmitting file data . Committed revision 131. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-11-25 15:30:14
|
Feature Requests item #2895607, was opened at 2009-11-10 19:25 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&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: James Butler (jamiebutler) Assigned to: Nobody/Anonymous (nobody) Summary: Identify in NTFS the SID of the owner of a file Initial Comment: The owner SID of files needs to be identified per file. Every file has an associated security identifier which identifies the owner, groups, etc. of the file. More than one file may have the same security identifier if the files share the exact same security descriptor. Using the security identifier of the file (secid), we can lookup its security descriptor within $Secure. Security descriptors are variable length and contained in the $SDS stream within $Secure. The $SII stream of $Secure is an index into the $SDS stream. $SII entries are stored incrementally by the secid. Once we find the secid of the file inside the $SII stream, the $SII entry will tell the offset within the $SDS stream to read the security descriptor. Use the tsk_fs_file_read_owner_sid function within fs_file.c to get the string representation of the owner SID of a file on NTFS. When an NTFS filesystem is opened ntfs_open is called. ntfs_open initializes a pointer to ntfs_lookup_security_id and then calls ntfs_load_secure. ntfs_load_secure opens MFT entry 9, $Secure, and reads in the $SDS and $SII streams. When tsk_fs_file_read_owner_sid is called on a TSK_FS_FILE, the owner SID is returned in its string form. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-25 10:30 Message: Applied memory leak patches into fs_file.c: Sending fs/fs_file.c Transmitting file data . Committed revision 131. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2895607&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-11-25 14:37:10
|
Feature Requests item #2903757, was opened at 2009-11-25 09:37 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903757&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: HFS+ specific ffind code Initial Comment: HFS+, like NTFS already does, should have special code to map a metadata address to a name. The current code recurses the directories until it finds a file that maps to the metadata. We could develop code that looks up the thread for the metadata address, and goes up the parent directory links in the catalog file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903757&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-11-25 14:01:04
|
Feature Requests item #2903408, was opened at 2009-11-24 17:46 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903408&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: ffind -d option Initial Comment: Make an ffind -d option that allows you to specify the block and it finds the metadata address and then the name. This merges 'ifind -d' into ffind. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-25 09:01 Message: Requires request 2206344 to be resolved first, which makes ifind more library friendly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903408&group_id=55685 |
From: SourceForge.net <no...@so...> - 2009-11-25 13:56:10
|
Feature Requests item #2903736, was opened at 2009-11-25 08:55 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903736&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: Deleted Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: ffind -d option Initial Comment: Make an ffind -d option that allows you to specify the block and it finds the metadata address and then the name. This merges 'ifind -d' into ffind. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2009-11-25 08:56 Message: Created by accident. Duplicate of existing request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2903736&group_id=55685 |