Nabble - sleuthkit-users

Autopsy not displaying "lookup" button in metadata view

2009-12-18T08:25:52Z

Hi All,

I'm using Autopsy 2.21/TSK 3.0.1 (w/ Debian) and have both
an NSRLFile.txt as well as my own md5 alert database configured.
According to the documentation the corresponding index files have been
created using hfind and been configured in the conf.pl and the host
configuration file, respectively. Autopsy has been restarted.

While Autopsy's "Hash Database Manager" works fine I don't get any
of the "lookup" checkboxes I expected to see when viewing the metadata
of an Inode.

What am I missing here?

Thanks in advance!

Stefan.

--
Stefan Kelm <skelm@...>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstrasse 100 Tel: +49-721-96201-1
D-76133 Karlsruhe Fax: +49-721-96201-99

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: OT Simson on the CyberSpeak podcast.

2009-12-14T15:24:04Z

Great job on the interview, Simson. It was very interesting!
Ken

On Mon, Dec 14, 2009 at 10:53 AM, Ron McGill <ronm@...> wrote:

Simson gives a great interview on CyberSpeak. Check it out...

http://cyberspeak.libsyn.com/

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev

_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: Sector number -> filenumber within the API

2009-12-14T13:28:53Z

Hi Simson,

The 'ifind' program uses the 'inode_walk' method to walk all of the files and then uses the 'file_walk' method on each file to get the blocks for that file. It then looks for a file that uses that sector. This is all done in the tsk_fs_ifind_data() method, which is unfortunately not very library friendly right now. It prints the results to STDOUT instead of returning them in a structure. If you want to help fix that function to return data instead of printing it, I can work it into the code.

The methods in tsk_fs_ifind_data() are the same ones used in the TSK samples (and fiwalk). Is there a specific method you are looking for?

brian

On Dec 13, 2009, at 10:46 AM, Simson Garfinkel wrote:

> A few weeks ago we discussed the command-level commands for turning a sector number into a file number.
>
> I would like to do this from within the Sleuthkit API. My current approach is to create a map of the entire hard drive and then search the map. This has some scaling problems. Is there a more efficient approach?
>
> I am looking for the specific calling sequence to take any sector number on any hard drive and turn it into some kind of data structure that will tell me if it is unallocated between partitions, within a partition, file system metadata, or within a specific file.
>
> Thanks!
>
>
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

OT Simson on the CyberSpeak podcast.

2009-12-14T08:53:05Z

Simson gives a great interview on CyberSpeak. Check it out...

http://cyberspeak.libsyn.com/

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Sector number -> filenumber within the API

2009-12-13T07:46:41Z

A few weeks ago we discussed the command-level commands for turning a sector number into a file number.

I would like to do this from within the Sleuthkit API. My current approach is to create a map of the entire hard drive and then search the map. This has some scaling problems. Is there a more efficient approach?

I am looking for the specific calling sequence to take any sector number on any hard drive and turn it into some kind of data structure that will tell me if it is unallocated between partitions, within a partition, file system metadata, or within a specific file.

Thanks!

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Sleuthkit JNI

2009-12-13T07:45:04Z

Has anybody created JNI bindings for Sleuthkit, allowing the API to be called from Java?

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

tsk_img_open_utf8 changed signature

2009-12-10T09:56:21Z

tsk_img_open_utf8 changed signature moving from SleuthKit 3.0 to 3.1.

How do I write my code to handle both versions? There is no #define that I can find in the SleuthKit includes that provides the version number.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

TSK Forensic Browser Demonstration Paper

2009-12-07T06:46:30Z

I am working through the example cases in Anthony Dowling's "The Sleuth Kit v2.01 and Autopsy Forensic Browser Demonstration" paper (http://www.sjones.co.nz/downloads/Files/Forensics/TSK_v201_Demonstration.pdf) and stumped by what looks like a basic. On page 108 the paper shows FILE SYSTEM INFORMATION and the File System Layout (in sectors) for the suspect floppy reported as Total Range: 0 - 2879. So far so good. I expected a floppy to have a total of 2,880 sectors. My question is about the output on page 111. The text refers to sectors 33 to 2879, yet the Autopsy output screen shot shows Hex Contents of Sectors 33-2878. What am I missing? Where is sector 2879? I tried using Data Unit mode to locate sector 2879 and Autopsy returns: Invalid API argument (tsk_fs_blkcat: requested size is larger than last block in image (2879)). I'd appreciate any help trying to understand this.

--
Suman Beros
suman.beros@...

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: beta 3.1.0b1 - tsk3/fs/tsk_fs_i.h

2009-12-07T06:33:48Z

On Dec 6, 2009, at 12:28 AM, Simson Garfinkel wrote:

> tsk_fs_make_ls(TSK_FS_META *, char *); is declared in tsk_fs_i.h , but tsk_fs_i.h is not installed into /usr/local/include/tsk3 in the 3.1 beta. Can it be added?

The *_i.h files are the internal functions that are not intended to be used by programs using the library. There is an open feature request to move this function to the tsk_fs.h file. I have that on my list of features to add before the official release. I need to clean up the naming a bit to make it consistent with the other exported functions.

thanks,
brian

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: 3.10b1 - tsk_img_open_utf8

2009-12-07T06:31:42Z

Thanks. The Doxygen API docs (when they are generated for the the new release) have the description of the new arguments. I added the name to the header file.

brian

On Dec 5, 2009, at 2:07 PM, Simson Garfinkel wrote:

> Sleuthkit 3.1 changes the calling sequence of tsk_img_open_utf8.
>
> The new calling sequence is:
>
> extern TSK_IMG_INFO *tsk_img_open_utf8(int num_img,
> const char *const images[], TSK_IMG_TYPE_ENUM type, unsigned int);
>
> This is good news --- apparently the new argument is the sector size (0 for default).
>
> But it would be nice if the #include file gave a name for the fourth argument, rather than just calling it "unsigned int"
>
> Please change the include file to read:
>
> extern TSK_IMG_INFO *tsk_img_open_utf8(int num_img,
> const char *const images[], TSK_IMG_TYPE_ENUM type, unsigned int sector_size);
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

beta 3.1.0b1 - tsk3/fs/tsk_fs_i.h

2009-12-05T21:28:13Z

tsk_fs_make_ls(TSK_FS_META *, char *); is declared in tsk_fs_i.h , but tsk_fs_i.h is not installed into /usr/local/include/tsk3 in the 3.1 beta. Can it be added?

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

3.10b1 - tsk_img_open_utf8

2009-12-05T11:07:18Z

Sleuthkit 3.1 changes the calling sequence of tsk_img_open_utf8.

The new calling sequence is:

extern TSK_IMG_INFO *tsk_img_open_utf8(int num_img,
const char *const images[], TSK_IMG_TYPE_ENUM type, unsigned int);

This is good news --- apparently the new argument is the sector size (0 for default).

But it would be nice if the #include file gave a name for the fourth argument, rather than just calling it "unsigned int"

Please change the include file to read:

extern TSK_IMG_INFO *tsk_img_open_utf8(int num_img,
const char *const images[], TSK_IMG_TYPE_ENUM type, unsigned int sector_size);

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: TSK 3.0.1 crashes with truncated volumes

2009-12-01T19:12:55Z

Thanks for the trace. I fixed it and it is checked into the trunk.

thanks,
brian

On Dec 1, 2009, at 9:54 PM, Simson Garfinkel wrote:

> Hi, Brian. I also got it to crash with TSK 3.1beta
>
> (gdb) run -o63 ~/0411.iso
> Starting program: /Users/simsong/domex/src/dist/sleuthkit-3.1.0b1/
> tools/fstools/fls -o63 ~/0411.iso
> Reading symbols for shared libraries .+++++++++. done
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x00000001007f9ff0
> 0x00007fffffe00f40 in __memcpy ()
> (gdb) where
> #0 0x00007fffffe00f40 in __memcpy ()
> #1 0x0000000100004580 in __inline_memcpy_chk (__dest=0x100801e00,
> __src=0x1001ce014, __len=18446744073709519360) at _string.h:58
> #2 0x0000000100004285 in tsk_img_read (a_img_info=0x10018e000,
> a_off=97792, a_buf=0x100801e00 "", a_len=1536) at img_io.c:71
> #3 0x000000010003e8e6 in tsk_fs_read (a_fs=0x1002007a0,
> a_off=65536, a_buf=0x100801e00 "", a_len=1536) at fs_io.c:63
> #4 0x00000001000364a2 in ffs_open (img_info=0x10018e000,
> offset=32256, ftype=TSK_FS_TYPE_FFS_DETECT) at ffs.c:1963
> #5 0x000000010003ffc8 in tsk_fs_open_img (a_img_info=0x10018e000,
> a_offset=32256, a_ftype=TSK_FS_TYPE_DETECT) at fs_open.c:157
> #6 0x0000000100001457 in main (argc=<value temporarily unavailable,
> due to optimizations>, argv1=0x7fff5fbfef80) at fls.cpp:263
> (gdb) up
> #1 0x0000000100004580 in __inline_memcpy_chk (__dest=0x100801e00,
> __src=0x1001ce014, __len=18446744073709519360) at _string.h:58
> 58 return __builtin___memcpy_chk (__dest, __src, __len,
> __darwin_obsz0(__dest));
> Current language: auto; currently c
> (gdb) up
> #2 0x0000000100004285 in tsk_img_read (a_img_info=0x10018e000,
> a_off=97792, a_buf=0x100801e00 "", a_len=1536) at img_io.c:71
> 71 memcpy(a_buf,
> (gdb) list 65,75
> 65 if (tsk_verbose)
> 66 fprintf(stderr,
> 67 "tsk_img_read: Read found in cache %d\n", i);
> 68 */
> 69
> 70 // We found it...
> 71 memcpy(a_buf,
> 72 &a_img_info->cache[i][a_off -
> 73 a_img_info->cache_off[i]], len2);
> 74 retval = (ssize_t) len2;
> 75
> (gdb) p a_buf
> $1 = 0x100801e00 ""
> (gdb) p i
> $2 = 3
> (gdb) p a_off
> $3 = 97792
> (gdb) p a_img_info->cache_off[i]
> $4 = 32256
> (gdb) p len2
> $5 = 18446744073709519360
> (gdb)
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: TSK 3.0.1 crashes with truncated volumes

2009-12-01T18:54:49Z

Hi, Brian. I also got it to crash with TSK 3.1beta

(gdb) run -o63 ~/0411.iso
Starting program: /Users/simsong/domex/src/dist/sleuthkit-3.1.0b1/tools/fstools/fls -o63 ~/0411.iso
Reading symbols for shared libraries .+++++++++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000001007f9ff0
0x00007fffffe00f40 in __memcpy ()
(gdb) where
#0 0x00007fffffe00f40 in __memcpy ()
#1 0x0000000100004580 in __inline_memcpy_chk (__dest=0x100801e00, __src=0x1001ce014, __len=18446744073709519360) at _string.h:58
#2 0x0000000100004285 in tsk_img_read (a_img_info=0x10018e000, a_off=97792, a_buf=0x100801e00 "", a_len=1536) at img_io.c:71
#3 0x000000010003e8e6 in tsk_fs_read (a_fs=0x1002007a0, a_off=65536, a_buf=0x100801e00 "", a_len=1536) at fs_io.c:63
#4 0x00000001000364a2 in ffs_open (img_info=0x10018e000, offset=32256, ftype=TSK_FS_TYPE_FFS_DETECT) at ffs.c:1963
#5 0x000000010003ffc8 in tsk_fs_open_img (a_img_info=0x10018e000, a_offset=32256, a_ftype=TSK_FS_TYPE_DETECT) at fs_open.c:157
#6 0x0000000100001457 in main (argc=<value temporarily unavailable, due to optimizations>, argv1=0x7fff5fbfef80) at fls.cpp:263
(gdb) up
#1 0x0000000100004580 in __inline_memcpy_chk (__dest=0x100801e00, __src=0x1001ce014, __len=18446744073709519360) at _string.h:58
58 return __builtin___memcpy_chk (__dest, __src, __len, __darwin_obsz0(__dest));
Current language: auto; currently c
(gdb) up
#2 0x0000000100004285 in tsk_img_read (a_img_info=0x10018e000, a_off=97792, a_buf=0x100801e00 "", a_len=1536) at img_io.c:71
71 memcpy(a_buf,
(gdb) list 65,75
65 if (tsk_verbose)
66 fprintf(stderr,
67 "tsk_img_read: Read found in cache %d\n", i);
68 */
69
70 // We found it...
71 memcpy(a_buf,
72 &a_img_info->cache[i][a_off -
73 a_img_info->cache_off[i]], len2);
74 retval = (ssize_t) len2;
75
(gdb) p a_buf
$1 = 0x100801e00 ""
(gdb) p i
$2 = 3
(gdb) p a_off
$3 = 97792
(gdb) p a_img_info->cache_off[i]
$4 = 32256
(gdb) p len2
$5 = 18446744073709519360
(gdb)

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: 3.1.0 beta

2009-12-01T18:28:09Z

Hi Adric,

Thanks. If you could check for missing files and errors about
unexpected data, then that would be great.

thanks,
brian

On Nov 30, 2009, at 8:59 PM, Adric Net wrote:

> Hi,
>
> I've got the beta loaded up on my MacBook here and have a freshly
> acquired Tiger Server HFS+ image (dd splitfile) loaded into Autopsy.
> I'll be poking at it with sleuthkit and looking around over the next
> few days, but if there is anything in particular you'd like tested,
> please let me know.
>
> Thanks,
> adric
>
> On Nov 25, 2009, at 3:57 PM, Brian Carrier wrote:
>
>> I was hoping to get the 3.1.0 release out in the Spring before the
>> baby was born, but that didn't work. So, a new release is LONG over
>> due. There are a lot of bug fixes in the 3.1.0 release and HFS
>> support is now enabled by default. Thanks to Rob Joyce and ATC-NY
>> for
>> their HFS help. I would like to have the HFS code put through some
>> more tests before an official release is made though.
>>
>> 3.1.0b1 is available from http://www.sleuthkit.org/betas/. I'll build
>> the Windows executables next week. Everyone is free to try it out,
>> but
>> help with HFS is especially appreciated. The goal is to have the
>> official 3.1.0 out by the end of 09.
>>
>> thanks!
>>
>> brian
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports
>> 2008 30-Day
>> trial. Simplify your report design, integration and deployment -
>> and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>
> Adric Net
> adric@...
>
>
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: TSK 3.0.1 crashes with truncated volumes

2009-12-01T18:22:07Z

Hi Simson,

I can't recreate this with the trunk or 3.0.1:

# fls -o 63 ~/Downloads/0411.iso
Error reading image file (tsk_fs_read_block: Address missing in
partial image: 261)) (tsk_fs_file_walk: Error reading block at 261 -
fatfs_dir_open_meta)
# fls -V
The Sleuth Kit ver 3.0.1

Can you run 'fls' in gdb and send me the 'bt' stack trace for the
crash on your system?

thanks,
brian

On Nov 29, 2009, at 12:49 AM, Simson Garfinkel wrote:

> I have a number of disks for which I was only able to image the
> first 64K of so. These images cause TSK to crash.
>
> One of the images is 0411.iso, which can be downloaded from http://www.simson.net/0411.iso
>
> $ mmls ~/0411.iso
> DOS Partition Table
> Offset Sector: 0
> Units are in 512-byte sectors
>
> Slot Start End Length Description
> 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
> 01: ----- 0000000000 0000000062 0000000063 Unallocated
> 02: 00:00 0000000063 0002124863 0002124801 DOS FAT16 (0x06)
> c$ fls -o 63 ~/0411.iso
> Segmentation fault (core dumped)
> 12:47 AM t:~/domex/src/fiwalk/src$ ls -l ~/0411.iso
> -rw-r--r-- 1 simsong slg 65536 2009-11-29 00:46 /home/simsong/0411.iso
> $ fls -V
> The Sleuth Kit ver 3.0.1
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: 3.1.0 beta

2009-11-30T17:59:21Z

Hi,

I've got the beta loaded up on my MacBook here and have a freshly acquired Tiger Server HFS+ image (dd splitfile) loaded into Autopsy.
I'll be poking at it with sleuthkit and looking around over the next few days, but if there is anything in particular you'd like tested, please let me know.

Thanks,
adric

On Nov 25, 2009, at 3:57 PM, Brian Carrier wrote:

> I was hoping to get the 3.1.0 release out in the Spring before the
> baby was born, but that didn't work. So, a new release is LONG over
> due. There are a lot of bug fixes in the 3.1.0 release and HFS
> support is now enabled by default. Thanks to Rob Joyce and ATC-NY for
> their HFS help. I would like to have the HFS code put through some
> more tests before an official release is made though.
>
> 3.1.0b1 is available from http://www.sleuthkit.org/betas/. I'll build
> the Windows executables next week. Everyone is free to try it out, but
> help with HFS is especially appreciated. The goal is to have the
> official 3.1.0 out by the end of 09.
>
> thanks!
>
> brian
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Adric Net
adric@...

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

TSK 3.0.1 crashes with truncated volumes

2009-11-28T21:49:17Z

I have a number of disks for which I was only able to image the first 64K of so. These images cause TSK to crash.

One of the images is 0411.iso, which can be downloaded from http://www.simson.net/0411.iso

$ mmls ~/0411.iso
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000000 0000000062 0000000063 Unallocated
02: 00:00 0000000063 0002124863 0002124801 DOS FAT16 (0x06)
c$ fls -o 63 ~/0411.iso
Segmentation fault (core dumped)
12:47 AM t:~/domex/src/fiwalk/src$ ls -l ~/0411.iso
-rw-r--r-- 1 simsong slg 65536 2009-11-29 00:46 /home/simsong/0411.iso
$ fls -V
The Sleuth Kit ver 3.0.1

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

3.1.0 beta

2009-11-25T12:57:38Z

I was hoping to get the 3.1.0 release out in the Spring before the
baby was born, but that didn't work. So, a new release is LONG over
due. There are a lot of bug fixes in the 3.1.0 release and HFS
support is now enabled by default. Thanks to Rob Joyce and ATC-NY for
their HFS help. I would like to have the HFS code put through some
more tests before an official release is made though.

3.1.0b1 is available from http://www.sleuthkit.org/betas/. I'll build
the Windows executables next week. Everyone is free to try it out, but
help with HFS is especially appreciated. The goal is to have the
official 3.1.0 out by the end of 09.

thanks!

brian

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: make-live-cd returns...

2009-11-25T10:53:00Z

Confirming that the fix works. Thank you Brian.

Brian Carrier wrote:

That is a bug. I just fixed it. If you copy this file:

http://svn.sleuthkit.org/repos/autopsy/trunk/base/make-live-cd.base

to your 'base' directory, and then type './configure'. You can say no to the question about making a new config file and yes to making a new 'autopsy'. Then, it should work.

brian

On Nov 24, 2009, at 11:47 PM, suman.beros@... wrote:

Missing Sleuth Kit executable (md5) at ./make-live-cd line 48.

Autopsy reports MD5 values, so I'd say it was able to find it. Browsing through sleuthkit-users archive I don't see any mention of this situation. Would appreciate any help.

sleuthkit-3.01
autopsy-2.21
ubuntu 9.10

Best regards,
Suman
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4636 (20091125) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: make-live-cd returns...

2009-11-25T09:17:35Z

That is a bug. I just fixed it. If you copy this file:

http://svn.sleuthkit.org/repos/autopsy/trunk/base/make-live-cd.base

to your 'base' directory, and then type './configure'. You can say no
to the question about making a new config file and yes to making a new
'autopsy'. Then, it should work.

brian

On Nov 24, 2009, at 11:47 PM, suman.beros@... wrote:

> Missing Sleuth Kit executable (md5) at ./make-live-cd line 48.
>
> Autopsy reports MD5 values, so I'd say it was able to find it.
> Browsing through sleuthkit-users archive I don't see any mention of
> this situation. Would appreciate any help.
>
> sleuthkit-3.01
> autopsy-2.21
> ubuntu 9.10
>
> Best regards,
> Suman
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

make-live-cd returns...

2009-11-24T20:47:33Z

Missing Sleuth Kit executable (md5) at ./make-live-cd line 48.

Autopsy reports MD5 values, so I'd say it was able to find it. Browsing through sleuthkit-users archive I don't see any mention of this situation. Would appreciate any help.

sleuthkit-3.01
autopsy-2.21
ubuntu 9.10

Best regards,
Suman

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Badblocks - Speed...

2009-11-24T20:39:39Z

Hi,

This maybe slightly OT, but definitly I am sure someone here can help out.

I am running badblocks on a drive (which possibly has water damage).

Normally when badblocks finds a badblock it simply output the badblock number to the std output, ie:
1998696

Thought I have noticed, sometimes I get output like:
1998696 done, 13:55 elapsed

I think this means that the block passed, but it may have taken more time than normal to test that block?

Now on the drive in question I have done 2000017 blocks and its been running for about 30 minutes though the command line reads:
2000017 done, 15:23 elapsed

But I am sure its been longer that 15 minutes. The drive is a WD 2.5" 250Gb.

So, a few questions about interpreting the results and in particular whether that seems slow? I my experience I have been able to test 100-200Gb drives in about 15 minutes. At this rate with a total of 488397167 it is going to take a very long time (days!).

I would also assume that a drive this slow is a sign of impending failure?

Cheers in advance,

-Al

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-24T16:08:50Z

Brian,

Precisely correct! The hard drives now hide the low-level details of how data is stored, and only provide us with LBAs.

Yours for more fuller encapsulation,

Simson

On Nov 24, 2009, at 2:23 PM, Brian Carrier wrote:

>
> On Nov 22, 2009, at 2:05 PM, Simson Garfinkel wrote:
>
>>
>> On Nov 22, 2009, at 10:55 AM, Al Grant wrote:
>>
>>>
>>> Thanks. This has been a most interesting bit of learning.
>>>
>>> While we are on the subject do partitions have to start on a new Cylinder?
>>
>> Hard drives don't have cylinders anymore, and haven't for more than 10 years. Everything is done with the Logical Block Address.
>
> I thought there was no value in low-level details.... :)
>
>
>
>

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-24T14:23:33Z

