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

Re: [sleuthkit-users] Bad Superblock and tsk versus foremost

[youcef b. <ybi...@ya...>]

Hi,
foremost is mostly suited where the files were
allocated in consecutive clusters. if a file was
defragmented than foremost will not retrieve it (thus
the corruption that you may experience in some files).

I am not sure what filessytem you have on that disk.
depending in where the corruption occurs, if you have
a FAT file system then you may be lucky to retrieve it
using a winhex and of course some knowledge of how the
FAT filesystem is layed out (Brian Book is the best in
this topic).

I've mentioned FAT because it's the easiet to work
with using a manual process as I described above, NTFS
is is a kill to follow with a hexeditor.


regards

youcef

--- esrkq yahoo <es...@ya...> wrote:

> Hi,
> 
> Had a disk failure in windows.  There are some MS
> Office files I would like to retrieve in particular
> one Excel spreadsheet.
> 
> I tried to mount the relevant partition under linux
> but got a bad superblock message.  The partition
> type
> is vfat.
> 
> I imaged the partion under linux using dd and ran
> foremost against it and it recovered 399 MS Office
> files but unfortunately the one that I really wanted
> wasn't amongst them.  Quite a few of the files it
> recovered were corrupt.  It seemed to have more
> success with Word  Docs than Excel.
> 
> I tried mounting the dd image with the loop back
> driver but got the same error 'bad superblock'.
> 
> Is there any point trying to find the info using
> sleuthkit / autopsy.  If I could search for and find
> a
> relevant string using autopsy could I recover the
> file
> any better than foremost (which didn't even locate
> this particular document).
> 
> Foremost finds office documents by looking for ole
> objects which is obviously a different search
> strategy
> than my typing in a particular string to search for
> in
> Autopsy.
> 
> Also, would the fact that the image has a bad
> superblock preclude me from using sleuthkit/autopsy.
> 
> I tried a couple of windows utilities (old version
> of
> Norton and a version of Paragon) to see if they
> could
> ressurect the partition but no joy.
> 
> Any advice much appreciated,
> 
> Cheers,
> JP.
> 
> 
> 
> 
>  
> 
> 
> 		
>
___________________________________________________________
> 
> To help you stay safe and secure online, we've
> developed the all new Yahoo! Security Centre.
> http://uk.security.yahoo.com
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by xPML, a
> groundbreaking scripting language
> that extends applications into web and mobile media.
> Attend the live webcast
> and join the prime developer group breaking into
> this new coding territory!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Re: SPAM: 99.9: Re: [sleuthkit-users] Autopsy: File Activity Timelines not working

[<gim...@we...>]

On Mon, 6 Mar 2006 20:25:43 -0500
Brian Carrier <ca...@sl...> wrote:

> Your partition table is screwed up.  TSK / Autopsy don't provide any  
> tools to help fix that.  You can use a tool like testdisk or gpart
> to see if the FAT file system exists somewhere on the disk.
> 

You got it, i tried a simple "fdisk -l image.img" and then i got
very clearly message something is wrong with image.
I looked at both tools, but gpart seems to be out of date and didn't
compile. It's provided static binary doesn't run, too.
But never mind, testdisk is a very interesting tool...

Thanks.

Re: [sleuthkit-users] Install TSK under SuSe 10

[Seth A. <set...@su...>]

On Tue, Mar 07, 2006 at 09:27:15AM -0500, Bill Ethridge wrote:
> I am trying to install TSK under Suse 10. It uses cc1, and I get an
> unrecognized command -c error when tries to run cc1, then error 2 on no-perl
> and another command.

It sounds like your system don't have enough of a development environment
installed to compile TSK.

I suggest running the following command to install some of the development
environment necessary to build packages:

yast -i cpp gcc make binutils glibc-devel

Every external library that a program uses must have a corresponding
-devel package installed. I don't recall which libraries TSK / Autopsy
require any more, but when gcc inevitably complains about missing #include
or header files, you'll need to figure out which -devel package provides
those headers, and install them, too.

(This process does get easier as you compile more software. :)

[sleuthkit-users] Install TSK under SuSe 10

[Bill E. <bil...@da...>]

I am trying to install TSK under Suse 10. It uses cc1, and I get an
unrecognized command -c error when tries to run cc1, then error 2 on no-perl
and another command.

 

Any Help?

 

Thanks Bill

Re: [sleuthkit-users] Bad Superblock and tsk versus foremost

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

TSK / Autopsy may be able to analyze the corrupt image, but it is  
hard to say without knowing what is corrupt.  Some tools are more  
picky about some things than others.

Keyword searching isn't going to help you much if foremost didn't  
find it.  Keyword searching may show you a sector from the file, but  
you still need to group the sectors together.  Presumably, foremost  
would have found the corresponding header if it existed.  You may  
need to manually choose which sectors are from the file and which  
ones aren't .....  Not an easy task.

brian



On Mar 6, 2006, at 6:51 PM, esrkq yahoo wrote:

