sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.

Re: [sleuthkit-users] What are indirect blocks?

[Aaron S. <aa...@se...>]

On Mon, May 16, 2005, Brian Carrier <ca...@sl...> said:

> On May 16, 2005, at 1:58 AM, Aaron Stone wrote:
> 
>> What are indirect blocks, and what does this output from 'istat' mean?
> 
> Ext2 stores the file content in blocks.  The first 12 block addresses 
> that a file has allocated are stored in the inode.  The remaining 
> blocks are stored in indirect blocks, which are blocks that contain a 
> list of block addresses.  The error you are getting is because one of 
> the addresses in an indirect block is larger than the partition is.  
> This occurs when the block has been reallocated to a new file and has 
> normal file content in it (and not block addresses).  In other words, 
> part of your deleted file has been reallocated to new files and 
> overwritten.

The file was never deleted; the disk was dying and I made an image before
sending it in for RMA. The other partition image off this disk mounts
completely cleanly and all files are accessible, but this partition didn't
make it so well.

Aaron

RE: [sleuthkit-users] What are indirect blocks?

[Aaron S. <aa...@se...>]

On Mon, May 16, 2005, ""Baskin, Brian"" <ba...@dc...> said:

[snip]
> The 14th pointer then acts as a double indirect.  This pointer holds the address for another 8KB data block, but instead of this data block containing contents or direct pointers, it contains 2048 single indirects.  So, each of these single indirects point to another 8KB data block that contains 2048 direct pointers.  All filled, a file can acheive 32GB of size. ((2048*2048*8K)+96K)

My blocksize is 4k, and the file that I get by dcat'ing each of the blocks
that istat is able to give me is 4.1M; so it looks like my "13th pointer"
is in good shape, but my "14th pointer" is trashed. Which means that I'm
missing all but the first 4MB of my 6GB file.

Do any of these indirect blocks have backlinks that can be used to locate
them with a binary grep?


> I can only guess that a corrupted value was placed in one of the pointers.  If it's an indirect pointer value that was corrupted, that could mean the loss of quite a bit of information (16MB), but when recovered it may not be too dramatic of a loss.  However, seeing as how the direct blocks are sequential, with none missing, it may just be the loss of a single direct pointer value, which can be insignificant once recovered.  I would try viewing the contents of the data blocks immediately before and after the error, either through the GUI or through dcat, and seeing if they report errors or seem bad:

Right, you mean the loss of everything > 16MB. But in my blocksize, it's
4MB. I'd be surprised if there's anything of value up in that first 4MB
:-\

The blocks are sequential in groups of a few dozen, with fairly large
jumps between them. Sounds like the ext2/3 preallocation strategy.



> To pull this file out, is the image a full disk image or a partition?

The image is a partition, and the file inside is also a partition; I
rarely (if ever) do a 'dd if=/dev/hda of=image' because of the relative
difficulty in mounting up the individual partitions inside with the
loopback driver.

Aaron

Re: [sleuthkit-users] What are indirect blocks?

[Brian C. <ca...@sl...>]

On May 16, 2005, at 1:58 AM, Aaron Stone wrote:

> What are indirect blocks, and what does this output from 'istat' mean?

Ext2 stores the file content in blocks.  The first 12 block addresses 
that a file has allocated are stored in the inode.  The remaining 
blocks are stored in indirect blocks, which are blocks that contain a 
list of block addresses.  The error you are getting is because one of 
the addresses in an indirect block is larger than the partition is.  
This occurs when the block has been reallocated to a new file and has 
normal file content in it (and not block addresses).  In other words, 
part of your deleted file has been reallocated to new files and 
overwritten.

brian



>
> bash$ istat AaronOldImage.ext3 193
> inode: 193
> Allocated
> Group: 0
> Generation Id: 4016250406
> uid / gid: 0 / 0
> mode: -rw-r--r--
> Flags: Immutable,
> size: 6045548544
> num of links: 1
>
> Inode Times:
> Accessed:       Sun Jan 30 17:24:05 2005
> File Modified:  Wed May 12 14:40:18 2004
> Inode Modified: Wed May 12 14:42:13 2004
>
> Direct Blocks:
> 9373 9600 9602 9603 9604 9605 9606 9799
> [snip about 60 lines of block listings]
> 512422 512423 512424 534529 534530 534531 534532 534533
> istat: Invalid address in indirect list (too large): 136081568
> 534534 534535 534536 534537
> bash$
>
> Thanks,
> Aaron
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Has anybody tried sleuth to recover a NTFS partition a broken raid?