On Nov 22, 2009, at 2:05 PM, Simson Garfinkel wrote:

>
> On Nov 22, 2009, at 10:55 AM, Al Grant wrote:
>
>>
>> Thanks. This has been a most interesting bit of learning.
>>
>> While we are on the subject do partitions have to start on a new
>> Cylinder?
>
> Hard drives don't have cylinders anymore, and haven't for more than
> 10 years. Everything is done with the Logical Block Address.

I thought there was no value in low-level details.... :)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Off-topic -- A good forensics education -- How to obtain -- "push button forensics" (PBF)

2009-11-22T15:30:01Z

Theodore Pham wrote:

>> I think there is room for both. Good tools that automate tedious,
>> error prone tasks and are at least somewhat transparent as to what
>> they are doing to achieve a given output are desirable.
>>
>> But at the same time, there are fundamentals that a good forensic
>> analyst should understand independent of what tools they choose to
>> use. If you don't at least expose beginners to the fundamentals of
>> file systems, inodes, and data blocks, then I believe their overall
>> ability to reason and interpret the output of higher level tools is
>> reduced. Especially if the higher level tool has a bug and is lying
>> to you or basing its output on an assumption which may be incorrect in
>> your situation.
>>
>> I'm not arguing that they need to master all the nuances down to
>> assembly language, they just need to be aware of where the limit of
>> their knowledge is so that if they find themselves in a situation
>> where they are not specialized enough, they know to seek out help from
>> someone who is if necessary.
>>
>> Think about doctors. Someone may end up specializing in orthodontics,
>> but they are still forced to do general medical school so they have
>> the proper exposure and understanding of how problems with your teeth
>> may manifest as other symptoms throughout your body.
>>
>> Our field is changing so rapidly that a solid understanding of the
>> fundamentals will do you immense benefit as what is old becomes new
>> again.
>>
>> Then again I went down the SANS path which teaches the fundamentals
>> before showing you the higher level tools so maybe I'm biased.
>>
>> On Sun, Nov 22, 2009 at 1:34 PM, Simson Garfinkel <simsong@...> wrote:
>>> On Nov 21, 2009, at 11:00 AM, Al Grant wrote:
>>>
>>>> Sure I would love it thanks Simson.
>>>>
>>>> I still however want to do it the manual way a few times first, else there
>>>> is no learning :-)
>>> Al,
>>>
>>> I would politely disagree with this statement. I do not think that there is much value in everyone's learning the low-level details of SleuthKit, just as there is no reason to learn the low-level details of assembly language or RTL (resistor transistor logic). Forensics is so complicated that people must specialize --- there is simply too much to learn. We need higher-level tools for creating forensic tools, so that it is easier to automate tasks and pass along each other's knowledge.
>>>
>>> Guidance Software's scripting language (escript) is a good first step. Unfortunately, the language is quite inefficient, poorly documented outside of the company's manuals (which are not freely available), and the only implementation is inside EnCase. The main problem with EnCase is that, as a GUI application, it is hard to use in a forensics pipeline. Because it only runs from a Windows GUI, you can't use EnCase on a cluster, even if you have thousands of disk images that you want to analyze in parallel.
>>>
>>> Simson