> Hi,
>
> Had a disk failure in windows.  There are some MS
> Office files I would like to retrieve in particular
> one Excel spreadsheet.
>
> I tried to mount the relevant partition under linux
> but got a bad superblock message.  The partition type
> is vfat.
>
> I imaged the partion under linux using dd and ran
> foremost against it and it recovered 399 MS Office
> files but unfortunately the one that I really wanted
> wasn't amongst them.  Quite a few of the files it
> recovered were corrupt.  It seemed to have more
> success with Word  Docs than Excel.
>
> I tried mounting the dd image with the loop back
> driver but got the same error 'bad superblock'.
>
> Is there any point trying to find the info using
> sleuthkit / autopsy.  If I could search for and find a
> relevant string using autopsy could I recover the file
> any better than foremost (which didn't even locate
> this particular document).
>
> Foremost finds office documents by looking for ole
> objects which is obviously a different search strategy
> than my typing in a particular string to search for in
> Autopsy.
>
> Also, would the fact that the image has a bad
> superblock preclude me from using sleuthkit/autopsy.
>
> I tried a couple of windows utilities (old version of
> Norton and a version of Paragon) to see if they could
> ressurect the partition but no joy.
>
> Any advice much appreciated,
>
> Cheers,
> JP.
>
>
>
>
>
>
>
> 		
> ___________________________________________________________
> To help you stay safe and secure online, we've developed the all  
> new Yahoo! Security Centre. http://uk.security.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

Re: [sleuthkit-users] Interest in AIX version

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

TSK should compile under AIX with a little tweaking, but it doesn't =20
support the native file system (JFS, I think...) so you can't analyze =20=

an AIX system.

brian


On Mar 6, 2006, at 12:19 PM, Mason Yu wrote:

>
>
> Gentlemen:
>
>
> I recently had an opportunity to obtain a copy of the book =20
> "Forensic Discovery"
> as part of the Addison-Wesley Series in Computer Science.  I did =20
> some further
> research in the sleuthkit, rootkit, etc.  What I was hoping to find =20=

> whether there
> a version for the IBM AIX rel 5.2, etc. for the sleuthkit.   If no =20
> one has set one up,
> I do have access to an AIX environment.  I would be interested in =20
> any feddback or
> response.
>
> Yours truly,
>
>
> Mason Yu, Jr.
> Java
>
> _________________________________________________________________
> Don=92t just search. Find. Check out the new MSN Search! http://=20
> search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20
> language
> that extends applications into web and mobile media. Attend the =20
> live webcast
> and join the prime developer group breaking into this new coding =20
> territory!
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

Re: SPAM: 99.9: Re: [sleuthkit-users] too many false positives

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

On Mar 6, 2006, at 7:24 AM, "" <gim...@we...> <gim...@we...>  
wrote:

> On Fri, 3 Mar 2006 12:15:03 -0500
> Brian Carrier <ca...@sl...> wrote:
>
>> They are deleted files and the clusters that they previously used
>> have been reallocated.  fls has no way of knowing if they have been
>> reallocated or not (and actually you don't either because there
>> could be MPEGs and HTML files with a .doc extension).
>
>
> So i used file utility to check this.
> Is there any tool or magicfile database which does this check  
> better in
> mind of forensic analyzes?
> file will check by magic key, but perhaps files do have more
> characteristics file doesn't check because it doesn't need to.

The sorter tool will compare the output of 'file' with a database of  
extensions.

brian

Re: SPAM: 99.9: Re: [sleuthkit-users] Autopsy: File Activity Timelines not working

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

Your partition table is screwed up.  TSK / Autopsy don't provide any  
tools to help fix that.  You can use a tool like testdisk or gpart to  
see if the FAT file system exists somewhere on the disk.

brian



On Mar 6, 2006, at 7:04 AM, "" <gim...@we...> <gim...@we...>  
wrote:

> On Wed, 22 Feb 2006 22:01:00 -0500
> Brian Carrier <ca...@sl...> wrote:
>
>>
>>> I added Partition 4 to case and it was partition i choosed to make
>>> timeline of.
>>
>> Was partition 4 added as a specific file system (i.e. can you go
>> into the file analysis mode of Autopsy and view the directory
>> listing?)? Only file systems are shown in the timeline view.  If it
>> was added as raw or swap then it will not be shown in the timeline
>> view.
>
> I'm sorry for my late answer (i did overlook this message thread for
> a while).
>
> You are right! I choosed file system type "raw"!
> That's because fat filesystem wasn't detected properly.
>
> Here is what i got:
>
> Collecting details on new image file:
>
> Warning: Conflicts in the partitions were detected.
> The full mmls output is given at the bottom of the page
>
> For your reference, the mmls output was the following:
> DOS Partition Table
> Sector: 0
> Units are in 512-byte sectors
>
> Slot Start End Length Description
> 00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
> 01: ----- 0000000001 0538989390 0538989390 Unallocated
> 02: 00:02 0538989391 1937352302 1398362912 OnTrack Disk Manager (0x53)
> 03: 00:01 1330184202 1869160489 0538976288 Unknown Type (0x6B)
> 04: 00:03 1394627663 1394648999 0000021337 Unknown Type (0x49)
> 05: ----- 1394649000 1935758367 0541109368 Unallocated
> 06: 00:00 1935758368 3615603091 1679844724 Unused (0x20)
>
> I did make image from iomega zip disk (100 MB). These zip disks use
> fat16 (fat12?) filesystems on partition 4.
>
> But it isn't recognized:
>
> Testing partitions
>
> Partition 4 is not a fat16 file system
> Use the browser's back button to fix the data
>
>
> Do you have any idea?
>
> regards
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

[sleuthkit-users] Bad Superblock and tsk versus foremost

[esrkq y. <es...@ya...>]

Hi,

Had a disk failure in windows.  There are some MS
Office files I would like to retrieve in particular
one Excel spreadsheet.

I tried to mount the relevant partition under linux
but got a bad superblock message.  The partition type
is vfat.

I imaged the partion under linux using dd and ran
foremost against it and it recovered 399 MS Office
files but unfortunately the one that I really wanted
wasn't amongst them.  Quite a few of the files it
recovered were corrupt.  It seemed to have more
success with Word  Docs than Excel.

