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

Re: [sleuthkit-users] Help!! New to TSK and Linux

[Alan <ts...@as...>]

Hi Brian, Here are a few answers to your first questions.

Imaging to a Fat32 partition...
Either split up the image (I don't know the specific syntax to do this 
specifically) or format your hdb1 output partition in a filesystem that 
supports larger files. Ext3 will work, NTFS will also.

 >What is the advantage of imaging a drive over just cloning it? In other 
words, why would I want to create an image as opposed to a bit-for->bit 
copy of one drive to another?

When you image using dd, you are creating a bit-for-bit copy. dd reads each 
raw sector from input and writes to output. I think the distinction is 
grey. I consider imaging generally as writing the bit-for-bit to a file, 
while cloning as writing a bit-for-bit image directly to a blank drive.

 >Also, why wouldn't I use bs=8k as opposed bs=512?

Larger block sizes generally makes the imaging go faster. HTH

Alan

At 19:05 3/15/2005, you wrote:
>Hi, I am new to Linux and have a lot of questions.  Any help is HUGELY 
>appreciated . . . here is what I am trying to do.
>IMAGING
>I need to image a 17 Gig hard drive that is FAT32 (has Windows ME on it). 
>I am using the TSK bootable cd to do the imaging. My target drive is a 
>FAT32 formatted hard disk that is partitioned several times - All FAT32. I 
>am using the following command:
>
>dcfldd if=/dev/hda1 of=/mnt/hdb1/image.dd conv=noerror,sync hashwindow=0 
>hashlog= hash.txt
>
>This stops after 2 Gigs of copying due to the FAT32 file size limit being 
>exceeded. How do I get around this? Is it even possible with any 
>filesystem to create a 17 Gig image file?  Would I use a formatted ext3 
>file system?
>
>What is the advantage of imaging a drive over just cloning it? In other 
>words, why would I want to create an image as opposed to a bit-for-bit 
>copy of one drive to another?  Does it allow the forensic analyses to be 
>performed quicker?
>Also, why wouldn't I use bs=8k as opposed bs=512?
>
>AUTOPSY
>Because of the file size limit, I created a bit for bit clone of the disk, 
>from which I am attempting to use TSK forensic tools (which may or may not 
>be the correct approach).
>So with that, I began using autopsy.  I added a new case.  Gave it a host 
>name of 192.168.1.1 and timezone of PST.  I then added an image location 
>of /dev/hda1, symlink as the import method, fstype of fat32, mounting 
>point of /mnt/hda1, and ignore md5.  Is this a correct setup?  With this 
>setup I began to use the autopsy tools with the following results:
>
>-The keyword search didn't work - is this because I am using /mnt/hda1 
>instead of an image file?  Does this version of autopsy work using /mnt/hda1?
>-The sorter also did not work.  No output files in the directories 
>specified.  Is this also because I am not using an image as well?
>
>GREP
>Also, I have a general linux question.  Is there a way to speed up 
>grep?  I am searching the unallocated/slack space and it is taking forever 
>. . . here is the command I am using:
>             tr '[:cntrl:]' '\n' < /dev/hda1 | grep -aib tonja /dev/hda1 > 
> grephits.txt
>
>I would really like to use TSK - just need these issues addressed.  I 
>really want to use linux.  Heaven forbid purchasing a windows forensic 
>software package.
>
>Thanks so much in advance.
>
>Brian
>

[sleuthkit-users] Help!! New to TSK and Linux

[Brian S. <Br...@Pe...>]

Hi, I am new to Linux and have a lot of questions.  Any help is HUGELY
appreciated . . . here is what I am trying to do. 
IMAGING
I need to image a 17 Gig hard drive that is FAT32 (has Windows ME on it). I
am using the TSK bootable cd to do the imaging. My target drive is a FAT32
formatted hard disk that is partitioned several times - All FAT32. I am
using the following command: 

dcfldd if=/dev/hda1 of=/mnt/hdb1/image.dd conv=noerror,sync hashwindow=0
hashlog= hash.txt 

This stops after 2 Gigs of copying due to the FAT32 file size limit being
exceeded. How do I get around this? Is it even possible with any filesystem
to create a 17 Gig image file?  Would I use a formatted ext3 file system?  

What is the advantage of imaging a drive over just cloning it? In other
words, why would I want to create an image as opposed to a bit-for-bit copy
of one drive to another?  Does it allow the forensic analyses to be
performed quicker?  
Also, why wouldn't I use bs=8k as opposed bs=512?
 
