sleuthkit-developers Mailing List for The Sleuth Kit (Page 17)
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(22) |
Feb
(39) |
Mar
(8) |
Apr
(17) |
May
(10) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(4) |
| 2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(9) |
Jul
(14) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
| 2009 |
Jan
(7) |
Feb
(10) |
Mar
(10) |
Apr
(19) |
May
(16) |
Jun
(3) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(16) |
Nov
(35) |
Dec
(30) |
| 2010 |
Jan
(4) |
Feb
(24) |
Mar
(25) |
Apr
(31) |
May
(11) |
Jun
(9) |
Jul
(11) |
Aug
(31) |
Sep
(11) |
Oct
(10) |
Nov
(15) |
Dec
(3) |
| 2011 |
Jan
(8) |
Feb
(17) |
Mar
(14) |
Apr
(2) |
May
(4) |
Jun
(4) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(8) |
Nov
(16) |
Dec
(1) |
| 2012 |
Jan
(9) |
Feb
(2) |
Mar
(3) |
Apr
(13) |
May
(10) |
Jun
(7) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(3) |
| 2013 |
Jan
(16) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(18) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
| 2015 |
Jan
(5) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(23) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: SourceForge.net <no...@so...> - 2011-03-04 15:25:28
|
Feature Requests item #3197980, was opened at 2011-03-03 01:38 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3197980&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Image Layer Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Specify only first image in split Initial Comment: The user should be able to specify only the first image in a split image or E01 set and TSK will test for the follow in files. ---------------------------------------------------------------------- Comment By: Joachim Metz (jbmetz) Date: 2011-03-04 16:25 Message: Brian, know that libewf v2 comes with a glob functions for this, which can be implemented in the img layer. Regarding split RAW you might want to take a look at libsmraw (libsmio project on SF), which also has a glob function for several split RAW naming schemes, which can be extended if necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3197980&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-03-03 00:38:32
|
Feature Requests item #3197980, was opened at 2011-03-02 19:38 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3197980&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Image Layer Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Specify only first image in split Initial Comment: The user should be able to specify only the first image in a split image or E01 set and TSK will test for the follow in files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3197980&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-28 02:48:56
|
Bugs item #3191391, was opened at 2011-02-24 11:23 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3191391&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 Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: encode mactime csv output Initial Comment: The mactime csv output can contain commas in the file name, which can screw up the importing process. We should either change the delimiter or surround the file names in quotes. Reported by Dan Mares. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-02-27 21:48 Message: Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/tools/timeline/mactime.base Sending trunk/NEWS.txt Sending trunk/tools/timeline/mactime.base Transmitting file data .... Committed revision 319. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3191391&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-25 17:13:02
|
Feature Requests item #3192458, was opened at 2011-02-25 09:13 Message generated for change (Tracker Item Submitted) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3192458&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: Auto Group: None Status: Open Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: Add unallocated block list to TSK db Initial Comment: The database feature of TSK 3.2.0 is a great enhancement to TSK allowing for major speed enhancements by following a "parse the image once but read results many times model." The table can be read directly and simple tools/scripts can be crafted to read the table rather than the image itself. However, the tsk_fs_blocks table only maps allocated blocks. The mapping of unallocated blocks would allow tools to make quick calculations of any byte offset in the image, enhancing TSK over the current slower blkcalc tool. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3192458&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-24 16:23:04
|
Bugs item #3191391, was opened at 2011-02-24 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=3191391&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 Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: encode mactime csv output Initial Comment: The mactime csv output can contain commas in the file name, which can screw up the importing process. We should either change the delimiter or surround the file names in quotes. Reported by Dan Mares. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3191391&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-24 14:56:03
|
Bugs item #3191323, was opened at 2011-02-24 15:56 Message generated for change (Tracker Item Submitted) made by ghede You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3191323&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob J Meijer (ghede) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple build problems on Suse Initial Comment: In order to build the 3.2.0 release the following additional actions were needed: sleuthkit-3.2.0/tsk3/auto/sqlite3.c had to be patched by adding the following two lines: #include <dlfcn.h> #include <pthread.h> Next to this, the line: pthread_mutexattr_settype(&recursiveAttr, PTHREAD_MUTEX_RECURSIVE); did not compile, changing it to pthread_mutexattr_settype(&recursiveAttr, PTHREAD_MUTEX_RECURSIVE_NP); Fixed this, but not sure if that is the right thing to do. After fixing the above, linking failed. Managed to complete the build process using the following commands: cd tools/autotools/ g++ -g -O2 -o tsk_loaddb tsk_loaddb.o -L/usr/local/lib ../../tsk3/.libs/libtsk3.a /usr/lib/gcc/i586-suse-linux/4.1.2/libstdc++.so -lm -lc -lgcc_s /usr/local/lib/libewf.so -lz -Wl,-rpath -Wl,/usr/lib/gcc/i586-suse-linux/4.1.2 -Wl,-rpath -Wl,/usr/lib/gcc/i586-suse-linux/4.1.2 -lpthread -ldl cd ../.. make The g++ command above was the one executed by make , but than with '-lpthread -ldl ' added to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3191323&group_id=55685 |
|
From: James L. <Jam...@de...> - 2011-02-18 16:06:41
|
Hi, Can anyone sanity check / confirm these potential memory leaks, I've been working from 3.1 source code but believe these are still relevant in the latest 3.2 nightly: I've been building code using VS2010 on windows and gcc on Unix. tsk/fs/ifind_lib.c - Line numbers reference sleuthkit-3.2-2011.2.18 nightly src Function: tsk_fs_path2inum Line 364: Should fs_file_alloc and fs_file_del be closed before the return 0 on line 364. (if they have been allocated). i.e. lines 377 -> line 384 should be repeated before the return 0; tsk/fs/ntfs_dent.c - Line numbers reference sleuthkit-3.2-2011.2.18 nightly src Function: ntfs_dir_open_meta Line 1093: fs_file_orp doesn't seem to be closed at any point. Thanks, Please consider the environment before printing this email. This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Limited group of companies. Detica Limited is registered in England under No: 1337451. Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England. |
|
From: SourceForge.net <no...@so...> - 2011-02-17 04:23:37
|
Feature Requests item #3184455, was opened at 2011-02-16 23:21 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184455&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: builddir != srcdir support Initial Comment: Hi, sleuthkit 3.2.0 requires to run ./configure in source directory. If /path/sleuthkit-VERSION/configure is run from a separate build directory the make command fails due to missing files. Packaging support tools often use a separate build directory by default. The attached patch fixes this. The include path are all set relative to current $(builddir) and the corresponding $(srcdir): AM_CPPFLAGS=-I../.. -I$(srcdir)/../.. An alternative would be to use: AM_CPPFLAGS=-I$(top_builddir) -I$(top_srcdir) The patch also adds tsk3/tsk_incs.h to the "clean" target. Otherwise "make distcleancheck" and "make distcheck" fail. Thanks, Christian (Christian Franke to sleuthkit-users) ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-02-16 23:23 Message: Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/samples/Makefile.am Sending branches/sleuthkit-3.2/tests/Makefile.am Sending branches/sleuthkit-3.2/tools/autotools/Makefile.am Sending branches/sleuthkit-3.2/tools/fstools/Makefile.am Sending branches/sleuthkit-3.2/tools/hashtools/Makefile.am Sending branches/sleuthkit-3.2/tools/imgtools/Makefile.am Sending branches/sleuthkit-3.2/tools/sorter/Makefile.am Sending branches/sleuthkit-3.2/tools/srchtools/Makefile.am Sending branches/sleuthkit-3.2/tools/timeline/Makefile.am Sending branches/sleuthkit-3.2/tools/vstools/Makefile.am Sending branches/sleuthkit-3.2/tsk3/auto/Makefile.am Sending branches/sleuthkit-3.2/tsk3/fs/Makefile.am Sending branches/sleuthkit-3.2/tsk3/hashdb/Makefile.am Sending branches/sleuthkit-3.2/tsk3/img/Makefile.am Sending branches/sleuthkit-3.2/tsk3/vs/Makefile.am Sending trunk/NEWS.txt Sending trunk/samples/Makefile.am Sending trunk/tests/Makefile.am Sending trunk/tools/autotools/Makefile.am Sending trunk/tools/fstools/Makefile.am Sending trunk/tools/hashtools/Makefile.am Sending trunk/tools/imgtools/Makefile.am Sending trunk/tools/sorter/Makefile.am Sending trunk/tools/srchtools/Makefile.am Sending trunk/tools/timeline/Makefile.am Sending trunk/tools/vstools/Makefile.am Sending trunk/tsk3/auto/Makefile.am Sending trunk/tsk3/fs/Makefile.am Sending trunk/tsk3/hashdb/Makefile.am Sending trunk/tsk3/img/Makefile.am Sending trunk/tsk3/vs/Makefile.am Transmitting file data ................................ Committed revision 317. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184455&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-17 04:21:35
|
Feature Requests item #3184455, was opened at 2011-02-16 23:21 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184455&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: builddir != srcdir support Initial Comment: Hi, sleuthkit 3.2.0 requires to run ./configure in source directory. If /path/sleuthkit-VERSION/configure is run from a separate build directory the make command fails due to missing files. Packaging support tools often use a separate build directory by default. The attached patch fixes this. The include path are all set relative to current $(builddir) and the corresponding $(srcdir): AM_CPPFLAGS=-I../.. -I$(srcdir)/../.. An alternative would be to use: AM_CPPFLAGS=-I$(top_builddir) -I$(top_srcdir) The patch also adds tsk3/tsk_incs.h to the "clean" target. Otherwise "make distcleancheck" and "make distcheck" fail. Thanks, Christian (Christian Franke to sleuthkit-users) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184455&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2011-02-17 03:44:55
|
So the issue is when trying to parse 'istat'? Can you use the library to do this? The istat output is intended for human consumption. Would you prefer different names instead?
On Jan 19, 2011, at 4:19 PM, Lee Ayres wrote:
> Oh my, upon further review I kinda screwed up my problem. It happened
> quite a while back and I hacked a fix into 3.1.3 that I had to revisit
> as I was working on confirming that 3.2.0 will integrate into our
> process. Working from memory is a bad policy, however I was on the
> right track. Ill show the code and give an illustrative example.
>
> Beginning with line 4187 in ntfs.c
>
> if (fs_file->meta->name2) {
> TSK_FS_META_NAME_LIST *fs_name = fs_file->meta->name2;
> tsk_fprintf(hFile, "Name: ");
> while (fs_name) {
> tsk_fprintf(hFile, "%s", fs_name->name);
> fs_name = fs_name->next;
> if (fs_name)
> tsk_fprintf(hFile, ", ");
> else
> tsk_fprintf(hFile, "\n");
> }
> }
>
> I have come across instances in the wild of files with the same name
> attribute twice. I dont know enough about the way Windows manages
> files to be able to assert why that was. Such a file with a duplicated
> name attribute, for example, with the name "Larry, Curly, and Moe"
> would have the following line in istat output:
>
> "Name: Larry, Curly, and Moe, Larry, Curly, and Moe"
>
> A human reader may be able to tease that apart, but a script is likely
> to freak out.
>
> On Wed, Jan 19, 2011 at 2:52 PM, Brian Carrier <ca...@sl...> wrote:
>> Hi Lee,
>>
>> Can you point to an example in the code where this happens? Line number is fine if you have one. I'm not sure that I am following the problem.
>>
>> thanks,
>> brian
>>
>>
>> On Jan 19, 2011, at 1:46 PM, Lee Ayres wrote:
>>
>>> In the current version of ntfs.c multiple names are concatenated
>>> together and separated by white space. This makes multiple names
>>> difficult to distinguish from file names with white space in them. I
>>> propose that a change be made to the formatting of names for output.
>
> --
> Lee T. Ayres, Senior Analyst
> Interhack Corporation
> http://web.interhack.com/ +1 614 545 4225
|
|
From: SourceForge.net <no...@so...> - 2011-02-17 03:40:14
|
Feature Requests item #3184431, was opened at 2011-02-16 22:40 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184431&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: Auto Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: full file path in DB Initial Comment: John Lehr requested that the full file path be stored in SQLite instead of just the parent directory address. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184431&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-17 03:39:26
|
Bugs item #3184429, was opened at 2011-02-16 22:39 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184429&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: inconsistent 0 time reporting. Initial Comment: John Lehr reported inconsistent behavior with 0-times. fls prints them as 0s and istat displays them as epoch times. We should be consistent and use '0' when possible to not give false impressions. Perhaps make some wrapper methods for returning time strings. fls: d/d 3: DCIM 0000-00-00 00:00:00 (UTC) 0000-00-00 00:00:00 (UTC) 0000-00-00 00:00:00 (UTC) 0000-00-00 00:00:00 (UTC) 32768 0 0 istat: Directory Entry: 3 Allocated File Attributes: Directory Size: 32768 Name: DCIM Directory Entry Times: Written: Wed Dec 31 16:00:00 1969 Accessed: Wed Dec 31 16:00:00 1969 Created: Wed Dec 31 16:00:00 1969 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184429&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-17 03:29:51
|
Bugs item #3173095, was opened at 2011-02-04 18:01 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3173095&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: None Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: fls misses allocated files in fat16 file system Initial Comment: System: Sleuthkit 3.2.0 on Debian Testing, Target was a 2gb MicroSD imaged in ewf (encase6) with libewf 20100226. BUG: The allocated files under directory "501" are not listed in recursive or direct listing but are listed by standard file list tools when the filesystem is mounted. Specifying the -f fat16 flag has no effect. $ fls -o137 -r image.dd r/r 5: ._.Trashes d/d * 6: _RASHE~1.0ZW d/d 8: .Trashes + d/d 17056261: 501 + r/r 17056263: ._501 d/d 10: .fseventsd + r/r 17058311: fseventsd-uuid + r/r 17058314: 0000000000007a09 + r/r 17058317: 0000000000014426 v/v 61463043: $MBR v/v 61463044: $FAT1 v/v 61463045: $FAT2 d/d 61463046: $OrphanFiles $ fls -o137 image.dd 17056261 -a d/d 17056261: . d/d 8: .. $ tree --inodes -a #mounted file system through xmount . |-- [ 190] DCIM | `-- [ 195] 100media | `-- [ 197] Rec_000.3gp |-- [ 193] .fseventsd | |-- [ 202] 0000000000007a09 | |-- [ 203] 0000000000014426 | `-- [ 201] fseventsd-uuid |-- [ 192] .Trashes | |-- [ 206] 501 | | |-- [ 211] Rec_000.3gp | | `-- [ 210] sun810.3gp | `-- [ 207] ._501 `-- [ 191] ._.Trashes -------------------------------------------------------------------- Additional data of interest: $mmls image.dd DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000000136 0000000137 Unallocated 02: 00:00 0000000137 0003842047 0003841911 DOS FAT16 (0x06) $fsstat -o137 image.ddFILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT16 OEM Name: Volume ID: 0x4326430 Volume Label (Boot Sector): ^@^@^@^@^@^@^@^@^@^@^@ Volume Label (Root Directory): File System Type Label: FAT16 Sectors before file system: 137 File System Layout (in sectors) Total Range: 0 - 3841910 * Reserved: 0 - 0 ** Boot Sector: 0 * FAT 0: 1 - 235 * FAT 1: 236 - 470 * Data Area: 471 - 3841910 ** Root Directory: 471 - 502 ** Cluster Area: 503 - 3841910 METADATA INFORMATION -------------------------------------------- Range: 2 - 61463046 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 32768 Total Cluster Range: 2 - 60023 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-02-16 22:29 Message: This was fixed on 2/7: r314 | carriersvn | 2011-02-07 23:36:01 -0500 (Mon, 07 Feb 2011) | 1 line resolved 3173095 re: files with invalid FAT dates now being shown ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2011-02-05 02:21 Message: I have determined that tsk is only reporting one file system state prior to the current state in the FAT16 file system (after the initial file system change). The problem can be reproduced thusly: 1) create an empty file with dd, e.g., dd if=/dev/zero of=fat16.dd bs=1024 count=102400 2) format the file fat16, e.g., mkfs.vfat -F16 fat16.dd 3) fls -r fat16.dd shows no files 4) mount fat16.dd 5) make a directory in the mounted fat16 file system, e.g., /dir1 6) fls -r fat16.dd shows dir1 7) make another directory, e.g., /dir2 8) fls -r fat16.dd shows only dir1 9) make another directory, e.g., /dir3, dir2 appears but not dir3. 10) Any query of the filesystem, such as ls or umount the file system, will cause fls to now report dir3. The images I was examining were all mounted in OSX and had files moved to .Trashes. This in some cases, but not all was the last action on the filesystem. Otherwise the cards were inserted in digital video cameras of an unknown manufacturer. ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2011-02-04 18:34 Message: I just noticed the allocated DCIM folder (and contents) on the root is not displayed by fls either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3173095&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-17 03:27:57
|
Bugs item #3184419, was opened at 2011-02-16 22:22 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184419&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: mingw compile errors Initial Comment: Simson G sent the following to the list: Using SleuthKit with libewf under mingw results in the error below in the configure.ac script because zlib isn't included natively in mingw; the solution is to add this line before the libewf test: My winning configure.ac script is attached. Unfortunately, this causes another problem with ewf.h: #if defined(TSK_WIN32) #include <config_msc.h> #endif It turns out that you don't have config_msc.h when compiling under mingw, because WIN32 and MSC are not synonyms. There really needs to be an explicit check to see if config_msc.h is present. So this needs to be added to configure.ac: AC_CHECK_HEADERS([config_msc.h]) And the line in ewf.h needs to be changed to read: #ifdef HAVE_CONFIG_MSC_H #include <config_msc.h> #endif Another problem shows up in ewf.c: #if defined (TSK_WIN32) if (libewf_check_file_signature_wide(images[0]) == 0) { #else if (libewf_check_file_signature(images[0],0) == 0) { #endif which generates this error: ewf.c:147: error: too few arguments to function `libewf_check_file_signature_wide' Which can be fixed with: if (libewf_check_file_signature_wide(images[0],0) == 0) { Another problem is auto.cpp: libtool: compile: /opt/local/bin//i386-mingw32-g++ -DHAVE_CONFIG_H -I. -I../../tsk3 -I../.. -Wall -mwin32 -mconsole -march=pentium4 -Wall -MT auto.lo -MD -MP -MF .deps/auto.Tpo -c auto.cpp -o auto.o In file included from /opt/local/i386-mingw32/include/c++/3.4.5/bits/stl_algobase.h:67, from /opt/local/i386-mingw32/include/c++/3.4.5/bits/stl_tree.h:66, from /opt/local/i386-mingw32/include/c++/3.4.5/map:66, from tsk_auto.h:32, from tsk_auto_i.h:29, from auto.cpp:16: /opt/local/i386-mingw32/include/c++/3.4.5/cstdlib:111: error: `::realloc' has not been declared This seems to happening when tsk_auto.h executes the #include <map> or the #include<string> The interesting thing is, neither of those includes are actually necessary to compile the auto class. I commented them out and the compile proceeded but linking failed with this: libtool: link: /opt/local/bin//i386-mingw32-g++ -mwin32 -mconsole -march=pentium4 -Wall -o img_cat.exe img_cat.o ../../tsk3/.libs/libtsk3.a -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_i386-mingw32-gcc/work/build/i386-mingw32/libstdc++-v3/src -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_i386-mingw32-gcc/work/build/i386-mingw32/libstdc++-v3/src/.libs -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_i386-mingw32-gcc/work/build/gcc -L/opt/local/i386-mingw32/bin -L/opt/local/i386-mingw32/lib -L/opt/local/lib/../i386-mingw32/lib /opt/local/i386-mingw32/lib/libstdc++.a -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lm /opt/local/i386-mingw32/lib/libewf.a -lz -lws2_32 -lgdi32 ../../tsk3/.libs/libtsk3.a(mymalloc.o):mymalloc.c:(.text+0x8d): undefined reference to `_rpl_realloc' Now that's weird, but it turns out that in tsk3/tsk_config.h, you'll find this: /* Define to rpl_realloc if the replacement function should be used. */ #define realloc rpl_realloc Which is just the wrong thing to be doing. We have realloc on this platform, but for some reason AC_FUNC_REALLOC things that we don't. So I commented out AC_FUNC_REALLOC in configure.ac Apparently the failure of AC_FUNC_REALLOC has been discovered in the past: http://www.opensubscriber.com/message/aut...@gn.../8275001.html http://www.opensubscriber.com/message/aut...@gn.../8275242.html AND THEN YOU CAN COMPILE SLEUTHKIT 3.2.0 on MINGW! HURRAY! ============== configure:19255: result: no configure:19324: checking libewf.h usability configure:19341: /opt/local/bin//i386-mingw32-gcc -c -mwin32 -mconsole -march=pentium4 -Wall conftest.c >&5 configure:19347: $? = 0 configure:19361: result: yes configure:19365: checking libewf.h presence configure:19380: /opt/local/bin//i386-mingw32-gcc -E conftest.c configure:19386: $? = 0 configure:19400: result: yes configure:19428: checking for libewf.h configure:19436: result: yes configure:19445: checking for libewf_open in -lewf configure:19480: /opt/local/bin//i386-mingw32-gcc -o conftest.exe -mwin32 -mconsole -march=pentium4 -Wall -lws2_32 conftest.c -lewf -lws2_32 -lgdi32 >&5 /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_write_io_handle.o):libewf_write_io_handle.c:(.text+0x2901): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_write_io_handle.o):libewf_write_io_handle.c:(.text+0x541e): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_read_io_handle.o):libewf_read_io_handle.c:(.text+0x569): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_compression.o):libewf_compression.c:(.text+0x1ba): undefined reference to `_compress2' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_compression.o):libewf_compression.c:(.text+0x1e8): undefined reference to `_compressBound' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_compression.o):libewf_compression.c:(.text+0x3b0): undefined reference to `_uncompress' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x5c3): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0xa98): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x1be8): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x21c0): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x2557): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x2e6a): more undefined references to `_adler32' follow collect2: ld returned 1 exit status ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________ sleuthkit-users mailing list https://lists.sourceforge.net/lists/listinfo/sleuthkit-users http://www.sleuthkit.org ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2011-02-16 22:27 Message: Checked in some of the changes: Sending branches/sleuthkit-3.2/NEWS.txt Sending branches/sleuthkit-3.2/configure.ac Sending branches/sleuthkit-3.2/tsk3/auto/tsk_auto.h Sending branches/sleuthkit-3.2/tsk3/img/ewf.h Sending trunk/NEWS.txt Sending trunk/configure.ac Sending trunk/tsk3/auto/tsk_auto.h Sending trunk/tsk3/img/ewf.h Transmitting file data ........ Committed revision 316. Open issues include: - why does TSK need to check for zlib if that is a libewf dependency? The attached configure.ac makes zlib a requirement for TSK. - Does changing the wide arguments work on Visual Studio? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184419&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-17 03:22:34
|
Bugs item #3184419, was opened at 2011-02-16 22:22 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184419&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: mingw compile errors Initial Comment: Simson G sent the following to the list: Using SleuthKit with libewf under mingw results in the error below in the configure.ac script because zlib isn't included natively in mingw; the solution is to add this line before the libewf test: My winning configure.ac script is attached. Unfortunately, this causes another problem with ewf.h: #if defined(TSK_WIN32) #include <config_msc.h> #endif It turns out that you don't have config_msc.h when compiling under mingw, because WIN32 and MSC are not synonyms. There really needs to be an explicit check to see if config_msc.h is present. So this needs to be added to configure.ac: AC_CHECK_HEADERS([config_msc.h]) And the line in ewf.h needs to be changed to read: #ifdef HAVE_CONFIG_MSC_H #include <config_msc.h> #endif Another problem shows up in ewf.c: #if defined (TSK_WIN32) if (libewf_check_file_signature_wide(images[0]) == 0) { #else if (libewf_check_file_signature(images[0],0) == 0) { #endif which generates this error: ewf.c:147: error: too few arguments to function `libewf_check_file_signature_wide' Which can be fixed with: if (libewf_check_file_signature_wide(images[0],0) == 0) { Another problem is auto.cpp: libtool: compile: /opt/local/bin//i386-mingw32-g++ -DHAVE_CONFIG_H -I. -I../../tsk3 -I../.. -Wall -mwin32 -mconsole -march=pentium4 -Wall -MT auto.lo -MD -MP -MF .deps/auto.Tpo -c auto.cpp -o auto.o In file included from /opt/local/i386-mingw32/include/c++/3.4.5/bits/stl_algobase.h:67, from /opt/local/i386-mingw32/include/c++/3.4.5/bits/stl_tree.h:66, from /opt/local/i386-mingw32/include/c++/3.4.5/map:66, from tsk_auto.h:32, from tsk_auto_i.h:29, from auto.cpp:16: /opt/local/i386-mingw32/include/c++/3.4.5/cstdlib:111: error: `::realloc' has not been declared This seems to happening when tsk_auto.h executes the #include <map> or the #include<string> The interesting thing is, neither of those includes are actually necessary to compile the auto class. I commented them out and the compile proceeded but linking failed with this: libtool: link: /opt/local/bin//i386-mingw32-g++ -mwin32 -mconsole -march=pentium4 -Wall -o img_cat.exe img_cat.o ../../tsk3/.libs/libtsk3.a -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_i386-mingw32-gcc/work/build/i386-mingw32/libstdc++-v3/src -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_i386-mingw32-gcc/work/build/i386-mingw32/libstdc++-v3/src/.libs -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_i386-mingw32-gcc/work/build/gcc -L/opt/local/i386-mingw32/bin -L/opt/local/i386-mingw32/lib -L/opt/local/lib/../i386-mingw32/lib /opt/local/i386-mingw32/lib/libstdc++.a -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lm /opt/local/i386-mingw32/lib/libewf.a -lz -lws2_32 -lgdi32 ../../tsk3/.libs/libtsk3.a(mymalloc.o):mymalloc.c:(.text+0x8d): undefined reference to `_rpl_realloc' Now that's weird, but it turns out that in tsk3/tsk_config.h, you'll find this: /* Define to rpl_realloc if the replacement function should be used. */ #define realloc rpl_realloc Which is just the wrong thing to be doing. We have realloc on this platform, but for some reason AC_FUNC_REALLOC things that we don't. So I commented out AC_FUNC_REALLOC in configure.ac Apparently the failure of AC_FUNC_REALLOC has been discovered in the past: http://www.opensubscriber.com/message/aut...@gn.../8275001.html http://www.opensubscriber.com/message/aut...@gn.../8275242.html AND THEN YOU CAN COMPILE SLEUTHKIT 3.2.0 on MINGW! HURRAY! ============== configure:19255: result: no configure:19324: checking libewf.h usability configure:19341: /opt/local/bin//i386-mingw32-gcc -c -mwin32 -mconsole -march=pentium4 -Wall conftest.c >&5 configure:19347: $? = 0 configure:19361: result: yes configure:19365: checking libewf.h presence configure:19380: /opt/local/bin//i386-mingw32-gcc -E conftest.c configure:19386: $? = 0 configure:19400: result: yes configure:19428: checking for libewf.h configure:19436: result: yes configure:19445: checking for libewf_open in -lewf configure:19480: /opt/local/bin//i386-mingw32-gcc -o conftest.exe -mwin32 -mconsole -march=pentium4 -Wall -lws2_32 conftest.c -lewf -lws2_32 -lgdi32 >&5 /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_write_io_handle.o):libewf_write_io_handle.c:(.text+0x2901): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_write_io_handle.o):libewf_write_io_handle.c:(.text+0x541e): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_read_io_handle.o):libewf_read_io_handle.c:(.text+0x569): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_compression.o):libewf_compression.c:(.text+0x1ba): undefined reference to `_compress2' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_compression.o):libewf_compression.c:(.text+0x1e8): undefined reference to `_compressBound' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_compression.o):libewf_compression.c:(.text+0x3b0): undefined reference to `_uncompress' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x5c3): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0xa98): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x1be8): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x21c0): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x2557): undefined reference to `_adler32' /opt/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/lib/libewf.a(libewf_section.o):libewf_section.c:(.text+0x2e6a): more undefined references to `_adler32' follow collect2: ld returned 1 exit status ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________ sleuthkit-users mailing list https://lists.sourceforge.net/lists/listinfo/sleuthkit-users http://www.sleuthkit.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3184419&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-11 15:13:04
|
Feature Requests item #3178368, was opened at 2011-02-11 15:13 Message generated for change (Tracker Item Submitted) made by prosaic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3178368&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: prosaic (prosaic) Assigned to: Nobody/Anonymous (nobody) Summary: handle multiple $FILE_NAME attr Initial Comment: In NTFS, an inode can have multiple $FILE_NAME attributes. This usually occurs with just long and short file names if the system needs/wants to keep an 8.3 compatible file name, but can also happen if the system creates a hard link giving that inode a new name in a new directory. Also, as times in $FILE_NAME attributes are only updated if that attribute was updated, it is possible for the times in each $FILE_NAME to be different, giving further clues as to actions taken on that file. It would be very handy if istat parsed and displayed all of the $FILE_NAME attributes instead of just the first one, so that we could see the name, parent inode, and times associated with the others as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3178368&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 07:21:33
|
Bugs item #3173095, was opened at 2011-02-04 15:01 Message generated for change (Comment added) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3173095&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: fls misses allocated files in fat16 file system Initial Comment: System: Sleuthkit 3.2.0 on Debian Testing, Target was a 2gb MicroSD imaged in ewf (encase6) with libewf 20100226. BUG: The allocated files under directory "501" are not listed in recursive or direct listing but are listed by standard file list tools when the filesystem is mounted. Specifying the -f fat16 flag has no effect. $ fls -o137 -r image.dd r/r 5: ._.Trashes d/d * 6: _RASHE~1.0ZW d/d 8: .Trashes + d/d 17056261: 501 + r/r 17056263: ._501 d/d 10: .fseventsd + r/r 17058311: fseventsd-uuid + r/r 17058314: 0000000000007a09 + r/r 17058317: 0000000000014426 v/v 61463043: $MBR v/v 61463044: $FAT1 v/v 61463045: $FAT2 d/d 61463046: $OrphanFiles $ fls -o137 image.dd 17056261 -a d/d 17056261: . d/d 8: .. $ tree --inodes -a #mounted file system through xmount . |-- [ 190] DCIM | `-- [ 195] 100media | `-- [ 197] Rec_000.3gp |-- [ 193] .fseventsd | |-- [ 202] 0000000000007a09 | |-- [ 203] 0000000000014426 | `-- [ 201] fseventsd-uuid |-- [ 192] .Trashes | |-- [ 206] 501 | | |-- [ 211] Rec_000.3gp | | `-- [ 210] sun810.3gp | `-- [ 207] ._501 `-- [ 191] ._.Trashes -------------------------------------------------------------------- Additional data of interest: $mmls image.dd DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000000136 0000000137 Unallocated 02: 00:00 0000000137 0003842047 0003841911 DOS FAT16 (0x06) $fsstat -o137 image.ddFILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT16 OEM Name: Volume ID: 0x4326430 Volume Label (Boot Sector): ^@^@^@^@^@^@^@^@^@^@^@ Volume Label (Root Directory): File System Type Label: FAT16 Sectors before file system: 137 File System Layout (in sectors) Total Range: 0 - 3841910 * Reserved: 0 - 0 ** Boot Sector: 0 * FAT 0: 1 - 235 * FAT 1: 236 - 470 * Data Area: 471 - 3841910 ** Root Directory: 471 - 502 ** Cluster Area: 503 - 3841910 METADATA INFORMATION -------------------------------------------- Range: 2 - 61463046 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 32768 Total Cluster Range: 2 - 60023 ---------------------------------------------------------------------- >Comment By: John Lehr (jlehr) Date: 2011-02-04 23:21 Message: I have determined that tsk is only reporting one file system state prior to the current state in the FAT16 file system (after the initial file system change). The problem can be reproduced thusly: 1) create an empty file with dd, e.g., dd if=/dev/zero of=fat16.dd bs=1024 count=102400 2) format the file fat16, e.g., mkfs.vfat -F16 fat16.dd 3) fls -r fat16.dd shows no files 4) mount fat16.dd 5) make a directory in the mounted fat16 file system, e.g., /dir1 6) fls -r fat16.dd shows dir1 7) make another directory, e.g., /dir2 8) fls -r fat16.dd shows only dir1 9) make another directory, e.g., /dir3, dir2 appears but not dir3. 10) Any query of the filesystem, such as ls or umount the file system, will cause fls to now report dir3. The images I was examining were all mounted in OSX and had files moved to .Trashes. This in some cases, but not all was the last action on the filesystem. Otherwise the cards were inserted in digital video cameras of an unknown manufacturer. ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2011-02-04 15:34 Message: I just noticed the allocated DCIM folder (and contents) on the root is not displayed by fls either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3173095&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-04 23:34:57
|
Bugs item #3173095, was opened at 2011-02-04 15:01 Message generated for change (Comment added) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3173095&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: fls misses allocated files in fat16 file system Initial Comment: System: Sleuthkit 3.2.0 on Debian Testing, Target was a 2gb MicroSD imaged in ewf (encase6) with libewf 20100226. BUG: The allocated files under directory "501" are not listed in recursive or direct listing but are listed by standard file list tools when the filesystem is mounted. Specifying the -f fat16 flag has no effect. $ fls -o137 -r image.dd r/r 5: ._.Trashes d/d * 6: _RASHE~1.0ZW d/d 8: .Trashes + d/d 17056261: 501 + r/r 17056263: ._501 d/d 10: .fseventsd + r/r 17058311: fseventsd-uuid + r/r 17058314: 0000000000007a09 + r/r 17058317: 0000000000014426 v/v 61463043: $MBR v/v 61463044: $FAT1 v/v 61463045: $FAT2 d/d 61463046: $OrphanFiles $ fls -o137 image.dd 17056261 -a d/d 17056261: . d/d 8: .. $ tree --inodes -a #mounted file system through xmount . |-- [ 190] DCIM | `-- [ 195] 100media | `-- [ 197] Rec_000.3gp |-- [ 193] .fseventsd | |-- [ 202] 0000000000007a09 | |-- [ 203] 0000000000014426 | `-- [ 201] fseventsd-uuid |-- [ 192] .Trashes | |-- [ 206] 501 | | |-- [ 211] Rec_000.3gp | | `-- [ 210] sun810.3gp | `-- [ 207] ._501 `-- [ 191] ._.Trashes -------------------------------------------------------------------- Additional data of interest: $mmls image.dd DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000000136 0000000137 Unallocated 02: 00:00 0000000137 0003842047 0003841911 DOS FAT16 (0x06) $fsstat -o137 image.ddFILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT16 OEM Name: Volume ID: 0x4326430 Volume Label (Boot Sector): ^@^@^@^@^@^@^@^@^@^@^@ Volume Label (Root Directory): File System Type Label: FAT16 Sectors before file system: 137 File System Layout (in sectors) Total Range: 0 - 3841910 * Reserved: 0 - 0 ** Boot Sector: 0 * FAT 0: 1 - 235 * FAT 1: 236 - 470 * Data Area: 471 - 3841910 ** Root Directory: 471 - 502 ** Cluster Area: 503 - 3841910 METADATA INFORMATION -------------------------------------------- Range: 2 - 61463046 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 32768 Total Cluster Range: 2 - 60023 ---------------------------------------------------------------------- >Comment By: John Lehr (jlehr) Date: 2011-02-04 15:34 Message: I just noticed the allocated DCIM folder (and contents) on the root is not displayed by fls either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3173095&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-02-04 23:01:24
|
Bugs item #3173095, was opened at 2011-02-04 15:01 Message generated for change (Tracker Item Submitted) made by jlehr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3173095&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: File System Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: fls misses allocated files in fat16 file system Initial Comment: System: Sleuthkit 3.2.0 on Debian Testing, Target was a 2gb MicroSD imaged in ewf (encase6) with libewf 20100226. BUG: The allocated files under directory "501" are not listed in recursive or direct listing but are listed by standard file list tools when the filesystem is mounted. Specifying the -f fat16 flag has no effect. $ fls -o137 -r image.dd r/r 5: ._.Trashes d/d * 6: _RASHE~1.0ZW d/d 8: .Trashes + d/d 17056261: 501 + r/r 17056263: ._501 d/d 10: .fseventsd + r/r 17058311: fseventsd-uuid + r/r 17058314: 0000000000007a09 + r/r 17058317: 0000000000014426 v/v 61463043: $MBR v/v 61463044: $FAT1 v/v 61463045: $FAT2 d/d 61463046: $OrphanFiles $ fls -o137 image.dd 17056261 -a d/d 17056261: . d/d 8: .. $ tree --inodes -a #mounted file system through xmount . |-- [ 190] DCIM | `-- [ 195] 100media | `-- [ 197] Rec_000.3gp |-- [ 193] .fseventsd | |-- [ 202] 0000000000007a09 | |-- [ 203] 0000000000014426 | `-- [ 201] fseventsd-uuid |-- [ 192] .Trashes | |-- [ 206] 501 | | |-- [ 211] Rec_000.3gp | | `-- [ 210] sun810.3gp | `-- [ 207] ._501 `-- [ 191] ._.Trashes -------------------------------------------------------------------- Additional data of interest: $mmls image.dd DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000000136 0000000137 Unallocated 02: 00:00 0000000137 0003842047 0003841911 DOS FAT16 (0x06) $fsstat -o137 image.ddFILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT16 OEM Name: Volume ID: 0x4326430 Volume Label (Boot Sector): ^@^@^@^@^@^@^@^@^@^@^@ Volume Label (Root Directory): File System Type Label: FAT16 Sectors before file system: 137 File System Layout (in sectors) Total Range: 0 - 3841910 * Reserved: 0 - 0 ** Boot Sector: 0 * FAT 0: 1 - 235 * FAT 1: 236 - 470 * Data Area: 471 - 3841910 ** Root Directory: 471 - 502 ** Cluster Area: 503 - 3841910 METADATA INFORMATION -------------------------------------------- Range: 2 - 61463046 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 32768 Total Cluster Range: 2 - 60023 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3173095&group_id=55685 |
|
From: Michael C. <scu...@gm...> - 2011-01-30 22:18:20
|
Hi All, I have just added the ability to compile the python bindings for windows (still on an ubuntu box). There are some pre-compiled binaries there. Please test. http://code.google.com/p/pytsk/ Samples of python code to use the sleuthkit can be found here: http://code.google.com/p/pytsk/source/browse/#hg%2Fsamples Michael. |
|
From: Lee A. <ay...@in...> - 2011-01-19 21:20:02
|
Oh my, upon further review I kinda screwed up my problem. It happened
quite a while back and I hacked a fix into 3.1.3 that I had to revisit
as I was working on confirming that 3.2.0 will integrate into our
process. Working from memory is a bad policy, however I was on the
right track. Ill show the code and give an illustrative example.
Beginning with line 4187 in ntfs.c
if (fs_file->meta->name2) {
TSK_FS_META_NAME_LIST *fs_name = fs_file->meta->name2;
tsk_fprintf(hFile, "Name: ");
while (fs_name) {
tsk_fprintf(hFile, "%s", fs_name->name);
fs_name = fs_name->next;
if (fs_name)
tsk_fprintf(hFile, ", ");
else
tsk_fprintf(hFile, "\n");
}
}
I have come across instances in the wild of files with the same name
attribute twice. I dont know enough about the way Windows manages
files to be able to assert why that was. Such a file with a duplicated
name attribute, for example, with the name "Larry, Curly, and Moe"
would have the following line in istat output:
"Name: Larry, Curly, and Moe, Larry, Curly, and Moe"
A human reader may be able to tease that apart, but a script is likely
to freak out.
On Wed, Jan 19, 2011 at 2:52 PM, Brian Carrier <ca...@sl...> wrote:
> Hi Lee,
>
> Can you point to an example in the code where this happens? Line number is fine if you have one. I'm not sure that I am following the problem.
>
> thanks,
> brian
>
>
> On Jan 19, 2011, at 1:46 PM, Lee Ayres wrote:
>
>> In the current version of ntfs.c multiple names are concatenated
>> together and separated by white space. This makes multiple names
>> difficult to distinguish from file names with white space in them. I
>> propose that a change be made to the formatting of names for output.
--
Lee T. Ayres, Senior Analyst
Interhack Corporation
http://web.interhack.com/ +1 614 545 4225
|
|
From: Brian C. <ca...@sl...> - 2011-01-19 20:52:28
|
Hi Lee, Can you point to an example in the code where this happens? Line number is fine if you have one. I'm not sure that I am following the problem. thanks, brian On Jan 19, 2011, at 1:46 PM, Lee Ayres wrote: > In the current version of ntfs.c multiple names are concatenated > together and separated by white space. This makes multiple names > difficult to distinguish from file names with white space in them. I > propose that a change be made to the formatting of names for output. > > My understanding is that ntfs allows for any character but null and > '/'. Separating the values with '/' characters would seem to me to be > a compliant choice, however it might confuse users. > > In practice the names could be surrounded with quote characters since > Windows doesn't allow them and in my experience they are very uncommon > even in environments and filesystems where they are allowed. If you > are willing to put just a small bit of cognitive burden on the human > viewer the name string could be escaped with \" replacing literal > double quotes and \\ replacing literal backslashes. > > Alternately, the output can have multiple "Name" lines. > > I'm happy to submit a patch that implements any one of the > alternatives if needs be. > > P.S. If one wants to get terrifically pedantic, I see nothing to > indicate that new-lines are disallowed in ntfs file names. Am I wrong > about that, and if not what effect might that have on the choice of an > output strategy? > > -- > Lee T. Ayres, Senior Analyst > Interhack Corporation > http://web.interhack.com/ +1 614 545 4225 > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
|
From: Lee A. <ay...@in...> - 2011-01-19 19:52:19
|
In the current version of ntfs.c multiple names are concatenated together and separated by white space. This makes multiple names difficult to distinguish from file names with white space in them. I propose that a change be made to the formatting of names for output. My understanding is that ntfs allows for any character but null and '/'. Separating the values with '/' characters would seem to me to be a compliant choice, however it might confuse users. In practice the names could be surrounded with quote characters since Windows doesn't allow them and in my experience they are very uncommon even in environments and filesystems where they are allowed. If you are willing to put just a small bit of cognitive burden on the human viewer the name string could be escaped with \" replacing literal double quotes and \\ replacing literal backslashes. Alternately, the output can have multiple "Name" lines. I'm happy to submit a patch that implements any one of the alternatives if needs be. P.S. If one wants to get terrifically pedantic, I see nothing to indicate that new-lines are disallowed in ntfs file names. Am I wrong about that, and if not what effect might that have on the choice of an output strategy? -- Lee T. Ayres, Senior Analyst Interhack Corporation http://web.interhack.com/ +1 614 545 4225 |
|
From: SourceForge.net <no...@so...> - 2011-01-10 22:38:49
|
Feature Requests item #3154655, was opened at 2011-01-10 23:12 Message generated for change (Comment added) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3154655&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: None Status: Open Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf/make m4 directory Initial Comment: As indicated by recent versions of autoconf/make please use a sub-directory for M4 scripts. The attached patch makes the necessary changes for this. ---------------------------------------------------------------------- >Comment By: Joachim Metz (jbmetz) Date: 2011-01-10 23:38 Message: BTW you'll need to add the m4 sub-directory by hand. It is not included in the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3154655&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2011-01-10 22:27:24
|
Feature Requests item #3154664, was opened at 2011-01-10 23:27 Message generated for change (Tracker Item Submitted) made by jbmetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3154664&group_id=55685 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Image Layer Group: None Status: Open Priority: 5 Private: No Submitted By: Joachim Metz (jbmetz) Assigned to: Nobody/Anonymous (nobody) Summary: libewf version 2 support Initial Comment: Although libewf version 2 is still in alpha version. With this tracker the changes necessary for version 2 API support with backwards compatibility for current stable of libewf. The patch only changes tsk3/img/ewf.[ch] not the configure.ac detection of libewf. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3154664&group_id=55685 |
1 message has been excluded from this view by a project administrator.
