Re: [sleuthkit-users] recover $orphaned files
Brought to you by:
carrier
Menu
▾
▴
Re: [sleuthkit-users] recover $orphaned files
|
From: Jason W. <jwr...@gm...> - 2014-02-25 12:26:16
|
Sorry for the redundancy, I see Atila basically said the same thing. On Tue, Feb 25, 2014 at 7:25 AM, Jason Wright <jwr...@gm...> wrote: > Ewaldo, > > The original icat states a filesize of 24064, which is 47 sectors. Drop > your count to 47 in your dd and see if that works. > > R/ > > Jason > > > On Tue, Feb 25, 2014 at 12:05 AM, ewaldo simon <ewa...@gm...>wrote: > >> I'm sorry to bump this thread, but I got lost again.... >> >> here is my dd command >> >> dd if=imagename.001 of=dd_output.xls bs=512 skip=20959 count=48 >> >> >> the skip comes from the first sector that istat produce by working on inode 1571469, which is sector 20896, then I add 63 as the offset. >> >> >> here is my icat command >> >> >> icat -o63 -v imagename.001 1571469 > icat_output.xls >> >> tsk_img_open: Type: 0 NumImg: 1 Img1: imagename.001 >> Not an EWF file >> fsopen: Auto detection mode at offset 32256 >> raw_read: byte offset: 32256 len: 65536 >> raw_read: byte offset: 97792 len: 65536 >> raw_read: byte offset: 294400 len: 65536 >> iso9660_open img_info: 140321104 ftype: 2048 test: 1 >> iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001 >> Trying RAW ISO9660 with 16-byte pre-block size >> fs_prepost_read: Mapped 32768 to 69904 >> iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001 >> Trying RAW ISO9660 with 24-byte pre-block size >> fs_prepost_read: Mapped 32768 to 69912 >> iso_load_vol_desc: Bad volume descriptor: Magic number is not CD001 >> fatfs_inode_lookup: reading sector 105856 for inode 1571469 >> raw_read: byte offset: 54230528 len: 65536 >> raw_read: byte offset: 97280 len: 65536 >> tsk_fs_file_walk: Processing file 1571469 >> fatfs_make_data_run: Processing deleted file 1571469 in recovery mode >> raw_read: byte offset: 10731008 len: 65536 >> >> >> then I look for the md5sums of both of them. >> >> >> 3a1ef7b320ee2d675ed631dbd4bc53c3 dd_output.xls >> 1f12a90ee22e0565be9be1f9a8673688 icat_output.xls >> >> >> >> this is the output of running "diff dd_output.xls icat_output.xls": >> >> Binary files dd_output.xls and icat_output.xls differ >> >> >> why do they have diffrent md5sum? aren't they suppose to be the same file? >> >> >> >> >> On Mon, Feb 24, 2014 at 5:44 PM, ewaldo simon <ewa...@gm...>wrote: >> >>> James, >>> >>> I've read the foremost auditlog, but after trying to find inode of those >>> files that foremost carved, none of them is being pointed by the FAT >>> entries of "tagihan.xls" I've shown before. >>> >>> I've also check the metadata of those excel files that foremost carved, >>> and also no information there. to read the metadata I open them on >>> libreoffice and also right click properties on explorer. >>> >>> I guess that's it then, unless there is another suggestion, I will be >>> more than happy to oblige. >>> anyway thank you for all your help, it really helped me alot, and I have >>> much thing that I learned. >>> >>> >>> >>> >>> On Mon, Feb 24, 2014 at 11:01 AM, James Haughom <ja...@ne...> wrote: >>> >>>> Ewaldo >>>> >>>> Foremost produces an audit file which will give you the offset from >>>> which the file was recovered. You might be able to correlate the offset >>>> with data that you are extracting with istat. >>>> >>>> Good luck >>>> >>>> >>>> On 2/23/14 9:07 PM, ewaldo simon wrote: >>>> > Jason, >>>> > >>>> > Thank you very much, you're right, by running: >>>> > >>>> > ifind -o63 imagename.001 -d 20896 (and on other data unit on the same >>>> > FAT entry) >>>> > >>>> > result in diffrent inode/fat entry (which is 156282). >>>> > >>>> > the thing is I have 6 excel files, carved by foremost that I suspected >>>> > is related to those files (because the content of the file). >>>> > FYI, "tagihan" means invoice, and those 6 files that I carved are >>>> invoices, >>>> > the question is this: >>>> > do you guys have any other mean to connect the files that I carved >>>> (with >>>> > foremost) with those files that I found using fls? or how can I tell >>>> > which data unit that foremost used to carved these files. >>>> > >>>> > Thank you before. >>>> > >>>> > ps. I posted this also in forensicfocus.com <http://forensicfocus.com >>>> >, >>>> > and if it is OK with you, I'll post this discussion result in there >>>> too. >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > On Sun, Feb 23, 2014 at 10:34 PM, Jason Wright <jwr...@gm... >>>> > <mailto:jwr...@gm...>> wrote: >>>> > >>>> > Ewaldo, >>>> > >>>> > It is possible the blocks have been reused since these are all >>>> > deleted references. The metadata can still reference the file, but >>>> > the blocks can be reused by an allocated file. If the header of >>>> the >>>> > file dumped by icat isn't for an xls file then that is likely the >>>> > case. Use ifind to see what inode is associated with the specific >>>> > block (20896 for example). >>>> > >>>> > R/ >>>> > >>>> > Jason >>>> > >>>> > First of all thank you for your suggestion, I've tried your >>>> > suggestion and change the blocksize, It didn't work out either. >>>> I've >>>> > also tried using icat on that inode (which doesn't use blocksize) >>>> it >>>> > didn't work either. >>>> > is it possible that the data unit that being pointed by the >>>> metadata >>>> > (FAT entries) already used by another file/folder? >>>> > >>>> > actually I managed to save some of those (if it is true that that >>>> is >>>> > the files) files needed, by using foremost, and I need to find the >>>> > names of the files, so I tried using dd and/or icat. >>>> > >>>> > so the bottomline is I need a way to extract those excel, or found >>>> > out the name that foremost carved, or make sure that some of those >>>> > files shown with fls is actually the one that foremost recovered. >>>> > >>>> > Thank you before, and sorry for my bad english. >>>> > >>>> > >>>> > >>>> > On Sun, Feb 23, 2014 at 1:13 AM, Alex Nelson < >>>> ajn...@cs... >>>> > <mailto:ajn...@cs...>> wrote: >>>> > >>>> > Hi Ewaldo, >>>> > >>>> > Your dd should work given the sector offsets. However, you >>>> > passed a sector size of 4096 (bs=4096). I'm guessing because >>>> > -o63 worked in istat, you should have passed bs=512 in dd. >>>> > >>>> > --Alex >>>> > >>>> > >>>> > On Feb 22, 2014, at 01:44 , ewaldo simon < >>>> ewa...@gm... >>>> > <mailto:ewa...@gm...>> wrote: >>>> > >>>> >> Dear sleuthkit user mailing list, can anyone help me with >>>> >> this, I am trying to recover some orphan files. >>>> >> >>>> >> >>>> >> 1. first, using fls, I've found some orphaned files: >>>> >> >>>> >> Code: >>>> >> fls -o 63 -r F imagename.001 | grep -i file_name >>>> >> >>>> >> -/r * 649873: $OrphanFiles/TAGIHAN.xls >>>> >> r/r * 122506: $OrphanFiles/PT8D15~1.NUG/REKAP TAGIHAN >>>> MAR'11.xls >>>> >> -/r * 1212051: $OrphanFiles/TAGIHA~1.XLS >>>> >> -/r * 1282702: $OrphanFiles/TAGIHA~1.XLS >>>> >> -/r * 1374865: $OrphanFiles/TAGIHA~1.XLS >>>> >> -/r * 1472145: $OrphanFiles/TAGIHA~1.XLS >>>> >> -/r * 1519249: $OrphanFiles/TAGIHA~1.XLS >>>> >> -/r * 1571469: $OrphanFiles/TAGIHA~1.XLS >>>> >> >>>> >> 2. then, using istat to see the metadata of the last file >>>> >> listed before (this is the part that I got wrong the last >>>> time) >>>> >> >>>> >> Code: >>>> >> istat -o 63 imagename 1571469 >>>> >> >>>> >> Directory Entry: 1571469 >>>> >> Not Allocated >>>> >> File Attributes: File, Archive >>>> >> Size: 24064 >>>> >> Name: TAGIHA~1.XLS >>>> >> >>>> >> Directory Entry Times: >>>> >> Written: Mon Aug 24 14:26:16 2009 >>>> >> Accessed: Tue Aug 7 00:00:00 2012 >>>> >> Created: Tue Aug 7 09:40:58 2012 >>>> >> >>>> >> Sectors: >>>> >> 20896 20897 20898 20899 20900 20901 20902 20903 >>>> >> 20904 20905 20906 20907 20908 20909 20910 20911 >>>> >> 20912 20913 20914 20915 20916 20917 20918 20919 >>>> >> 20920 20921 20922 20923 20924 20925 20926 20927 >>>> >> 20928 20929 20930 20931 20932 20933 20934 20935 >>>> >> 20936 20937 20938 20939 20940 20941 20942 20943 >>>> >> >>>> >> it means that the directory entry still points to the FAT >>>> >> entries and in the end points to the sectors used by that >>>> file. >>>> >> >>>> >> 3. now I don't get how to recover the TAGIHA~1.XLS >>>> >> >>>> >> I've tried using dd: >>>> >> Code: >>>> >> dd if=imagefile of=outputfile bs=4096 skip=20896 count=6 >>>> >> and >>>> >> also icat >>>> >> >>>> >> icat -o 63 imagename.001 1571496 > TAGI~1.xls >>>> >> >>>> >> >>>> >> again to no avail. >>>> >> >>>> >> I've tried recovering with foremost, and it does recover some >>>> >> files, but I need the name of the files, that's why I'm >>>> trying >>>> >> to use this method. >>>> >> Please correct me if I'm wrong, and give me the hint where to >>>> >> go from here. I really appriciate your help, thank you. >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Regards, >>>> >> Ewaldo Simon >>>> >> >>>> ------------------------------------------------------------------------------ >>>> >> Managing the Performance of Cloud-Based Applications >>>> >> Take advantage of what the Cloud has to offer - Avoid Common >>>> >> Pitfalls. >>>> >> Read the Whitepaper. >>>> >> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________ >>>> >> sleuthkit-users mailing list >>>> >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>> >> http://www.sleuthkit.org >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Regards, >>>> > Ewaldo Simon >>>> > >>>> > >>>> ------------------------------------------------------------------------------ >>>> > Managing the Performance of Cloud-Based Applications >>>> > Take advantage of what the Cloud has to offer - Avoid Common >>>> Pitfalls. >>>> > Read the Whitepaper. >>>> > >>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk >>>> > _______________________________________________ >>>> > sleuthkit-users mailing list >>>> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>> > http://www.sleuthkit.org >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Regards, >>>> > Ewaldo Simon >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------------------ >>>> > Flow-based real-time traffic analytics software. Cisco certified tool. >>>> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >>>> > Customize your own dashboards, set traffic alerts and generate >>>> reports. >>>> > Network behavioral analysis & security monitoring. All-in-one tool. >>>> > >>>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > sleuthkit-users mailing list >>>> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>> > http://www.sleuthkit.org >>>> > >>>> >>>> >>>> >>> >>> >>> -- >>> Regards, >>> Ewaldo Simon >>> >> >> >> >> -- >> Regards, >> Ewaldo Simon >> >> >> ------------------------------------------------------------------------------ >> Flow-based real-time traffic analytics software. Cisco certified tool. >> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >> Customize your own dashboards, set traffic alerts and generate reports. >> Network behavioral analysis & security monitoring. All-in-one tool. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk >> _______________________________________________ >> sleuthkit-users mailing list >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >> http://www.sleuthkit.org >> >> > |