I tried mounting the dd image with the loop back
driver but got the same error 'bad superblock'.

Is there any point trying to find the info using
sleuthkit / autopsy.  If I could search for and find a
relevant string using autopsy could I recover the file
any better than foremost (which didn't even locate
this particular document).

Foremost finds office documents by looking for ole
objects which is obviously a different search strategy
than my typing in a particular string to search for in
Autopsy.

Also, would the fact that the image has a bad
superblock preclude me from using sleuthkit/autopsy.

I tried a couple of windows utilities (old version of
Norton and a version of Paragon) to see if they could
ressurect the partition but no joy.

Any advice much appreciated,

Cheers,
JP.




 


		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

[sleuthkit-users] ECCE2006 - e-crime and computer evidence 2006 conference announcement

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

I am pleased to announce that the Call for Papers for ECCE 2006 has now been 
issued. The conference is scheduled to run in Nottingham, UK from 12th to 
14th September and we are inviting papers from a range of disciplines 
including computing, criminology, law and education. Please pass this 
information on to any colleagues who may be interested.

Details of the conference are now available at http://www.ecce-conference.com/

[sleuthkit-users] Interest in AIX version

[Mason Y. <mas...@ho...>]

Gentlemen:


I recently had an opportunity to obtain a copy of the book "Forensic 
Discovery"
as part of the Addison-Wesley Series in Computer Science.  I did some 
further
research in the sleuthkit, rootkit, etc.  What I was hoping to find whether 
there
a version for the IBM AIX rel 5.2, etc. for the sleuthkit.   If no one has 
set one up,
I do have access to an AIX environment.  I would be interested in any 
feddback or
response.

Yours truly,


Mason Yu, Jr.
Java

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: [sleuthkit-users] too many false positives

[<gim...@we...>]

On Fri, 3 Mar 2006 12:15:03 -0500
Brian Carrier <ca...@sl...> wrote:

> They are deleted files and the clusters that they previously used  
> have been reallocated.  fls has no way of knowing if they have been  
> reallocated or not (and actually you don't either because there
> could be MPEGs and HTML files with a .doc extension).


So i used file utility to check this.
Is there any tool or magicfile database which does this check better in
mind of forensic analyzes?
file will check by magic key, but perhaps files do have more
characteristics file doesn't check because it doesn't need to.

regards

Re: [sleuthkit-users] Restoring files

[<gim...@we...>]

On Mon, 27 Feb 2006 11:59:47 -0500
Bill McGonigle <bi...@bf...> wrote:

> So this shell script helps automate some of the recovery work then?  
> Interested in sharing?
> 

It's only a quick and dirty solution...
Shell script works similiar to this one:

http://forums.gentoo.org/viewtopic-t-365703.html

There's another script (from perhaps many out there) at

http://metawire.org/~henk/recoup

but i didn't make it run for me.

(

$ perl recoup.pl 
main::list() called too early to check prototype at recoup.pl line 33.

$ vi recoup.pl
line 33:
list($FLS_inode);

)

regards

Re: [sleuthkit-users] Autopsy: File Activity Timelines not working

[<gim...@we...>]

On Wed, 22 Feb 2006 22:01:00 -0500
Brian Carrier <ca...@sl...> wrote:

>
> > I added Partition 4 to case and it was partition i choosed to make
> > timeline of.
> 
> Was partition 4 added as a specific file system (i.e. can you go
> into the file analysis mode of Autopsy and view the directory
> listing?)? Only file systems are shown in the timeline view.  If it
> was added as raw or swap then it will not be shown in the timeline
> view.

I'm sorry for my late answer (i did overlook this message thread for
a while).

You are right! I choosed file system type "raw"!
That's because fat filesystem wasn't detected properly.

Here is what i got:

Collecting details on new image file:

Warning: Conflicts in the partitions were detected.
The full mmls output is given at the bottom of the page  

For your reference, the mmls output was the following:
DOS Partition Table
Sector: 0
Units are in 512-byte sectors

Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0538989390 0538989390 Unallocated
02: 00:02 0538989391 1937352302 1398362912 OnTrack Disk Manager (0x53)
03: 00:01 1330184202 1869160489 0538976288 Unknown Type (0x6B)
04: 00:03 1394627663 1394648999 0000021337 Unknown Type (0x49)
05: ----- 1394649000 1935758367 0541109368 Unallocated
06: 00:00 1935758368 3615603091 1679844724 Unused (0x20) 

I did make image from iomega zip disk (100 MB). These zip disks use
fat16 (fat12?) filesystems on partition 4.

But it isn't recognized:

Testing partitions

Partition 4 is not a fat16 file system
Use the browser's back button to fix the data


Do you have any idea?

regards

Re: [sleuthkit-users] too many false positives

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

They are deleted files and the clusters that they previously used =20
have been reallocated.  fls has no way of knowing if they have been =20
reallocated or not (and actually you don't either because there could =20=

be MPEGs and HTML files with a .doc extension).

brian


On Mar 2, 2006, at 2:31 PM, "" <gim...@we...> <gim...@we...> =20
wrote:

> Hi,
>
> does anyone know, why calling
>
> fls -f fat -p -r image.img
>
> and
>
> icat -f fat -r zippad.img (both used in script)
>
> brings up so many false positives?
>
> Look here:
>
> $file
> ...
> _FCHEN~1.DOC: data
> _U=E1BAK~1.DOC: MPEG ADTS, AAC, v4 Main, 96 kHz
> _UFA1E~1.DOC: COM executable for MS-DOS
> _DNKTE~1.DOC: ASCII HTML document text
> ...
>
> What can i do to get better results?
>
> Does anyone know the trick?
>
> regards
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20
> language
> that extends applications into web and mobile media. Attend the =20
> live webcast
> and join the prime developer group breaking into this new coding =20
> territory!
> http://sel.as-us.falkag.net/sel?=20
> cmd_______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] too many false positives

