Thread: [sleuthkit-users] ISTAT output question
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users
|
From: Jaime C. <jc...@id...> - 2005-04-25 20:30:38
|
Hello everybody, In the following istat output, Directory Entry: 24006 Not Allocated File Attributes: File, Archive Size: 10425 Num of links: 0 Name: _UTFOXED.PNG Directory Entry Times: Written: Sun Feb 27 14:39:58 2005 Accessed: Sun Feb 27 00:00:00 2005 Created: Sun Feb 27 14:39:58 2005 Sectors: 1545 1546 1547 1548 Recovery: 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 Does anyone know what might be the difference, if any, between the sectors in the "Sectors:" section and the sectors in the "Recovery:" section. In most of the deleted files I have been trying, the sectors from the "Sectors:" section is always included in the "Recovery:" section. Is there a case where this might not be true? Thanks in advance Jimmy. |
|
From: Brian C. <ca...@sl...> - 2005-04-25 21:53:57
|
On Apr 25, 2005, at 3:30 PM, Jaime Chang wrote: > Hello everybody, > > In the following istat output, [...] > Sectors: > 1545 1546 1547 1548 > > Recovery: > 1545 1546 1547 1548 1549 1550 1551 1552 > 1553 1554 1555 1556 1557 1558 1559 1560 > 1561 1562 1563 1564 1565 1566 1567 1568 > > Does anyone know what might be the difference, if any, between the > sectors in the "Sectors:" section and the sectors in the "Recovery:" > section. In most of the deleted files I have been trying, the sectors > from the "Sectors:" section is always included in the "Recovery:" > section. Is there a case where this might not be true? The sectors in the "Sectors:" section are the ones in the starting cluster of the file. Because the file is unallocated and we know only the starting cluster (sectors), TSK tries to determine the remaining sectors. Those are listed in the recovery section. So, yes the "Recovery" section will always contain the sectors from the "Sectors" section. They are separated to show which addresses we have more confidence in. We know the 1545-1548 addresses are correct for the file because they are referenced by the directory entry, but the other addresses could be incorrect if the original file was fragmented and TSK couldn't determine the original layout. brian |
|
From: <fu...@gm...> - 2005-04-27 14:56:55
|
sorry, I've sent this on falsely on the linux-forensics-list On Mon, 25 Apr 2005 16:34:08 -0500 Brian Carrier <ca...@ce...> wrote: > > On Apr 25, 2005, at 10:34 AM, fu...@gm... wrote: > > > I know that all these tasks can be done with sleuthkit tools like > > sorter, > > srch_strings and so far, but now with the ability to load full images > > and > > not only partitons this getting more complicated to do in a script. So > > I'd > > like to ask what your tricks are to do this efficiently? Did you all > > write > > scripts? > > dls and sorter are run the exact same way as before, but now you need > to specify '-o X' where X is the sector offset of the file system in > the disk. You can just make a script, copy and paste the relevant > commands for each partition, and then change the offset values for > each. > > Extracting strings from a partition is a little more tricky because the > strings tool does not know where the partition boundaries are. So, > you will need to use either 'dd' or 'dls -f raw -e' to extract out the > sectors relevant to the partition and then pipe that into strings. You > can look at the exec log to see the commands that have been executed > for previous files as a basis. Oh I did not know about this log, this is exactly what I was looking for. I now start compiliing al list of one-liner, so I can make things faster. As fas as I can see the only problem would be that these steps are not automatically logged in the Autopsy-Files, so maybe not the best thing from the forensic point of view? > > Adding the files to the Autopsy config file is probably the biggest > change because of the new file format. As an example, a strings entry > could be: > > strings vol10 vol5 output/basic-dos.dd-63-48194-ntfs.asc > > Every file now has a volume ID in autopsy and each entry in the config > file describes a file. The above entry means that the volume id for > this strings file is 'vol10' and it is a strings file for the volume > with id 'vol5' (which could be a part entry or dls entry). The > strings are located in 'output/basic-dos....'. The dls entries have > a similar format. > got it, this is not much problem to handle. Furthermore, I got kinda other problem: I analyze an image of a NTFS-Hardrive, containing two partitions. If I look at the deleted files list on the first partition, I see a lot of files which are deleted, if I look into the directories, they are still there OR I don't see the brown, unallocated file. Is this a problem with NTFS handling? > > The loading whole images features rocks by the way! > > thanks. thank you so much |
|
From: Brian C. <ca...@sl...> - 2005-04-28 06:59:31
|
On Apr 27, 2005, at 9:56 AM, fu...@gm... wrote: >> You >> can look at the exec log to see the commands that have been executed >> for previous files as a basis. > > Oh I did not know about this log, this is exactly what I was looking > for. I now start compiliing al list of one-liner, so I can make things > faster. As fas as I can see the only problem would be that these steps > are not automatically logged in the Autopsy-Files, so maybe not the > best thing from the forensic point of view? There is no legal requirement that you have a log of every single command that is executed. You can always write down the commands that you used in a notebook. > Furthermore, I got kinda other problem: I analyze an image of a > NTFS-Hardrive, containing two partitions. If I look at the deleted > files list on the first partition, I see a lot of files which are > deleted, if I look into the directories, they are still there OR I > don't see the brown, unallocated file. Is this a problem with NTFS > handling? I'm not quite sure what you are asking. Can you give a specific example? brian |
Thanks for helping keep SourceForge clean.
X