AUTOPSY 
Because of the file size limit, I created a bit for bit clone of the disk,
from which I am attempting to use TSK forensic tools (which may or may not
be the correct approach).

So with that, I began using autopsy.  I added a new case.  Gave it a host
name of 192.168.1.1 and timezone of PST.  I then added an image location of
/dev/hda1, symlink as the import method, fstype of fat32, mounting point of
/mnt/hda1, and ignore md5.  Is this a correct setup?  With this setup I
began to use the autopsy tools with the following results:
 
-The keyword search didn't work - is this because I am using /mnt/hda1
instead of an image file?  Does this version of autopsy work using
/mnt/hda1?
-The sorter also did not work.  No output files in the directories
specified.  Is this also because I am not using an image as well?
 
GREP
Also, I have a general linux question.  Is there a way to speed up grep?  I
am searching the unallocated/slack space and it is taking forever . . . here
is the command I am using:
            tr '[:cntrl:]' '\n' < /dev/hda1 | grep -aib tonja /dev/hda1 >
grephits.txt
 
I would really like to use TSK - just need these issues addressed.  I really
want to use linux.  Heaven forbid purchasing a windows forensic software
package.  

Thanks so much in advance. 

Brian
 

Re: [sleuthkit-users] Presentation of Evidence

[Jon N. <qu...@li...>]

Regis Cassidy said:
> In theory, say you are using your digital forensics application. You
> complete your analysis and have now effectively completed you
> investigation. But now you need a way to show and explain everything yo=
u
> did and everything you discovered. You push the "generate report" butto=
n
> and the printer spits out a thick manuscript that details the whole
> entire investigation and you are done and ready to head to court. For
> the manuscript to be complete what all needs to be in it? Please respon=
d
> with you suggestions and sources of where I may obtain more information=
.

Regis,

It is important to note that there is no one report that could be
generated that would fit everyone's needs.  My reports will differ betwee=
n
investigations of different natures.  Any report generation mechanism
needs to have a great deal of flexibility so an individual can edit the
report to include/remove information pertinent to the specific
investigation.

I have looked into this in the past and thought using wiki to
generate/edit the report would make sense.  There are a lot of wiki
modules available at cpan:

    http://search.cpan.org/search?query=3Dwiki&mode=3Dall

There should be an interface that allows the user to select/remove every
aspect of the analysis for inclusion in the report. Then the user should
be able to edit the individual entries.

That's my opinion in a nutshell.

Jon



--
Trooper Jon S. Nelson, Linux Certified Admin., CCNA
Pa. State Police, Bureau of Criminal Investigation
Computer Crimes Unit
Work: 484-340-3609 Cell/Page: 866.284.1603
jonelson <at> state <dot> pa <dot> us

Re: [sleuthkit-users] Presentation of Evidence

[Angus M. <an...@n-...>]

In my experience, the court really has no interest in how I did what I did. 
The other expert might want to discuss it sometimes, but the court's main 
interest is in what I found and what it means. They certainly don't want to 
go through page after page of procedural information on top of the recovered 
files. This might be just a UK (England & Wales, and Scotland - different 
legal systems) perspective of course.

On a personal note, I'm concerned about the current UK CRFP proposals for 
accreditation of computer examiners. The last draft mechanism that I saw 
seemed to revolve around procedure with little interest in experience or 
qualifications.


On Thursday 10 March 2005 00:24, Regis Cassidy wrote:
> For my thesis I will be researching how digital analysis is properly
> logged and how the evidence is presented in court. I wish to add
> extensions to Brain's Autopsy Forensic Browser so that reports are
> automatically generated. I want these reports to provide a summary (or a
> timeline so to speak) of when the investigator performed what. I also
> want the reports to provide summaries of the actual evidence discovered
> during the investigation.  For example, the reports should contain
> information as to what deleted files have been recovered  and provide
> detailed information about the nature of that evidence. My question is,
> what is that detailed information? I have no experience on the legal
> side of digital forensics so I am hoping all you expert witnesses out
> there may be able to help me out. How should digital evidence be
> represented in court by means of a paper report? What is being done now
> and how do you think it can be done more effectively?
>
> In theory, say you are using your digital forensics application. You
> complete your analysis and have now effectively completed you
> investigation. But now you need a way to show and explain everything you
> did and everything you discovered. You push the "generate report" button
> and the printer spits out a thick manuscript that details the whole
> entire investigation and you are done and ready to head to court. For
> the manuscript to be complete what all needs to be in it? Please respond
> with you suggestions and sources of where I may obtain more information.
>
> Thanks in advance,
> Regis Cassidy
>
>
> -------------------------------------------------------
> 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