[<gim...@we...>]

Hi,

does anyone know, why calling

fls -f fat -p -r image.img=20

and

icat -f fat -r zippad.img (both used in script)

brings up so many false positives?

Look here:

$file
...
_FCHEN~1.DOC: data
_U=E1BAK~1.DOC: MPEG ADTS, AAC, v4 Main, 96 kHz
_UFA1E~1.DOC: COM executable for MS-DOS
_DNKTE~1.DOC: ASCII HTML document text
...

What can i do to get better results?

Does anyone know the trick?

regards

Re: [sleuthkit-users] Question about ifind and indirect blocks

[Nelson G. Mejias-D. <nel...@ne...>]

That's great! Thanks for taking the time to look into this.

Nelson

On Mon, 27 Feb 2006 23:05:11 -0400, Brian Carrier <ca...@sl...> wrote:

> You are correct.  I just fixed it (sf bug 1440075).  It also applied
> to indirect blocks for UFS.  I also fixed the duplicate messages.
>
> thanks!
> brian
>
>
> On Feb 24, 2006, at 1:00 PM, Nelson G. Mejias-Diaz wrote:
>
>> Hi Everyone,
>>
>> I'm new to this list and I have a question about ifind and indirect
>> blocks in ext2, using sleuthkit 2.03.  When I use the 'ifind' tool
>> and give an indirect block as an argument, to find its inode
>> number, I get an "Inode not found" message.  I want to know if the
>> tool is working correctly or if this indicates a bug.  I did
>> searches in Google and this mailing list but I haven't found an
>> answer for this.
>>
>> Here is the output of the command line call:
>>
>> [root@rush bin]# ./ifind -d 4361910 /dev/hda2
>> Inode not found
>> Inode not found
>>
>> where '4361910' is an indirect block number
>>
>>
>> I took this number from the output of the 'istat' command shown below.
>>
>> ------------ start of command output ------------
>>
>> [root@rush bin]# ./istat /dev/hda2 2180294
>> inode: 2180294
>> Allocated
>> Group: 133
>> Generation Id: 2672944929
>> uid / gid: 0 / 0
>> mode: -rw-r--r--
>> size: 613857
>> num of links: 1
>>
>> Inode Times:
>> Accessed:       Wed Jan 18 14:00:47 2006
>> File Modified:  Wed Jan 18 14:00:47 2006
>> Inode Modified: Wed Jan 18 14:00:47 2006
>>
>> Direct Blocks:
>> 4361893 4361894 4361895 4361896 4361897 4361898 4361899 4361900
>> 4361901 4361902 4361903 4361904 4361911 4361914 4361915 4361916
>> 4361917 4361918 4361919 4361920 4361921 4361922 4361923 4361924
>> 4361925 4361926 4361927 4361928 4361929 4361930 4361931 4361932
>> 4361933 4361934 4361937 4361938 4361939 4361940 4361941 4361942
>> 4361943 4361944 4362303 4362304 4362305 4362306 4362307 4362308
>> 4362309 4362310 4362311 4362312 4362313 4362314 4362315 4362316
>> 4362317 4362318 4362319 4362320 4362321 4362322 4362323 4362324
>> 4362325 4362326 4362407 4362408 4362409 4362410 4362411 4362412
>> 4362413 4362414 4362415 4362416 4362417 4362418 4362419 4362425
>> 4362426 4362427 4362428 4362429 4362430 4362431 4362432 4362433
>> 4362434 4362435 4362436 4362437 4362438 4362459 4362460 4362461
>> 4362462 4362463 4362464 4362465 4362466 4362467 4362468 4362472
>> 4362491 4362492 4362493 4362494 4362495 4362496 4362497 4362498
>> 4362499 4362500 4362501 4362502 4362503 4362504 4362505 4362506
>> 4362507 4362508 4362509 4362510 4362511 4362512 4362513 4362514
>> 4362515 4362516 4362517 4362518 4362519 4362521 4362522 4362523
>> 4362524 4362525 4362526 4362527 4362528 4362529 4362530 4362531
>> 4362532 4362533 4362534 4362535 4362536 4362537
>>
>> Indirect Blocks:
>> 4361910
>>
>



-- 
Nelson G. Mejias-Diaz
Director of Software Development
Netxar Technologies Inc.
phone: (787) 765-0058 ext 2009
email: nel...@ne...
website: www.netxar.com
--

RE: [sleuthkit-users] Analyzing FreeBSD Partition

[Brooks, P. <pre...@tw...>]

Thanks Brian and Barry,

after imaging /dev/hda, I was successful in gaining access to the =
filesystem.  I appreciate everyone who provided me these tips regarding =
how BSD managed the devices.


-----Original Message-----
From:	Brian Carrier [mailto:ca...@sl...]
Sent:	Mon 2/27/2006 9:36 PM
To:	Brooks, Prentis
Cc:	bg...@im...; sle...@li...
Subject:	Re: [sleuthkit-users] Analyzing FreeBSD Partition


On Feb 24, 2006, at 5:06 PM, Brooks, Prentis wrote:
>
> So, I should have imaged /dev/had rather than /dev/hda1?

Yes, Barry is correct.  You should have imaged /dev/hda AND you need =20
to keep in mind that the offsets in the FreeBSD disk label are =20
relative to the start of the disk and not relative to the start of =20
the FreeBSD partition.

brian

Re: [sleuthkit-users] Question about ifind and indirect blocks

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

