Re: [sleuthkit-users] recover $orphaned files
Brought to you by:
carrier
From: Jason W. <jwr...@gm...> - 2014-02-25 12:25:24
|
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 > > |