sleuthkit-users Mailing List for The Sleuth Kit (Page 48)
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(1) |
Feb
(20) |
Mar
(60) |
Apr
(40) |
May
(24) |
Jun
(28) |
Jul
(18) |
Aug
(27) |
Sep
(6) |
Oct
(14) |
Nov
(15) |
Dec
(22) |
| 2004 |
Jan
(34) |
Feb
(13) |
Mar
(28) |
Apr
(23) |
May
(27) |
Jun
(26) |
Jul
(37) |
Aug
(19) |
Sep
(20) |
Oct
(39) |
Nov
(17) |
Dec
(9) |
| 2005 |
Jan
(45) |
Feb
(43) |
Mar
(66) |
Apr
(36) |
May
(19) |
Jun
(64) |
Jul
(10) |
Aug
(11) |
Sep
(35) |
Oct
(6) |
Nov
(4) |
Dec
(13) |
| 2006 |
Jan
(52) |
Feb
(34) |
Mar
(39) |
Apr
(39) |
May
(37) |
Jun
(15) |
Jul
(13) |
Aug
(48) |
Sep
(9) |
Oct
(10) |
Nov
(47) |
Dec
(13) |
| 2007 |
Jan
(25) |
Feb
(4) |
Mar
(2) |
Apr
(29) |
May
(11) |
Jun
(19) |
Jul
(13) |
Aug
(15) |
Sep
(30) |
Oct
(12) |
Nov
(10) |
Dec
(13) |
| 2008 |
Jan
(2) |
Feb
(54) |
Mar
(58) |
Apr
(43) |
May
(10) |
Jun
(27) |
Jul
(25) |
Aug
(27) |
Sep
(48) |
Oct
(69) |
Nov
(55) |
Dec
(43) |
| 2009 |
Jan
(26) |
Feb
(36) |
Mar
(28) |
Apr
(27) |
May
(55) |
Jun
(9) |
Jul
(19) |
Aug
(16) |
Sep
(15) |
Oct
(17) |
Nov
(70) |
Dec
(21) |
| 2010 |
Jan
(56) |
Feb
(59) |
Mar
(53) |
Apr
(32) |
May
(25) |
Jun
(31) |
Jul
(36) |
Aug
(11) |
Sep
(37) |
Oct
(19) |
Nov
(23) |
Dec
(6) |
| 2011 |
Jan
(21) |
Feb
(20) |
Mar
(30) |
Apr
(30) |
May
(74) |
Jun
(50) |
Jul
(34) |
Aug
(34) |
Sep
(12) |
Oct
(33) |
Nov
(10) |
Dec
(8) |
| 2012 |
Jan
(23) |
Feb
(57) |
Mar
(26) |
Apr
(14) |
May
(27) |
Jun
(27) |
Jul
(60) |
Aug
(88) |
Sep
(13) |
Oct
(36) |
Nov
(97) |
Dec
(85) |
| 2013 |
Jan
(60) |
Feb
(24) |
Mar
(43) |
Apr
(32) |
May
(22) |
Jun
(38) |
Jul
(51) |
Aug
(50) |
Sep
(76) |
Oct
(65) |
Nov
(25) |
Dec
(30) |
| 2014 |
Jan
(19) |
Feb
(41) |
Mar
(43) |
Apr
(28) |
May
(61) |
Jun
(12) |
Jul
(10) |
Aug
(37) |
Sep
(76) |
Oct
(31) |
Nov
(41) |
Dec
(12) |
| 2015 |
Jan
(33) |
Feb
(28) |
Mar
(53) |
Apr
(22) |
May
(29) |
Jun
(20) |
Jul
(15) |
Aug
(17) |
Sep
(52) |
Oct
(3) |
Nov
(18) |
Dec
(21) |
| 2016 |
Jan
(20) |
Feb
(8) |
Mar
(21) |
Apr
(7) |
May
(13) |
Jun
(35) |
Jul
(34) |
Aug
(11) |
Sep
(14) |
Oct
(22) |
Nov
(31) |
Dec
(23) |
| 2017 |
Jan
(20) |
Feb
(7) |
Mar
(5) |
Apr
(6) |
May
(6) |
Jun
(22) |
Jul
(11) |
Aug
(16) |
Sep
(8) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
(16) |
Apr
(2) |
May
(6) |
Jun
(5) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
|
Nov
(16) |
Dec
(13) |
| 2019 |
Jan
|
Feb
(1) |
Mar
(25) |
Apr
(9) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Simson G. <si...@ac...> - 2014-02-02 17:16:18
|
Thanks for the explanation. I think that this is an aspect of the SleuthKit API that fiwalk is not properly handling. it seems to be sending those attributes when the primary data is not available. Is there a flag being set that says “these data are different from what you are used to getting?” Failing that, we can make fiwalk simply suppress hashing and generation of the byte runs on 0-length files. As for your proposal below — would anybody use it? On Feb 1, 2014, at 3:11 PM, Alex Nelson <ajn...@cs...> wrote: > Hi Simson, > > The NTFS $Secure file is a weird one. Its primary data is stored in the $DATA attribute with the name $SDS, and $SDH and $SII are two $INDEX attributes for the same file. I think there are a couple other NTFS special files that have multiple indices like this; there are definitely files with non-standard indices. > > Normally, the default, unnamed data attribute of a file would supply the content that Fiwalk would hash. In the case of $Secure, that attribute is in fact 0-length. (Absent, even, according to your istat.) The real data of $Secure is in the named data stream "$Secure:$SDS". Fiwalk and DFXML don't presently have a way to express that aside from making a whole different fileobject; so, $Secure would be a 0-length file, $Secure:$SDS would be a 1.9MB (for you) file. Right now, Fiwalk is just quietly hashing the content of $Secure:$SDS; I forget if there's an explicit check for that or it's a side-effect of something. > > There is further expression weirdness if you want to express $Secure:$SDH or $Secure:$SII, since those aren't technically content, they're indices. > > I've been thinking about how to express those in DFXML for a while, because the problem also arises for named data streams in general. What's the hash of a file with multiple data streams? I hope you'll agree that there should be one hash per stream, instead of one hash per file. > > I think the best way to approach this problem is to define a new child element of a <fileobject>, a named data stream (I think it's abbreviated NDS in the Carrier book; it's "Alternate" data stream elsewhere). So, in $Secure's case: > > <fileobject> > <filename>$Secure</filename> > <ntfs:nds> > <tsk:icat_id>9-128-11</tsk:icat_id> > <parent_object> > <inode>9</inode> > </parent_object> > <filename>$SDS</filename> > <byte_runs><!--As expected...--></byte_runs> > <hashdigest type="sha1">1234abcd...</hashdigest> > </ntfs:nds> > </fileobject> > > The name data stream elements would be a subset of the <fileobject> elements. > > Similarly, there can be elements for the NTFS index root and index allocation attributes, which would also be children of a fileobject. > > <ntfs:index_root> > <tsk:icat_id>9-144-12</tsk:icat_id> > <parent_object> > <inode>9</inode> > </parent_object> > <filename>$SII</filename> > <byte_runs><!--The resident data in the MFT entry's attribute; will take some engineering to get this right, I think--></byte_runs> > <hashdigest type="sha1">5678...</hashdigest> > </ntfs:index_root> > > <ntfs:index_allocation> > <tsk:icat_id>9-160-13</tsk:icat_id> > <parent_object> > <inode>9</inode> > </parent_object> > <filename>$SII</filename> > <byte_runs><!--Of the index clusters--></byte_runs> > <hashdigest type="sha1">9abc...</hashdigest> > </ntfs:index_allocation> > > This approach wouldn't require changes to the DFXML schema. > > Do you think this solves the problem of extra indices and data streams for NTFS? > > --Alex > > > > > > On Fri, Jan 31, 2014 at 9:38 PM, Simson Garfinkel <si...@ac...> wrote: > > I have an NTFS disk image. There is a file on it that the SleuthKit reports has 0 length. But fiwalk reports that it has several byte runs. Currently fiwalk is computing the hash of those byte runs and reporting it as the file hash, which is the wrong behavior. > > Below is the istat, followed by the XML dump and also the fls output. It looks to me that there are several attributes; one of them, the $SDS attribute, is 1.9MB in length. > > Clearly the attributes should not be hashed to determine the file's hash, so there is a bug in fiwalk that I need to fix. From the API, how do I determine that the data callback is being given an attribute that shouldn't be hashed? > > Here is the relevant part of the directory list with fls: > > r/r * 9-144-16(realloc): > title_ctr[1].gif:$SDH > r/r * 9-144-18(realloc): title_ctr[1].gif:$SII > r/r * 9-128-19(realloc): title_ctr[1].gif:$SDS > > > > Here is the istat: > > $ istat -o 63 SG1-1064.E01 9-144-16 > MFT Entry Header Values: > Entry: 9 Sequence: 9 > $LogFile Sequence Number: 586416701932 > Allocated File > Links: 1 > > $STANDARD_INFORMATION Attribute Values: > Flags: Hidden, System > Owner ID: 0 > Security ID: 257 (S-1-5-32-544) > Created: 2004-07-12 16:58:51 (EDT) > File Modified: 2004-07-12 16:58:51 (EDT) > MFT Modified: 2004-07-12 16:58:51 (EDT) > Accessed: 2004-07-12 16:58:51 (EDT) > > $FILE_NAME Attribute Values: > Flags: > Name: $Secure > Parent MFT Entry: 5 Sequence: 5 > Allocated Size: 0 Actual Size: 0 > Created: 2076-11-29 03:54:34 (EST) > File Modified: 2076-11-29 03:54:34 (EST) > MFT Modified: 2076-11-29 03:54:34 (EST) > Accessed: 2076-11-29 03:54:34 (EST) > > $ATTRIBUTE_LIST Attribute Values: > Type: 16-0 MFT Entry: 9 > VCN: 0 > Type: 48-7 MFT Entry: 9 > VCN: 0 > Type: 128-0 MFT Entry: 178770 > VCN: 0 > Type: 144-16 MFT Entry: 9 > VCN: 0 > Type: 144-18 MFT Entry: 9 > VCN: 0 > Type: 160-2 MFT Entry: 6781 > VCN: 0 > Type: 160-3 MFT Entry: 6781 > VCN: 0 > Type: 176-4 MFT Entry: 6781 > VCN: 0 > Type: 176-5 MFT Entry: 6781 > VCN: 0 > > Attributes: > Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 > Type: $ATTRIBUTE_LIST (32-17) Name: N/A Non-Resident size: 344 init_size: 344 > 549297 > Type: $FILE_NAME (48-7) Name: N/A Resident size: 80 > Type: $INDEX_ROOT (144-16) Name: $SDH Resident size: 56 > Type: $INDEX_ROOT (144-18) Name: $SII Resident size: 56 > Type: $DATA (128-19) Name: $SDS Non-Resident size: 1960040 init_size: 1960040 > 390176 390177 390178 390179 390180 390181 390182 390183 > 390184 390185 390186 390187 390188 390189 390190 390191 > 390192 390193 390194 390195 390196 390197 390198 390199 > 390200 390201 390202 390203 390204 390205 390206 390207 > 390208 390209 390210 390211 390212 390213 390214 390215 > 390216 390217 390218 390219 390220 390221 390222 390223 > 390224 390225 390226 390227 390228 390229 390230 390231 > 390232 390233 390234 390235 390236 390237 390238 390239 > 390240 487278 487279 663659 638527 481604 79306 706903 > 785371 9883 610353 610355 610371 610270 600412 619380 > 596219 569580 699395 717528 368206 370944 482186 489621 > 531746 532353 6076591 6060120 7432272 7403576 7402093 7400205 > 6386639 6424782 6425853 6308043 6542545 6496155 6556126 6624373 > 6899574 6900049 7130039 7125434 7125816 7142050 7140859 7137126 > 7133695 7133209 7132301 7131597 7131365 7131351 7126255 7125530 > 7124837 7124653 7123341 7132208 8324618 8611460 9711057 3778491 > 7299721 7299722 7299723 7299724 7299725 7299726 7299727 7299728 > 7299729 7299730 7299731 7299732 7299733 7299734 7299735 7299736 > 7299737 7299738 7299739 7299740 7299741 7299742 7299743 7299744 > 7299745 7299746 7299747 7299748 7299749 7299750 7299751 7299752 > 7299753 7299754 7299755 7299756 7299757 7299758 7299759 7299760 > 7299761 7299762 7299763 7299764 7299765 7299766 7299767 7299768 > 7299769 7299770 7299771 7299772 7299773 7299774 7299775 7299776 > 7299777 7299778 7299779 7299780 7299781 7299782 7299783 7299784 > 7299785 6678550 4855356 3758831 3758828 3758502 3758435 3757936 > 3757899 3757896 3758437 3764874 3764875 3772231 3381010 3373829 > 3354308 3373799 3066264 3050316 3050323 3639068 3579136 5890982 > 5005380 5391161 744788 744567 742412 2521794 2544838 2544980 > 2545877 2547574 2547572 5537845 5427693 5390572 5281512 5274421 > 5274391 5005604 5005540 4996110 4996004 4919745 4810409 4810410 > 4810411 4806319 4818401 4835951 7299630 7410654 7380435 6777589 > 7518578 3611101 3765721 3765626 3765627 3768851 3744748 3732304 > 3465268 3465269 3465270 3465271 3465272 3465273 3465274 3465275 > 3465276 3465277 3465278 3465279 3465280 3465281 3465282 3465283 > 3465284 3465285 3465286 3465287 3465288 3465289 3465290 3465291 > 3465292 3465293 3465294 3465295 3465296 3465297 3465298 3465299 > 3465300 3465301 3465302 3465303 3465304 3465305 3465306 3465307 > 3465308 3465309 3465310 3465311 3465312 3465313 3465314 3465315 > 3465316 3465317 3465318 3465319 3465320 3465321 3465322 3465323 > 3465324 3465325 3465326 3465327 3465328 3465329 3465330 3465331 > 3465332 3466493 4851942 296156 3420790 3421259 3421441 3421592 > 3421723 3400696 3400697 3400698 3400699 3400700 3400701 3400702 > 3400703 3400704 3400705 3400665 3403006 3403025 3403181 3404423 > 3406406 3406408 3393559 3385169 3379651 3370783 3368782 3368665 > 3366669 3350989 3350453 3350833 3353678 3342048 3341341 3333236 > 3333234 3333000 3331552 3331254 3331241 3330349 3328982 3328912 > 3328910 3328053 3327416 3327413 3327387 3322469 3321112 3311241 > 3304448 3302498 3300538 3300466 3294442 3294089 3291273 3286158 > 3734663 3734664 3734665 3734666 3734667 3734668 3734669 3734670 > 3734671 3734672 3734673 3734674 3734675 3734676 3734677 3734678 > 3734679 3734680 3734681 3734682 3734683 3734684 3734685 3734686 > 3734687 3734688 3734689 3734690 3734691 3734692 3734693 3734694 > 3734695 3734696 3734697 3734698 3734699 3734700 3734701 3734702 > 3734703 3734704 3734705 3734706 3734707 3734708 3734709 3734710 > 3734711 3734712 3734713 3734714 3734715 3734716 3734717 3734718 > 3734719 3734720 3734721 3734722 3734723 3734724 3734725 3734726 > 3734727 3732144 3730026 3730023 3729973 3727747 3727641 3727639 > 3727631 3727124 3727103 3726877 3726430 3726011 3720147 3720217 > 3720248 3722010 3722064 3722169 3725802 3748438 3756656 798823 > 780465 520279 148378 378527 355345 346371 346370 > Type: $INDEX_ALLOCATION (160-20) Name: $SDH Non-Resident size: 262144 init_size: 262144 > 78369 610316 610317 610318 610319 700617 700640 695953 > 690523 692402 1262355 1262344 4855163 4855576 4855596 4853877 > 4858975 3784815 3762045 3764806 3757945 3757507 366474 7299002 > 7299012 7298974 3293690 5912759 5915587 5916360 5917039 3758551 > 3778787 3778785 4850977 4851160 4850782 4851841 4852120 4849070 > 4847515 4845527 4845314 4844785 4844745 4842047 4841786 4841724 > 4837114 4837045 3772243 3761602 378528 616442 618862 756370 > 756371 756372 756373 756374 756375 756376 756377 756378 > Type: $INDEX_ALLOCATION (160-21) Name: $SII Non-Resident size: 249856 init_size: 249856 > 511627 478499 1175609 610352 663398 570363 164501 312115 > 6076594 616643 752222 306845 548567 549279 549339 687886 > 797375 798538 798352 799153 799352 799355 799361 787025 > 755996 1589868 1589999 792974 8310299 8306866 8306894 8305736 > 1583227 1592148 1592149 3532863 3532864 3533327 4017458 4017459 > 4017460 4017461 4017462 4017437 4017505 4017509 4017511 4017272 > 4017261 4017457 4016963 4016617 4016615 4016372 4016962 4017433 > 4017435 4015948 3772658 1245269 1010788 > Type: $BITMAP (176-22) Name: $SDH Resident size: 16 > Type: $BITMAP (176-23) Name: $SII Resident size: 8 > > > > Here is the XML that fiwalk dumps: > > <fileobject> > <filename>Documents and Settings/*******/Local Settings/Temporary Internet Files/Content.IE5/89MRS52V/title_ctr[1].gif</filename> > <partition>1</partition> > <id>162982</id> > <name_type>r</name_type> > <filesize>0</filesize> > <alloc>1</alloc> > <used>1</used> > <inode>9</inode> > <meta_type>1</meta_type> > <mode>365</mode> > <nlink>1</nlink> > <uid>0</uid> > <gid>0</gid> > <mtime>2004-07-12T20:58:51Z</mtime> > <ctime>2004-07-12T20:58:51Z</ctime> > <atime>2004-07-12T20:58:51Z</atime> > <crtime>2004-07-12T20:58:51Z</crtime> > <seq>9</seq> > <byte_runs> > <byte_run file_offset='0' fs_offset='1598160896' img_offset='1598193152' len='266240'/> > <byte_run file_offset='266240' fs_offset='1995890688' img_offset='1995922944' len='8192'/> > <byte_run file_offset='274432' fs_offset='2718347264' img_offset='2718379520' len='4096'/> > <byte_run file_offset='278528' fs_offset='2615406592' img_offset='2615438848' len='4096'/> > <byte_run file_offset='282624' fs_offset='1972649984' img_offset='1972682240' len='4096'/> > <byte_run file_offset='286720' fs_offset='324837376' img_offset='324869632' len='4096'/> > ... > <byte_run file_offset='1953792' fs_offset='1418735616' img_offset='1418767872' len='4096'/> > <byte_run file_offset='1957888' fs_offset='1418731520' img_offset='1418763776' len='2152'/> > </byte_runs> > <hashdigest type='md5'>14e29e689be66747926c29e7b6d8da1c</hashdigest> > <hashdigest type='sha1'>4755f96f4cc83ab7bf8827d361e2d66d1086f0cf</hashdigest> > </fileobject> > > > > > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > > |
|
From: Alex N. <ajn...@cs...> - 2014-02-01 20:11:36
|
Hi Simson,
The NTFS $Secure file is a weird one. Its primary data is stored in the
$DATA attribute with the name $SDS, and $SDH and $SII are two $INDEX
attributes for the same file. I think there are a couple other NTFS
special files that have multiple indices like this; there are definitely
files with non-standard indices.
Normally, the default, unnamed data attribute of a file would supply the
content that Fiwalk would hash. In the case of $Secure, that attribute is
in fact 0-length. (Absent, even, according to your istat.) The real data
of $Secure is in the named data stream "$Secure:$SDS". Fiwalk and DFXML
don't presently have a way to express that aside from making a whole
different fileobject; so, $Secure would be a 0-length file, $Secure:$SDS
would be a 1.9MB (for you) file. Right now, Fiwalk is just quietly hashing
the content of $Secure:$SDS; I forget if there's an explicit check for that
or it's a side-effect of something.
There is further expression weirdness if you want to express $Secure:$SDH
or $Secure:$SII, since those aren't technically content, they're indices.
I've been thinking about how to express those in DFXML for a while, because
the problem also arises for named data streams in general. What's the hash
of a file with multiple data streams? I hope you'll agree that there
should be one hash per stream, instead of one hash per file.
I think the best way to approach this problem is to define a new child
element of a <fileobject>, a named data stream (I think it's abbreviated
NDS in the Carrier book; it's "Alternate" data stream elsewhere). So, in
$Secure's case:
<fileobject>
<filename>$Secure</filename>
<ntfs:nds>
<tsk:icat_id>9-128-11</tsk:icat_id>
<parent_object>
<inode>9</inode>
</parent_object>
<filename>$SDS</filename>
<byte_runs><!--As expected...--></byte_runs>
<hashdigest type="sha1">1234abcd...</hashdigest>
</ntfs:nds>
</fileobject>
The name data stream elements would be a subset of the <fileobject>
elements.
Similarly, there can be elements for the NTFS index root and index
allocation attributes, which would also be children of a fileobject.
<ntfs:index_root>
<tsk:icat_id>9-144-12</tsk:icat_id>
<parent_object>
<inode>9</inode>
</parent_object>
<filename>$SII</filename>
<byte_runs><!--The resident data in the MFT entry's attribute; will take
some engineering to get this right, I think--></byte_runs>
<hashdigest type="sha1">5678...</hashdigest>
</ntfs:index_root>
<ntfs:index_allocation>
<tsk:icat_id>9-160-13</tsk:icat_id>
<parent_object>
<inode>9</inode>
</parent_object>
<filename>$SII</filename>
<byte_runs><!--Of the index clusters--></byte_runs>
<hashdigest type="sha1">9abc...</hashdigest>
</ntfs:index_allocation>
This approach wouldn't require changes to the DFXML schema.
Do you think this solves the problem of extra indices and data streams for
NTFS?
--Alex
On Fri, Jan 31, 2014 at 9:38 PM, Simson Garfinkel <si...@ac...> wrote:
>
> I have an NTFS disk image. There is a file on it that the SleuthKit
> reports has 0 length. But fiwalk reports that it has several byte runs.
> Currently fiwalk is computing the hash of those byte runs and reporting it
> as the file hash, which is the wrong behavior.
>
> Below is the istat, followed by the XML dump and also the fls output. It
> looks to me that there are several attributes; one of them, the $SDS
> attribute, is 1.9MB in length.
>
> Clearly the attributes should not be hashed to determine the file's
> hash, so there is a bug in fiwalk that I need to fix. From the API, how do
> I determine that the data callback is being given an attribute that
> shouldn't be hashed?
>
> Here is the relevant part of the directory list with fls:
>
> r/r * 9-144-16(realloc): title_ctr[1].gif:$SDH
> r/r * 9-144-18(realloc): title_ctr[1].gif:$SII
> r/r * 9-128-19(realloc): title_ctr[1].gif:$SDS
>
>
>
> Here is the istat:
>
> $ istat -o 63 SG1-1064.E01 9-144-16
> MFT Entry Header Values:
> Entry: 9 Sequence: 9
> $LogFile Sequence Number: 586416701932
> Allocated File
> Links: 1
>
> $STANDARD_INFORMATION Attribute Values:
> Flags: Hidden, System
> Owner ID: 0
> Security ID: 257 (S-1-5-32-544)
> Created: 2004-07-12 16:58:51 (EDT)
> File Modified: 2004-07-12 16:58:51 (EDT)
> MFT Modified: 2004-07-12 16:58:51 (EDT)
> Accessed: 2004-07-12 16:58:51 (EDT)
>
> $FILE_NAME Attribute Values:
> Flags:
> Name: $Secure
> Parent MFT Entry: 5 Sequence: 5
> Allocated Size: 0 Actual Size: 0
> Created: 2076-11-29 03:54:34 (EST)
> File Modified: 2076-11-29 03:54:34 (EST)
> MFT Modified: 2076-11-29 03:54:34 (EST)
> Accessed: 2076-11-29 03:54:34 (EST)
>
> $ATTRIBUTE_LIST Attribute Values:
> Type: 16-0 MFT Entry: 9 VCN: 0
> Type: 48-7 MFT Entry: 9 VCN: 0
> Type: 128-0 MFT Entry: 178770 VCN: 0
> Type: 144-16 MFT Entry: 9 VCN: 0
> Type: 144-18 MFT Entry: 9 VCN: 0
> Type: 160-2 MFT Entry: 6781 VCN: 0
> Type: 160-3 MFT Entry: 6781 VCN: 0
> Type: 176-4 MFT Entry: 6781 VCN: 0
> Type: 176-5 MFT Entry: 6781 VCN: 0
>
> Attributes:
> Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
> Type: $ATTRIBUTE_LIST (32-17) Name: N/A Non-Resident size: 344
> init_size: 344
> 549297
> Type: $FILE_NAME (48-7) Name: N/A Resident size: 80
> Type: $INDEX_ROOT (144-16) Name: $SDH Resident size: 56
> Type: $INDEX_ROOT (144-18) Name: $SII Resident size: 56
> Type: $DATA (128-19) Name: $SDS Non-Resident size: 1960040
> init_size: 1960040
> 390176 390177 390178 390179 390180 390181 390182 390183
> 390184 390185 390186 390187 390188 390189 390190 390191
> 390192 390193 390194 390195 390196 390197 390198 390199
> 390200 390201 390202 390203 390204 390205 390206 390207
> 390208 390209 390210 390211 390212 390213 390214 390215
> 390216 390217 390218 390219 390220 390221 390222 390223
> 390224 390225 390226 390227 390228 390229 390230 390231
> 390232 390233 390234 390235 390236 390237 390238 390239
> 390240 487278 487279 663659 638527 481604 79306 706903
> 785371 9883 610353 610355 610371 610270 600412 619380
> 596219 569580 699395 717528 368206 370944 482186 489621
> 531746 532353 6076591 6060120 7432272 7403576 7402093 7400205
> 6386639 6424782 6425853 6308043 6542545 6496155 6556126 6624373
> 6899574 6900049 7130039 7125434 7125816 7142050 7140859 7137126
> 7133695 7133209 7132301 7131597 7131365 7131351 7126255 7125530
> 7124837 7124653 7123341 7132208 8324618 8611460 9711057 3778491
> 7299721 7299722 7299723 7299724 7299725 7299726 7299727 7299728
> 7299729 7299730 7299731 7299732 7299733 7299734 7299735 7299736
> 7299737 7299738 7299739 7299740 7299741 7299742 7299743 7299744
> 7299745 7299746 7299747 7299748 7299749 7299750 7299751 7299752
> 7299753 7299754 7299755 7299756 7299757 7299758 7299759 7299760
> 7299761 7299762 7299763 7299764 7299765 7299766 7299767 7299768
> 7299769 7299770 7299771 7299772 7299773 7299774 7299775 7299776
> 7299777 7299778 7299779 7299780 7299781 7299782 7299783 7299784
> 7299785 6678550 4855356 3758831 3758828 3758502 3758435 3757936
> 3757899 3757896 3758437 3764874 3764875 3772231 3381010 3373829
> 3354308 3373799 3066264 3050316 3050323 3639068 3579136 5890982
> 5005380 5391161 744788 744567 742412 2521794 2544838 2544980
> 2545877 2547574 2547572 5537845 5427693 5390572 5281512 5274421
> 5274391 5005604 5005540 4996110 4996004 4919745 4810409 4810410
> 4810411 4806319 4818401 4835951 7299630 7410654 7380435 6777589
> 7518578 3611101 3765721 3765626 3765627 3768851 3744748 3732304
> 3465268 3465269 3465270 3465271 3465272 3465273 3465274 3465275
> 3465276 3465277 3465278 3465279 3465280 3465281 3465282 3465283
> 3465284 3465285 3465286 3465287 3465288 3465289 3465290 3465291
> 3465292 3465293 3465294 3465295 3465296 3465297 3465298 3465299
> 3465300 3465301 3465302 3465303 3465304 3465305 3465306 3465307
> 3465308 3465309 3465310 3465311 3465312 3465313 3465314 3465315
> 3465316 3465317 3465318 3465319 3465320 3465321 3465322 3465323
> 3465324 3465325 3465326 3465327 3465328 3465329 3465330 3465331
> 3465332 3466493 4851942 296156 3420790 3421259 3421441 3421592
> 3421723 3400696 3400697 3400698 3400699 3400700 3400701 3400702
> 3400703 3400704 3400705 3400665 3403006 3403025 3403181 3404423
> 3406406 3406408 3393559 3385169 3379651 3370783 3368782 3368665
> 3366669 3350989 3350453 3350833 3353678 3342048 3341341 3333236
> 3333234 3333000 3331552 3331254 3331241 3330349 3328982 3328912
> 3328910 3328053 3327416 3327413 3327387 3322469 3321112 3311241
> 3304448 3302498 3300538 3300466 3294442 3294089 3291273 3286158
> 3734663 3734664 3734665 3734666 3734667 3734668 3734669 3734670
> 3734671 3734672 3734673 3734674 3734675 3734676 3734677 3734678
> 3734679 3734680 3734681 3734682 3734683 3734684 3734685 3734686
> 3734687 3734688 3734689 3734690 3734691 3734692 3734693 3734694
> 3734695 3734696 3734697 3734698 3734699 3734700 3734701 3734702
> 3734703 3734704 3734705 3734706 3734707 3734708 3734709 3734710
> 3734711 3734712 3734713 3734714 3734715 3734716 3734717 3734718
> 3734719 3734720 3734721 3734722 3734723 3734724 3734725 3734726
> 3734727 3732144 3730026 3730023 3729973 3727747 3727641 3727639
> 3727631 3727124 3727103 3726877 3726430 3726011 3720147 3720217
> 3720248 3722010 3722064 3722169 3725802 3748438 3756656 798823
> 780465 520279 148378 378527 355345 346371 346370
> Type: $INDEX_ALLOCATION (160-20) Name: $SDH Non-Resident size:
> 262144 init_size: 262144
> 78369 610316 610317 610318 610319 700617 700640 695953
> 690523 692402 1262355 1262344 4855163 4855576 4855596 4853877
> 4858975 3784815 3762045 3764806 3757945 3757507 366474 7299002
> 7299012 7298974 3293690 5912759 5915587 5916360 5917039 3758551
> 3778787 3778785 4850977 4851160 4850782 4851841 4852120 4849070
> 4847515 4845527 4845314 4844785 4844745 4842047 4841786 4841724
> 4837114 4837045 3772243 3761602 378528 616442 618862 756370
> 756371 756372 756373 756374 756375 756376 756377 756378
> Type: $INDEX_ALLOCATION (160-21) Name: $SII Non-Resident size:
> 249856 init_size: 249856
> 511627 478499 1175609 610352 663398 570363 164501 312115
> 6076594 616643 752222 306845 548567 549279 549339 687886
> 797375 798538 798352 799153 799352 799355 799361 787025
> 755996 1589868 1589999 792974 8310299 8306866 8306894 8305736
> 1583227 1592148 1592149 3532863 3532864 3533327 4017458 4017459
> 4017460 4017461 4017462 4017437 4017505 4017509 4017511 4017272
> 4017261 4017457 4016963 4016617 4016615 4016372 4016962 4017433
> 4017435 4015948 3772658 1245269 1010788
> Type: $BITMAP (176-22) Name: $SDH Resident size: 16
> Type: $BITMAP (176-23) Name: $SII Resident size: 8
>
>
>
> Here is the XML that fiwalk dumps:
>
> <fileobject>
> <filename>Documents and Settings/*******/Local Settings/Temporary
> Internet Files/Content.IE5/89MRS52V/title_ctr[1].gif</filename>
> <partition>1</partition>
> <id>162982</id>
> <name_type>r</name_type>
> <filesize>0</filesize>
> <alloc>1</alloc>
> <used>1</used>
> <inode>9</inode>
> <meta_type>1</meta_type>
> <mode>365</mode>
> <nlink>1</nlink>
> <uid>0</uid>
> <gid>0</gid>
> <mtime>2004-07-12T20:58:51Z</mtime>
> <ctime>2004-07-12T20:58:51Z</ctime>
> <atime>2004-07-12T20:58:51Z</atime>
> <crtime>2004-07-12T20:58:51Z</crtime>
> <seq>9</seq>
> <byte_runs>
> <byte_run file_offset='0' fs_offset='1598160896'
> img_offset='1598193152' len='266240'/>
> <byte_run file_offset='266240' fs_offset='1995890688'
> img_offset='1995922944' len='8192'/>
> <byte_run file_offset='274432' fs_offset='2718347264'
> img_offset='2718379520' len='4096'/>
> <byte_run file_offset='278528' fs_offset='2615406592'
> img_offset='2615438848' len='4096'/>
> <byte_run file_offset='282624' fs_offset='1972649984'
> img_offset='1972682240' len='4096'/>
> <byte_run file_offset='286720' fs_offset='324837376'
> img_offset='324869632' len='4096'/>
> ...
> <byte_run file_offset='1953792' fs_offset='1418735616'
> img_offset='1418767872' len='4096'/>
> <byte_run file_offset='1957888' fs_offset='1418731520'
> img_offset='1418763776' len='2152'/>
> </byte_runs>
> <hashdigest type='md5'>14e29e689be66747926c29e7b6d8da1c</hashdigest>
> <hashdigest
> type='sha1'>4755f96f4cc83ab7bf8827d361e2d66d1086f0cf</hashdigest>
> </fileobject>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>
|
|
From: Simson G. <si...@ac...> - 2014-02-01 02:39:27
|
I have an NTFS disk image. There is a file on it that the SleuthKit reports has 0 length. But fiwalk reports that it has several byte runs. Currently fiwalk is computing the hash of those byte runs and reporting it as the file hash, which is the wrong behavior.
Below is the istat, followed by the XML dump and also the fls output. It looks to me that there are several attributes; one of them, the $SDS attribute, is 1.9MB in length.
Clearly the attributes should not be hashed to determine the file's hash, so there is a bug in fiwalk that I need to fix. From the API, how do I determine that the data callback is being given an attribute that shouldn't be hashed?
Here is the relevant part of the directory list with fls:
r/r * 9-144-16(realloc):
title_ctr[1].gif:$SDH
r/r * 9-144-18(realloc): title_ctr[1].gif:$SII
r/r * 9-128-19(realloc): title_ctr[1].gif:$SDS
Here is the istat:
$ istat -o 63 SG1-1064.E01 9-144-16
MFT Entry Header Values:
Entry: 9 Sequence: 9
$LogFile Sequence Number: 586416701932
Allocated File
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags: Hidden, System
Owner ID: 0
Security ID: 257 (S-1-5-32-544)
Created: 2004-07-12 16:58:51 (EDT)
File Modified: 2004-07-12 16:58:51 (EDT)
MFT Modified: 2004-07-12 16:58:51 (EDT)
Accessed: 2004-07-12 16:58:51 (EDT)
$FILE_NAME Attribute Values:
Flags:
Name: $Secure
Parent MFT Entry: 5 Sequence: 5
Allocated Size: 0 Actual Size: 0
Created: 2076-11-29 03:54:34 (EST)
File Modified: 2076-11-29 03:54:34 (EST)
MFT Modified: 2076-11-29 03:54:34 (EST)
Accessed: 2076-11-29 03:54:34 (EST)
$ATTRIBUTE_LIST Attribute Values:
Type: 16-0 MFT Entry: 9
VCN: 0
Type: 48-7 MFT Entry: 9
VCN: 0
Type: 128-0 MFT Entry: 178770
VCN: 0
Type: 144-16 MFT Entry: 9
VCN: 0
Type: 144-18 MFT Entry: 9
VCN: 0
Type: 160-2 MFT Entry: 6781
VCN: 0
Type: 160-3 MFT Entry: 6781
VCN: 0
Type: 176-4 MFT Entry: 6781
VCN: 0
Type: 176-5 MFT Entry: 6781
VCN: 0
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $ATTRIBUTE_LIST (32-17) Name: N/A Non-Resident size: 344 init_size: 344
549297
Type: $FILE_NAME (48-7) Name: N/A Resident size: 80
Type: $INDEX_ROOT (144-16) Name: $SDH Resident size: 56
Type: $INDEX_ROOT (144-18) Name: $SII Resident size: 56
Type: $DATA (128-19) Name: $SDS Non-Resident size: 1960040 init_size: 1960040
390176 390177 390178 390179 390180 390181 390182 390183
390184 390185 390186 390187 390188 390189 390190 390191
390192 390193 390194 390195 390196 390197 390198 390199
390200 390201 390202 390203 390204 390205 390206 390207
390208 390209 390210 390211 390212 390213 390214 390215
390216 390217 390218 390219 390220 390221 390222 390223
390224 390225 390226 390227 390228 390229 390230 390231
390232 390233 390234 390235 390236 390237 390238 390239
390240 487278 487279 663659 638527 481604 79306 706903
785371 9883 610353 610355 610371 610270 600412 619380
596219 569580 699395 717528 368206 370944 482186 489621
531746 532353 6076591 6060120 7432272 7403576 7402093 7400205
6386639 6424782 6425853 6308043 6542545 6496155 6556126 6624373
6899574 6900049 7130039 7125434 7125816 7142050 7140859 7137126
7133695 7133209 7132301 7131597 7131365 7131351 7126255 7125530
7124837 7124653 7123341 7132208 8324618 8611460 9711057 3778491
7299721 7299722 7299723 7299724 7299725 7299726 7299727 7299728
7299729 7299730 7299731 7299732 7299733 7299734 7299735 7299736
7299737 7299738 7299739 7299740 7299741 7299742 7299743 7299744
7299745 7299746 7299747 7299748 7299749 7299750 7299751 7299752
7299753 7299754 7299755 7299756 7299757 7299758 7299759 7299760
7299761 7299762 7299763 7299764 7299765 7299766 7299767 7299768
7299769 7299770 7299771 7299772 7299773 7299774 7299775 7299776
7299777 7299778 7299779 7299780 7299781 7299782 7299783 7299784
7299785 6678550 4855356 3758831 3758828 3758502 3758435 3757936
3757899 3757896 3758437 3764874 3764875 3772231 3381010 3373829
3354308 3373799 3066264 3050316 3050323 3639068 3579136 5890982
5005380 5391161 744788 744567 742412 2521794 2544838 2544980
2545877 2547574 2547572 5537845 5427693 5390572 5281512 5274421
5274391 5005604 5005540 4996110 4996004 4919745 4810409 4810410
4810411 4806319 4818401 4835951 7299630 7410654 7380435 6777589
7518578 3611101 3765721 3765626 3765627 3768851 3744748 3732304
3465268 3465269 3465270 3465271 3465272 3465273 3465274 3465275
3465276 3465277 3465278 3465279 3465280 3465281 3465282 3465283
3465284 3465285 3465286 3465287 3465288 3465289 3465290 3465291
3465292 3465293 3465294 3465295 3465296 3465297 3465298 3465299
3465300 3465301 3465302 3465303 3465304 3465305 3465306 3465307
3465308 3465309 3465310 3465311 3465312 3465313 3465314 3465315
3465316 3465317 3465318 3465319 3465320 3465321 3465322 3465323
3465324 3465325 3465326 3465327 3465328 3465329 3465330 3465331
3465332 3466493 4851942 296156 3420790 3421259 3421441 3421592
3421723 3400696 3400697 3400698 3400699 3400700 3400701 3400702
3400703 3400704 3400705 3400665 3403006 3403025 3403181 3404423
3406406 3406408 3393559 3385169 3379651 3370783 3368782 3368665
3366669 3350989 3350453 3350833 3353678 3342048 3341341 3333236
3333234 3333000 3331552 3331254 3331241 3330349 3328982 3328912
3328910 3328053 3327416 3327413 3327387 3322469 3321112 3311241
3304448 3302498 3300538 3300466 3294442 3294089 3291273 3286158
3734663 3734664 3734665 3734666 3734667 3734668 3734669 3734670
3734671 3734672 3734673 3734674 3734675 3734676 3734677 3734678
3734679 3734680 3734681 3734682 3734683 3734684 3734685 3734686
3734687 3734688 3734689 3734690 3734691 3734692 3734693 3734694
3734695 3734696 3734697 3734698 3734699 3734700 3734701 3734702
3734703 3734704 3734705 3734706 3734707 3734708 3734709 3734710
3734711 3734712 3734713 3734714 3734715 3734716 3734717 3734718
3734719 3734720 3734721 3734722 3734723 3734724 3734725 3734726
3734727 3732144 3730026 3730023 3729973 3727747 3727641 3727639
3727631 3727124 3727103 3726877 3726430 3726011 3720147 3720217
3720248 3722010 3722064 3722169 3725802 3748438 3756656 798823
780465 520279 148378 378527 355345 346371 346370
Type: $INDEX_ALLOCATION (160-20) Name: $SDH Non-Resident size: 262144 init_size: 262144
78369 610316 610317 610318 610319 700617 700640 695953
690523 692402 1262355 1262344 4855163 4855576 4855596 4853877
4858975 3784815 3762045 3764806 3757945 3757507 366474 7299002
7299012 7298974 3293690 5912759 5915587 5916360 5917039 3758551
3778787 3778785 4850977 4851160 4850782 4851841 4852120 4849070
4847515 4845527 4845314 4844785 4844745 4842047 4841786 4841724
4837114 4837045 3772243 3761602 378528 616442 618862 756370
756371 756372 756373 756374 756375 756376 756377 756378
Type: $INDEX_ALLOCATION (160-21) Name: $SII Non-Resident size: 249856 init_size: 249856
511627 478499 1175609 610352 663398 570363 164501 312115
6076594 616643 752222 306845 548567 549279 549339 687886
797375 798538 798352 799153 799352 799355 799361 787025
755996 1589868 1589999 792974 8310299 8306866 8306894 8305736
1583227 1592148 1592149 3532863 3532864 3533327 4017458 4017459
4017460 4017461 4017462 4017437 4017505 4017509 4017511 4017272
4017261 4017457 4016963 4016617 4016615 4016372 4016962 4017433
4017435 4015948 3772658 1245269 1010788
Type: $BITMAP (176-22) Name: $SDH Resident size: 16
Type: $BITMAP (176-23) Name: $SII Resident size: 8
Here is the XML that fiwalk dumps:
<fileobject>
<filename>Documents and Settings/*******/Local Settings/Temporary Internet Files/Content.IE5/89MRS52V/title_ctr[1].gif</filename>
<partition>1</partition>
<id>162982</id>
<name_type>r</name_type>
<filesize>0</filesize>
<alloc>1</alloc>
<used>1</used>
<inode>9</inode>
<meta_type>1</meta_type>
<mode>365</mode>
<nlink>1</nlink>
<uid>0</uid>
<gid>0</gid>
<mtime>2004-07-12T20:58:51Z</mtime>
<ctime>2004-07-12T20:58:51Z</ctime>
<atime>2004-07-12T20:58:51Z</atime>
<crtime>2004-07-12T20:58:51Z</crtime>
<seq>9</seq>
<byte_runs>
<byte_run file_offset='0' fs_offset='1598160896' img_offset='1598193152' len='266240'/>
<byte_run file_offset='266240' fs_offset='1995890688' img_offset='1995922944' len='8192'/>
<byte_run file_offset='274432' fs_offset='2718347264' img_offset='2718379520' len='4096'/>
<byte_run file_offset='278528' fs_offset='2615406592' img_offset='2615438848' len='4096'/>
<byte_run file_offset='282624' fs_offset='1972649984' img_offset='1972682240' len='4096'/>
<byte_run file_offset='286720' fs_offset='324837376' img_offset='324869632' len='4096'/>
...
<byte_run file_offset='1953792' fs_offset='1418735616' img_offset='1418767872' len='4096'/>
<byte_run file_offset='1957888' fs_offset='1418731520' img_offset='1418763776' len='2152'/>
</byte_runs>
<hashdigest type='md5'>14e29e689be66747926c29e7b6d8da1c</hashdigest>
<hashdigest type='sha1'>4755f96f4cc83ab7bf8827d361e2d66d1086f0cf</hashdigest>
</fileobject>
|
|
From: Brian C. <ca...@sl...> - 2014-01-30 14:27:20
|
No, Ext3 deleted files do not retain the link between the name and the metadata. So, that is as good as you'll get with TSK. Other tools use the journal / log to recover recently deleted info, but we've never integrated that into TSK. On Jan 29, 2014, at 6:15 PM, Aribird <ari...@gm...> wrote: > I have a bunch of files under $OrphanFiles/ and I wonder if there is any way > to determine the original directory that contained each of them. > This is a EXT3 image . > > fls "image" "inode of deleted folder or file" shows nothing in the > terminal. > Any idea in how to proceed from here ??? > Thanks in advance for any help... > > root@arielc-helix:/home/arielc/Desktop# fls -rpd extfs.dd > d/d * 10084: dir1/index_files > r/r * 22179: dir2/dir3/test1.txt > d/d * 18145(realloc): dir4 > r/r * 12102(realloc): .Trash-999/info/dir4.trashinfo.J3GPPV > r/r * 22179: .Trash-999/expunged/3021210733 > d/d * 10085: $OrphanFiles/OrphanFile-10085 > r/r * 10086: $OrphanFiles/OrphanFile-10086 > r/r * 10087: $OrphanFiles/OrphanFile-10087 > r/r * 10088: $OrphanFiles/OrphanFile-10088 > r/r * 10089: $OrphanFiles/OrphanFile-10089 > r/r * 10090: $OrphanFiles/OrphanFile-10090 > r/r * 10091: $OrphanFiles/OrphanFile-10091 > r/r * 10092: $OrphanFiles/OrphanFile-10092 > r/r * 10093: $OrphanFiles/OrphanFile-10093 > r/r * 10094: $OrphanFiles/OrphanFile-10094 > r/r * 10095: $OrphanFiles/OrphanFile-10095 > r/r * 10096: $OrphanFiles/OrphanFile-10096 > r/r * 10097: $OrphanFiles/OrphanFile-10097 > r/r * 10098: $OrphanFiles/OrphanFile-10098 > r/r * 10099: $OrphanFiles/OrphanFile-10099 > r/r * 10100: $OrphanFiles/OrphanFile-10100 > r/r * 10101: $OrphanFiles/OrphanFile-10101 > r/r * 10102: $OrphanFiles/OrphanFile-10102 > r/r * 10103: $OrphanFiles/OrphanFile-10103 > r/r * 10104: $OrphanFiles/OrphanFile-10104 > r/r * 10105: $OrphanFiles/OrphanFile-10105 > r/r * 10106: $OrphanFiles/OrphanFile-10106 > r/r * 10107: $OrphanFiles/OrphanFile-10107 > r/r * 10108: $OrphanFiles/OrphanFile-10108 > r/r * 10109: $OrphanFiles/OrphanFile-10109 > r/r * 10110: $OrphanFiles/OrphanFile-10110 > r/r * 10111: $OrphanFiles/OrphanFile-10111 > r/r * 10112: $OrphanFiles/OrphanFile-10112 > r/r * 10113: $OrphanFiles/OrphanFile-10113 > r/r * 10115: $OrphanFiles/OrphanFile-10115 > r/r * 10116: $OrphanFiles/OrphanFile-10116 > r/r * 12101: $OrphanFiles/OrphanFile-12101 > root@arielc-helix:/home/arielc/Desktop# > > > > > -- > View this message in context: http://filesystems.996266.n3.nabble.com/Find-deleted-folder-for-OrphanFiles-tp8409.html > Sent from the sleuthkit-users mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
|
From: Aribird <ari...@gm...> - 2014-01-29 23:16:01
|
I have a bunch of files under $OrphanFiles/ and I wonder if there is any way to determine the original directory that contained each of them. This is a EXT3 image . fls "image" "inode of deleted folder or file" shows nothing in the terminal. Any idea in how to proceed from here ??? Thanks in advance for any help... root@arielc-helix:/home/arielc/Desktop# fls -rpd extfs.dd d/d * 10084: dir1/index_files r/r * 22179: dir2/dir3/test1.txt d/d * 18145(realloc): dir4 r/r * 12102(realloc): .Trash-999/info/dir4.trashinfo.J3GPPV r/r * 22179: .Trash-999/expunged/3021210733 d/d * 10085: $OrphanFiles/OrphanFile-10085 r/r * 10086: $OrphanFiles/OrphanFile-10086 r/r * 10087: $OrphanFiles/OrphanFile-10087 r/r * 10088: $OrphanFiles/OrphanFile-10088 r/r * 10089: $OrphanFiles/OrphanFile-10089 r/r * 10090: $OrphanFiles/OrphanFile-10090 r/r * 10091: $OrphanFiles/OrphanFile-10091 r/r * 10092: $OrphanFiles/OrphanFile-10092 r/r * 10093: $OrphanFiles/OrphanFile-10093 r/r * 10094: $OrphanFiles/OrphanFile-10094 r/r * 10095: $OrphanFiles/OrphanFile-10095 r/r * 10096: $OrphanFiles/OrphanFile-10096 r/r * 10097: $OrphanFiles/OrphanFile-10097 r/r * 10098: $OrphanFiles/OrphanFile-10098 r/r * 10099: $OrphanFiles/OrphanFile-10099 r/r * 10100: $OrphanFiles/OrphanFile-10100 r/r * 10101: $OrphanFiles/OrphanFile-10101 r/r * 10102: $OrphanFiles/OrphanFile-10102 r/r * 10103: $OrphanFiles/OrphanFile-10103 r/r * 10104: $OrphanFiles/OrphanFile-10104 r/r * 10105: $OrphanFiles/OrphanFile-10105 r/r * 10106: $OrphanFiles/OrphanFile-10106 r/r * 10107: $OrphanFiles/OrphanFile-10107 r/r * 10108: $OrphanFiles/OrphanFile-10108 r/r * 10109: $OrphanFiles/OrphanFile-10109 r/r * 10110: $OrphanFiles/OrphanFile-10110 r/r * 10111: $OrphanFiles/OrphanFile-10111 r/r * 10112: $OrphanFiles/OrphanFile-10112 r/r * 10113: $OrphanFiles/OrphanFile-10113 r/r * 10115: $OrphanFiles/OrphanFile-10115 r/r * 10116: $OrphanFiles/OrphanFile-10116 r/r * 12101: $OrphanFiles/OrphanFile-12101 root@arielc-helix:/home/arielc/Desktop# -- View this message in context: http://filesystems.996266.n3.nabble.com/Find-deleted-folder-for-OrphanFiles-tp8409.html Sent from the sleuthkit-users mailing list archive at Nabble.com. |
|
From: Adam D. Ph.D., P.E. <de...@al...> - 2014-01-29 19:46:36
|
The “kind soul” was me. After, I got some of the answers below, I was able to get it working. Thank you for the help. --Adam On Jan 29, 2014, at 2:38 PM, Alex Nelson <ajn...@cs...> wrote: > Some kind soul just updated libewf in MacPorts. > > https://trac.macports.org/ticket/42297 > > --Alex > > > > > On Wed, Jan 29, 2014 at 9:16 AM, Simson Garfinkel <si...@ac...> wrote: > bulk_extractor has #ifdef’s and stuff in configure.ac that lets it work with the old libewf and the new libewf calling conventions. Unfortunately it’s a lot of work due to some parameter changes. (the functions didn’t change name, but the calling sequences did.) > > > On Jan 29, 2014, at 12:25 AM, Stefan Kelm <sk...@bf...> wrote: > > >> Meanwhile, MacPorts could really, really use an update for libewf, and they > >> aren't the only package manager I've seen with that problem. > > > > Yeah, same over here. Had been running the (ancient) Debian libewf > > packages and TSK 4.1.3 wouldn't build. Purged those packages, > > installed the most recent libewf sources, TSK now works fine again. > > > > Cheers, > > > > Stefan. > > > > -- > > Stefan Kelm <sk...@bf...> > > BFK edv-consulting GmbH http://www.bfk.de/ > > Kriegsstrasse 100 Tel: +49-721-96201-1 > > D-76133 Karlsruhe Fax: +49-721-96201-99 > > > > ------------------------------------------------------------------------------ > > WatchGuard Dimension instantly turns raw network data into actionable > > security intelligence. It gives you real-time visual feedback on key > > security issues and trends. Skip the complicated setup - simply import > > a virtual appliance and go from zero to informed in seconds. > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > > _______________________________________________ > > sleuthkit-users mailing list > > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > > http://www.sleuthkit.org > > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk_______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
|
From: Alex N. <ajn...@cs...> - 2014-01-29 19:38:36
|
Some kind soul just updated libewf in MacPorts. https://trac.macports.org/ticket/42297 --Alex On Wed, Jan 29, 2014 at 9:16 AM, Simson Garfinkel <si...@ac...> wrote: > bulk_extractor has #ifdef's and stuff in configure.ac that lets it work > with the old libewf and the new libewf calling conventions. Unfortunately > it's a lot of work due to some parameter changes. (the functions didn't > change name, but the calling sequences did.) > > > On Jan 29, 2014, at 12:25 AM, Stefan Kelm <sk...@bf...> wrote: > > >> Meanwhile, MacPorts could really, really use an update for libewf, and > they > >> aren't the only package manager I've seen with that problem. > > > > Yeah, same over here. Had been running the (ancient) Debian libewf > > packages and TSK 4.1.3 wouldn't build. Purged those packages, > > installed the most recent libewf sources, TSK now works fine again. > > > > Cheers, > > > > Stefan. > > > > -- > > Stefan Kelm <sk...@bf...> > > BFK edv-consulting GmbH http://www.bfk.de/ > > Kriegsstrasse 100 Tel: +49-721-96201-1 > > D-76133 Karlsruhe Fax: +49-721-96201-99 > > > > > ------------------------------------------------------------------------------ > > WatchGuard Dimension instantly turns raw network data into actionable > > security intelligence. It gives you real-time visual feedback on key > > security issues and trends. Skip the complicated setup - simply import > > a virtual appliance and go from zero to informed in seconds. > > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > > _______________________________________________ > > sleuthkit-users mailing list > > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > > http://www.sleuthkit.org > > > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
|
From: Simson G. <si...@ac...> - 2014-01-29 14:16:33
|
bulk_extractor has #ifdef’s and stuff in configure.ac that lets it work with the old libewf and the new libewf calling conventions. Unfortunately it’s a lot of work due to some parameter changes. (the functions didn’t change name, but the calling sequences did.) On Jan 29, 2014, at 12:25 AM, Stefan Kelm <sk...@bf...> wrote: >> Meanwhile, MacPorts could really, really use an update for libewf, and they >> aren't the only package manager I've seen with that problem. > > Yeah, same over here. Had been running the (ancient) Debian libewf > packages and TSK 4.1.3 wouldn't build. Purged those packages, > installed the most recent libewf sources, TSK now works fine again. > > Cheers, > > Stefan. > > -- > Stefan Kelm <sk...@bf...> > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstrasse 100 Tel: +49-721-96201-1 > D-76133 Karlsruhe Fax: +49-721-96201-99 > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
|
From: Stefan K. <sk...@bf...> - 2014-01-29 08:26:00
|
> Meanwhile, MacPorts could really, really use an update for libewf, and they > aren't the only package manager I've seen with that problem. Yeah, same over here. Had been running the (ancient) Debian libewf packages and TSK 4.1.3 wouldn't build. Purged those packages, installed the most recent libewf sources, TSK now works fine again. Cheers, Stefan. -- Stefan Kelm <sk...@bf...> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 |
|
From: Alex N. <ajn...@cs...> - 2014-01-28 17:24:35
|
The "Downloads" link on the Google Code page---left, bottom---links to the recent versions. 20131230 is up to date; hopefully that works for you. I haven't tried building 4.1.3 yet. Meanwhile, MacPorts could really, really use an update for libewf, and they aren't the only package manager I've seen with that problem. However, it's a volunteer effort, and I haven't found the time to volunteer myself, so I'll just leave this complaint sitting here and not fan it any further... --Alex On Tue, Jan 28, 2014 at 10:32 AM, Adam Dershowitz Ph.D., P.E. < de...@al...> wrote: > I have libewf installed and just tried to upgrade from 4.1.2 to 4.1.3 but > I am getting a link error: > > :info:build Undefined symbols for architecture x86_64: > :info:build "_libewf_glob_free", referenced from: > :info:build _ewf_image_close in libtsk.a(ewf.o) > > I am on a Mac, and using macports, so the "current" libewf is 20100226. > The TSK web site points to http://sourceforge.net/projects/libewf/ for > the code. But that site then points to http://code.google.com/p/libewf/ > and there doesn't seem to be any source code there at all. > Is there a site where libewf, that is compatible with TSK, is available? > Does TSK no longer work with ewf? > > Thanks, > > --Adam > > > > > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > > |
|
From: Lehr, J. <jl...@sl...> - 2014-01-28 17:11:14
|
I have built TSK 4.1.3 successfully on Linux using the latest Libewf. The projected is now located on Google Code at https://code.google.com/p/libewf/. --------------------------------- John Lehr Evidence Technician San Luis Obispo Police Department ________________________________ From: Adam Dershowitz Ph.D., P.E. [de...@al...] Sent: Tuesday, January 28, 2014 7:32 To: sle...@li... Subject: [sleuthkit-users] TSK 4.1.3 won't build with libewf I have libewf installed and just tried to upgrade from 4.1.2 to 4.1.3 but I am getting a link error: :info:build Undefined symbols for architecture x86_64: :info:build "_libewf_glob_free", referenced from: :info:build _ewf_image_close in libtsk.a(ewf.o) I am on a Mac, and using macports, so the “current” libewf is 20100226. The TSK web site points to http://sourceforge.net/projects/libewf/ for the code. But that site then points to http://code.google.com/p/libewf/ and there doesn’t seem to be any source code there at all. Is there a site where libewf, that is compatible with TSK, is available? Does TSK no longer work with ewf? Thanks, --Adam |
|
From: Adam D. Ph.D., P.E. <de...@al...> - 2014-01-28 16:32:44
|
I have libewf installed and just tried to upgrade from 4.1.2 to 4.1.3 but I am getting a link error: :info:build Undefined symbols for architecture x86_64: :info:build "_libewf_glob_free", referenced from: :info:build _ewf_image_close in libtsk.a(ewf.o) I am on a Mac, and using macports, so the “current” libewf is 20100226. The TSK web site points to http://sourceforge.net/projects/libewf/ for the code. But that site then points to http://code.google.com/p/libewf/ and there doesn’t seem to be any source code there at all. Is there a site where libewf, that is compatible with TSK, is available? Does TSK no longer work with ewf? Thanks, --Adam |
|
From: Brian C. <ca...@sl...> - 2014-01-27 04:32:45
|
4.1.3 is on the website. Bug fixes and minor feature enhancements. Autopsy release should be out tomorrow or Tuesday.
http://sleuthkit.org/sleuthkit/download.php
We're shooting for a 4.2 release in Feb/Mar with ExFAT, new hash database support, and new database schema. It's on the 'develop' branch on github if you want to play with it.
thanks,
brian
Updates in 4.1.3:
- fixed bug that could crash UFS/ExtX in inode_lookup.
- More bounds checking in ISO9660 code
- Image layer bounds checking
- Update version of SQLITE-JDBC
- changed how java loads navite libraries
- Config file for YAFFS2 spare area
- New method in image layer to return names
- Yaffs2 cleanup.
- Escape all strings in SQLite database
- SQlite code uses NTTFS sequence number to match parent IDs
|
|
From: s. <19...@qq...> - 2014-01-22 01:33:32
|
Hi Jason, It's really great! ------------------ Original ------------------ From: "Jason Letourneau";<jle...@ba...>; Date: Wed, Jan 22, 2014 04:54 AM To: "steven"<19...@qq...>; Cc: "sleuthkit-users"<sle...@li...>; Subject: Re: [sleuthkit-users] can't remove the item in the tag Hi Steven - We're tracking this issue here now it looks like: https://github.com/sleuthkit/autopsy/issues/435 We've got the code to do this in the develop branch, and plan to release in the next couple of months along with a bunch of additional features. Jason ------------------------------------------------ Jason Letourneau Product Manager, Digital Forensics Basis Technology jle...@ba... 617-386-2000 ext. 152 On Jan 17, 2014, at 7:41 AM, steven <19...@qq...> wrote: Hi, it seems the items in the tag such as bookmark can't be removed in autopsy3.0.8. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk_______________________________________________ sleuthkit-users mailing list https://lists.sourceforge.net/lists/listinfo/sleuthkit-users http://www.sleuthkit.org |
|
From: Jason L. <jle...@ba...> - 2014-01-21 21:24:33
|
Hi Steven - We're tracking this issue here now it looks like: https://github.com/sleuthkit/autopsy/issues/435 We've got the code to do this in the develop branch, and plan to release in the next couple of months along with a bunch of additional features. Jason ------------------------------------------------ Jason Letourneau Product Manager, Digital Forensics Basis Technology jle...@ba... 617-386-2000 ext. 152 On Jan 17, 2014, at 7:41 AM, steven <19...@qq...> wrote: > Hi, it seems the items in the tag such as bookmark can't be removed in autopsy3.0.8. > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk_______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
|
From: Brian C. <ca...@sl...> - 2014-01-21 18:07:24
|
Basis Technology has extended the Autopsy Module writing contest that we organized around OSDFCon to a semester-based student competition.
http://www.basistech.com/digital-forensics/autopsy-student-development-contest/
If you a student and need a class project (or a side project), check it out. If you are a teacher and need some projects for your students, check it out.
Cash prizes for the top three teams. Submissions due June 27, 2014. We'll do another non-student competition for OSDFCon (details coming soon) and another student competition next semester.
thanks,
brian
|
|
From: s. <19...@qq...> - 2014-01-17 12:42:05
|
Hi, it seems the items in the tag such as bookmark can't be removed in autopsy3.0.8. |
|
From: Nanni B. <dig...@gm...> - 2014-01-17 09:07:37
|
CAINE 5.0 "Blackhole" is out! Kernel 3.8.0-35 Based on Ubuntu 12.04.3 64BIT - UEFI/SECURE BOOT Ready! Caine 5.0 on pendrive can boot on Uefi/Uefi+secure boot/Legacy Bios/Bios. Caine 5.0 on DVD can boot on Legacy Bios/Bios. SystemBack is the new installer. Windows side is Win-Ufo. http://www.caine-live.net/ -- Dr. Nanni Bassetti http://www.nannibassetti.com CAINE project manager - http://www.caine-live.net |
|
From: Derrick K. <dk...@gm...> - 2014-01-13 23:43:08
|
Hello. Just an FYI for anyone who might be using SaltStack to deploy software across their environments. We pushed up our deployment .sls files for Autopsy, bulk_extractor, and some other forensic software, to the upstream Salt Windows repository (https://github.com/saltstack/salt-winrepo). It works well for getting Autopsy installed and running on all of our forensic machines. Perhaps somebody else will benefit from it. Derrick |
|
From: Stefan K. <sk...@bf...> - 2014-01-10 08:39:08
|
Philippe, I think you need to try .*top.* instead of ".*top.*" as the regex to search for. Cheers, Stefan. -- Stefan Kelm <sk...@bf...> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 |
|
From: Raphaël R. <ml-...@sy...> - 2013-12-23 10:29:01
|
On 20/12/2013 07:56, Kalin KOZHUHAROV wrote: > Hello, > > I remember being able to do this a long time ago, but apparently not any more... > > Any hints on how to compile it statically, so that I can just send fls > or some other binary to a remote machine? > > # git clone https://github.com/sleuthkit/sleuthkit > # ./bootstrap > # ./configure --prefix=/tmp/test --enable-static --disable-shared > --disable-java --without-afflib --without-libewf > # make -j4 > # make install Hello, I managed to do it in an ugly way after trying the "correct" way, but the build system is very rigid and complex. So (works on a 64bit debian Sid, you will need to adjust paths): 1) Compile normally 2) cd tools/fstools/ 3) make clean 4) make 2>&1 > log 5) egrep '^g++' log | sed -r -e 's/-o ([a-z]+).o/-o \1/' -e 's/++ /++ -static /' -e 's/-c //' -e 's;$; ../../tsk/.libs/libtsk.a /usr/lib/x86_64-linux-gnu/libz.a /usr/lib/x86_64-linux-gnu/libpthread.a;' | tee static.sh 6) bash static.sh Yes, this is ugly but it works :) Regards, Raphaël Rigo |
|
From: farmer d. <far...@ya...> - 2013-12-21 03:44:14
|
Kalin, Been a while since I've statically linked The Sleuth Kit. But years back you could do it by setting your environment correctly, via; 1) untar the archive 2) change into The Sleuth Kit directory 3) issue: make CC='gcc -static' Depending upon your Linux environment prior to executing the above you may end up having to tweak any number of settings, including: CFLAGS=-static LDFLAGS=-static ./configure --enable-static --disable shared --disable-nls etc. make LDFLAGS=-all-static make CC='gcc -static' ETC. But remember, even if you cannot get it statically linked you can set your load path to be your trusted libraries so that your known good libraries are used. Cheers! farmerdude -------------------------------------------- On Fri, 12/20/13, Kalin KOZHUHAROV <me....@gm...> wrote: Subject: Re: [sleuthkit-users] statically compiling sleuthkit To: "Simson Garfinkel" <si...@ac...> Cc: "Brian Carrier" <ca...@sl...>, sle...@li... Date: Friday, December 20, 2013, 8:53 PM Hello Simson, On Dec 21, 2013 12:06 AM, "Simson Garfinkel" <si...@ac...> wrote: > You sent us the commands that you sent but not the output after they ran. > Yes, I intentionally did that, will post more later. > My guess is that the configure script won’t make a static linked executable unless you have all of the necessary static libraries installed on your system. > I am almost certain I don't have all those statically linked, great guess! I am willing to spend some time on fixing this, but is there a simple fix of the Makefiles so that build fails if one of them is missing? Then I can rinse-n-repeat until I have all deps cleared. > Can you verify that you have libz.a, libdl.a, libstdc++.a, libgcc_s.a, libc.a, and the others? There may be version number issues and 32/64 bit issues as well. > Alternatively, is there a programmatic way to list all those dependencies? Kalin. -----Inline Attachment Follows----- ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk -----Inline Attachment Follows----- _______________________________________________ sleuthkit-users mailing list https://lists.sourceforge.net/lists/listinfo/sleuthkit-users http://www.sleuthkit.org |
|
From: Kalin K. <me....@gm...> - 2013-12-21 01:53:32
|
Hello Simson, On Dec 21, 2013 12:06 AM, "Simson Garfinkel" <si...@ac...> wrote: > You sent us the commands that you sent but not the output after they ran. > Yes, I intentionally did that, will post more later. > My guess is that the configure script won’t make a static linked executable unless you have all of the necessary static libraries installed on your system. > I am almost certain I don't have all those statically linked, great guess! I am willing to spend some time on fixing this, but is there a simple fix of the Makefiles so that build fails if one of them is missing? Then I can rinse-n-repeat until I have all deps cleared. > Can you verify that you have libz.a, libdl.a, libstdc++.a, libgcc_s.a, libc.a, and the others? There may be version number issues and 32/64 bit issues as well. > Alternatively, is there a programmatic way to list all those dependencies? Kalin. |
|
From: Simson G. <si...@ac...> - 2013-12-20 15:06:21
|
Kalin, You sent us the commands that you sent but not the output after they ran. My guess is that the configure script won’t make a static linked executable unless you have all of the necessary static libraries installed on your syst em. Can you verify that you have libz.a, libdl.a, libstdc++.a, libgcc_s.a, libc.a, and the others? There may be version number issues and 32/64 bit issues as well. Simson On Dec 20, 2013, at 9:27 AM, Brian Carrier <ca...@sl...> wrote: > Hmm, seems like the feature expansion over the years has made this less possible. > - libz is needed by HFS. You can probably use without-zlib to try to remove that dependency. > - libdl is needed by sqlite (which is part of the library that used to be entirely static). > - libpthread is needed for lock protection. > - ... > > Someone will need to spend some time isolating these types of features if we want to get back back to a purely static version... > > > > > > On Dec 20, 2013, at 1:56 AM, Kalin KOZHUHAROV <me....@gm...> wrote: > >> Hello, >> >> I remember being able to do this a long time ago, but apparently not any more... >> >> Any hints on how to compile it statically, so that I can just send fls >> or some other binary to a remote machine? >> >> # git clone https://github.com/sleuthkit/sleuthkit >> # ./bootstrap >> # ./configure --prefix=/tmp/test --enable-static --disable-shared >> --disable-java --without-afflib --without-libewf >> # make -j4 >> # make install >> >> However >> >> # file /tmp/test/bin/fls >> /tmp/test/bin/fls: ELF 32-bit LSB executable, Intel 80386, version 1 >> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, >> not stripped >> # ldd /tmp/test/bin/fls >> linux-gate.so.1 (0xf7732000) >> libz.so.1 => /lib/libz.so.1 (0xf7714000) >> libdl.so.2 => /lib/libdl.so.2 (0xf7710000) >> libstdc++.so.6 => >> /usr/lib/gcc/i686-pc-linux-gnu/4.7.3/libstdc++.so.6 (0xf7624000) >> libm.so.6 => /lib/libm.so.6 (0xf75fd000) >> libgcc_s.so.1 => >> /usr/lib/gcc/i686-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0xf75e0000) >> libpthread.so.0 => /lib/libpthread.so.0 (0xf75c6000) >> libc.so.6 => /lib/libc.so.6 (0xf743c000) >> /lib/ld-linux.so.2 (0xf7733000) >> >> Alternatively, is there a public DL link with statically linked tools? >> >> Cheers, >> Kalin. >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> sleuthkit-users mailing list >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >> http://www.sleuthkit.org > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
|
From: Brian C. <ca...@sl...> - 2013-12-20 14:28:45
|
Hi Philippe, What keyword are you searching for and what do you expect it to match on? The current search is exact match, meaning that if you search for "top" it will only find instances of "top" and not "autopsy". We're working on changing the UI to make substrings easier. Currently, you need to choose the keyword as "regular expression" and use the term ".*top.*" in that case. Does that solve the scenario you are talking about or are you missing an exact match? thanks, brian On Dec 13, 2013, at 5:11 AM, Philippe Jourdin <pjo...@pa...> wrote: > Hello, > > I have generated a DD file on a Ubuntu 10.04 VM. (dd if=/dev/sdb1 of=/usr3/essai3.dd) > /dev/sdb1 is EXT3. > > I get 1G file. Then I transfer (Binary copy) it to my Windows XP(SP3) disk. > > When Autopsy ingest this file, there is no Keyword hits detected although : > > - I KNOW there is a witness non-deleted file which contains a keyword I record in Autopsy Keyword Hits. > - I could list and display my witness file on Autopsy Data Sources tree > > Is somebody known this problem ? > > Many thanks > Regards > > Philippe JOURDIN > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org |
38 messages has been excluded from this view by a project administrator.