You are correct.  I just fixed it (sf bug 1440075).  It also applied  
to indirect blocks for UFS.  I also fixed the duplicate messages.

thanks!
brian


On Feb 24, 2006, at 1:00 PM, Nelson G. Mejias-Diaz wrote:

> Hi Everyone,
>
> I'm new to this list and I have a question about ifind and indirect  
> blocks in ext2, using sleuthkit 2.03.  When I use the 'ifind' tool  
> and give an indirect block as an argument, to find its inode  
> number, I get an "Inode not found" message.  I want to know if the  
> tool is working correctly or if this indicates a bug.  I did  
> searches in Google and this mailing list but I haven't found an  
> answer for this.
>
> Here is the output of the command line call:
>
> [root@rush bin]# ./ifind -d 4361910 /dev/hda2
> Inode not found
> Inode not found
>
> where '4361910' is an indirect block number
>
>
> I took this number from the output of the 'istat' command shown below.
>
> ------------ start of command output ------------
>
> [root@rush bin]# ./istat /dev/hda2 2180294
> inode: 2180294
> Allocated
> Group: 133
> Generation Id: 2672944929
> uid / gid: 0 / 0
> mode: -rw-r--r--
> size: 613857
> num of links: 1
>
> Inode Times:
> Accessed:       Wed Jan 18 14:00:47 2006
> File Modified:  Wed Jan 18 14:00:47 2006
> Inode Modified: Wed Jan 18 14:00:47 2006
>
> Direct Blocks:
> 4361893 4361894 4361895 4361896 4361897 4361898 4361899 4361900
> 4361901 4361902 4361903 4361904 4361911 4361914 4361915 4361916
> 4361917 4361918 4361919 4361920 4361921 4361922 4361923 4361924
> 4361925 4361926 4361927 4361928 4361929 4361930 4361931 4361932
> 4361933 4361934 4361937 4361938 4361939 4361940 4361941 4361942
> 4361943 4361944 4362303 4362304 4362305 4362306 4362307 4362308
> 4362309 4362310 4362311 4362312 4362313 4362314 4362315 4362316
> 4362317 4362318 4362319 4362320 4362321 4362322 4362323 4362324
> 4362325 4362326 4362407 4362408 4362409 4362410 4362411 4362412
> 4362413 4362414 4362415 4362416 4362417 4362418 4362419 4362425
> 4362426 4362427 4362428 4362429 4362430 4362431 4362432 4362433
> 4362434 4362435 4362436 4362437 4362438 4362459 4362460 4362461
> 4362462 4362463 4362464 4362465 4362466 4362467 4362468 4362472
> 4362491 4362492 4362493 4362494 4362495 4362496 4362497 4362498
> 4362499 4362500 4362501 4362502 4362503 4362504 4362505 4362506
> 4362507 4362508 4362509 4362510 4362511 4362512 4362513 4362514
> 4362515 4362516 4362517 4362518 4362519 4362521 4362522 4362523
> 4362524 4362525 4362526 4362527 4362528 4362529 4362530 4362531
> 4362532 4362533 4362534 4362535 4362536 4362537
>
> Indirect Blocks:
> 4361910
>

Re: [sleuthkit-users] Analyzing FreeBSD Partition

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

On Feb 24, 2006, at 5:06 PM, Brooks, Prentis wrote:
>
> So, I should have imaged /dev/had rather than /dev/hda1?

Yes, Barry is correct.  You should have imaged /dev/hda AND you need  
to keep in mind that the offsets in the FreeBSD disk label are  
relative to the start of the disk and not relative to the start of  
the FreeBSD partition.

brian

Re: [sleuthkit-users] Restoring files

[Bill M. <bi...@bf...>]

On Feb 20, 2006, at 15:15, gimeshell wrote:

> Thanks for the hint, used to build a shell script (ils + icat)!

So this shell script helps automate some of the recovery work then?  
Interested in sharing?

Thanks,
-Bill

-----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bi...@bf...           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

RE: [sleuthkit-users] Analyzing FreeBSD Partition

[Barry J. G. <bg...@im...>]

On Fri, 2006-02-24 at 17:06 -0500, Brooks, Prentis wrote:
> And no, not finding any "unix labelufs" 

Sorry, if you grep, use -i.  The string is in all CAPS.


-- 
/***************************************
Special Agent Barry J. Grundy
NASA Office of Inspector General
Computer Crimes Division 
Goddard Space Flight Center
Code 190
Greenbelt Rd.
Greenbelt, MD 20771
(301)286-3358
**************************************/

RE: [sleuthkit-users] Analyzing FreeBSD Partition

