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-24 02:07:51
|
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, 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...>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...> 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...> 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 |