[sleuthkit-users] Presentation of Evidence

[Regis C. <reg...@sb...>]

For my thesis I will be researching how digital analysis is properly 
logged and how the evidence is presented in court. I wish to add 
extensions to Brain's Autopsy Forensic Browser so that reports are 
automatically generated. I want these reports to provide a summary (or a 
timeline so to speak) of when the investigator performed what. I also 
want the reports to provide summaries of the actual evidence discovered 
during the investigation.  For example, the reports should contain 
information as to what deleted files have been recovered  and provide 
detailed information about the nature of that evidence. My question is, 
what is that detailed information? I have no experience on the legal 
side of digital forensics so I am hoping all you expert witnesses out 
there may be able to help me out. How should digital evidence be 
represented in court by means of a paper report? What is being done now 
and how do you think it can be done more effectively?

In theory, say you are using your digital forensics application. You 
complete your analysis and have now effectively completed you 
investigation. But now you need a way to show and explain everything you 
did and everything you discovered. You push the "generate report" button 
and the printer spits out a thick manuscript that details the whole 
entire investigation and you are done and ready to head to court. For 
the manuscript to be complete what all needs to be in it? Please respond 
with you suggestions and sources of where I may obtain more information.

Thanks in advance,
Regis Cassidy

Re: [sleuthkit-users] ReiserFS support

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

On Mar 9, 2005, at 10:02 AM, Geovane Goncalves wrote:

> Hi,
>
> I would like to know if=A0exists forecast for ReiserFS and XFS =
support.=A0

There has been talk of Reiser support for quite some time (from me and=20=

various other people), but little (if any) progress has been made.

brian=

[sleuthkit-users] ReiserFS support

[Geovane G. <geo...@ig...>]

Hi,

I would like to know if exists forecast for ReiserFS and XFS support. =20


Grateful


Geovane Gon=E7alves
Brasil

[sleuthkit-users] Beta Testers Needed

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

My grandiose plans for v2 of TSK have been reduced because I have too 
many other projects going on.  The internal size changes, autodetect 
file system type, disk images, and split image support are complete in 
both TSK and Autopsy.  I have started to look at incorporating the 
Unicode and indexing support, but my gut feeling is that they will take 
a while.  Therefore, I think I am going to release v2 without them so 
that people can use the new disk image support sooner.

If anyone is interested in playing with the new versions before they 
are publicly released, then let me know (off-list).   They are both 
stable, but I would like a few additional people to use it.

brian

Re: [sleuthkit-users] Funky Partition Table

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

Sector 144585 should have a partition table in it for the extended 
partitions, but it does not seem to (it should end with the typical 
0xAA55 magic value).  Was that one of the errors?

The start of partition "5" should typically be 63 sectors after the 
start of the extended partition (which is 144648).  Check that sector 
to see if there is a file system there.  Do you know how many 
partitions there should be on the system?  If you can find a file 
system in 144648, then see how large the file system is, jump to the 
end of the FS and look for another partition table (or jump ahead 63 
more sectors and look for another file system).

Alternatively, you can use a tool like gpart or testdisk to search for 
the starting locations of the file systems.

brian



On Mar 3, 2005, at 4:49 PM, John T. Hoffoss wrote:

> ---> /usr/local/sleuthkit-1.73/bin/mmls -v -t dos **/images/**.dat
> dos_load_prim: Table Sector: 0
> load_pri:0:0    Start: 63   Size: 32067  Type: 22
> load_pri:0:1    Start: 32130   Size: 112455  Type: 6
> load_pri:0:2    Start: 144585   Size: 16305975  Type: 5
> dos_load_ext: Table Sector: 144585, Primary Base Sector: 144585
> /usr/local/sleuthkit-1.73/bin/mmls: Invalid extended partition table
> in sector 144585
>
> ---> fdisk -lu **/images/**.dat
> Warning: ignoring extra data in partition table 5
> Warning: ignoring extra data in partition table 5
> Warning: invalid flag 0x4fe0 of partition table 5 will be corrected by 
> w(rite)
>
> Disk **/images/**.dat: 9102 MB, 9102397440 bytes
> 255 heads, 63 sectors/track, 1106 cylinders, total 17778120 sectors
> Units = sectors of 1 * 512 = 512 bytes
>
>                Device Boot      Start         End      Blocks   Id  
> System
> **/images/**.dat1              63       32129       16033+  16  Hidden 
> FAT16
> **/images/**.dat2   *       32130      144584       56227+   6  FAT16
> **/images/**.dat3          144585    16450559     8152987+   5  
> Extended
> **/images/**.dat5   ?      212045  2382538316  1191163136   76  Unknown

Re: [sleuthkit-users] Funky Partition Table

[Rich T. <te...@ap...>]

John,
See my notes below.


--- "John T. Hoffoss" <joh...@gm...>
wrote:

> ---> /usr/local/sleuthkit-1.73/bin/mmls -v -t dos
> **/images/**.dat
> dos_load_prim: Table Sector: 0
> load_pri:0:0    Start: 63   Size: 32067  Type: 22
> load_pri:0:1    Start: 32130   Size: 112455  Type: 6
> load_pri:0:2    Start: 144585   Size: 16305975 
> Type: 5
> dos_load_ext: Table Sector: 144585, Primary Base
> Sector: 144585
> /usr/local/sleuthkit-1.73/bin/mmls: Invalid extended
> partition table
> in sector 144585
> 
> ---> fdisk -lu **/images/**.dat
> Warning: ignoring extra data in partition table 5
> Warning: ignoring extra data in partition table 5
> Warning: invalid flag 0x4fe0 of partition table 5
> will be corrected by w(rite)
> 
> Disk **/images/**.dat: 9102 MB, 9102397440 bytes
> 255 heads, 63 sectors/track, 1106 cylinders, total
> 17778120 sectors
> Units = sectors of 1 * 512 = 512 bytes
> 
>                Device Boot      Start         End   
>   Blocks   Id  System
> **/images/**.dat1              63       32129      
> 16033+  16  Hidden FAT16
> **/images/**.dat2   *       32130      144584      
> 56227+   6  FAT16
> **/images/**.dat3          144585    16450559    
> 8152987+   5  Extended
> **/images/**.dat5   ?      212045  2382538316 
> 1191163136   76  Unknown
> 
> 
> That says it all. :) Sort of.



 
> So the problem lies in the fact that partition 3 is
> extended, which,
> to my understanding, means partition 5 should be an
> identical size.
> But neither start nor end for partitions 3 or 5 are
> the same, or
> sequential, but instead just overlap.

I don't think this is problem.  I'd have to pull out
some of my parition stuff - but the fact that the
extended 3, and unknown 5 aren't the same shouldn't be
an issue.  Althought I haven't seen this type of drive
set up in a while, I don't ever remember seeing an
extended and its children being the same.  But I might
be wrong.

 
> Manually viewing sectors before or after 144585,
> 212045, and 16450559
> do not appear to contain any special data indicating
> the start or end
> of a partition, either. Any ideas, tools, data I can
> look for to
> identify what is actually on this disk?

Do a search for WINS4.1, when you find it, look at the
hex output for that/those sectors, 3 characters before
the WINS4.1 you should see, in hex, EB - that is the
beginning of your partition.

Also, the master boot record indicated the first
partion started at sector 63.  So, you need to go to
sectors  144647, 212107 for the beginning of those
partitons (the ending sector of the last partition +
63)... they should be there.

See ya,
Rich

[sleuthkit-users] Funky Partition Table

[John T. H. <joh...@gm...>]

---> /usr/local/sleuthkit-1.73/bin/mmls -v -t dos **/images/**.dat
dos_load_prim: Table Sector: 0
load_pri:0:0    Start: 63   Size: 32067  Type: 22
load_pri:0:1    Start: 32130   Size: 112455  Type: 6
load_pri:0:2    Start: 144585   Size: 16305975  Type: 5
dos_load_ext: Table Sector: 144585, Primary Base Sector: 144585
/usr/local/sleuthkit-1.73/bin/mmls: Invalid extended partition table
in sector 144585

---> fdisk -lu **/images/**.dat
Warning: ignoring extra data in partition table 5
Warning: ignoring extra data in partition table 5
Warning: invalid flag 0x4fe0 of partition table 5 will be corrected by w(rite)

Disk **/images/**.dat: 9102 MB, 9102397440 bytes
255 heads, 63 sectors/track, 1106 cylinders, total 17778120 sectors
Units = sectors of 1 * 512 = 512 bytes

               Device Boot      Start         End      Blocks   Id  System
**/images/**.dat1              63       32129       16033+  16  Hidden FAT16
**/images/**.dat2   *       32130      144584       56227+   6  FAT16
**/images/**.dat3          144585    16450559     8152987+   5  Extended
**/images/**.dat5   ?      212045  2382538316  1191163136   76  Unknown


That says it all. :) Sort of.

I dd'd this drive (NT4) and went to look at it later, to find it had a
goofed partition table. Unfortunately, I had about six read errors
while imaging on this disk that I bypassed by passing dd the flag
conv=noerror. I can get back to this system if I have to, but if
anyone has any idea what is going on, it'd be nice to not have to go
touch this system again. None of these errors were anywhere near the
partition table of the disk.

So the problem lies in the fact that partition 3 is extended, which,
to my understanding, means partition 5 should be an identical size.
But neither start nor end for partitions 3 or 5 are the same, or
sequential, but instead just overlap.

Manually viewing sectors before or after 144585, 212045, and 16450559
do not appear to contain any special data indicating the start or end
of a partition, either. Any ideas, tools, data I can look for to
identify what is actually on this disk?

Re: [sleuthkit-users] two directory entries for same deleted file in FAT16

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

On Mar 1, 2005, at 7:27 AM, Alan wrote:

> Hello Brian, Thanks for the reply.
>
> I just want to say you have done something invaluable for the infosec 
> community by writing the tsk and autopsy tools, and contributing them 
> open-source.

Thanks.

> One little suggestion. When tsk/autopsy is creating the timeline from 
> a FAT image, it sets the a-time to 00:00. When looking at this for the 
> first time, I was mystified. Was the system left on overnight and 
> somehow Windows touches all the files at midnight? It wasn't until I 
> read the FAT spec that it turned out there is no field for the a-time, 
> just the a-date. There is really no a-time information at all.
>
> One could argue that putting the 00:00 time could compromise something 
> if opposing counsel says, hey this timeline says the file was accessed 
> at midnight and my client isn't at the office at midnight. Of course 
> you could explain that as I did above. But if I were to create my own 
> timeline I would denote the a-date with a-time unknown.

Unfortunately, that makes the program much more complex if I were to 
include all of the different special cases for each file system.  Plus, 
where would the entries go in the timeline?  The current behavior for 
each file system is described in the docs/skins_* files and the fat 
file has a note about timezones and last access times.  I guess one 
simple solution would be to replace the 00:00:00 time with something 
like 0-:--:-- so that it always sorts to the top of the list, but is 
more obvious that it is not a real time.

brian

Re: [sleuthkit-users] two directory entries for same deleted file in FAT16

[Alan <ts...@as...>]

Hello Brian, Thanks for the reply.

I just want to say you have done something invaluable for the infosec 
community by writing the tsk and autopsy tools, and contributing them 
open-source.

One little suggestion. When tsk/autopsy is creating the timeline from a FAT 
image, it sets the a-time to 00:00. When looking at this for the first 
time, I was mystified. Was the system left on overnight and somehow Windows 
touches all the files at midnight? It wasn't until I read the FAT spec that 
it turned out there is no field for the a-time, just the a-date. There is 
really no a-time information at all.

One could argue that putting the 00:00 time could compromise something if 
opposing counsel says, hey this timeline says the file was accessed at 
midnight and my client isn't at the office at midnight. Of course you could 
explain that as I did above. But if I were to create my own timeline I 
would denote the a-date with a-time unknown.

Alan

At 01:09 3/1/2005, you wrote:

>On Feb 27, 2005, at 6:03 PM, Alan wrote:
>
>>Some deleted files have two directory entries. I'm not talking about LFN 
>>entries, I see those too. But the entries I'm talking about have 
>>attribute value 0x20 (archive). These entries are very similar, both have 
>>the deleted 0x2E flag at byte 0. The dates are different, but the kicker 
>>is one of the entries has the six least significant bits (cluster address 
>>and file size) set to all zeros. The other entry has real values that 
>>were the cluster address and file size of the file.
>>
>>Why does this happen? Does it have to do with LFN or something about file 
>>deletion? Why are there two attribute 0x20 entries for the same file?
>
>I noticed this same behavior when I was looking at the various FAT 
>allocation strategies for the FSFA book.  I found that Windows XP 
>applications would create the basic entry with zero size and starting 
>address and then create a second entry with the size and starting 
>address.  Creating a file from the command line or drag and dropping 
>wouldn't do it, but creating the file from a 'save' in an application would.
>
>brian
>
>
>
>
>-------------------------------------------------------
>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] Why does Foremost hate me???

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

On Feb 28, 2005, at 9:32 PM, Rich Thompson wrote:

> Howdy folks,
>
> Tyring to install Foremost 0.69 w/ problems.  Whne I
> run the make install I get:
>
> install -CDm 755 foremost   /usr/local/bin/foremost
> install: invalid option -- C
> Try `install --help' for more information.
> make: *** [install] Error 1
>
> what gives????

You can edit the Makefile and remove the '-C' from lines 58 & 59.  I'm 
not sure if Jesse is on this list or not, but the site says to use 
res...@je... for questions.

brian

Re: [sleuthkit-users] two directory entries for same deleted file in FAT16

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

On Feb 27, 2005, at 6:03 PM, Alan wrote:

> Some deleted files have two directory entries. I'm not talking about 
> LFN entries, I see those too. But the entries I'm talking about have 
> attribute value 0x20 (archive). These entries are very similar, both 
> have the deleted 0x2E flag at byte 0. The dates are different, but the 
> kicker is one of the entries has the six least significant bits 
> (cluster address and file size) set to all zeros. The other entry has 
> real values that were the cluster address and file size of the file.
>
> Why does this happen? Does it have to do with LFN or something about 
> file deletion? Why are there two attribute 0x20 entries for the same 
> file?

I noticed this same behavior when I was looking at the various FAT 
allocation strategies for the FSFA book.  I found that Windows XP 
applications would create the basic entry with zero size and starting 
address and then create a second entry with the size and starting 
address.  Creating a file from the command line or drag and dropping 
wouldn't do it, but creating the file from a 'save' in an application 
would.

brian
  

[sleuthkit-users] Why does Foremost hate me???

[Rich T. <te...@ap...>]

Howdy folks,

Tyring to install Foremost 0.69 w/ problems.  Whne I
run the make install I get:

install -CDm 755 foremost   /usr/local/bin/foremost
install: invalid option -- C
Try `install --help' for more information.
make: *** [install] Error 1


what gives????

I am installing it on an AMD64 machine running Sus3
9.2.

TIA,
Rich

[sleuthkit-users] two directory entries for same deleted file in FAT16

[Alan <ts...@as...>]

Hello, I'm sort of new to the exciting world of filesystem forensics. I'm 
analyzing this relatively simple FAT16 image of a USB drive in TSK and 
Autopsy, but there was something confusing. So after examining the FAT16 
spec in detail and looking at the 32-byte directory entries in hex, I have 
a question.

Some deleted files have two directory entries. I'm not talking about LFN 
entries, I see those too. But the entries I'm talking about have attribute 
value 0x20 (archive). These entries are very similar, both have the deleted 
0x2E flag at byte 0. The dates are different, but the kicker is one of the 
entries has the six least significant bits (cluster address and file size) 
set to all zeros. The other entry has real values that were the cluster 
address and file size of the file.

Why does this happen? Does it have to do with LFN or something about file 
deletion? Why are there two attribute 0x20 entries for the same file?

I would appreciate a hint here. Thanks.

Regards,

Alan

Re: [sleuthkit-users] How to retrieve data from a corrupted floppy

[Paul B. <p.j...@br...>]

Under linux you can use:
dd if=/dev/fd0 of=floppyimg conv=sync,noerror bs=512

This tries to read all data it can from the floppy and puts it in
floppyimg.

After that, run for instance foremost on the image to retrieve recoverable files.

Paul Bakker
On Mon, Feb 21, 2005 at 06:04:06PM +0530, Pradeep M wrote:
> How to retrieve data from a corrupted floppy? If anyone has any idea
> regarding this,
> do reply me to this id.
> 
> 
> -------------------------------------------------------
> 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

[sleuthkit-users] How to retrieve data from a corrupted floppy

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

How to retrieve data from a corrupted floppy? If anyone has any idea
regarding this,
do reply me to this id.

Re: [sleuthkit-users] Words of wisdom on recent SHA collisions

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

Sorry the numbers 269 and 280 should read in exponential notation. The 
correction is 2**69 and 2**80 respectively

Gary Palmer wrote:

> Hi,
> Just received this from Doug White (NIST) who is attending RSA. He and 
> his colleagues has some thoughtful statements about the state of SHA 
> both theoretically and in practice.
> ciao,
> Gary
> ********************
>
> Gary,
>
> I'm replying to you, and, as I can't post to CFID, if you wish to
> forward this, you may.
>
> Let me first say I am not in the Computer Security Division at NIST,
> and my opinions do not represent NIST's official response to this
> SHA-1 collision news.
>
> At RSA on Tuesday morning, Shamir made the statement that he had
> received an email over the weekend from a team claiming to have
> manufactured a full SHA-1 collision in 269. From his statements,
> I (and others) assume that he has seen an advance copy of a paper
> or an outline of the process, and that there is no public release
> of the work yet, with no expected date.
>
> While this is fascinating and an advance on several fronts - collision
> through 80 rounds, in well under 280 (theoretical threshold) - I
> do not believe it affects the usefulness of SHA-1 as applied in
> our situation. There has always been a possibility of SHA-1 collisions,
> the probability of SHA-1 collisions has not, as far as I can see,
> been raised greatly. I do not know but I highly doubt that this new
> research could lead to a preimage attack.
>
> There are more SHA-1 related tracks at RSA today that I will be
> attending, and if any news comes out there, I will forward it on
> to you and the list.
>
> Doug
>
>
>>>>> This year, Eli Biham and Rafi
>>>>> Chen, and separately Antoine Joux, announced some pretty impressive
>>>>> cryptographic results against MD5 and SHA. Collisions have been
>>>>> demonstrated in SHA. And there are rumors, unconfirmed at this
>>>>> writing, of results against SHA-1.
>>>>>
>>>>> The magnitude of these results depends on who you are. If you're a
>>>>> cryptographer, this is a huge deal. ....
>>>>>
>>>>> To a user of cryptographic systems -- as I assume most readers are --
>>>>> this news is important, but not particularly worrisome. MD5 and SHA
>>>>> aren't suddenly insecure. No one is going to be breaking digital
>>>>> signatures or reading encrypted messages anytime soon with these
>>>>> techniques. The electronic world is no less secure after these
>>>>> announcements than it was before.
>>>>
>>>   
>>
>
>
> Douglas White           National Institute of Standards and Technology
> National Software Reference Library - http://www.nsrl.nist.gov
> NIST, 100 Bureau Drive Stop 8970, Gaithersburg, MD 20899-8970
> Voice: 301-975-4761   Fax: 301-926-3696   Email:dou...@ni...
> My opinions aren't necessarily my employer's nor any other 
> organization's.
>        "It would be better if it was perfect."
>
>
>
>
>
> -------------------------------------------------------
> 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
>

[sleuthkit-users] Words of wisdom on recent SHA collisions

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

Hi,
Just received this from Doug White (NIST) who is attending RSA. He and 
his colleagues has some thoughtful statements about the state of SHA 
both theoretically and in practice.
ciao,
Gary
********************

Gary,

I'm replying to you, and, as I can't post to CFID, if you wish to
forward this, you may.

Let me first say I am not in the Computer Security Division at NIST,
and my opinions do not represent NIST's official response to this
SHA-1 collision news.

At RSA on Tuesday morning, Shamir made the statement that he had
received an email over the weekend from a team claiming to have
manufactured a full SHA-1 collision in 269. From his statements,
I (and others) assume that he has seen an advance copy of a paper
or an outline of the process, and that there is no public release
of the work yet, with no expected date.

While this is fascinating and an advance on several fronts - collision
through 80 rounds, in well under 280 (theoretical threshold) - I
do not believe it affects the usefulness of SHA-1 as applied in
our situation. There has always been a possibility of SHA-1 collisions,
the probability of SHA-1 collisions has not, as far as I can see,
been raised greatly. I do not know but I highly doubt that this new
research could lead to a preimage attack.

There are more SHA-1 related tracks at RSA today that I will be
attending, and if any news comes out there, I will forward it on
to you and the list.

Doug


>>>> This year, Eli Biham and Rafi
>>>> Chen, and separately Antoine Joux, announced some pretty impressive
>>>> cryptographic results against MD5 and SHA. Collisions have been
>>>> demonstrated in SHA. And there are rumors, unconfirmed at this
>>>> writing, of results against SHA-1.
>>>>
>>>> The magnitude of these results depends on who you are. If you're a
>>>> cryptographer, this is a huge deal. ....
>>>>
>>>> To a user of cryptographic systems -- as I assume most readers are --
>>>> this news is important, but not particularly worrisome. MD5 and SHA
>>>> aren't suddenly insecure. No one is going to be breaking digital
>>>> signatures or reading encrypted messages anytime soon with these
>>>> techniques. The electronic world is no less secure after these
>>>> announcements than it was before.
>>    
>>


Douglas White           National Institute of Standards and Technology
 National Software Reference Library - http://www.nsrl.nist.gov
NIST, 100 Bureau Drive Stop 8970, Gaithersburg, MD 20899-8970
Voice: 301-975-4761   Fax: 301-926-3696   Email:dou...@ni...
My opinions aren't necessarily my employer's nor any other organization's.
        "It would be better if it was perfect."

[sleuthkit-users] Re: [sleuthkit-developers] Possible Suggestion for timeline creation in future versions of Autopsy

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

I can add this to the TODO list.  The basic concept can be achieved=20
using the file name search in the File Mode, but then you can sort only=20=

on one of the times and not a full timeline.

brian


On Feb 15, 2005, at 1:24 AM, Surago Jones wrote:

> Hi all,
>
> Whilst using Autopsy, and testing with a couple different suspect
> images, I have found that now and again I am often running several
> commands from the command line to help the investigation process.
>
> One process I often complete as part of an investigation is to create =
a
> timeline of files and folders that start with a '.' (dot).  I was
> thinking that an additional option in the 'Create Timeline' feature of
> Autopsy could allow an extra step to be run that would run grep to=20
> limit
> the timeline to certain details..
>
> For example, I run the following command to get a timeline of all '.'
> (dot) folders and files...
>
> grep '\/\.' flsdatafile > fls-dotfiles.dat
>
> It would be useful if on the 'Create Timeline' form, if the user could
> click a button (Similar to the pre-defined search options, on the=20
> search
> form) in order to create various useful timelines.   Another example
> would be to create a timeline of only the 'dev' folders.
>
> If this could be templated in some way, then maybe people could
> place/upload their own search options/template on the sleuthkit=20
> website,
> as whilst each investigation differs from each other, there is still
> some common ground.
>
> In the case of the dot files, it currently appears to be a common
> practice of intruders to utilise files and folders starting with a =
dot.
> Obviously, as time progresses and development on the rootkit side of
> things and the forensic side of things this practice may become rare =
as
> it is an easy method for identifying possible suspect files and=20
> folders.
>
> Just an idea I thought would help improve Autopsy's usability.
>
> Cheers
>
> Surago
>
>
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-users] Win98 registry

[Nathan C. <na...@cc...>]

Well I should really have preempted the requests for the 2.4 hack for
the ntreg driver. So here it is;

I am not supporting this hack in any way, if it doesn't work for you
then tough luck. If you want to run with this then good luck.

regards,

Nathan

--
Computer Crime Consultants Ltd
http://www.ccc-ltd.com

Support the fight against software patents:
http://www.NoSoftwarePatents.com
http://swpat.ffii.org

[sleuthkit-users] DFRWS 2005 CFP

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

**** DFRWS announces the Preliminary Call for Papers. Please have a look 
at http://www.dfrws.org ****
The DFRWS has undergone some administrative changes since last years 
event. Last October government budget tightening threatened support for 
the workshop. In fact, I was convinced there wouldn't be a workshop this 
year. I even told a few people that with some certainty.  However, in 
the past few weeks a group of DFRWS members, some whose names you will 
recognize, have decided to help keep it going by volunteering for 
leadership roles. Dan Kalil and I will still be involved, but from now 
on more researchers and practitioners from the digital forensics 
community will be actively engaged in all aspects of the workshop. You 
can expect to be hearing from them as well. This change promises to add 
relevance and freshness to the agenda and help make DFRWS more effective 
in solving the many tough, and constantly morphing, technical and legal 
challenges we face. So, expect to see some exciting changes to DFRWS in 
the comming weeks and months leading up to the next event.
Please take a look at the website. The CFP has been posted as well as 
some new contacts. More complete information will be added over the next 
few weeks as our new commitee agrees on procedures, plans and content 
for the DFRWS this August, 17-19 in New Orleans. So mark your calendars
Thanks for your time,
Gary

[sleuthkit-users] Possible Suggestion for timeline creation in future versions of Autopsy

[Surago J. <su...@sj...>]

Hi all,

Whilst using Autopsy, and testing with a couple different suspect
images, I have found that now and again I am often running several
commands from the command line to help the investigation process.

One process I often complete as part of an investigation is to create a
timeline of files and folders that start with a '.' (dot).  I was
thinking that an additional option in the 'Create Timeline' feature of
Autopsy could allow an extra step to be run that would run grep to limit
the timeline to certain details..

For example, I run the following command to get a timeline of all '.'
(dot) folders and files...

grep '\/\.' flsdatafile > fls-dotfiles.dat

It would be useful if on the 'Create Timeline' form, if the user could
click a button (Similar to the pre-defined search options, on the search
form) in order to create various useful timelines.   Another example
would be to create a timeline of only the 'dev' folders.

If this could be templated in some way, then maybe people could
place/upload their own search options/template on the sleuthkit website,
as whilst each investigation differs from each other, there is still
some common ground. =20

In the case of the dot files, it currently appears to be a common
practice of intruders to utilise files and folders starting with a dot.
Obviously, as time progresses and development on the rootkit side of
things and the forensic side of things this practice may become rare as
it is an easy method for identifying possible suspect files and folders.

Just an idea I thought would help improve Autopsy's usability.

Cheers=20

Surago