Re: [sleuthkit-users] recover $orphaned files
Brought to you by:
carrier
Menu
▾
▴
Re: [sleuthkit-users] recover $orphaned files
|
From: ewaldo s. <ewa...@gm...> - 2014-02-25 05:06:03
|
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 |