This thread of discussion is somewhat relevant to several other, recent
forensics discussions that dealt with the question of the value of "push
button forensics" (PBF). You may find them here:

A)
http://integriography.wordpress.com/2009/11/17/the-value-of-push-button-forensics/

-- see especially the comments that appear _after_ the article.

B)
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=9884541&gid=36573&commentID=8553835&trk=view_disc

C)
http://integriography.wordpress.com/2009/11/19/push-button-forensics-managing-the-downsides/

The comment that I attached the most value to was the one by Windows
forensics expert Harlan Carvey, whose comment is the first one in the
first link above. I would like to know whether others agree with H.
Carvey's remark.

Sincerely,
Paul Bain

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-22T12:00:24Z

BIOSes can still present a cylinder abstraction for compatibility even
though modern software deals with LBAs.

IIRC, it's so you don't fire up an old copy of Norton Disk Doctor or
fdisk and do something bad by accident.

But yeah, modern software won't care.

On Sun, Nov 22, 2009 at 2:05 PM, Simson Garfinkel <simsong@...> wrote:

>
> On Nov 22, 2009, at 10:55 AM, Al Grant wrote:
>
>>
>> Thanks. This has been a most interesting bit of learning.
>>
>> While we are on the subject do partitions have to start on a new Cylinder?
>
> Hard drives don't have cylinders anymore, and haven't for more than 10 years. Everything is done with the Logical Block Address.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-22T11:49:32Z

I think there is room for both. Good tools that automate tedious,
error prone tasks and are at least somewhat transparent as to what
they are doing to achieve a given output are desirable.

But at the same time, there are fundamentals that a good forensic
analyst should understand independent of what tools they choose to
use. If you don't at least expose beginners to the fundamentals of
file systems, inodes, and data blocks, then I believe their overall
ability to reason and interpret the output of higher level tools is
reduced. Especially if the higher level tool has a bug and is lying
to you or basing its output on an assumption which may be incorrect in
your situation.

I'm not arguing that they need to master all the nuances down to
assembly language, they just need to be aware of where the limit of
their knowledge is so that if they find themselves in a situation
where they are not specialized enough, they know to seek out help from
someone who is if necessary.

Think about doctors. Someone may end up specializing in orthodontics,
but they are still forced to do general medical school so they have
the proper exposure and understanding of how problems with your teeth
may manifest as other symptoms throughout your body.

Our field is changing so rapidly that a solid understanding of the
fundamentals will do you immense benefit as what is old becomes new
again.

Then again I went down the SANS path which teaches the fundamentals
before showing you the higher level tools so maybe I'm biased.

On Sun, Nov 22, 2009 at 1:34 PM, Simson Garfinkel <simsong@...> wrote:

>
> On Nov 21, 2009, at 11:00 AM, Al Grant wrote:
>
>>
>> Sure I would love it thanks Simson.
>>
>> I still however want to do it the manual way a few times first, else there
>> is no learning :-)
>
> Al,
>
> I would politely disagree with this statement. I do not think that there is much value in everyone's learning the low-level details of SleuthKit, just as there is no reason to learn the low-level details of assembly language or RTL (resistor transistor logic). Forensics is so complicated that people must specialize --- there is simply too much to learn. We need higher-level tools for creating forensic tools, so that it is easier to automate tasks and pass along each other's knowledge.
>
> Guidance Software's scripting language (escript) is a good first step. Unfortunately, the language is quite inefficient, poorly documented outside of the company's manuals (which are not freely available), and the only implementation is inside EnCase. The main problem with EnCase is that, as a GUI application, it is hard to use in a forensics pipeline. Because it only runs from a Windows GUI, you can't use EnCase on a cluster, even if you have thousands of disk images that you want to analyze in parallel.
>
> Simson
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-22T11:05:14Z

On Nov 22, 2009, at 10:55 AM, Al Grant wrote:

>
> Thanks. This has been a most interesting bit of learning.
>
> While we are on the subject do partitions have to start on a new Cylinder?

Hard drives don't have cylinders anymore, and haven't for more than 10 years. Everything is done with the Logical Block Address.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-22T10:55:41Z

Thanks. This has been a most interesting bit of learning.

While we are on the subject do partitions have to start on a new Cylinder?

Look at the following for example:

al@al-ubuntu:~$ sudo mmls /dev/sdb
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000062 0000000062 Unallocated
02: 00:00 0000000063 0000128519 0000128457 Dell Utilities FAT (0xde)
03: ----- 0000128520 0000129023 0000000504 Unallocated
04: 00:01 0000129024 0021100543 0020971520 NTFS (0x07)
05: 00:02 0021100544 0307335167 0286234624 NTFS (0x07)
06: 00:03 0307335168 0312578047 0005242880 Win95 Extended (0x0F)
07: ----- 0307335168 0307335168 0000000001 Extended Table (#1)
08: ----- 0307335169 0307337215 0000002047 Unallocated
09: 01:00 0307337216 0312578047 0005240832 Hidden CTOS Memdump? (0xdd)
10: ----- 0312578048 0312581807 0000003760 Unallocated
al@al-ubuntu:~$ sudo fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xaf010487

Device Boot Start End Blocks Id System
/dev/sda1 * 1 121601 976760001 83 Linux

Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x70000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 8 64228+ de Dell Utility
/dev/sdb2 9 1314 10485760 7 HPFS/NTFS
/dev/sdb3 * 1314 19131 143117312 7 HPFS/NTFS
/dev/sdb4 19131 19458 2621440 f W95 Ext'd (LBA)
/dev/sdb5 19131 19458 2620416 dd Unknown
al@al-ubuntu:~$

The first NTFS partition ends on 1314 clyinder (and the next one starts on the same cylinder).

If I multiply C*H*S, 1314*255*63 = 21109410, which is close but not the same as 21100543.

Cheers

-Al

Theodore Pham wrote:

I think you've got that right. It's early and I haven't had any caffeine yet.

When you run the istat command on the inode you found via ifind, you
can cross validate your result by looking at the cluster numbers
underneath

"Type: $DATA (128-3) Name: $J Non-Resident, Sparse size: 5296921952"

One of them should be the one you calculated: 214612

Normally when you see a filename with $ in front, it means that it's a
special NTFS internal metadata file and they are hidden from the
Windows Explorer.

In this case, the <filename>:<blah> notation means you are looking at
an Alternate Data Stream of the file called <filename>.

And as luck would have it, it seems damage in that file can cause boot
issues. See:

http://forums.techguy.org/all-other-software/631384-what-c-extend-usnjrnl-j.html
http://microsoft-personal-operating-systems.hostweb.com/TopicMessages/microsoft.public.windowsxp.general/2026959/1/Default.aspx

And http://support.microsoft.com/kb/311724 tells how to use chkdsk to fix it.

Though you seemed to have a pretty long list of bad blocks so some of
the other ones might also be causing issues, especially if they are
corrupting system files.

On Sun, Nov 22, 2009 at 2:35 AM, Al Grant <bigal.nz@gmail.com> wrote:
>
> Hi Theodore,
>
> I think I followed your instructions ok. Let see what I got:
>
>
> Theodore Pham wrote:
>>
>> On Sat, Nov 21, 2009 at 8:47 PM, Theodore Pham <telamon@gmail.com> wrote:
>> Ok, let's try this again but with the proper physical sector to
>> partition relative block/cluster mapping this time. I was looking at
>> a really old script I wrote the first time I tried to write this up
>> and of course that script was wrong. Sorry.
>>
>> Run mmls -i raw /dev/sdb
>>
>
> al@al-ubuntu:~$ sudo mmls /dev/sdb
> DOS Partition Table
> Offset Sector: 0
> Units are in 512-byte sectors
>
> Slot Start End Length Description
> 00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
> 01: ----- 0000000001 0000000062 0000000062 Unallocated
> 02: 00:00 0000000063 0000128519 0000128457 Dell Utilities FAT
> (0xde)
> 03: ----- 0000128520 0000129023 0000000504 Unallocated
> 04: 00:01 0000129024 0021100543 0020971520 NTFS (0x07)
> 05: 00:02 0021100544 0307335167 0286234624 NTFS (0x07)
> 06: 00:03 0307335168 0312578047 0005242880 Win95 Extended (0x0F)
> 07: ----- 0307335168 0307335168 0000000001 Extended Table (#1)
> 08: ----- 0307335169 0307337215 0000002047 Unallocated
> 09: 01:00 0307337216 0312578047 0005240832 Hidden CTOS Memdump?
> (0xdd)
> 10: ----- 0312578048 0312581807 0000003760 Unallocated
>
>
>
> Theodore Pham wrote:
>>
>> Next, you need to know the cluster (aka block) size for the filesystem
>> in the partition you care about.
>>
>> Run fsstat -i raw -o <absolute start sector of partition> <dd image
>> file or /dev device>
>>
>
> Now I know from badblocks that one of the badblocks is 22817441.
>
> I can see that this number falls in the range of one of the partitions that
> is listed as starting at 21100544. So the offset in fsstat is :
>
> al@al-ubuntu:~$ sudo fsstat -o 21100544 /dev/sdb
> FILE SYSTEM INFORMATION
> --------------------------------------------
> File System Type: NTFS
> Volume Serial Number: 8C3E8ADC3E8ABF28
> OEM Name: NTFS
> Volume Name: OS
> Version: Windows XP
>
> METADATA INFORMATION
> --------------------------------------------
> First Cluster of MFT: 786432
> First Cluster of MFT Mirror: 18217343
> Size of MFT Entries: 1024 bytes
> Size of Index Records: 4096 bytes
> Range: 0 - 137151
> Root Directory: 5
>
> CONTENT INFORMATION
> --------------------------------------------
> Sector Size: 512
> Cluster Size: 4096
> Total Cluster Range: 0 - 35779325
> Total Sector Range: 0 - 286234607
> <SNIP>
>
>
> Theodore Pham wrote:
>>
>> Now calculate the partition relative cluster number using this formula
>>
>> Partition relative cluster number = (Absolute sector number in
>> question - Absolute sector number of partition start) * sector size /
>> cluster size
>>
>> If the result is a floating point number, then you just want the integer
>> part.
>>
>
> Ok, not sure I have done this step right, but plugging in my numbers:
>
> Partition Relative Cluster Number = (22817441 - 21100544) * 512/4096
> = 1716897 * 0.125
> = 214612.125
> = 214612 (integer only)
>
>
>
> Theodore Pham wrote:
>>
>> Now use ifind with the -o argument to tell it what absolute sector the
>> partition begins at and the -d argument to indicate the partition
>> relative cluster number you're interested in.
>>
>> For your example absolute sector of 22817441, let's assume the
>> partition containing it starts at 22817300. Your relative sector
>> number would be 22817441 - 22817300 = 141. So you would run:
>>
>> ifind -i raw -o 22817300 -d 17 <dd image or /dev device>
>>
>
> Ok, again plugging in my numbers:
>
> al@al-ubuntu:~$ sudo ifind -o 21100544 -d 214612 /dev/sdb
> 51798-128-3
>
>
>
> Theodore Pham wrote:
>>
>> Once you have the inode number, you can run:
>>
>> istat -i raw -o <partition start absolute sector> <dd image or /dev
>> device> <inode number>
>>
>
> al@al-ubuntu:~$ sudo istat -o 21100544 /dev/sdb 51798-128-3 |more
> MFT Entry Header Values:
> Entry: 51798 Sequence: 1
> $LogFile Sequence Number: 19669486580
> Allocated File
> Links: 1
>
> $STANDARD_INFORMATION Attribute Values:
> Flags: Hidden, System, Archive, Sparse
> Owner ID: 0
> Created: Tue Mar 11 20:43:50 2008
> File Modified: Tue Mar 11 20:43:50 2008
> MFT Modified: Tue Mar 11 20:43:50 2008
> Accessed: Tue Mar 11 20:43:50 2008
>
> $FILE_NAME Attribute Values:
> Flags: Hidden, System, Archive, Sparse
> Name: $UsnJrnl
> Parent MFT Entry: 11 Sequence: 11
> Allocated Size: 0 Actual Size: 0
> Created: Tue Mar 11 20:43:50 2008
> File Modified: Tue Mar 11 20:43:50 2008
> MFT Modified: Tue Mar 11 20:43:50 2008
> Accessed: Tue Mar 11 20:43:50 2008
> Attributes:
> Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
> Type: $FILE_NAME (48-1) Name: N/A Resident size: 82
> Type: $DATA (128-3) Name: $J Non-Resident, Sparse size: 5296921952
> 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0
> <SNIP>
> 24670595 24670596 24670597 24670598 24670599 24670600 24670601 24670602
> 24670603 24670604 24670605 24670606 24670607 24670608 24670609 24670610
> 24670611 24670612 24670613 24670614 24670615 24670616 24670617 24670618
> 24670619 24670620 24670621 24670622 24670623 24670624 24670625 24670626
> 24670627 24670628 24670629 24670630 24670631 24670632 24670633 24670634
> Type: $DATA (128-5) Name: $Max Resident size: 32
> al@al-ubuntu:~$
>
>
>
> Theodore Pham wrote:
>>
>> to show you useful information about the inode including, whether or
>> not it is allocated, it's relative name and what data clusters are
>> allocated to it.
>>
>> Then you can run ffind with the same arguments to give you the full
>> path and filename:
>>
>> ffind -i raw -o <partition start absolute sector> <dd image or /dev
>> device> <inode number>
>>
>
> Now this last bit of information is very cryptic:
>
> al@al-ubuntu:~$ sudo ffind -o 21100544 /dev/sdb 51798-128-3
> /$Extend/$UsnJrnl:$J
> al@al-ubuntu:~$
>
> So I would like to know if you think I have followed the instructions
> correctly?
>
> I am not sure what file the badblock affected?
>
> I also again appreciate all your patient help on this one Theodore. Input
> from others still welcome.
>
> Cheers
>
> -Al
>
>
>
>
> --
> View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26463322.html
> Sent from the sleuthkit-users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-22T10:34:45Z

On Nov 21, 2009, at 11:00 AM, Al Grant wrote:

>
> Sure I would love it thanks Simson.
>
> I still however want to do it the manual way a few times first, else there
> is no learning :-)

Al,

I would politely disagree with this statement. I do not think that there is much value in everyone's learning the low-level details of SleuthKit, just as there is no reason to learn the low-level details of assembly language or RTL (resistor transistor logic). Forensics is so complicated that people must specialize --- there is simply too much to learn. We need higher-level tools for creating forensic tools, so that it is easier to automate tasks and pass along each other's knowledge.

Guidance Software's scripting language (escript) is a good first step. Unfortunately, the language is quite inefficient, poorly documented outside of the company's manuals (which are not freely available), and the only implementation is inside EnCase. The main problem with EnCase is that, as a GUI application, it is hard to use in a forensics pipeline. Because it only runs from a Windows GUI, you can't use EnCase on a cluster, even if you have thousands of disk images that you want to analyze in parallel.

Simson

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

announcing isectorfind.py (was Re: icat and ifind -- Help with -- )

2009-11-22T10:29:27Z

All,

I have written a small program using the fiwalk python framework that takes a disk image and sector numbers and prints a list of the files that map to those sectors. The program automatically handles filesystems on raw devices as well as multiple partitions on a single physical device. The program is called isectorfind.py and it is part of version 0.5.7 of the fiwalk package. You can download it from http://www.afflib.org/.

Total time to write this program using the framework was about 45 minutes. Most of the time was spent fixing some bugs in the fiwalk.py Python module that resulted from some XML changes that I made over the weekend. I had to make those fixes before the release anyway, of course. I also had to add the has_sector() method to the fileobject class and the byterun class. Both additions took about 3 minutes.

This program is part of the fiwalk system that you can download from http://afflib.org/. Basically, fiwalk finds all of the partitions and filesystems on a disk image using SleuthKit's "walk" functions and outputs a big XML block. The idea is that it is easier for us to write tools that work with this XML block than to work with the raw SleuthKit primitives. The main "tool" that I use for this XML block is the fiwalk.py Python module, which provides a very easy-to-use (and efficient) python interface to the disk metadata.

To use fiwalk.py you need to install fiwalk, which requires that the SleuthKit developer libraries be installed.

My purpose of posting this program is to show just how easy it is to write forensic tools using Python and the fiwalk XML system we have been creating. If you would like to learn more, please read my paper from SADFE 2009, which you can download from:

http://simson.net/xml_forensics.pdf .

This paper includes a tutorial and several sample programs.

Here is an example of using isectorfind.py to find which files map to sectors 47520 49217 and 50690 from the the disk image nps-2009-canon2-gen6.raw, which you can download from digitalcorpora.org:

$ python isectorfind.py nps-2009-canon2-gen6.raw 47520 49217 50690

47520 DCIM/100CANON/_MG_0030.JPG

49217 DCIM/100CANON/IMG_0031.JPG

50690 DCIM/100CANON/IMG_0032.JPG

Below is the program in its entirety; the business portion is in BOLD. As you can see, more space is taken up by the usage message and options processing than by the business logic.

#!/usr/bin/python

"""Usage: isectorfind.py imagefile.iso s1 [s2 s3 ...] ...

Reports the files in which sectors s1, s2, s3... are located.

"""

import fiwalk

if __name__=="__main__":

import sys

from sys import stdout

from optparse import OptionParser

parser = OptionParser()

parser.usage = '%prog [options] image.iso s1 [s2 s3 s3 ...]'

parser.add_option("-d","--debug",help="debug",action="store_true")

(options,args) = parser.parse_args()

if len(args)<1:

parser.print_help()

sys.exit(1)

sectors = set() # sectors we are looking for

for s in args[1:]:

sectors.add(int(s))

def process(fi):

for s in sectors:

if fi.has_sector(s):

print "%d\t%s" % (s,fi.filename())

fiwalk.fiwalk_using_sax(imagefile=open(args[0]),callback=process)

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-22T07:29:36Z

I think you've got that right. It's early and I haven't had any caffeine yet.

When you run the istat command on the inode you found via ifind, you
can cross validate your result by looking at the cluster numbers
underneath

"Type: $DATA (128-3) Name: $J Non-Resident, Sparse size: 5296921952"

One of them should be the one you calculated: 214612

Normally when you see a filename with $ in front, it means that it's a
special NTFS internal metadata file and they are hidden from the
Windows Explorer.

In this case, the <filename>:<blah> notation means you are looking at
an Alternate Data Stream of the file called <filename>.

And as luck would have it, it seems damage in that file can cause boot
issues. See:

http://forums.techguy.org/all-other-software/631384-what-c-extend-usnjrnl-j.html
http://microsoft-personal-operating-systems.hostweb.com/TopicMessages/microsoft.public.windowsxp.general/2026959/1/Default.aspx

And http://support.microsoft.com/kb/311724 tells how to use chkdsk to fix it.

Though you seemed to have a pretty long list of bad blocks so some of
the other ones might also be causing issues, especially if they are
corrupting system files.

On Sun, Nov 22, 2009 at 2:35 AM, Al Grant <bigal.nz@...> wrote:

>
> Hi Theodore,
>
> I think I followed your instructions ok. Let see what I got:
>
>
> Theodore Pham wrote:
>>
>> On Sat, Nov 21, 2009 at 8:47 PM, Theodore Pham <telamon@...> wrote:
>> Ok, let's try this again but with the proper physical sector to
>> partition relative block/cluster mapping this time. I was looking at
>> a really old script I wrote the first time I tried to write this up
>> and of course that script was wrong. Sorry.
>>
>> Run mmls -i raw /dev/sdb
>>
>
> al@al-ubuntu:~$ sudo mmls /dev/sdb
> DOS Partition Table
> Offset Sector: 0
> Units are in 512-byte sectors
>
> Slot Start End Length Description
> 00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
> 01: ----- 0000000001 0000000062 0000000062 Unallocated
> 02: 00:00 0000000063 0000128519 0000128457 Dell Utilities FAT
> (0xde)
> 03: ----- 0000128520 0000129023 0000000504 Unallocated
> 04: 00:01 0000129024 0021100543 0020971520 NTFS (0x07)
> 05: 00:02 0021100544 0307335167 0286234624 NTFS (0x07)
> 06: 00:03 0307335168 0312578047 0005242880 Win95 Extended (0x0F)
> 07: ----- 0307335168 0307335168 0000000001 Extended Table (#1)
> 08: ----- 0307335169 0307337215 0000002047 Unallocated
> 09: 01:00 0307337216 0312578047 0005240832 Hidden CTOS Memdump?
> (0xdd)
> 10: ----- 0312578048 0312581807 0000003760 Unallocated
>
>
>
> Theodore Pham wrote:
>>
>> Next, you need to know the cluster (aka block) size for the filesystem
>> in the partition you care about.
>>
>> Run fsstat -i raw -o <absolute start sector of partition> <dd image
>> file or /dev device>
>>
>
> Now I know from badblocks that one of the badblocks is 22817441.
>
> I can see that this number falls in the range of one of the partitions that
> is listed as starting at 21100544. So the offset in fsstat is :
>
> al@al-ubuntu:~$ sudo fsstat -o 21100544 /dev/sdb
> FILE SYSTEM INFORMATION
> --------------------------------------------
> File System Type: NTFS
> Volume Serial Number: 8C3E8ADC3E8ABF28
> OEM Name: NTFS
> Volume Name: OS
> Version: Windows XP
>
> METADATA INFORMATION
> --------------------------------------------
> First Cluster of MFT: 786432
> First Cluster of MFT Mirror: 18217343
> Size of MFT Entries: 1024 bytes
> Size of Index Records: 4096 bytes
> Range: 0 - 137151
> Root Directory: 5
>
> CONTENT INFORMATION
> --------------------------------------------
> Sector Size: 512
> Cluster Size: 4096
> Total Cluster Range: 0 - 35779325
> Total Sector Range: 0 - 286234607
> <SNIP>
>
>
> Theodore Pham wrote:
>>
>> Now calculate the partition relative cluster number using this formula
>>
>> Partition relative cluster number = (Absolute sector number in
>> question - Absolute sector number of partition start) * sector size /
>> cluster size
>>
>> If the result is a floating point number, then you just want the integer
>> part.
>>
>
> Ok, not sure I have done this step right, but plugging in my numbers:
>
> Partition Relative Cluster Number = (22817441 - 21100544) * 512/4096
> = 1716897 * 0.125
> = 214612.125
> = 214612 (integer only)
>
>
>
> Theodore Pham wrote:
>>
>> Now use ifind with the -o argument to tell it what absolute sector the
>> partition begins at and the -d argument to indicate the partition
>> relative cluster number you're interested in.
>>
>> For your example absolute sector of 22817441, let's assume the
>> partition containing it starts at 22817300. Your relative sector
>> number would be 22817441 - 22817300 = 141. So you would run:
>>
>> ifind -i raw -o 22817300 -d 17 <dd image or /dev device>
>>
>
> Ok, again plugging in my numbers:
>
> al@al-ubuntu:~$ sudo ifind -o 21100544 -d 214612 /dev/sdb
> 51798-128-3
>
>
>
> Theodore Pham wrote:
>>
>> Once you have the inode number, you can run:
>>
>> istat -i raw -o <partition start absolute sector> <dd image or /dev
>> device> <inode number>
>>
>
> al@al-ubuntu:~$ sudo istat -o 21100544 /dev/sdb 51798-128-3 |more
> MFT Entry Header Values:
> Entry: 51798 Sequence: 1
> $LogFile Sequence Number: 19669486580
> Allocated File
> Links: 1
>
> $STANDARD_INFORMATION Attribute Values:
> Flags: Hidden, System, Archive, Sparse
> Owner ID: 0
> Created: Tue Mar 11 20:43:50 2008
> File Modified: Tue Mar 11 20:43:50 2008
> MFT Modified: Tue Mar 11 20:43:50 2008
> Accessed: Tue Mar 11 20:43:50 2008
>
> $FILE_NAME Attribute Values:
> Flags: Hidden, System, Archive, Sparse
> Name: $UsnJrnl
> Parent MFT Entry: 11 Sequence: 11
> Allocated Size: 0 Actual Size: 0
> Created: Tue Mar 11 20:43:50 2008
> File Modified: Tue Mar 11 20:43:50 2008
> MFT Modified: Tue Mar 11 20:43:50 2008
> Accessed: Tue Mar 11 20:43:50 2008
> Attributes:
> Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
> Type: $FILE_NAME (48-1) Name: N/A Resident size: 82
> Type: $DATA (128-3) Name: $J Non-Resident, Sparse size: 5296921952
> 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0
> <SNIP>
> 24670595 24670596 24670597 24670598 24670599 24670600 24670601 24670602
> 24670603 24670604 24670605 24670606 24670607 24670608 24670609 24670610
> 24670611 24670612 24670613 24670614 24670615 24670616 24670617 24670618
> 24670619 24670620 24670621 24670622 24670623 24670624 24670625 24670626
> 24670627 24670628 24670629 24670630 24670631 24670632 24670633 24670634
> Type: $DATA (128-5) Name: $Max Resident size: 32
> al@al-ubuntu:~$
>
>
>
> Theodore Pham wrote:
>>
>> to show you useful information about the inode including, whether or
>> not it is allocated, it's relative name and what data clusters are
>> allocated to it.
>>
>> Then you can run ffind with the same arguments to give you the full
>> path and filename:
>>
>> ffind -i raw -o <partition start absolute sector> <dd image or /dev
>> device> <inode number>
>>
>
> Now this last bit of information is very cryptic:
>
> al@al-ubuntu:~$ sudo ffind -o 21100544 /dev/sdb 51798-128-3
> /$Extend/$UsnJrnl:$J
> al@al-ubuntu:~$
>
> So I would like to know if you think I have followed the instructions
> correctly?
>
> I am not sure what file the badblock affected?
>
> I also again appreciate all your patient help on this one Theodore. Input
> from others still welcome.
>
> Cheers
>
> -Al
>
>
>
>
> --
> View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26463322.html
> Sent from the sleuthkit-users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-21T23:35:10Z

Hi Theodore,

I think I followed your instructions ok. Let see what I got:

Theodore Pham wrote:

On Sat, Nov 21, 2009 at 8:47 PM, Theodore Pham <telamon@gmail.com> wrote:
Ok, let's try this again but with the proper physical sector to
partition relative block/cluster mapping this time. I was looking at
a really old script I wrote the first time I tried to write this up
and of course that script was wrong. Sorry.

Run mmls -i raw /dev/sdb

al@al-ubuntu:~$ sudo mmls /dev/sdb
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000062 0000000062 Unallocated
02: 00:00 0000000063 0000128519 0000128457 Dell Utilities FAT (0xde)
03: ----- 0000128520 0000129023 0000000504 Unallocated
04: 00:01 0000129024 0021100543 0020971520 NTFS (0x07)
05: 00:02 0021100544 0307335167 0286234624 NTFS (0x07)
06: 00:03 0307335168 0312578047 0005242880 Win95 Extended (0x0F)
07: ----- 0307335168 0307335168 0000000001 Extended Table (#1)
08: ----- 0307335169 0307337215 0000002047 Unallocated
09: 01:00 0307337216 0312578047 0005240832 Hidden CTOS Memdump? (0xdd)
10: ----- 0312578048 0312581807 0000003760 Unallocated

Theodore Pham wrote:

Next, you need to know the cluster (aka block) size for the filesystem
in the partition you care about.

Run fsstat -i raw -o <absolute start sector of partition> <dd image
file or /dev device>

Now I know from badblocks that one of the badblocks is 22817441.

I can see that this number falls in the range of one of the partitions that is listed as starting at 21100544. So the offset in fsstat is :

al@al-ubuntu:~$ sudo fsstat -o 21100544 /dev/sdb
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: 8C3E8ADC3E8ABF28
OEM Name: NTFS
Volume Name: OS
Version: Windows XP

METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 786432
First Cluster of MFT Mirror: 18217343
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 137151
Root Directory: 5

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 35779325
Total Sector Range: 0 - 286234607
<SNIP>

Theodore Pham wrote:

Now calculate the partition relative cluster number using this formula

Partition relative cluster number = (Absolute sector number in
question - Absolute sector number of partition start) * sector size /
cluster size

If the result is a floating point number, then you just want the integer part.

Ok, not sure I have done this step right, but plugging in my numbers:

Partition Relative Cluster Number = (22817441 - 21100544) * 512/4096
= 1716897 * 0.125
= 214612.125
= 214612 (integer only)

Theodore Pham wrote:

Now use ifind with the -o argument to tell it what absolute sector the
partition begins at and the -d argument to indicate the partition
relative cluster number you're interested in.

For your example absolute sector of 22817441, let's assume the
partition containing it starts at 22817300. Your relative sector
number would be 22817441 - 22817300 = 141. So you would run:

ifind -i raw -o 22817300 -d 17 <dd image or /dev device>

Ok, again plugging in my numbers:

al@al-ubuntu:~$ sudo ifind -o 21100544 -d 214612 /dev/sdb
51798-128-3

Theodore Pham wrote:

Once you have the inode number, you can run:

istat -i raw -o <partition start absolute sector> <dd image or /dev
device> <inode number>

al@al-ubuntu:~$ sudo istat -o 21100544 /dev/sdb 51798-128-3 |more
MFT Entry Header Values:
Entry: 51798 Sequence: 1
$LogFile Sequence Number: 19669486580
Allocated File
Links: 1

$STANDARD_INFORMATION Attribute Values:
Flags: Hidden, System, Archive, Sparse
Owner ID: 0
Created: Tue Mar 11 20:43:50 2008
File Modified: Tue Mar 11 20:43:50 2008
MFT Modified: Tue Mar 11 20:43:50 2008
Accessed: Tue Mar 11 20:43:50 2008

$FILE_NAME Attribute Values:
Flags: Hidden, System, Archive, Sparse
Name: $UsnJrnl
Parent MFT Entry: 11 Sequence: 11
Allocated Size: 0 Actual Size: 0
Created: Tue Mar 11 20:43:50 2008
File Modified: Tue Mar 11 20:43:50 2008
MFT Modified: Tue Mar 11 20:43:50 2008
Accessed: Tue Mar 11 20:43:50 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-1) Name: N/A Resident size: 82
Type: $DATA (128-3) Name: $J Non-Resident, Sparse size: 5296921952
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
<SNIP>
24670595 24670596 24670597 24670598 24670599 24670600 24670601 24670602
24670603 24670604 24670605 24670606 24670607 24670608 24670609 24670610
24670611 24670612 24670613 24670614 24670615 24670616 24670617 24670618
24670619 24670620 24670621 24670622 24670623 24670624 24670625 24670626
24670627 24670628 24670629 24670630 24670631 24670632 24670633 24670634
Type: $DATA (128-5) Name: $Max Resident size: 32
al@al-ubuntu:~$

Theodore Pham wrote:

to show you useful information about the inode including, whether or
not it is allocated, it's relative name and what data clusters are
allocated to it.

Then you can run ffind with the same arguments to give you the full
path and filename:

ffind -i raw -o <partition start absolute sector> <dd image or /dev
device> <inode number>

Now this last bit of information is very cryptic:

al@al-ubuntu:~$ sudo ffind -o 21100544 /dev/sdb 51798-128-3
/$Extend/$UsnJrnl:$J
al@al-ubuntu:~$

So I would like to know if you think I have followed the instructions correctly?

I am not sure what file the badblock affected?

I also again appreciate all your patient help on this one Theodore. Input from others still welcome.

Cheers

-Al

Re: icat and ifind -- Help with -- Please DO NOT hijack threads

2009-11-21T18:51:09Z

On Sat, Nov 21, 2009 at 8:47 PM, Theodore Pham <telamon@...> wrote:
> Folks, ignore this. I think I forgot to map the physical sector to a
> partition relative cluster number. I'll repost shortly when I double
> check this on a real data.

Ok, let's try this again but with the proper physical sector to
partition relative block/cluster mapping this time. I was looking at
a really old script I wrote the first time I tried to write this up
and of course that script was wrong. Sorry.

Run mmls -i raw /dev/sdb

BTW, if you use a dd image, you may be able to drop the -i raw from
this command and the rest of the TSK commands.

That will print out the partition table with the absolute sector start
and end values and the sector size (usually 512 bytes.)

Find the partition that your absolute sector value belongs to and note
the absolute start sector.

Next, you need to know the cluster (aka block) size for the filesystem
in the partition you care about.

Run fsstat -i raw -o <absolute start sector of partition> <dd image
file or /dev device>

You'll see output that should include:

<begin excerpt>
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 26522894
Total Range in Image: 0 - 26522262
Total Sector Range: 0 - 212183166
<end excerpt>

That example output snippet comes from an NTFS partition and usually
NTFS uses a cluster size of 4096 bytes, but this is configurable at
format time.

Now calculate the partition relative cluster number using this formula

Partition relative cluster number = (Absolute sector number in
question - Absolute sector number of partition start) * sector size /
cluster size

If the result is a floating point number, then you just want the integer part.

Going back to your absolute sector of 22817441 and assuming absolute
sector number of partition start is 22817300, sector size is 512, and
cluster size is 4096, then:

(22817441 - 22817300) * 512 / 4096 = 17.625

So your partition relative cluster number is 17.

Now use ifind with the -o argument to tell it what absolute sector the
partition begins at and the -d argument to indicate the partition
relative cluster number you're interested in.

For your example absolute sector of 22817441, let's assume the
partition containing it starts at 22817300. Your relative sector
number would be 22817441 - 22817300 = 141. So you would run:

ifind -i raw -o 22817300 -d 17 <dd image or /dev device>

ifind will tell you the inode number(s) for the file the data block is
associated with. An inode is a metadata structure that contains
information for a file or directory. What information it contains
depends on the file system type, but knowing the inode number uniquely
identifies a file or directory. And yes, ifind may return multiple
inode numbers because a data block may have been reallocated -
normally this means only one of the returned inodes is allocated and
the rest are unallocated (represents a deleted file/directory). If
you find two allocated inodes referencing the same data block, then
you either have a hard linked file (intentional and valid for some
filesystem types) OR a cross linked one (corrupted file system.)

Once you have the inode number, you can run:

istat -i raw -o <partition start absolute sector> <dd image or /dev
device> <inode number>

to show you useful information about the inode including, whether or
not it is allocated, it's relative name and what data clusters are
allocated to it.

Then you can run ffind with the same arguments to give you the full
path and filename:

ffind -i raw -o <partition start absolute sector> <dd image or /dev
device> <inode number>

However, if your bad block is being used to house inodes, then istat
and ffind may fail because they may not be able to valid data needed
to traverse the file system.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org