sleuthkit-developers Mailing List for The Sleuth Kit (Page 11)
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(22) |
Feb
(39) |
Mar
(8) |
Apr
(17) |
May
(10) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(4) |
| 2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(9) |
Jul
(14) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
| 2009 |
Jan
(7) |
Feb
(10) |
Mar
(10) |
Apr
(19) |
May
(16) |
Jun
(3) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(16) |
Nov
(35) |
Dec
(30) |
| 2010 |
Jan
(4) |
Feb
(24) |
Mar
(25) |
Apr
(31) |
May
(11) |
Jun
(9) |
Jul
(11) |
Aug
(31) |
Sep
(11) |
Oct
(10) |
Nov
(15) |
Dec
(3) |
| 2011 |
Jan
(8) |
Feb
(17) |
Mar
(14) |
Apr
(2) |
May
(4) |
Jun
(4) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(8) |
Nov
(16) |
Dec
(1) |
| 2012 |
Jan
(9) |
Feb
(2) |
Mar
(3) |
Apr
(13) |
May
(10) |
Jun
(7) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(3) |
| 2013 |
Jan
(16) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(18) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
| 2015 |
Jan
(5) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(23) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: SourceForge.net <no...@so...> - 2012-12-15 05:26:57
|
Bugs item #3596212, was opened at 2012-12-14 21:26 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3596212&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: configure.ac looks for wrong libewf function Initial Comment: in configure.ac please change libewf_open to libewf_get_version. libewf_open is v1 API, libewf_handle_open is v2, libewf_get_version should be in both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3596212&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-12-12 12:17:26
|
Bugs item #3523019, was opened at 2012-05-02 06:36 Message generated for change (Comment added) made by timowpre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&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: More checks on FAT "." entries Initial Comment: Currently, TSK does special things with any "." entry it finds in the directory. We should limit this to only the first couple of entires in the directory. Otherwise, someone could manually change the name of a file to be "." and its content would not be accessible. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-12-12 04:17 Message: From aca201cb4a937709c055350101cdd36b01ce4b5b Mon Sep 17 00:00:00 2001 From: Timo Warns <wa...@pr...> Date: Wed, 12 Dec 2012 11:52:19 +0100 Subject: [PATCH] limit special handling of files named "." and ".." A file named "." or ".." shall only be specially handled if it is a directory and is among the first two directory entries. Otherwise, renaming a file to "." or ".." could hide the file from TSK. Fixes CVE-2012-5619. --- tsk3/fs/fatfs_dent.cpp | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/tsk3/fs/fatfs_dent.cpp b/tsk3/fs/fatfs_dent.cpp index b76b9e3..aa0a4e2 100644 --- a/tsk3/fs/fatfs_dent.cpp +++ b/tsk3/fs/fatfs_dent.cpp @@ -439,7 +439,9 @@ static TSK_RETVAL_ENUM * slot in the cluster, but it needs to refer to the original * slot */ - if (TSK_FS_ISDOT(fs_name->name)) { + if (TSK_FS_ISDOT(fs_name->name) + && (fs_name->type == TSK_FS_NAME_TYPE_DIR) + && idx < 2) { if (fs_name->name[1] == '\0') { fs_name->meta_addr = a_fs_dir->fs_file->meta->addr; -- 1.7.2.5 ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-12-12 04:16 Message: The attached patch seems to fix the issue. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-11-26 06:28 Message: Here is a reproducer: ### create an empty image $ dd if=/dev/zero of=empty.img bs=1M count=50 $ mkfs.vfat -F32 empty.img ### create an image with FILE.txt $ cp empty.img file.img $ mount -o loop file.img /mnt/image/ $ echo "HELLO" > /mnt/image/FILE.TXT $ umount /mnt/image/ ### create an image with "." file (renamed from FILE.TXT) $ xxd -p file.img | sed -e 's/46494c4520202020545854/2e20202020202020202020/' | xxd -r -p > dot.img ### use TSK $ fls -V The Sleuth Kit ver 4.0.1 $ fls -a empty.img v/v 1612675: $MBR v/v 1612676: $FAT1 v/v 1612677: $FAT2 d/d 1612678: $OrphanFiles $ fls -a file.img r/r 3: FILE.TXT v/v 1612675: $MBR v/v 1612676: $FAT1 v/v 1612677: $FAT2 d/d 1612678: $OrphanFiles $ fls -a dot.img r/d 2: . v/v 1612675: $MBR v/v 1612676: $FAT1 v/v 1612677: $FAT2 d/d 1612678: $OrphanFiles ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-11-26 06:22 Message: Interesting. That side effect could also be because of the de-duping code in TSK. It's strange in that report that entry 2 came up as r/d meaning that it thought it was a file at the name level, but then mapped it to the directory at the meta data level. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-11-26 01:15 Message: Note that this bug affects analyses of USB sticks that came in contact with the Flame malware. On FAT file systems, Flame creates a file with short name "HUB001.DAT" and long name "." in the root directory (see http://labs.bitdefender.com/2012/06/flame-the-story-of-leaked-data-carried-by-human-vector/). TSK does not appropriately show such files (e.g., see http://blog.crysys.hu/2012/06/flame-usb-dot-file-confirmed/). If Flame writes its file to an empty USB stick, the file is the very first entry of the root directory. Hence, a limitation of the "special things" to the first couple of entries is not sufficient in this case. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-05-02 06:37 Message: Reported by Ilias Van Peer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-12-12 12:16:43
|
Bugs item #3523019, was opened at 2012-05-02 06:36 Message generated for change (Comment added) made by timowpre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&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: More checks on FAT "." entries Initial Comment: Currently, TSK does special things with any "." entry it finds in the directory. We should limit this to only the first couple of entires in the directory. Otherwise, someone could manually change the name of a file to be "." and its content would not be accessible. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-12-12 04:16 Message: The attached patch seems to fix the issue. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-11-26 06:28 Message: Here is a reproducer: ### create an empty image $ dd if=/dev/zero of=empty.img bs=1M count=50 $ mkfs.vfat -F32 empty.img ### create an image with FILE.txt $ cp empty.img file.img $ mount -o loop file.img /mnt/image/ $ echo "HELLO" > /mnt/image/FILE.TXT $ umount /mnt/image/ ### create an image with "." file (renamed from FILE.TXT) $ xxd -p file.img | sed -e 's/46494c4520202020545854/2e20202020202020202020/' | xxd -r -p > dot.img ### use TSK $ fls -V The Sleuth Kit ver 4.0.1 $ fls -a empty.img v/v 1612675: $MBR v/v 1612676: $FAT1 v/v 1612677: $FAT2 d/d 1612678: $OrphanFiles $ fls -a file.img r/r 3: FILE.TXT v/v 1612675: $MBR v/v 1612676: $FAT1 v/v 1612677: $FAT2 d/d 1612678: $OrphanFiles $ fls -a dot.img r/d 2: . v/v 1612675: $MBR v/v 1612676: $FAT1 v/v 1612677: $FAT2 d/d 1612678: $OrphanFiles ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-11-26 06:22 Message: Interesting. That side effect could also be because of the de-duping code in TSK. It's strange in that report that entry 2 came up as r/d meaning that it thought it was a file at the name level, but then mapped it to the directory at the meta data level. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-11-26 01:15 Message: Note that this bug affects analyses of USB sticks that came in contact with the Flame malware. On FAT file systems, Flame creates a file with short name "HUB001.DAT" and long name "." in the root directory (see http://labs.bitdefender.com/2012/06/flame-the-story-of-leaked-data-carried-by-human-vector/). TSK does not appropriately show such files (e.g., see http://blog.crysys.hu/2012/06/flame-usb-dot-file-confirmed/). If Flame writes its file to an empty USB stick, the file is the very first entry of the root directory. Hence, a limitation of the "special things" to the first couple of entries is not sufficient in this case. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-05-02 06:37 Message: Reported by Ilias Van Peer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-26 14:28:41
|
Bugs item #3523019, was opened at 2012-05-02 06:36 Message generated for change (Comment added) made by timowpre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&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: More checks on FAT "." entries Initial Comment: Currently, TSK does special things with any "." entry it finds in the directory. We should limit this to only the first couple of entires in the directory. Otherwise, someone could manually change the name of a file to be "." and its content would not be accessible. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-11-26 06:28 Message: Here is a reproducer: ### create an empty image $ dd if=/dev/zero of=empty.img bs=1M count=50 $ mkfs.vfat -F32 empty.img ### create an image with FILE.txt $ cp empty.img file.img $ mount -o loop file.img /mnt/image/ $ echo "HELLO" > /mnt/image/FILE.TXT $ umount /mnt/image/ ### create an image with "." file (renamed from FILE.TXT) $ xxd -p file.img | sed -e 's/46494c4520202020545854/2e20202020202020202020/' | xxd -r -p > dot.img ### use TSK $ fls -V The Sleuth Kit ver 4.0.1 $ fls -a empty.img v/v 1612675: $MBR v/v 1612676: $FAT1 v/v 1612677: $FAT2 d/d 1612678: $OrphanFiles $ fls -a file.img r/r 3: FILE.TXT v/v 1612675: $MBR v/v 1612676: $FAT1 v/v 1612677: $FAT2 d/d 1612678: $OrphanFiles $ fls -a dot.img r/d 2: . v/v 1612675: $MBR v/v 1612676: $FAT1 v/v 1612677: $FAT2 d/d 1612678: $OrphanFiles ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-11-26 06:22 Message: Interesting. That side effect could also be because of the de-duping code in TSK. It's strange in that report that entry 2 came up as r/d meaning that it thought it was a file at the name level, but then mapped it to the directory at the meta data level. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-11-26 01:15 Message: Note that this bug affects analyses of USB sticks that came in contact with the Flame malware. On FAT file systems, Flame creates a file with short name "HUB001.DAT" and long name "." in the root directory (see http://labs.bitdefender.com/2012/06/flame-the-story-of-leaked-data-carried-by-human-vector/). TSK does not appropriately show such files (e.g., see http://blog.crysys.hu/2012/06/flame-usb-dot-file-confirmed/). If Flame writes its file to an empty USB stick, the file is the very first entry of the root directory. Hence, a limitation of the "special things" to the first couple of entries is not sufficient in this case. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-05-02 06:37 Message: Reported by Ilias Van Peer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-26 14:22:35
|
Bugs item #3523019, was opened at 2012-05-02 06:36 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&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: More checks on FAT "." entries Initial Comment: Currently, TSK does special things with any "." entry it finds in the directory. We should limit this to only the first couple of entires in the directory. Otherwise, someone could manually change the name of a file to be "." and its content would not be accessible. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2012-11-26 06:22 Message: Interesting. That side effect could also be because of the de-duping code in TSK. It's strange in that report that entry 2 came up as r/d meaning that it thought it was a file at the name level, but then mapped it to the directory at the meta data level. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-11-26 01:15 Message: Note that this bug affects analyses of USB sticks that came in contact with the Flame malware. On FAT file systems, Flame creates a file with short name "HUB001.DAT" and long name "." in the root directory (see http://labs.bitdefender.com/2012/06/flame-the-story-of-leaked-data-carried-by-human-vector/). TSK does not appropriately show such files (e.g., see http://blog.crysys.hu/2012/06/flame-usb-dot-file-confirmed/). If Flame writes its file to an empty USB stick, the file is the very first entry of the root directory. Hence, a limitation of the "special things" to the first couple of entries is not sufficient in this case. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-05-02 06:37 Message: Reported by Ilias Van Peer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-26 09:15:26
|
Bugs item #3523019, was opened at 2012-05-02 06:36 Message generated for change (Comment added) made by timowpre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&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: More checks on FAT "." entries Initial Comment: Currently, TSK does special things with any "." entry it finds in the directory. We should limit this to only the first couple of entires in the directory. Otherwise, someone could manually change the name of a file to be "." and its content would not be accessible. ---------------------------------------------------------------------- Comment By: Timo Warns (timowpre) Date: 2012-11-26 01:15 Message: Note that this bug affects analyses of USB sticks that came in contact with the Flame malware. On FAT file systems, Flame creates a file with short name "HUB001.DAT" and long name "." in the root directory (see http://labs.bitdefender.com/2012/06/flame-the-story-of-leaked-data-carried-by-human-vector/). TSK does not appropriately show such files (e.g., see http://blog.crysys.hu/2012/06/flame-usb-dot-file-confirmed/). If Flame writes its file to an empty USB stick, the file is the very first entry of the root directory. Hence, a limitation of the "special things" to the first couple of entries is not sufficient in this case. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-05-02 06:37 Message: Reported by Ilias Van Peer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&group_id=55685 |
|
From: Jon S. <jo...@li...> - 2012-11-15 20:53:44
|
Ah... it looks like git-clean won't remove files in .gitignore, unless you tell it otherwise. Jon On Thu, Nov 15, 2012 at 3:51 PM, Brian Carrier <ca...@sl...> wrote: > ntfs_dent (and fatfs_dent) were renamed from a .c to .cpp so that they can internally use some C++ maps to better manage data than what I was using before. I've found that you need to remove the '.deps' folder in tsk3/fs afer a git pull. Something like: > > # rm -rf tsk3/fs/.deps > # ./configure > # make > > > On Nov 15, 2012, at 3:35 PM, Jon Stewart <jo...@li...> wrote: > >> Interestingly, I have no problem building the released tarball of >> 4.0.1. Am I missing something obvious when building from the git repo? >> >> >> Jon >> >> On Tue, Nov 13, 2012 at 6:46 PM, Jon Stewart >> <jo...@li...> wrote: >>> I'm getting this build error on 4.0.1 (and on HEAD): >>> >>> make[3]: *** No rule to make target `fatfs_dent.c', needed by >>> `fatfs_dent.lo'. Stop. >>> >>> >>> This is on up-to-date Fedora 17, gcc 4.7.2. Looks like it was on >>> tsk3/fs/Makefile, which is attached. >>> >>> >>> Jon >>> -- >>> Jon Stewart, Principal >>> (646) 719-0317 | jo...@li... | Arlington, VA >> >> >> >> -- >> Jon Stewart, Principal >> (646) 719-0317 | jo...@li... | Arlington, VA >> >> ------------------------------------------------------------------------------ >> Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> sleuthkit-developers mailing list >> sle...@li... >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers > -- Jon Stewart, Principal (646) 719-0317 | jo...@li... | Arlington, VA |
|
From: Brian C. <ca...@sl...> - 2012-11-15 20:51:52
|
ntfs_dent (and fatfs_dent) were renamed from a .c to .cpp so that they can internally use some C++ maps to better manage data than what I was using before. I've found that you need to remove the '.deps' folder in tsk3/fs afer a git pull. Something like: # rm -rf tsk3/fs/.deps # ./configure # make On Nov 15, 2012, at 3:35 PM, Jon Stewart <jo...@li...> wrote: > Interestingly, I have no problem building the released tarball of > 4.0.1. Am I missing something obvious when building from the git repo? > > > Jon > > On Tue, Nov 13, 2012 at 6:46 PM, Jon Stewart > <jo...@li...> wrote: >> I'm getting this build error on 4.0.1 (and on HEAD): >> >> make[3]: *** No rule to make target `fatfs_dent.c', needed by >> `fatfs_dent.lo'. Stop. >> >> >> This is on up-to-date Fedora 17, gcc 4.7.2. Looks like it was on >> tsk3/fs/Makefile, which is attached. >> >> >> Jon >> -- >> Jon Stewart, Principal >> (646) 719-0317 | jo...@li... | Arlington, VA > > > > -- > Jon Stewart, Principal > (646) 719-0317 | jo...@li... | Arlington, VA > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
|
From: Jon S. <jo...@li...> - 2012-11-15 20:35:18
|
Interestingly, I have no problem building the released tarball of 4.0.1. Am I missing something obvious when building from the git repo? Jon On Tue, Nov 13, 2012 at 6:46 PM, Jon Stewart <jo...@li...> wrote: > I'm getting this build error on 4.0.1 (and on HEAD): > > make[3]: *** No rule to make target `fatfs_dent.c', needed by > `fatfs_dent.lo'. Stop. > > > This is on up-to-date Fedora 17, gcc 4.7.2. Looks like it was on > tsk3/fs/Makefile, which is attached. > > > Jon > -- > Jon Stewart, Principal > (646) 719-0317 | jo...@li... | Arlington, VA -- Jon Stewart, Principal (646) 719-0317 | jo...@li... | Arlington, VA |
|
From: SourceForge.net <no...@so...> - 2012-11-12 21:53:45
|
Bugs item #3584744, was opened at 2012-11-06 05:16 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584744&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk_init_lock and tsk_deinit_lock not exported Initial Comment: Issue concerning TSK 4.0.0 API The functions tsk_init_lock and tsk_deinit_lock are not exported in tsk3.h but they are necessary when creating a custom Img info object as in pytsk. Please add them or add other functions to set/release the locks for custom img info objects. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2012-11-12 13:53 Message: The main problem for pytsk is that we need to be managing our own memory (so we can arrange for freeing off the python GC). TSK confounds the allocation of the memory with the initialization of the memory by putting both into the function tsk_img_malloc()/tsk_img_free() so we effectively need to reimplement the initialization done in tsk_img_malloc() again (This is ultimately why we need access to the lock initialization functions). At the moment this initialization just includes initializing locks but we will always need to duplicate this code in future which is inconvenient. The proper solution to the problem is to separate tsk_img_malloc() into an allocation function and an initialization function, or alternatively have tsk able to take a user supplied allocator implementation (for example like libjpeg, zlib and many other libraries do). The typical use case for pytsk is something like: typedef struct { TSK_IMG_INFO base; struct Img_Info_t *container; } Extended_TSK_IMG_INFO; e.g. we extend the basic TSK object with our object which contains more information specific to python implementation. Hence we need to allocate a bit more memory than sizeof(TSK_IMG_INFO) and then we need to get tsk to initialize its part of the struct. Then we initialize our part. ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2012-11-12 10:35 Message: The idea of pytsk is to wrap python calls in an IMG info object, and allow to extend the object in python. Therefore it needs to control the locks. For now I've just added the function calls. And build pytsk statically. This does not allow me to build against a DLL version. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:30 Message: Hi Joachim, The theory was that if you are extending TSK, you would use tsk_base_i.h. tsk_base.h is really just if you want to use the library from another program. Does that work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584744&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-12 19:38:49
|
Bugs item #3553704, was opened at 2012-08-02 10:52 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3553704&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan (jlam03) Assigned to: Nobody/Anonymous (nobody) >Summary: Error when compiling TSK 3.2.2 Initial Comment: Attempting to compile Sleuthkit 3.2.2 win32 on Windows 7, Visual Studion 2010, and came across these errors. (BTW, I posted to the Requested Feature by mistake, so repost it here. My apology). Any help would be great as this is for my final project in Digita Forensics class. C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "copy "c:\Digital_Forensics\Project\libewf-20120603msvscpp\release\libewf.dll" "C:\Digital_Forensics\Project\sleuthkit-sleuthkit-9b83edc\win32\Debug\" C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: IF EXIST "c:\Digital_Forensics\Project\libewf-20120603\msvscpp\zlib-1.2.6" ( C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: xcopy "c:\Digital_Forensics\Project\libewf-20120603\msvscpp\Release\zlib.dll" "C:\Digital_Forensics\Project\sleuthkit-sleuthkit-9b83edc\win32\Debug\" /R /Y C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: ) ELSE ( C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: xcopy "c:\Digital_Forensics\Project\libewf-20120603\msvscpp\zlib\zlib1.dll" "C:\Digital_Forensics\Project\sleuthkit-sleuthkit-9b83edc\win32\Debug\" /R /Y C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: ) C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 4. Build FAILED. Time Elapsed 00:00:29.59 ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:45 Message: TSK 4 build targets all have an explicit slash in them to solve this problem. Does it work OK with v4? ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:39 Message: Looks like a bug with a slash missing between libewf-20120603 and msvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3553704&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-12 18:45:34
|
Bugs item #3553704, was opened at 2012-08-02 10:52 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3553704&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan (jlam03) Assigned to: Nobody/Anonymous (nobody) Summary: Error when compiling SKT 3.2.2 Initial Comment: Attempting to compile Sleuthkit 3.2.2 win32 on Windows 7, Visual Studion 2010, and came across these errors. (BTW, I posted to the Requested Feature by mistake, so repost it here. My apology). Any help would be great as this is for my final project in Digita Forensics class. C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "copy "c:\Digital_Forensics\Project\libewf-20120603msvscpp\release\libewf.dll" "C:\Digital_Forensics\Project\sleuthkit-sleuthkit-9b83edc\win32\Debug\" C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: IF EXIST "c:\Digital_Forensics\Project\libewf-20120603\msvscpp\zlib-1.2.6" ( C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: xcopy "c:\Digital_Forensics\Project\libewf-20120603\msvscpp\Release\zlib.dll" "C:\Digital_Forensics\Project\sleuthkit-sleuthkit-9b83edc\win32\Debug\" /R /Y C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: ) ELSE ( C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: xcopy "c:\Digital_Forensics\Project\libewf-20120603\msvscpp\zlib\zlib1.dll" "C:\Digital_Forensics\Project\sleuthkit-sleuthkit-9b83edc\win32\Debug\" /R /Y C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: ) C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 4. Build FAILED. Time Elapsed 00:00:29.59 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:45 Message: TSK 4 build targets all have an explicit slash in them to solve this problem. Does it work OK with v4? ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:39 Message: Looks like a bug with a slash missing between libewf-20120603 and msvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3553704&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-12 18:39:45
|
Bugs item #3553704, was opened at 2012-08-02 10:52 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3553704&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan (jlam03) Assigned to: Nobody/Anonymous (nobody) Summary: Error when compiling SKT 3.2.2 Initial Comment: Attempting to compile Sleuthkit 3.2.2 win32 on Windows 7, Visual Studion 2010, and came across these errors. (BTW, I posted to the Requested Feature by mistake, so repost it here. My apology). Any help would be great as this is for my final project in Digita Forensics class. C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "copy "c:\Digital_Forensics\Project\libewf-20120603msvscpp\release\libewf.dll" "C:\Digital_Forensics\Project\sleuthkit-sleuthkit-9b83edc\win32\Debug\" C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: IF EXIST "c:\Digital_Forensics\Project\libewf-20120603\msvscpp\zlib-1.2.6" ( C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: xcopy "c:\Digital_Forensics\Project\libewf-20120603\msvscpp\Release\zlib.dll" "C:\Digital_Forensics\Project\sleuthkit-sleuthkit-9b83edc\win32\Debug\" /R /Y C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: ) ELSE ( C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: xcopy "c:\Digital_Forensics\Project\libewf-20120603\msvscpp\zlib\zlib1.dll" "C:\Digital_Forensics\Project\sleuthkit-sleuthkit-9b83edc\win32\Debug\" /R /Y C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: ) C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 4. Build FAILED. Time Elapsed 00:00:29.59 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:39 Message: Looks like a bug with a slash missing between libewf-20120603 and msvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3553704&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-12 18:37:15
|
Bugs item #3554592, was opened at 2012-08-05 12:00 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3554592&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: 3 Private: No Submitted By: Jonathan (jlam03) Assigned to: Nobody/Anonymous (nobody) Summary: Error compiling TSK framework Initial Comment: I am compiling the STK framework in Windows, using the solution file in framework/win32/framework/, as well as the FileTypeSig module. I encounter the following errors: > > 1. LINK: Fatal error LNK1104- cannot open file 'libtskframework.lib'. I search the directory and can not find this file. > 2. I set TSK_HOME as well as POCO_HOME in my environment. > 3. warning: class 'std::....." needs to have dll-interface to be used by clients of class TskModule. > > I am stuck. I rebuild the sleuthkit, times and times as well as all the requiered POCO modules, and the framework. Any help would be greately appreciated. Don't know how to get the libtskframework.lib Thank you ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:37 Message: libtskframework.lib is one of the projects in the solution. Did that compile without error? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3554592&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-12 18:35:52
|
Bugs item #3584744, was opened at 2012-11-06 05:16 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584744&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk_init_lock and tsk_deinit_lock not exported Initial Comment: Issue concerning TSK 4.0.0 API The functions tsk_init_lock and tsk_deinit_lock are not exported in tsk3.h but they are necessary when creating a custom Img info object as in pytsk. Please add them or add other functions to set/release the locks for custom img info objects. ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2012-11-12 10:35 Message: The idea of pytsk is to wrap python calls in an IMG info object, and allow to extend the object in python. Therefore it needs to control the locks. For now I've just added the function calls. And build pytsk statically. This does not allow me to build against a DLL version. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:30 Message: Hi Joachim, The theory was that if you are extending TSK, you would use tsk_base_i.h. tsk_base.h is really just if you want to use the library from another program. Does that work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584744&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-12 18:30:59
|
Bugs item #3584744, was opened at 2012-11-06 05:16 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584744&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk_init_lock and tsk_deinit_lock not exported Initial Comment: Issue concerning TSK 4.0.0 API The functions tsk_init_lock and tsk_deinit_lock are not exported in tsk3.h but they are necessary when creating a custom Img info object as in pytsk. Please add them or add other functions to set/release the locks for custom img info objects. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:30 Message: Hi Joachim, The theory was that if you are extending TSK, you would use tsk_base_i.h. tsk_base.h is really just if you want to use the library from another program. Does that work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584744&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-12 18:29:19
|
Bugs item #3585242, was opened at 2012-11-07 13:08 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3585242&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk3/base/tsk_os.h unprotected ssize_t Initial Comment: The WIN32 ssize_t definition in tsk3/base/tsk_os.h is not safe guarded this will conflict when e.g. Python.h is included see proposed patch. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2012-11-12 10:29 Message: Checked into: [master ea07b45] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3585242&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-07 21:08:33
|
Bugs item #3585242, was opened at 2012-11-07 13:08 Message generated for change (Settings changed) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3585242&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk3/base/tsk_os.h unprotected ssize_t Initial Comment: The WIN32 ssize_t definition in tsk3/base/tsk_os.h is not safe guarded this will conflict when e.g. Python.h is included see proposed patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3585242&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-07 21:08:08
|
Bugs item #3585242, was opened at 2012-11-07 13:08 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3585242&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk3/base/tsk_os.h unprotected ssize_t Initial Comment: The WIN32 ssize_t definition in tsk3/base/tsk_os.h is not safe guarded this will conflict when e.g. Python.h is included see proposed patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3585242&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 13:23:42
|
Bugs item #3584745, was opened at 2012-11-06 05:21 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584745&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: TSK_VERSION_STR still indicates beta Initial Comment: The TSK_VERSION_STR in tsk_base.h still contains 4.0.0b1 ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2012-11-06 05:23 Message: My bad, looking at the wrong version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584745&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 13:21:06
|
Bugs item #3584745, was opened at 2012-11-06 05:21 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584745&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: TSK_VERSION_STR still indicates beta Initial Comment: The TSK_VERSION_STR in tsk_base.h still contains 4.0.0b1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584745&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-11-06 13:16:57
|
Bugs item #3584744, was opened at 2012-11-06 05:16 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584744&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: tsk_init_lock and tsk_deinit_lock not exported Initial Comment: Issue concerning TSK 4.0.0 API The functions tsk_init_lock and tsk_deinit_lock are not exported in tsk3.h but they are necessary when creating a custom Img info object as in pytsk. Please add them or add other functions to set/release the locks for custom img info objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3584744&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2012-10-17 13:37:25
|
Feature Requests item #3577797, was opened at 2012-10-17 01:46 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=3577797&group_id=55687 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Analysis Techniques Group: None Status: Open Priority: 5 Private: No Submitted By: Ivar F () Assigned to: Nobody/Anonymous (nobody) Summary: Select and bookmark several images Initial Comment: I miss the opportunity to select and bookmark several pictures ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2012-10-17 06:37 Message: I've moved this to the github tracker, which is what we are using for Autopsy 3 issues: https://github.com/sleuthkit/autopsy/issues/77 ---------------------------------------------------------------------- Comment By: Ivar F () Date: 2012-10-17 01:55 Message: One of our main uses of other forensic tools, such as EnCase, is to select pictures from a forensic image and bookmark these and make reports. It would be very nice if Autopsy 3.0 could implement such a feature; so that we could select and bookmark several pictures/files at once and have them printed on an automatic report. One could, for example, select pictures using the space-bar, og select several pictures using ctrl+click. And if one could then include only the bookmarked pictures in a report, that would be great. I think this is a feature that could be of use to many others as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=3577797&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2012-10-17 08:55:38
|
Feature Requests item #3577797, was opened at 2012-10-17 01:46 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=3577797&group_id=55687 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Analysis Techniques Group: None Status: Open Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Select and bookmark several images Initial Comment: I miss the opportunity to select and bookmark several pictures ---------------------------------------------------------------------- >Comment By: https://www.google.com/accounts () Date: 2012-10-17 01:55 Message: One of our main uses of other forensic tools, such as EnCase, is to select pictures from a forensic image and bookmark these and make reports. It would be very nice if Autopsy 3.0 could implement such a feature; so that we could select and bookmark several pictures/files at once and have them printed on an automatic report. One could, for example, select pictures using the space-bar, og select several pictures using ctrl+click. And if one could then include only the bookmarked pictures in a report, that would be great. I think this is a feature that could be of use to many others as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=3577797&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2012-10-17 08:46:11
|
Feature Requests item #3577797, was opened at 2012-10-17 01:46 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=3577797&group_id=55687 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Analysis Techniques Group: None Status: Open Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Select and bookmark several images Initial Comment: I miss the opportunity to select and bookmark several pictures ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=3577797&group_id=55687 |
1 message has been excluded from this view by a project administrator.