[Brooks, P. <pre...@tw...>]

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCiANClNv
LCBJIHNob3VsZCBoYXZlIGltYWdlZCAvZGV2L2hhZCByYXRoZXIgdGhhbiAvZGV2L2hkYTE/DQoN
CkFuZCBubywgbm90IGZpbmRpbmcgYW55ICJ1bml4IGxhYmVsdWZzIiANCg0KQWx0aG91Z2ggeW91
IGhhdmUgZ2l2ZW4gbWUgYW5vdGhlciB0YWN0aWMgdG8gYXR0ZW1wdCBuZXh0IHdlZWsuICBUaGFu
a3MNCg0KUHJlbnRpcyBCcm9va3MNCiANCg0KLSAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogQmFycnkgSi4gR3J1bmR5IFttYWlsdG86YmdydW5keUBpbXguaHEubmFzYS5nb3ZdIA0K
U2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAwNiA0OjU0IFBNDQpUbzogQnJvb2tzLCBQcmVu
dGlzDQpDYzogc2xldXRoa2l0LXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KU3ViamVjdDog
UmU6IFtzbGV1dGhraXQtdXNlcnNdIEFuYWx5emluZyBGcmVlQlNEIFBhcnRpdGlvbg0KDQpPbiBG
cmksIDIwMDYtMDItMjQgYXQgMTA6MDcgLTA1MDAsIEJyb29rcywgUHJlbnRpcyB3cm90ZToNCg0K
PiBob3dldmVyLCB0aGUgcmVzdWx0aW5nIGZyZWVic2QuZGQgaW1hZ2UgaGFzIHRoZSBzYW1lIGZh
aWx1cmVzIGFzIHRoZSANCj4gcHJldmlvdXMuICBJIGhhdmUgbG9va2VkIGZvciBhbnkgb3RoZXIg
cmVmZXJlbmNlcyB0byB0aGUgNC4yQlNEIGJ1dCANCj4gaGF2ZW4ndCBmb3VuZCBhbnl0aGluZyBp
biBwYXJ0aWN1bGFyIGFib3V0IGl0LiAgQW0gSSBtaXNzaW5nIA0KPiBzb21ldGhpbmc/ICBBbnkg
aGVscCB3aWxsIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQoNCkhpIFByZW50aXMsDQoNCkknbSBn
b2luZyB0byBoYXphcmQgYSBndWVzcyBoZXJlLi4uIEl0IGxvb2tzIGxpa2UgdGhlIGZpbGUgaGRh
MS5pbWcgaXMgYW4gaW1hZ2UgY3JlYXRlZCB2aWEgZGQgb2YgYSAiZnJlZWJzZCBwYXJ0aXRpb24i
LCBwZXJoYXBzIGlkZW50aWZpZWQgYnkgbGludXggZmRpc2sgKG9yIHNmZGlzaywgZXRjLikgSW4g
b3RoZXIgd29yZHMgIm5vdCB0aGUgd2hvbGUgZGlzayIuDQoNCllvdXIgbW1scyBjb21tYW5kIHNo
b3dzIHlvdSB0aGUgZGlzayBsYWJlbCBmb3VuZCBpbiB0aGF0IHBhcnRpdGlvbiwgYnV0IHRoZSBv
ZmZzZXRzIGdpdmVuIHRvIHRoZSBmcmVlYnNkIGZpbGVzeXN0ZW0gYXJlIHJlbGF0aXZlIHRvIHRo
ZSAqZGlzayoNCihoZGEpIG5vdCB0aGUgcGFydGl0aW9uIChoZGExKS4gIFNvIGluIHRyeWluZyB0
byBjYXJ2ZSBvdXQgdGhlIGZpbGVzeXN0ZW0sIHlvdSBhcmUgcGFzc2luZyBhbiBvZmZzZXQgdGhh
dCBpcyB3cm9uZy4NCg0KVGhhdCBpcyBhICpndWVzcyouDQoNCkhhdmUgeW91IHVzZWQgeHhkIChv
ciBvdGhlciB2aWV3ZXIpIHRvIGxvb2sgYXQgdGhlIGltYWdlIGFuZCB0aGUgcmVzdWx0cyBvZiB5
b3VyIGF0dGVtcHRlZCBjYXJ2ZT8gIEFueSAidW5peCBsYWJlbHVmcyIgc3RyaW5ncz8NCiANCi0g
LS0NCi8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClNwZWNpYWwgQWdl
bnQgQmFycnkgSi4gR3J1bmR5DQpOQVNBIE9mZmljZSBvZiBJbnNwZWN0b3IgR2VuZXJhbA0KQ29t
cHV0ZXIgQ3JpbWVzIERpdmlzaW9uDQpHb2RkYXJkIFNwYWNlIEZsaWdodCBDZW50ZXINCkNvZGUg
MTkwDQpHcmVlbmJlbHQgUmQuDQpHcmVlbmJlbHQsIE1EIDIwNzcxDQooMzAxKTI4Ni0zMzU4DQoq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8NCg0KDQotLS0tLUJFR0lOIFBH
UCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjogUEdQIERlc2t0b3AgOS4wLjUgKEJ1aWxkIDUwNTAp
DQoNCmlRRVZBd1VCUS8rRGdWTGF2MWxWYzBRckFRaTk3d2Y3QlhwSWNpd25rVi9nenBxeVZ6bENV
QUEzU1RyL1JiOGINCnZRK2J5R1lISTBQSUJlYlFuc3BadTlyaGxRT2JWaDFNN1k3NkwzQjBKeDRR
dnhmR2NJNkRkSWwydGtjV1lVY24NCkV5Q2Y1WXYybElWZDBLcWllcmRJR1lReHorZEhoWkpzVzRU
Tll3TUo3VkxpaVVpcG92Ti9aR0pqQWtvNTY1ZEkNCmFCSkJEQmFaN3VKMmp3MCtzZG0va0hmUUMx
eXFEeEg5RktyV3pOUXFwbTlIelhBTm9hTTkvOGRheFNOS3VadGINCmR3MGRqVjZkNlUwWnJNYmdk
d0ZhZE5FTER2VTZLb2hPZEhuWjgvOGpSa09PckRiaWxjVXNqNkZWMmtzV2NSVDENCmJ1TjBBM29p
V2hLREpnV2NpWFBuODVLZmJxWWxqNW45cW9JR3JGOHQ1ZkhETFVvNXZxY2VWZz09DQo9UXQ4eQ0K
LS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQoNCg==

Re: [sleuthkit-users] Analyzing FreeBSD Partition

[Barry J. G. <bg...@im...>]