[Brian C. <ca...@sl...>]

On May 9, 2005, at 11:25 PM, Edmundo Carmona wrote:
>
> I think I'm doing the right thing.... but I can't do much if I can't
> study the resulting image in case the linux ntfs say it's wrong. I
> guess I could use sleuth to analyse the result. Maybe you know of
> other people who have tried.
>
If  you can get an image file of the full partition or disk and the 
file system is valid, then TSK can be used.  TSK will not fix broken 
file systems and it will not recreate the RAID for you.

brian

[sleuthkit-users] What are indirect blocks?

[Aaron S. <aa...@se...>]

Hey folks,

I've been Googling for days to try to recover what appears to be a pretty
bad image of my old 60GB /home partition. I've given up on e2retieve and
e2salvage, and am now working with TSK and e2extract:

http://dreamscape.org/toolkit/README.html

The scoop is that buried in this image is another image of my old laptop's
hard drive. I desperately need to grab a 6GB needle out of a 60GB
haystack.

What are indirect blocks, and what does this output from 'istat' mean?

bash$ istat AaronOldImage.ext3 193
inode: 193
Allocated
Group: 0
Generation Id: 4016250406
uid / gid: 0 / 0
mode: -rw-r--r--
Flags: Immutable,
size: 6045548544
num of links: 1

Inode Times:
Accessed:       Sun Jan 30 17:24:05 2005
File Modified:  Wed May 12 14:40:18 2004
Inode Modified: Wed May 12 14:42:13 2004

Direct Blocks:
9373 9600 9602 9603 9604 9605 9606 9799
[snip about 60 lines of block listings]
512422 512423 512424 534529 534530 534531 534532 534533
istat: Invalid address in indirect list (too large): 136081568
534534 534535 534536 534537 
bash$

Thanks,
Aaron

[sleuthkit-users] 2005 DFRWS Update

[Gary P. <pa...@mi...>]

Registration for the 5th Annual Digital Forensic Research Workshop is 
now available.  The workshop will be held August 17-19 in New Orleans, 
LA and Wieste Venema, co-author of "Forensic Discovery," The Coroner's 
Toolkit (TCT), and many other software packages, will be the keynote 
speaker.  The Welcome Reception is being sponsored by Elsevier and the 
Journal of Digital Investigation.

http://www.dfrws.org/2005/

Also, the deadline for paper submission is June 1st, which is quickly 
approaching. Topics of interest include traditional disk analysis, 
memory and network forensics, legal issues, case studies, and more.  For 
details, refer to the call for papers at: 
http://www.dfrws.org/2005/dfrws2005CFP.html

DFRWS' goal is to bring together researchers and practitioners to 
advance the state of the art in digital forensics by sharing their 
knowledge, results, and experiences.

See you in New Orleans!

[sleuthkit-users] Has anybody tried sleuth to recover a NTFS partition a broken raid?

[Edmundo C. <ean...@gm...>]

Hi, guys!

I've been working with this raid at the office. It's a 5-disk raid
that since a power outage, hasn't wanted to "come back to life"
anymore.

Before the IT guys decided to reset it (you know, the M$ way ;)), I
made images of four of the five disks by extracting them ffrom the
rack they were in (it's a HP netserver rack storage/12) and putting
them on a different computer.

I even made a program that "rebuilds" the whole logical information of
the raid in a single image. When I do fdisk on the result file:

# fdisk -lu discoa1
You must set cylinders.
You can do this from the extra functions menu.

Disk discoa1: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units =3D sectors of 1 * 512 =3D 512 bytes

  Device Boot      Start         End      Blocks   Id  System
discoa1p1              63   142175249    71087593+   7  HPFS/NTFS
Partition 1 has different physical/logical endings:
    phys=3D(1023, 254, 63) logical=3D(8849, 254, 63)

It's complaining because that file I ised here is just the first chunk
(second, actually. I think the raid controller reserves the first
chunk of the disks) of the first image of the raid. But when I did it
on the whole
<i>rebuilt</i>image, It was OK.

The problem showed up when I mounted that partition. I got a ntfs
index problem. I know there are issues that I have to work on. If i'm
not using the same algorithm of the controller, I might get the data
back..... but the chunks won't be ordered the right way.

What algorithm was used by the controller? I think it's a left one.
But i'm not sure if it's simmetrich or not. :'( And so on.

I think I'm doing the right thing.... but I can't do much if I can't
study the resulting image in case the linux ntfs say it's wrong. I
guess I could use sleuth to analyse the result. Maybe you know of
other people who have tried.

I'd appreciate any help you could provide.

Bye!

PS The other thing I tried was bring up a software raid using
the four images plus a faulty one... but I wasn't able to do it either
( I even tried with a brand new one to see how the whole thing
worked.... but couldn't do that either). Maybe you know of someone who
has tried that before.

Here is a URL to a forum I started on linuxquestions.org about it:
http://www.linuxquestions.org/questions/showthread.php?s=3D&threadid=3D3193=
56

Another thing that I might try is study the first chunks of the images
to figure out the order in which they are logically placed one after
another. Then I could figure out the order of the images, and of
course, the algorithm used. What do you think? Could sleuth help me on that=
?

Well... thanks for reading anyway! :D

Take care

Re: [sleuthkit-users] Separate short names from long names

[Brian C. <ca...@sl...>]

On May 9, 2005, at 11:42 AM, Jaime Chang wrote:

> Hi all
>
> I am using the fs_dent method to get a list of files and I noticed 
> that the name attribute of the FS_DENT structure contains the long 
> name and the short name in parenthesis. For example:
>
>   HOME/MYDIRE~1/DummyFile.js (DUMMYF~1.JS)
>
> Is there a way to avoid the short names being part of the name 
> attribute? Also, is there a way to get the long filenames for the path 
> too?

Currently there is no way in the code to have only the long or only the 
short names or to have the long name in the directory path. This should 
probably be updated when I do the Unicode upgrade where the FS_DENT 
structure will have the ASCII and Unicode names.  The long and short 
versions of the name can also exist.

brian

[sleuthkit-users] Separate short names from long names

[Jaime C. <jc...@id...>]

Hi all

I am using the fs_dent method to get a list of files and I noticed that 
the name attribute of the FS_DENT structure contains the long name and 
the short name in parenthesis. For example:

   HOME/MYDIRE~1/DummyFile.js (DUMMYF~1.JS)

Is there a way to avoid the short names being part of the name 
attribute? Also, is there a way to get the long filenames for the path too?

Thanks in advance,

Jimmy

Re[2]: [sleuthkit-users] foreign language support

[tessy <te...@te...>]

Hi

On Wed, 4 May 2005 23:55:05 -0500
Brian Carrier <ca...@sl...> wrote:

> > I have an image with multiple files with Chinese names. They aren稚 
> > showing up in autopsy at all. Any suggestions?
> 
> Autopsy and TSK don't support Unicode.  There are patches for previous 
> versions, but a complete solution is not available yet.


We modified previous versions patches to newest versions.
Please check it.
http://www.t-dori.net/forensics/sleuthkit-2.01-utf8.patch
http://www.t-dori.net/forensics/autopsy-2.05-utf8.patch


previous versions patches

UTF-8 output patch for task-1.60/sleuthkit-1.6x
http://www.monyo.com/technical/unix/TASK/

Autopsy UTF-8 Patch (1.70-1.73)
http://www.asahi-net.or.jp/~uu8m-kbys/autopsy/



Team T-dori
http://www.t-dori.net/

-- 
tessy <te...@te...>

Re: [sleuthkit-users] foreign language support

[Brian C. <ca...@sl...>]

On May 4, 2005, at 2:54 PM, TY cowan wrote:

> I have an image with multiple files with Chinese names. They aren=92t=20=

> showing up in autopsy at all. Any suggestions?

Autopsy and TSK don't support Unicode.  There are patches for previous=20=

versions, but a complete solution is not available yet.

brian

[sleuthkit-users] foreign language support

[TY c. <sif...@ya...>]

I have an image with multiple files with Chinese names. They aren’t showing up in autopsy at all. Any suggestions?
 
Cheers

		
---------------------------------
Yahoo! Mail
 Stay connected, organized, and protected. Take the tour

Re: [sleuthkit-users] Corrupted floppy

[Enda C. <en...@co...>]

I find that when accessing a damaged floppy from windows / linux through an
application, when it can't read to EOF it refuses to display what it can
read resulting in you not being able to retrieve any data. Even without the
padded zero's, you will be able to read a corrupted file from the image
through to EOF, and it will display all that is available despite the file
integrity. Typically you loose a lot of formatting etc, and have to fish out
the relevant info. Strings is very useful for that.

 -Enda.

----- Original Message ----- 
From: "Bradley B" <br...@de...>
To: "'Enda Cronnolly'" <en...@co...>
Cc: <sle...@li...>
Sent: Sunday, May 01, 2005 1:33 AM
Subject: RE: [sleuthkit-users] Corrupted floppy


> When using conv=noerror it will begin writing to the file when it can read
> more data, which will prevent offsets from being correct. A solution is
> conv=sync,noerror where it will write zeroes when it has an error reading
> the disk. I find using sleuthkit and autopsy to recover files on a damaged
> filesystem is more successful than using the operating system and trying
to
> access the data.
>
> -----Original Message-----
> From: sle...@li...
> [mailto:sle...@li...] On Behalf Of Enda
> Cronnolly
> Sent: Monday, April 25, 2005 12:33 PM
> To: sle...@li...
> Subject: Re: [sleuthkit-users] Corrupted floppy
>
>
> when dd'ing a floppy, try using bs=1 and conv=noerror, then mounting the
> image under loopback.
>
> Have had sucess recovering some files which suffered the "thesis field
> effect" that way where there was physical damage to the disk. Document
> probably won't be 100% intact, but the majority of the content was
> recoverable.
>
> HTH,
>
>  -Enda.
>
> ----- Original Message ----- 
> From: "Brian Carrier" <ca...@sl...>
> To: "Pradeep M" <pra...@gm...>
> Cc: <sle...@li...>
> Sent: Monday, April 25, 2005 3:18 PM
> Subject: Re: [sleuthkit-users] Corrupted floppy
>
>
> > How do you mean "corrupted"?  Is the file system corrupt or is the
> > physical media damaged and it generates errors when you try to read it?
> >   If it is physical damage, then TSK / Autopsy will not help.  If it is
> > file system corruption, then you can try them but they will not fix any
> > errors that exist.  You can also make  an image of the floppy using
> > 'dd' and then run fsck on a copy so that it fixes any errors.
> >
> > brian
> >
> >
> >
> > On Apr 25, 2005, at 5:15 AM, Pradeep M wrote:
> >
> > > Hi
> > >         Is it possible to recover data from  a corrupted floppy using
> > > sleuthkit and autopsy.
> > > I tried using the tool but first of all its not possible to mount the
> > > floppy itself. I want to know whether it is possible to recover data
> > > from a corrupted floppy using this tool and if its not possible then
> > > which tool should be used. Pls help.
> > >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> >
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

RE: [sleuthkit-users] Corrupted floppy

[Bradley B <br...@de...>]

When using conv=noerror it will begin writing to the file when it can read
more data, which will prevent offsets from being correct. A solution is
conv=sync,noerror where it will write zeroes when it has an error reading
the disk. I find using sleuthkit and autopsy to recover files on a damaged
filesystem is more successful than using the operating system and trying to
access the data.

-----Original Message-----
From: sle...@li...
[mailto:sle...@li...] On Behalf Of Enda
Cronnolly
Sent: Monday, April 25, 2005 12:33 PM
To: sle...@li...
Subject: Re: [sleuthkit-users] Corrupted floppy


when dd'ing a floppy, try using bs=1 and conv=noerror, then mounting the
image under loopback.

Have had sucess recovering some files which suffered the "thesis field
effect" that way where there was physical damage to the disk. Document
probably won't be 100% intact, but the majority of the content was
recoverable.

HTH,

 -Enda.

----- Original Message ----- 
From: "Brian Carrier" <ca...@sl...>
To: "Pradeep M" <pra...@gm...>
Cc: <sle...@li...>
Sent: Monday, April 25, 2005 3:18 PM
Subject: Re: [sleuthkit-users] Corrupted floppy


> How do you mean "corrupted"?  Is the file system corrupt or is the
> physical media damaged and it generates errors when you try to read it?
>   If it is physical damage, then TSK / Autopsy will not help.  If it is
> file system corruption, then you can try them but they will not fix any
> errors that exist.  You can also make  an image of the floppy using
> 'dd' and then run fsck on a copy so that it fixes any errors.
>
> brian
>
>
>
> On Apr 25, 2005, at 5:15 AM, Pradeep M wrote:
>
> > Hi
> >         Is it possible to recover data from  a corrupted floppy using
> > sleuthkit and autopsy.
> > I tried using the tool but first of all its not possible to mount the
> > floppy itself. I want to know whether it is possible to recover data
> > from a corrupted floppy using this tool and if its not possible then
> > which tool should be used. Pls help.
> >
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: [sleuthkit-users] ISTAT output question

[Brian C. <ca...@sl...>]

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

Re: [sleuthkit-users] ISTAT output question

[<fu...@gm...>]

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

Re: [sleuthkit-users] Re: sleuthkit-users digest, Vol 1 #293 - 5 msgs

[DELHOMME O. DGPN-DCPJ-P. <Oli...@in...>]

(...)
>=20
> dd if=3D/dev/fd0 of=3D/path/to/wherever/you/want/the/floppy/image

--=20
Olivier DELHOMME
DCPJ / SDPTS / SITT / LATS

Tel +33 (0) 4.72.86.84.60
Fax +33 (0) 4.72.86.85.24
 bs=3D1
> conv=3Dnoerror
> mount -o loop /path/to/wherever/you/want/the/floppy/image /mnt/floppy

Please note that in case of an error you will miss 1 byte and the rest of
the data will be shifted. To avoid this you could use the option 'sync' to
the conv option parameter :

dd if=3D/dev/fd0 of=3D/path/to/wherever/you/want/the/floppy/image ibs=3D1 obs=3D1
conv=3Dsync,noerror

Should work better. When an error is found, the byte that was not read is
replaced by a 0x00. This ensures the filesystem integrity (files are locate=
d
were expected).

Note that imaging a floppy disk with this method can take several days if
the number of errors is very important.


--=20
Olivier DELHOMME
DCPJ / SDPTS / SITT / LATS

Tel +33 (0) 4.72.86.84.60
Fax +33 (0) 4.72.86.85.24

"Quand la v=E9rit=E9 n'est pas libre, la libert=E9 n'est pas vraie."

                                 [ Jacques Pr=E9vert ]

Re: [sleuthkit-users] Fls vs Ils

[Brian C. <ca...@sl...>]

On Apr 26, 2005, at 10:50 AM, Jaime Chang wrote:

> Hello everybody,
>
> If I was looking for all files using the commands below.  Is it 
> possible that one command could return more files than the other one?

Yes.

> ils -eZ -f fat test.img
> fls  -r -f fat test.img
>
> Basically, I'd like to know if there is any difference on how files 
> are searched between fls and ils commands.

They are entirely different (which is why the speeds are different and 
they have different names :) ). 'fls' traverses the directory and file 
name hierarchy (like users normally do) and 'ils' traverses the 
metadata tables (like inode tables or MFT).  'ils' ignores names 
entirely and knows nothing about parent directories and the like.  It 
is possible to have metadata entries that do not have a name associated 
with them and similarly there could be multiple names for a single 
metadata entry.  Therefore the numbers could be different.

> I noticed that in one of my test scenarios, I was actually getting 
> less files using the ils command

This is not surprising.  There are many reasons why this can happen, 
but since you are asking about FAT specifically, I'll give you one.   
The '-Z' check in ils verifies that the c-time is non-zero.  This is 
legacy from TCT and was used to organize the unallocated inodes that 
had been used and those that had not.  I have found many files in a FAT 
file system where Windows system files had a c-time of 0.  So, when you 
add the '-Z', you are skipping those odd files in the 'ils' command, 
but 'fls' will print them.

brian 

Re: [sleuthkit-users] Re: sleuthkit-users digest, Vol 1 #293 - 5 msgs

[Seth A. <sa...@im...>]

On Tue, Apr 26, 2005 at 12:31:14PM +0530, Pradeep M wrote:
>         The floppy is not physically damaged. It shows me the
> following error when mounting the floppy :
>=20
> mount /mnt/floppy/
> /dev/fd0: Input/output error
> mount: you must specify the filesystem type

Input/output error sure sounds like a damaged floppy. A few years ago, I
used around 50 brand new floppies and found roughly 10% were dead brand
new in the box. Appearance isn't everything. :)

>        enda : Thanks for ur help. I am new to linux and i dont know
> most of the commands.
> So pls give me the complete command for the following suggestion u gave me
>=20
>             when dd'ing a floppy, try using bs=3D1 and conv=3Dnoerror,
> then mounting the
>             image under loopback.

dd if=3D/dev/fd0 of=3D/path/to/wherever/you/want/the/floppy/image bs=3D1 co=
nv=3Dnoerror
mount -o loop /path/to/wherever/you/want/the/floppy/image /mnt/floppy

[sleuthkit-users] Fls vs Ils

[Jaime C. <jc...@id...>]

Hello everybody,

If I was looking for all files using the commands below.  Is it possible 
that one command could return more files than the other one?

ils -eZ -f fat test.img
fls  -r -f fat test.img

Basically, I'd like to know if there is any difference on how files are 
searched between fls and ils commands.

I noticed that in one of my test scenarios, I was actually getting less 
files using the ils command

Thanks in advance,

Jimmy

[sleuthkit-users] Re: sleuthkit-users digest, Vol 1 #293 - 5 msgs

[Pradeep M <pra...@gm...>]

        The floppy is not physically damaged. It shows me the
following error when mounting the floppy :

mount /mnt/floppy/
/dev/fd0: Input/output error
mount: you must specify the filesystem type

       =20
       enda : Thanks for ur help. I am new to linux and i dont know
most of the commands.
So pls give me the complete command for the following suggestion u gave me

            when dd'ing a floppy, try using bs=3D1 and conv=3Dnoerror,
then mounting the
            image under loopback.

First of all, I am not able to mount the floppy. I am getting the above err=
or.

pradeep


On 4/26/05, sle...@li...
<sle...@li...> wrote:
> Send sleuthkit-users mailing list submissions to
> =09s...@li...
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
> =09https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> or, via email, send a message with subject or body 'help' to
> =09s...@li...
>=20
> You can reach the person managing the list at
> =09s...@li...
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sleuthkit-users digest..."
>=20
>=20
> Today's Topics:
>=20
>    1. Corrupted floppy (Pradeep M)
>    2. Re: Corrupted floppy (Brian Carrier)
>    3. Re: Corrupted floppy (Enda Cronnolly)
>    4. ISTAT output question (Jaime Chang)
>    5. Re: ISTAT output question (Brian Carrier)
>=20
> --__--__--
>=20
> Message: 1
> Date: Mon, 25 Apr 2005 15:45:07 +0530
> From: Pradeep M <pra...@gm...>
> Reply-To: Pradeep M <pra...@gm...>
> To: sle...@li...
> Subject: [sleuthkit-users] Corrupted floppy
>=20
> Hi=3D20
>         Is it possible to recover data from  a corrupted floppy using
> sleuthkit and autopsy.
> I tried using the tool but first of all its not possible to mount the
> floppy itself. I want to know whether it is possible to recover data
> from a corrupted floppy using this tool and if its not possible then
> which tool should be used. Pls help.
>=20
> Pradeep
>=20
>=20
> --__--__--
>=20
> Message: 2
> Cc: sle...@li...
> From: Brian Carrier <ca...@sl...>
> Subject: Re: [sleuthkit-users] Corrupted floppy
> Date: Mon, 25 Apr 2005 09:18:27 -0500
> To: Pradeep M <pra...@gm...>
>=20
> How do you mean "corrupted"?  Is the file system corrupt or is the=20
> physical media damaged and it generates errors when you try to read it?=
=20
>   If it is physical damage, then TSK / Autopsy will not help.  If it is=
=20
> file system corruption, then you can try them but they will not fix any=
=20
> errors that exist.  You can also make  an image of the floppy using=20
> 'dd' and then run fsck on a copy so that it fixes any errors.
>=20
> brian
>=20
>=20
>=20
> On Apr 25, 2005, at 5:15 AM, Pradeep M wrote:
>=20
> > Hi
> >         Is it possible to recover data from  a corrupted floppy using
> > sleuthkit and autopsy.
> > I tried using the tool but first of all its not possible to mount the
> > floppy itself. I want to know whether it is possible to recover data
> > from a corrupted floppy using this tool and if its not possible then
> > which tool should be used. Pls help.
> >
>=20
>=20
>=20
> --__--__--
>=20
> Message: 3
> From: "Enda Cronnolly" <en...@co...>
> To: <sle...@li...>
> Subject: Re: [sleuthkit-users] Corrupted floppy
> Date: Mon, 25 Apr 2005 17:32:45 +0100
>=20
> when dd'ing a floppy, try using bs=3D1 and conv=3Dnoerror, then mounting =
the
> image under loopback.
>=20
> Have had sucess recovering some files which suffered the "thesis field
> effect" that way where there was physical damage to the disk. Document
> probably won't be 100% intact, but the majority of the content was
> recoverable.
>=20
> HTH,
>=20
>  -Enda.
>=20
> ----- Original Message -----=20
> From: "Brian Carrier" <ca...@sl...>
> To: "Pradeep M" <pra...@gm...>
> Cc: <sle...@li...>
> Sent: Monday, April 25, 2005 3:18 PM
> Subject: Re: [sleuthkit-users] Corrupted floppy
>=20
>=20
> > How do you mean "corrupted"?  Is the file system corrupt or is the
> > physical media damaged and it generates errors when you try to read it?
> >   If it is physical damage, then TSK / Autopsy will not help.  If it is
> > file system corruption, then you can try them but they will not fix any
> > errors that exist.  You can also make  an image of the floppy using
> > 'dd' and then run fsck on a copy so that it fixes any errors.
> >
> > brian
> >
> >
> >
> > On Apr 25, 2005, at 5:15 AM, Pradeep M wrote:
> >
> > > Hi
> > >         Is it possible to recover data from  a corrupted floppy using
> > > sleuthkit and autopsy.
> > > I tried using the tool but first of all its not possible to mount the
> > > floppy itself. I want to know whether it is possible to recover data
> > > from a corrupted floppy using this tool and if its not possible then
> > > which tool should be used. Pls help.
> > >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users=
.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> >
>=20
>=20
>=20
> --__--__--
>=20
> Message: 4
> Date: Mon, 25 Apr 2005 16:30:32 -0400
> From: Jaime Chang <jc...@id...>
> Organization: I.D.E.A.L. Technology Corporation
> To: sle...@li...
> Subject: [sleuthkit-users] ISTAT output question
>=20
> Hello everybody,
>=20
> In the following istat output,
>=20
> Directory Entry: 24006
> Not Allocated
> File Attributes: File, Archive
> Size: 10425
> Num of links: 0
> Name: _UTFOXED.PNG
>=20
> 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
>=20
> Sectors:
> 1545 1546 1547 1548
>=20
> 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
>=20
> Does anyone know what might be the difference, if any, between the=20
> sectors in the "Sectors:" section and the sectors in the "Recovery:"=20
> section. In most of the deleted files I have been trying, the sectors=20
> from the "Sectors:" section is always included in the "Recovery:"=20
> section. Is there a case where this might not be true?
>=20
> Thanks in advance
>=20
> Jimmy.
>=20
>=20
>=20
> --__--__--
>=20
> Message: 5
> Cc: sle...@li...
> From: Brian Carrier <ca...@sl...>
> Subject: Re: [sleuthkit-users] ISTAT output question
> Date: Mon, 25 Apr 2005 16:53:22 -0500
> To: Jaime Chang <jc...@id...>
>=20
>=20
> On Apr 25, 2005, at 3:30 PM, Jaime Chang wrote:
>=20
> > Hello everybody,
> >
> > In the following istat output,
>=20
> [...]
>=20
> > 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=20
> > sectors in the "Sectors:" section and the sectors in the "Recovery:"=20
> > section. In most of the deleted files I have been trying, the sectors=
=20
> > from the "Sectors:" section is always included in the "Recovery:"=20
> > section. Is there a case where this might not be true?
>=20
> The sectors in the "Sectors:" section are the ones in the starting=20
> cluster of the file.   Because  the file is unallocated and we know=20
> only the starting cluster (sectors), TSK tries to determine the=20
> remaining sectors.  Those are listed in the recovery section.  So, yes=20
> the "Recovery" section will always contain the sectors from the=20
> "Sectors" section.  They are separated to show which addresses we have=20
> more confidence in.  We know the 1545-1548 addresses are correct for=20
> the file because they are referenced by the directory entry, but the=20
> other addresses could be incorrect if the original file was fragmented=20
> and TSK couldn't determine the original layout.
>=20
> brian
>=20
>=20
>=20
>=20
> --__--__--
>=20
> _______________________________________________
> sleuthkit-users mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>=20
>=20
> End of sleuthkit-users Digest
>

Re: [sleuthkit-users] ISTAT output question

[Brian C. <ca...@sl...>]

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

[sleuthkit-users] ISTAT output question

[Jaime C. <jc...@id...>]

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.

Re: [sleuthkit-users] Corrupted floppy

[Enda C. <en...@co...>]

when dd'ing a floppy, try using bs=1 and conv=noerror, then mounting the
image under loopback.

Have had sucess recovering some files which suffered the "thesis field
effect" that way where there was physical damage to the disk. Document
probably won't be 100% intact, but the majority of the content was
recoverable.

HTH,

 -Enda.

----- Original Message ----- 
From: "Brian Carrier" <ca...@sl...>
To: "Pradeep M" <pra...@gm...>
Cc: <sle...@li...>
Sent: Monday, April 25, 2005 3:18 PM
Subject: Re: [sleuthkit-users] Corrupted floppy


> How do you mean "corrupted"?  Is the file system corrupt or is the
> physical media damaged and it generates errors when you try to read it?
>   If it is physical damage, then TSK / Autopsy will not help.  If it is
> file system corruption, then you can try them but they will not fix any
> errors that exist.  You can also make  an image of the floppy using
> 'dd' and then run fsck on a copy so that it fixes any errors.
>
> brian
>
>
>
> On Apr 25, 2005, at 5:15 AM, Pradeep M wrote:
>
> > Hi
> >         Is it possible to recover data from  a corrupted floppy using
> > sleuthkit and autopsy.
> > I tried using the tool but first of all its not possible to mount the
> > floppy itself. I want to know whether it is possible to recover data
> > from a corrupted floppy using this tool and if its not possible then
> > which tool should be used. Pls help.
> >
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] Corrupted floppy

[Brian C. <ca...@sl...>]

How do you mean "corrupted"?  Is the file system corrupt or is the 
physical media damaged and it generates errors when you try to read it? 
  If it is physical damage, then TSK / Autopsy will not help.  If it is 
file system corruption, then you can try them but they will not fix any 
errors that exist.  You can also make  an image of the floppy using 
'dd' and then run fsck on a copy so that it fixes any errors.

brian



On Apr 25, 2005, at 5:15 AM, Pradeep M wrote:

> Hi
>         Is it possible to recover data from  a corrupted floppy using
> sleuthkit and autopsy.
> I tried using the tool but first of all its not possible to mount the
> floppy itself. I want to know whether it is possible to recover data
> from a corrupted floppy using this tool and if its not possible then
> which tool should be used. Pls help.
>