On Fri, 2006-02-24 at 10:07 -0500, Brooks, Prentis wrote:

> however, the resulting freebsd.dd image has the same failures as the
> previous.  I have looked for any other references to the 4.2BSD but
> haven't found anything in particular about it.  Am I missing
> something?  Any help will be greatly appreciated.

Hi Prentis,

I'm going to hazard a guess here... It looks like the file hda1.img is
an image created via dd of a "freebsd partition", perhaps identified by
linux fdisk (or sfdisk, etc.) In other words "not the whole disk".

Your mmls command shows you the disk label found in that partition, but
the offsets given to the freebsd filesystem are relative to the *disk*
(hda) not the partition (hda1).  So in trying to carve out the
filesystem, you are passing an offset that is wrong.

That is a *guess*.

Have you used xxd (or other viewer) to look at the image and the results
of your attempted carve?  Any "unix labelufs" strings?
 
-- 
/***************************************
Special Agent Barry J. Grundy
NASA Office of Inspector General
Computer Crimes Division 
Goddard Space Flight Center
Code 190
Greenbelt Rd.
Greenbelt, MD 20771
(301)286-3358
**************************************/

RE: [sleuthkit-users] Analyzing FreeBSD Partition

[Brooks, P. <pre...@tw...>]

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNClRvIHBy
b3ZpZGUgbW9yZSBpbmZvcm1hdGlvbiwgaWYgSSB0ZWxsIGF1dG9wc3kgdG8gdHJlYXQgbXkgb3Jp
Z2luYWwgaW1hZ2UgYXMgYSBkaXNrLCB0aGlzIGlzIHdoYXQgaXQgaWRlbnRpZmllcyB3aXRoaW46
DQogDQpBbmFseXNpcyBvZiB0aGUgaW1hZ2UgZmlsZSBzaG93cyB0aGUgZm9sbG93aW5nIHBhcnRp
dGlvbnM6CSANCiANCiANClBhcnRpdGlvbiAxIChUeXBlOiBTd2FwICgweDAxKSkJDQogDQogIA0K
QWRkIHRvIGNhc2U/IA0KIA0KICANClNlY3RvciBSYW5nZTogNjMgdG8gMjYyMjA2DQogDQogIA0K
TW91bnQgUG9pbnQ6ICBGaWxlIFN5c3RlbSBUeXBlOiBleHQgZmF0IG50ZnMgdWZzIC0tLS0tIGZh
dDEyIGZhdDE2IGZhdDMyIGJzZGkgZnJlZWJzZCBvcGVuYnNkIHNvbGFyaXMgPT09PT09IHJhdyBz
d2FwCQ0KIA0KIAkNClBhcnRpdGlvbiAyIChUeXBlOiBVbnVzZWQgKDB4MDApKQkNCiANCiAgDQpB
ZGQgdG8gY2FzZT8gDQogDQogIA0KU2VjdG9yIFJhbmdlOiA2MyB0byAxOTUzNTAzOQ0KIA0KICAN
Ck1vdW50IFBvaW50OiAgRmlsZSBTeXN0ZW0gVHlwZTogZXh0IGZhdCBudGZzIHVmcyAtLS0tLSBm
YXQxMiBmYXQxNiBmYXQzMiBic2RpIGZyZWVic2Qgb3BlbmJzZCBzb2xhcmlzID09PT09PSByYXcg
c3dhcAkNCiANCiAJDQpQYXJ0aXRpb24gMyAoVHlwZTogNC4yQlNEICgweDA3KSkJDQogDQogIA0K
QWRkIHRvIGNhc2U/IA0KIA0KICANClNlY3RvciBSYW5nZTogMjYyMjA3IHRvIDE5NTM1MDM5DQog
DQogIA0KTW91bnQgUG9pbnQ6ICBGaWxlIFN5c3RlbSBUeXBlOiBleHQgZmF0IG50ZnMgdWZzIC0t
LS0tIGZhdDEyIGZhdDE2IGZhdDMyIGJzZGkgZnJlZWJzZCBvcGVuYnNkIHNvbGFyaXMgPT09PT09
IHJhdyBzd2FwCQ0KIA0KIAkNCiANCiANCkl0IGlzIFBhcnRpdGlvbiAzIHRoYXQgaXMgaW50ZXJl
c3RpbmcgdG8gbWUuDQogDQogDQpQcmVudGlzIEJyb29rcw0KIA0KIA0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KDQpGcm9tOiBzbGV1dGhraXQtdXNlcnMtYWRtaW5AbGlzdHMu
c291cmNlZm9yZ2UubmV0IFttYWlsdG86c2xldXRoa2l0LXVzZXJzLWFkbWluQGxpc3RzLnNvdXJj
ZWZvcmdlLm5ldF0gT24gQmVoYWxmIE9mIEJyb29rcywgUHJlbnRpcw0KU2VudDogRnJpZGF5LCBG
ZWJydWFyeSAyNCwgMjAwNiAxMDowNyBBTQ0KVG86IHNsZXV0aGtpdC11c2Vyc0BsaXN0cy5zb3Vy
Y2Vmb3JnZS5uZXQNClN1YmplY3Q6IFtzbGV1dGhraXQtdXNlcnNdIEFuYWx5emluZyBGcmVlQlNE
IFBhcnRpdGlvbg0KDQoNCkhleSBBbGwsDQogICAgSSBuZWVkIHNvbWUgaGVscCB0cnlpbmcgdG8g
Z2V0IHNsZXV0aGtpdCB0byByZWFkIGFuIGltYWdlIHB1bGxlZCBmcm9tIGEgKHJlcG9ydGVkbHkp
IEZyZWVCU0Qgc3lzdGVtLiAgVGhlIGltYWdlIHdhcyB0YWtlbiB1c2luZyBkZCBvZiAvZGV2L2hk
YTEuICBBdHRlbXB0cyB0byBwb2ludCBhdXRvcHN5IGF0IHRoZSBpbWFnZSBmaWxlIHVzaW5nIHVm
cywgZnJlZWJzZCwgYW5kIG9wZW5ic2QsIGFsbCBmYWlsIHJlcG9ydGluZyB0aGF0IHRoZSBpbWFn
ZSBpcyBub3QgdGhvc2UgZmlsZXN5c3RlbSB0eXBlcy4gIEFmdGVyIHJlYWRpbmcgdm9sdW1lIDEy
IG9mIHRoZSBpbmZvcm1lciwgSSBkZWNpZGVkIHRvIHRyeSByaXBwaW5nIHRoZSA0LjJCU0QgaW1h
Z2Ugb3V0Og0KIA0KbW1scyBvdXRwdXQgb2YgdGhlIHJlc3VsdGluZyBpbWFnZSBmaWxlOg0KIA0K
IC91c3IvbG9jYWwvc2xldXRoa2l0L2Jpbi9tbWxzIC10IGJzZCBoZGExLmltZyAgICAgICAgICBC
U0QgRGlzayBMYWJlbA0KU2VjdG9yOiAxDQpVbml0cyBhcmUgaW4gNTEyLWJ5dGUgc2VjdG9ycw0K
IA0KICAgICBTbG90ICAgIFN0YXJ0ICAgICAgICBFbmQgICAgICAgICAgTGVuZ3RoICAgICAgIERl
c2NyaXB0aW9uDQowMDogIC0tLS0tICAgMDAwMDAwMDAwMCAgIDAwMDAwMDAwNjIgICAwMDAwMDAw
MDYzICAgVW5hbGxvY2F0ZWQNCjAxOiAgMDEgICAgICAwMDAwMDAwMDYzICAgMDAwMDI2MjIwNiAg
IDAwMDAyNjIxNDQgICBTd2FwICgweDAxKQ0KMDI6ICAwMiAgICAgIDAwMDAwMDAwNjMgICAwMDE5
NTM1MDM5ICAgMDAxOTUzNDk3NyAgIFVudXNlZCAoMHgwMCkNCjAzOiAgMDAgICAgICAwMDAwMjYy
MjA3ICAgMDAxOTUzNTAzOSAgIDAwMTkyNzI4MzMgICA0LjJCU0QgKDB4MDcpDQogDQogDQpVc2lu
ZyB0aGUgZm9sbG93aW5nIGRkIGNvbW1hbmQ6IGRkIGlmPWhkYTEuaW1nIGJzPTUxMiBvZj1mcmVl
YnNkLmRkIHNraXA9MjYyMjA3IGNvdW50PTE5MjcyODMzDQogDQpob3dldmVyLCB0aGUgcmVzdWx0
aW5nIGZyZWVic2QuZGQgaW1hZ2UgaGFzIHRoZSBzYW1lIGZhaWx1cmVzIGFzIHRoZSBwcmV2aW91
cy4gIEkgaGF2ZSBsb29rZWQgZm9yIGFueSBvdGhlciByZWZlcmVuY2VzIHRvIHRoZSA0LjJCU0Qg
YnV0IGhhdmVuJ3QgZm91bmQgYW55dGhpbmcgaW4gcGFydGljdWxhciBhYm91dCBpdC4gIEFtIEkg
bWlzc2luZyBzb21ldGhpbmc/ICBBbnkgaGVscCB3aWxsIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQu
DQogDQpQcmVudGlzIEJyb29rcw0KRW50ZXJwcmlzZSBTZWN1cml0eSBUZWNobmljYWwgTWFuYWdl
cg0Kb2ZmaWNlOiA3MDQtNzMxLTM0MDggDQpBSU06IFRXQ1BhbGFkaW4gDQplbWFpbDogcHJlbnRp
cy5icm9va3NAdHdjYWJsZS5jb20NCiANCg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0N
ClZlcnNpb246IFBHUCBEZXNrdG9wIDkuMC41IChCdWlsZCA1MDUwKQ0KDQppUUVWQXdVQlEvOXlC
RkxhdjFsVmMwUXJBUWpZb3dmN0IyL2dyYzUwaEpVQVRwZnN4UVlNQlYvTGIxaXQ4cXpiDQpRK3JD
OFJPTndIODdqSUM2T0FpNnM2R2pESVJjUWkrSmMydDhNNGhWemVaV2tMNEhQeDFhT0d5Yk1VS0ZY
V2wzDQpKeHU0T1dXTmtOeTFVRmFCN1FtWWFucEdFVFZSblU4R2xlWlkvM0crMElXa0F0QTRhNGZS
WmRxYzZRYUtVR3NsDQpiZ3R0TDJTYVVQcWMwV2daWU01eFppWlVEd1VJTzQ2OXVCSHl3NUpJdVlY
SG5va0tzY2xqWXB4YmtCS21OZU1WDQpLakYzQ2dqRVZyVTBITHlrczBwRFRSQzBNbGRETzZ2a3B3
djVBaEEvcmszcUh5VndzZnFleFVaREE5SlVCU2wrDQpQVEFZaHA0aXlhK2JyaXNrSWxZc1pTUWkv
U3IzMGFkcjN6dTYxM2dPNk5WZ096RXhXZWNLR0E9PQ0KPTBEbHINCi0tLS0tRU5EIFBHUCBTSUdO
QVRVUkUtLS0tLQ0KDQo=