Thread: [sleuthkit-users] icat and ifind -- Help with -- Please DO NOT hijack threads
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users
|
From: Paul D. B. <pau...@po...> - 2009-11-20 23:53:43
|
Big...@gm... wrote: >> Hello all, >> >> I am very new to this field. >> >> Would there be someone willing to help me with some questions, mainly >> around icat and ifind. I dont mind doing it on list, Well, if you are going to do it on this list, then I suggest that you start a new thread of discussion (ToD) rather than hijack an existing email ToD. Folks, I am extremely disappointed to see ToD hijacking on a list comprised of sophisticated IT professionals, people who ought to know better than to do so. Please DO NOT hijack email ToD's. Sincerely, Paul Bain >> but I am likely to >> get my head around it faster through a IM session on MSN or Skype or the >> like. >> >> Thansk in advance >> >> -Al |
|
From: <Big...@gm...> - 2009-11-20 23:58:14
|
Paul, I think you need to calm down. It wasnt done intentioanlly. I created a new email to sle...@li... - somehow in doing this it sounds like its linked to someone elses thread. I suppose thats well and truely given me the kiss of death and killed any chance of some help. Thanks -Al On , "Paul D. Bain" <pau...@po...> wrote: > Big...@gm... wrote: > Hello all, > I am very new to this field. > Would there be someone willing to help me with some questions, mainly > around icat and ifind. I dont mind doing it on list, > Well, if you are going to do it on this list, then I suggest that you > start a new thread of discussion (ToD) rather than hijack an existing > email ToD. > Folks, I am extremely disappointed to see ToD hijacking on a list > comprised of sophisticated IT professionals, people who ought to know > better than to do so. Please DO NOT hijack email ToD's. > Sincerely, > Paul Bain > but I am likely to get my head around it faster through a IM session on > MSN or Skype or the like. > Thansk in advance > -Al |
|
From: Theodore P. <te...@gm...> - 2009-11-21 00:38:07
|
I think I've reviewed all the recent threads and I don't see where Al hijacked someone else's thread. Care to point out which thread he hijacked? On Fri, Nov 20, 2009 at 6:29 PM, Paul D. Bain <pau...@po...> wrote: > Big...@gm... wrote: >>> Hello all, >>> >>> I am very new to this field. >>> >>> Would there be someone willing to help me with some questions, mainly >>> around icat and ifind. I dont mind doing it on list, > > Well, if you are going to do it on this list, then I suggest that you > start a new thread of discussion (ToD) rather than hijack an existing > email ToD. > > Folks, I am extremely disappointed to see ToD hijacking on a list > comprised of sophisticated IT professionals, people who ought to know > better than to do so. Please DO NOT hijack email ToD's. > > Sincerely, > Paul Bain > >>> but I am likely to >>> get my head around it faster through a IM session on MSN or Skype or the >>> like. >>> >>> Thansk in advance >>> >>> -Al > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Richard L. <rk...@co...> - 2009-11-21 00:56:26
|
Is it Friday or is it just that everyone is a little testy tonight.... Have a great Thanksgiving... |R -----Original Message----- From: Theodore Pham [mailto:te...@gm...] Sent: Friday, November 20, 2009 6:38 PM To: pau...@po... Cc: sle...@li... Subject: Re: [sleuthkit-users] icat and ifind -- Help with -- Please DO NOT hijack threads I think I've reviewed all the recent threads and I don't see where Al hijacked someone else's thread. Care to point out which thread he hijacked? On Fri, Nov 20, 2009 at 6:29 PM, Paul D. Bain <pau...@po...> wrote: > Big...@gm... wrote: >>> Hello all, >>> >>> I am very new to this field. >>> >>> Would there be someone willing to help me with some questions, mainly >>> around icat and ifind. I dont mind doing it on list, > > Well, if you are going to do it on this list, then I suggest that you > start a new thread of discussion (ToD) rather than hijack an existing > email ToD. > > Folks, I am extremely disappointed to see ToD hijacking on a list > comprised of sophisticated IT professionals, people who ought to know > better than to do so. Please DO NOT hijack email ToD's. > > Sincerely, > Paul Bain > >>> but I am likely to >>> get my head around it faster through a IM session on MSN or Skype or the >>> like. >>> >>> Thansk in advance >>> >>> -Al > > > ---------------------------------------------------------------------------- -- > 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 |
|
From: Ron M. <ro...@fo...> - 2009-11-21 02:05:20
|
How many hours should I cook a turkey? Is one day per pound too much? Can sleuth kit make me a stuffing recipe? At least I know who sit at the little folk's table. Happy Thanksgiving and may all your hard drives baste themselves. --- On Fri, 11/20/09, Richard Linke <rk...@co...> wrote: > From: Richard Linke <rk...@co...> > Subject: Re: [sleuthkit-users] icat and ifind -- Help with -- Please DO NOT hijack threads > To: "'Theodore Pham'" <te...@gm...>, pau...@po... > Cc: sle...@li... > Date: Friday, November 20, 2009, 7:56 PM > Is it Friday or is it just that > everyone is a little testy tonight.... > > Have a great Thanksgiving... > > |R > > -----Original Message----- > From: Theodore Pham [mailto:te...@gm...] > > Sent: Friday, November 20, 2009 6:38 PM > To: pau...@po... > Cc: sle...@li... > Subject: Re: [sleuthkit-users] icat and ifind -- Help with > -- Please DO NOT > hijack threads > > I think I've reviewed all the recent threads and I don't > see where Al > hijacked someone else's thread. > > Care to point out which thread he hijacked? > > On Fri, Nov 20, 2009 at 6:29 PM, Paul D. Bain <pau...@po...> > wrote: > > Big...@gm... > wrote: > >>> Hello all, > >>> > >>> I am very new to this field. > >>> > >>> Would there be someone willing to help me with > some questions, mainly > >>> around icat and ifind. I dont mind doing it on > list, > > > > Well, if you are going to do it on this > list, then I suggest that > you > > start a new thread of discussion (ToD) rather than > hijack an existing > > email ToD. > > > > Folks, I am extremely disappointed to see > ToD hijacking on a list > > comprised of sophisticated IT professionals, people > who ought to know > > better than to do so. Please DO NOT hijack email > ToD's. > > > > Sincerely, > > Paul Bain > > > >>> but I am likely to > >>> get my head around it faster through a IM > session on MSN or Skype or the > >>> like. > >>> > >>> Thansk in advance > >>> > >>> -Al > > > > > > > ---------------------------------------------------------------------------- > -- > > 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 > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Paul D. B. <pau...@po...> - 2009-11-21 01:23:09
|
Theodore Pham wrote: > I think I've reviewed all the recent threads and I don't see where Al > hijacked someone else's thread. > > Care to point out which thread he hijacked? I am using Thunderbird (TB) 2.0.0.23 as my MUA. TB's threading module indicates that Al's email was made in reply to the 19 Nov. email from Simson Garfinkel whose subject line was thus: "Re: [sleuthkit-users] No mactime." IOW, when I view the emails from this mailing list in TB's threaded mode, Al's email appears directly underneath the email from S. Garfinkel and indented with respect to Garfinkel's email. Al's email does not appear as a separate ToD, at least not in TB. > On Fri, Nov 20, 2009 at 6:29 PM, Paul D. Bain <pau...@po...> wrote: >> Big...@gm... wrote: >>>> Hello all, >>>> >>>> I am very new to this field. >>>> >>>> Would there be someone willing to help me with some questions, mainly >>>> around icat and ifind. I dont mind doing it on list, >> Well, if you are going to do it on this list, then I suggest that you >> start a new thread of discussion (ToD) rather than hijack an existing >> email ToD. >> >> Folks, I am extremely disappointed to see ToD hijacking on a list >> comprised of sophisticated IT professionals, people who ought to know >> better than to do so. Please DO NOT hijack email ToD's. >> >> Sincerely, >> Paul Bain >> >>>> but I am likely to >>>> get my head around it faster through a IM session on MSN or Skype or the >>>> like. >>>> >>>> Thansk in advance >>>> >>>> -Al |
|
From: Theodore P. <te...@gm...> - 2009-11-21 01:50:22
|
Ah, that explains it. Looking at the full headers for Al's original message, I see that it contains the following header: In-Reply-To: <A8D...@ac...> I assume this is because he looked at the old thread to find the mailing list address, then hit Reply in his MUA. Once in the actual new draft, he would have had to change the Subject and may have trimmed out other recipient addresses if his MUA included them when he hit Reply. Not many MUA's I know of display the In-Reply-To header as part of the GUI so it likely went along for the ride without his knowing. Gmail and the list archiving software at Sourceforge don't seem to use the In-Reply-To header for threading, they seem to require that the Subject line not have been changed. Based upon what you have said, Thunderbird appears to use the In-Reply-To regardless of the Subject line. So you see, he didn't mean any offense. Hell I'm sure I've done the exact same thing on occasion. Interesting. At least I learned something new today :) On Fri, Nov 20, 2009 at 8:22 PM, Paul D. Bain <pau...@po...> wrote: > Theodore Pham wrote: >> >> I think I've reviewed all the recent threads and I don't see where Al >> hijacked someone else's thread. >> >> Care to point out which thread he hijacked? > > I am using Thunderbird (TB) 2.0.0.23 as my MUA. TB's threading module > indicates that Al's email was made in reply to the 19 Nov. email from Simson > Garfinkel whose subject line was thus: "Re: [sleuthkit-users] No mactime." > IOW, when I view the emails from this mailing list in TB's threaded mode, > Al's email appears directly underneath the email from S. Garfinkel and > indented with respect to Garfinkel's email. Al's email does not appear as a > separate ToD, at least not in TB. > > >> On Fri, Nov 20, 2009 at 6:29 PM, Paul D. Bain <pau...@po...> wrote: >>> >>> Big...@gm... wrote: >>>>> >>>>> Hello all, >>>>> >>>>> I am very new to this field. >>>>> >>>>> Would there be someone willing to help me with some questions, mainly >>>>> around icat and ifind. I dont mind doing it on list, >>> >>> Well, if you are going to do it on this list, then I suggest that >>> you >>> start a new thread of discussion (ToD) rather than hijack an existing >>> email ToD. >>> >>> Folks, I am extremely disappointed to see ToD hijacking on a list >>> comprised of sophisticated IT professionals, people who ought to know >>> better than to do so. Please DO NOT hijack email ToD's. >>> >>> Sincerely, >>> Paul Bain >>> >>>>> but I am likely to >>>>> get my head around it faster through a IM session on MSN or Skype or >>>>> the >>>>> like. >>>>> >>>>> Thansk in advance >>>>> >>>>> -Al > |
|
From: Paul D. B. <pau...@po...> - 2009-11-21 02:04:10
|
Theodore Pham wrote: > Ah, that explains it. Looking at the full headers for Al's original > message, I see that it contains the following header: > > In-Reply-To: <A8D...@ac...> > > I assume this is because he looked at the old thread to find the > mailing list address, then hit Reply in his MUA. > > Once in the actual new draft, he would have had to change the Subject > and may have trimmed out other recipient addresses if his MUA included > them when he hit Reply. Not many MUA's I know of display the > In-Reply-To header as part of the GUI so it likely went along for the > ride without his knowing. > > Gmail and the list archiving software at Sourceforge don't seem to use > the In-Reply-To header for threading, they seem to require that the > Subject line not have been changed. Based upon what you have said, > Thunderbird appears to use the In-Reply-To regardless of the Subject > line. Theodore Pham, Yes, this is my understanding, too. Apparently, the majority of the users of this mailing list seem to think that my criticism of Al was inappropriate. Interesting. > So you see, he didn't mean any offense. Hell I'm sure I've done the > exact same thing on occasion. Yes, I have probably transgressed thus once or twice, too, but not intentionally. > Interesting. At least I learned something new today :) > > On Fri, Nov 20, 2009 at 8:22 PM, Paul D. Bain <pau...@po...> wrote: >> Theodore Pham wrote: >>> I think I've reviewed all the recent threads and I don't see where Al >>> hijacked someone else's thread. >>> >>> Care to point out which thread he hijacked? >> I am using Thunderbird (TB) 2.0.0.23 as my MUA. TB's threading module >> indicates that Al's email was made in reply to the 19 Nov. email from Simson >> Garfinkel whose subject line was thus: "Re: [sleuthkit-users] No mactime." >> IOW, when I view the emails from this mailing list in TB's threaded mode, >> Al's email appears directly underneath the email from S. Garfinkel and >> indented with respect to Garfinkel's email. Al's email does not appear as a >> separate ToD, at least not in TB. >> >> >>> On Fri, Nov 20, 2009 at 6:29 PM, Paul D. Bain <pau...@po...> wrote: >>>> Big...@gm... wrote: >>>>>> Hello all, >>>>>> >>>>>> I am very new to this field. >>>>>> >>>>>> Would there be someone willing to help me with some questions, mainly >>>>>> around icat and ifind. I dont mind doing it on list, >>>> Well, if you are going to do it on this list, then I suggest that >>>> you >>>> start a new thread of discussion (ToD) rather than hijack an existing >>>> email ToD. >>>> >>>> Folks, I am extremely disappointed to see ToD hijacking on a list >>>> comprised of sophisticated IT professionals, people who ought to know >>>> better than to do so. Please DO NOT hijack email ToD's. >>>> >>>> Sincerely, >>>> Paul Bain >>>> >>>>>> but I am likely to >>>>>> get my head around it faster through a IM session on MSN or Skype or >>>>>> the >>>>>> like. >>>>>> >>>>>> Thansk in advance >>>>>> >>>>>> -Al > > ------------------------------------------------------------------------------ > 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 > |
|
From: Al G. <big...@gm...> - 2009-11-21 03:46:12
|
Right. Here is the question. I get harddisks (minly NTFS) with bad sectors on them. I want to know what if any files reside on the badblocks with ifind. I normally image them right there and then with ddrescue, but in this example we can with with the disk since its for the bin. Heres the badblocks data: 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:~$ sudo badblocks -b 512 -vs /dev/sdb Checking blocks 0 to 312581807 Checking for bad blocks (read-only test): 22817408done, 4:46 elapsed 22817432done, 5:55 elapsed 22817433done, 6:18 elapsed 22817434done, 6:42 elapsed 22817435done, 7:05 elapsed 22817436done, 7:28 elapsed 22817437done, 7:51 elapsed 22817438done, 8:14 elapsed 22817439done, 8:37 elapsed 22817440 22817441 22817442 22817443 22817444 22817445 22817446 22817447 22817448 22817449 22817450 22817451 22817452 22817453 22817454 22817455 22817456 22817457 22817458 22817459 22817460 22817461 22817462 22817463 22817464 22817465 22817466 22817467 22817468 22817469 22817470 22817471 22817472 22817473 22817474 22817475 22817476 22817477 22817478 22817479 22817480 22817481 22817482 22817483 22817484 22817485 22817486 22817487 22817488 22817489 22817490 22817491 22817492 22817493 22817494 22817495 22817496 22817497 22817498 22817499 22817500 22817501 22817502 22817503 22817504 22817505 22817506 22817507 22817508 22817509 22817510 22817511 22817512 22817513 22817514 22817515 22817516 22817517 22817518 22817519 22817520 22817521 22817522 22817523 22817524 22817525 22817526 22817527 22817528 22817529 22817530 22817531 22817532 22817533 22817534 22817535 22817536 22817537 22817538 22817539 22817540 22817541 22817542 22817543 215058296one, 52:13 elapsed 215058312one, 52:59 elapsed 215058313one, 53:22 elapsed 215058314one, 53:45 elapsed 215058315one, 54:08 elapsed 215058316one, 54:31 elapsed 215058317one, 54:54 elapsed 215058318one, 55:17 elapsed 215058319one, 55:40 elapsed done Pass completed, 122 bad blocks found. al@al-ubuntu:~$ Now, how to find what if any data is listed as residing on those blocks? Cheers -Al -- View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26453534.html Sent from the sleuthkit-users mailing list archive at Nabble.com. |
|
From: Al G. <big...@gm...> - 2009-11-21 11:33:41
|
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:~$ sudo badblocks -b 512 -vs /dev/sdb Checking blocks 0 to 312581807 Checking for bad blocks (read-only test): 22817408done, 4:46 elapsed 22817432done, 5:55 elapsed 22817433done, 6:18 elapsed 22817434done, 6:42 elapsed 22817435done, 7:05 elapsed 22817436done, 7:28 elapsed 22817437done, 7:51 elapsed 22817438done, 8:14 elapsed 22817439done, 8:37 elapsed 22817440 22817441 For example how do I determine which partition 22817441 resides on? -Al -- View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26455702.html Sent from the sleuthkit-users mailing list archive at Nabble.com. |
|
From: Al G. <big...@gm...> - 2009-11-21 14:11:39
|
I think I am having dialogue with myself here, but anyway this is what I did:
1. Imaged the disk with the badblocks
2. sudo fdisk -lu test_bad_disk.bin which gave:
al@al-ubuntu:~$ sudo fdisk -lu /home/al/test_bad_disk.bin
You must set cylinders.
You can do this from the extra functions menu.
Disk /home/al/test_bad_disk.bin: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x70000000
Device Boot Start End Blocks Id
System
/home/al/test_bad_disk.bin1 63 128519 64228+ de
Dell Utility
/home/al/test_bad_disk.bin2 129024 21100543 10485760 7
HPFS/NTFS
Partition 2 has different physical/logical endings:
phys=(1023, 254, 63) logical=(1313, 114, 17)
/home/al/test_bad_disk.bin3 * 21100544 307335167 143117312 7
HPFS/NTFS
Partition 3 has different physical/logical beginnings (non-Linux?):
phys=(1023, 254, 63) logical=(1313, 114, 18)
Partition 3 has different physical/logical endings:
phys=(1023, 254, 63) logical=(19130, 185, 63)
/home/al/test_bad_disk.bin4 307335168 312578047 2621440 f
W95 Ext'd (LBA)
Partition 4 has different physical/logical beginnings (non-Linux?):
phys=(1023, 254, 63) logical=(19130, 186, 1)
Partition 4 has different physical/logical endings:
phys=(1023, 254, 63) logical=(19457, 21, 20)
/home/al/test_bad_disk.bin5 307337216 312578047 2620416 dd
Unknown
Now lets say I am interested on what should be on 22817440 (a bad block
taken from output of badbocks). This number falls between the start/end
sectors for partition 2.
So I try this command with ifind:
al@al-ubuntu:~$ sudo ifind -f ntfs -d 22817440 -o 21100544
/home/al/test_bad_disk.bin
And the result is:
99512-128-4
I have no idea what that number means, what to do with it, or even if I put
the right offset in for my partition, or even if the badblocks block number
can go straight into the ifind command -d?
Love to hear from anyone who can tell me the answers to these questions.
Cheers
-Al
--
View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26456925.html
Sent from the sleuthkit-users mailing list archive at Nabble.com.
|
|
From: Grundy B. J T. <Bar...@ti...> - 2009-11-21 15:31:47
|
Al, May I point you to the LinuxIntro guide at http://www.linuxleo.com ? The exercise on page 150 of the current guide answers (I think) a lot of your questions with examples and graphics to assist. On a side note, for those who have been asking, portions of the updated guide are currently in review. Thanks, Barry /************************************************ Barry J. Grundy Senior Special Agent System Intrusion and Network Attack Response Team Strategic Enforcement Division Treasury Inspector General for Tax Administration (202) 283-5915 (w) (202) 527-5778 (c) Bar...@ti... *************************************************\ > -----Original Message----- > From: Al Grant [mailto:big...@gm...] > Sent: Saturday, November 21, 2009 9:11 AM > To: sle...@li... > Subject: Re: [sleuthkit-users] icat and ifind -- Help with -- Please DO > NOT hijack threads > > > I think I am having dialogue with myself here, but anyway this is what I > did: > > 1. Imaged the disk with the badblocks > 2. sudo fdisk -lu test_bad_disk.bin which gave: > > al@al-ubuntu:~$ sudo fdisk -lu /home/al/test_bad_disk.bin > You must set cylinders. > You can do this from the extra functions menu. > > Disk /home/al/test_bad_disk.bin: 0 MB, 0 bytes > 255 heads, 63 sectors/track, 0 cylinders, total 0 sectors > Units = sectors of 1 * 512 = 512 bytes > Disk identifier: 0x70000000 > > Device Boot Start End Blocks Id > System > /home/al/test_bad_disk.bin1 63 128519 64228+ de > Dell Utility > /home/al/test_bad_disk.bin2 129024 21100543 10485760 7 > HPFS/NTFS > Partition 2 has different physical/logical endings: > phys=(1023, 254, 63) logical=(1313, 114, 17) > /home/al/test_bad_disk.bin3 * 21100544 307335167 143117312 7 > HPFS/NTFS > Partition 3 has different physical/logical beginnings (non-Linux?): > phys=(1023, 254, 63) logical=(1313, 114, 18) > Partition 3 has different physical/logical endings: > phys=(1023, 254, 63) logical=(19130, 185, 63) > /home/al/test_bad_disk.bin4 307335168 312578047 2621440 f > W95 Ext'd (LBA) > Partition 4 has different physical/logical beginnings (non-Linux?): > phys=(1023, 254, 63) logical=(19130, 186, 1) > Partition 4 has different physical/logical endings: > phys=(1023, 254, 63) logical=(19457, 21, 20) > /home/al/test_bad_disk.bin5 307337216 312578047 2620416 dd > Unknown > > Now lets say I am interested on what should be on 22817440 (a bad block > taken from output of badbocks). This number falls between the start/end > sectors for partition 2. > > So I try this command with ifind: > > al@al-ubuntu:~$ sudo ifind -f ntfs -d 22817440 -o 21100544 > /home/al/test_bad_disk.bin > > And the result is: > > 99512-128-4 > > I have no idea what that number means, what to do with it, or even if I > put > the right offset in for my partition, or even if the badblocks block > number > can go straight into the ifind command -d? > > Love to hear from anyone who can tell me the answers to these questions. > > Cheers > > -Al > > > > > > > > -- > View this message in context: http://old.nabble.com/icat-and-ifind---- > Help-with----Please-DO-NOT-hijack-threads-tp26452166p26456925.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 |
|
From: Grundy B. J T. <Bar...@ti...> - 2009-11-21 15:48:56
|
I should point out that the exercise on pg 150 is for an ext file system, but there are also exercise for ntfs that will help you decipher the other "numbers" (MFT entries) you were asking about. Barry /************************************************ Barry J. Grundy Senior Special Agent System Intrusion and Network Attack Response Team Strategic Enforcement Division Treasury Inspector General for Tax Administration (202) 283-5915 (w) (202) 527-5778 (c) Bar...@ti... *************************************************\ > -----Original Message----- > From: Grundy Barry J TIGTA [mailto:Bar...@ti...] > Sent: Saturday, November 21, 2009 10:32 AM > To: sle...@li... > Subject: Re: [sleuthkit-users] icat and ifind -- Help with -- Please DO > NOThijack threads > > Al, > > May I point you to the LinuxIntro guide at http://www.linuxleo.com ? > > The exercise on page 150 of the current guide answers (I think) a lot of > your questions with examples and graphics to assist. > > On a side note, for those who have been asking, portions of the updated > guide are currently in review. > > Thanks, > Barry > > /************************************************ > Barry J. Grundy > Senior Special Agent > System Intrusion and Network Attack Response Team > Strategic Enforcement Division > Treasury Inspector General for Tax Administration > (202) 283-5915 (w) > (202) 527-5778 (c) > Bar...@ti... > *************************************************\ > > > -----Original Message----- > > From: Al Grant [mailto:big...@gm...] > > Sent: Saturday, November 21, 2009 9:11 AM > > To: sle...@li... > > Subject: Re: [sleuthkit-users] icat and ifind -- Help with -- Please > DO > > NOT hijack threads > > > > > > I think I am having dialogue with myself here, but anyway this is what > I > > did: > > > > 1. Imaged the disk with the badblocks > > 2. sudo fdisk -lu test_bad_disk.bin which gave: > > > > al@al-ubuntu:~$ sudo fdisk -lu /home/al/test_bad_disk.bin > > You must set cylinders. > > You can do this from the extra functions menu. > > > > Disk /home/al/test_bad_disk.bin: 0 MB, 0 bytes > > 255 heads, 63 sectors/track, 0 cylinders, total 0 sectors > > Units = sectors of 1 * 512 = 512 bytes > > Disk identifier: 0x70000000 > > > > Device Boot Start End Blocks > Id > > System > > /home/al/test_bad_disk.bin1 63 128519 64228+ > de > > Dell Utility > > /home/al/test_bad_disk.bin2 129024 21100543 10485760 > 7 > > HPFS/NTFS > > Partition 2 has different physical/logical endings: > > phys=(1023, 254, 63) logical=(1313, 114, 17) > > /home/al/test_bad_disk.bin3 * 21100544 307335167 143117312 > 7 > > HPFS/NTFS > > Partition 3 has different physical/logical beginnings (non-Linux?): > > phys=(1023, 254, 63) logical=(1313, 114, 18) > > Partition 3 has different physical/logical endings: > > phys=(1023, 254, 63) logical=(19130, 185, 63) > > /home/al/test_bad_disk.bin4 307335168 312578047 2621440 > f > > W95 Ext'd (LBA) > > Partition 4 has different physical/logical beginnings (non-Linux?): > > phys=(1023, 254, 63) logical=(19130, 186, 1) > > Partition 4 has different physical/logical endings: > > phys=(1023, 254, 63) logical=(19457, 21, 20) > > /home/al/test_bad_disk.bin5 307337216 312578047 2620416 > dd > > Unknown > > > > Now lets say I am interested on what should be on 22817440 (a bad > block > > taken from output of badbocks). This number falls between the > start/end > > sectors for partition 2. > > > > So I try this command with ifind: > > > > al@al-ubuntu:~$ sudo ifind -f ntfs -d 22817440 -o 21100544 > > /home/al/test_bad_disk.bin > > > > And the result is: > > > > 99512-128-4 > > > > I have no idea what that number means, what to do with it, or even if > I > > put > > the right offset in for my partition, or even if the badblocks block > > number > > can go straight into the ifind command -d? > > > > Love to hear from anyone who can tell me the answers to these > questions. > > > > Cheers > > > > -Al > > > > > > > > > > > > > > > > -- > > View this message in context: http://old.nabble.com/icat-and-ifind---- > > Help-with----Please-DO-NOT-hijack-threads-tp26452166p26456925.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 |
|
From: Theodore P. <te...@gm...> - 2009-11-21 15:04:48
|
Run mmls -i raw /dev/sdb That will print out the partition table with the absolute sector start and end values. Next, you will want to use ifind with the -o argument to tell it what absolute sector the partition begins at and the -d argument to indicate the relative sector number (absolute sector number - absolute sector number of partition start) 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 141 <dd image or /dev device> BTW, if you use a dd image, you may be able to drop the -i raw. 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. 1 cluster = multiple sectors and cluster size is defined by the file system format of the partition. 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. On Sat, Nov 21, 2009 at 6:33 AM, Al Grant <big...@gm...> wrote: > > 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:~$ sudo badblocks -b 512 -vs /dev/sdb > Checking blocks 0 to 312581807 > Checking for bad blocks (read-only test): 22817408done, 4:46 elapsed > 22817432done, 5:55 elapsed > 22817433done, 6:18 elapsed > 22817434done, 6:42 elapsed > 22817435done, 7:05 elapsed > 22817436done, 7:28 elapsed > 22817437done, 7:51 elapsed > 22817438done, 8:14 elapsed > 22817439done, 8:37 elapsed > 22817440 > 22817441 > > For example how do I determine which partition 22817441 resides on? > > -Al > > -- > View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26455702.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 > |
|
From: Simson G. <si...@ac...> - 2009-11-21 17:58:45
|
Hi, Al, It turns out that this is a pretty easy thing to do with the Python framework I have put together. Would you like a small program that, using the framework, just pops out the answers? On Nov 21, 2009, at 3:33 AM, Al Grant wrote: > > 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:~$ sudo badblocks -b 512 -vs /dev/sdb > Checking blocks 0 to 312581807 > Checking for bad blocks (read-only test): 22817408done, 4:46 elapsed > 22817432done, 5:55 elapsed > 22817433done, 6:18 elapsed > 22817434done, 6:42 elapsed > 22817435done, 7:05 elapsed > 22817436done, 7:28 elapsed > 22817437done, 7:51 elapsed > 22817438done, 8:14 elapsed > 22817439done, 8:37 elapsed > 22817440 > 22817441 > > For example how do I determine which partition 22817441 resides on? > > -Al > > -- > View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26455702.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 |
|
From: Al G. <big...@gm...> - 2009-11-21 19:00:44
|
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 :-) Cheers -Al Simson Garfinkel-3 wrote: > > Hi, Al, > > It turns out that this is a pretty easy thing to do with the Python > framework I have put together. Would you like a small program that, using > the framework, just pops out the answers? > > snip.... > -- View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26459318.html Sent from the sleuthkit-users mailing list archive at Nabble.com. |
|
From: Al G. <big...@gm...> - 2009-11-21 23:23:09
|
Thanks Theodore,
I had a quick crack at following your instructions and got this:
al@al-ubuntu:~$ sudo mmls -i raw /home/al/test_bad_disk.bin
[sudo] password for al:
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
Now lets say I am interested in whats on badblock 22817441. This falls on
one of the NTFS partitions (slot 05).
relative bad sectors is now 22817441 - 21100544 = 1716879. Thus:
al@al-ubuntu:~$ sudo ifind -i raw -o 21100544 -d 1716879 /dev/sdb
9845-128-4
Then:
al@al-ubuntu:~$ sudo istat -i raw -o 21100544 /dev/sdb 9845-128-4
MFT Entry Header Values:
Entry: 9845 Sequence: 1
$LogFile Sequence Number: 1747782526
Allocated File
Links: 2
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Created: Thu Nov 2 23:43:10 2006
File Modified: Thu Nov 2 23:41:55 2006
MFT Modified: Wed Mar 12 04:09:31 2008
Accessed: Thu Nov 2 23:41:55 2006
$FILE_NAME Attribute Values:
Flags: Archive
Name:
x86_microsoft-windows-font-truetype-mingliub_31bf3856ad364e35_6.0.6000.16386_none_c6eae5a23b4a0d1e_mingliub.ttc_b8743970
Parent MFT Entry: 2239 Sequence: 1
Allocated Size: 0 Actual Size: 0
Created: Wed Mar 12 04:09:31 2008
File Modified: Wed Mar 12 04:09:31 2008
MFT Modified: Wed Mar 12 04:09:31 2008
Accessed: Wed Mar 12 04:09:31 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-3) Name: N/A Resident size: 90
Type: $FILE_NAME (48-2) Name: N/A Resident size: 306
Type: $DATA (128-4) Name: $Data Non-Resident size: 33791880
1715691 1715692 1715693 1715694 1715695 1715696 1715697 1715698
1715699 1715700 1715701 1715702 1715703 1715704 1715705 1715706
1715707 1715708 1715709 1715710 1715711 1715712 1715713 1715714
1715715 1715716 1715717 1715718 1715719 1715720 1715721 1715722
LOTS MORE NUMBERS
And ffind:
al@al-ubuntu:~$ sudo ffind -i raw -o 21100544 /dev/sdb 9845-128-4
/Windows/winsxs/Backup/x86_microsoft-windows-font-truetype-mingliub_31bf3856ad364e35_6.0.6000.16386_none_c6eae5a23b4a0d1e_mingliub.ttc_b8743970
al@al-ubuntu:~$
A little bit of trouble interpreting this result as its not a file name and
path that I am used to seeing. Is it something in
C:\Windows\winsxs\Backup\????
Cheers
-Al
--
View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26461410.html
Sent from the sleuthkit-users mailing list archive at Nabble.com.
|
|
From: Theodore P. <te...@gm...> - 2009-11-22 01:18:10
|
The drive letter is assigned by the active operating system when you mount the partition. It's not embedded in the partition so TSK tools don't display it. Given that it's the first NTFS partition, the machine this image came from likely boots from that partition and it's likely assigned letter C:, but to be 100% sure you'd have to examine the Windows Registry in the partition or have booted the machine and observed it. So /Windows/winsxs/Backup likely is C:\Windows\winsxs\Backup Another clue is that this inode has a "Links: 2", which I believe means this file is hard linked in two locations within the file system. \Windows\winsxs is special in this regard as many files underneath are multiply hard linked. See http://blogs.techrepublic.com.com/itdojo/?p=1060 On Sat, Nov 21, 2009 at 6:22 PM, Al Grant <big...@gm...> wrote: > And ffind: > > al@al-ubuntu:~$ sudo ffind -i raw -o 21100544 /dev/sdb 9845-128-4 > /Windows/winsxs/Backup/x86_microsoft-windows-font-truetype-mingliub_31bf3856ad364e35_6.0.6000.16386_none_c6eae5a23b4a0d1e_mingliub.ttc_b8743970 > al@al-ubuntu:~$ > > A little bit of trouble interpreting this result as its not a file name and > path that I am used to seeing. Is it something in > C:\Windows\winsxs\Backup\???? > > Cheers > -Al |
|
From: Al G. <big...@gm...> - 2009-11-22 02:02:24
|
Theodore Pham wrote: > > The drive letter is assigned by the active operating system when you > mount the partition. It's not embedded in the partition so TSK tools > don't display it. > > Given that it's the first NTFS partition, the machine this image came > from likely boots from that partition and it's likely assigned letter > C:, but to be 100% sure you'd have to examine the Windows Registry in > the partition or have booted the machine and observed it. > > So /Windows/winsxs/Backup likely is C:\Windows\winsxs\Backup > Ok, I accept at this point that the drive ketter is irrelevant. But what about Name: x86_microsoft-windows-font-truetype-mingliub_31bf3856ad364e35_6.0.6000.16386_none_c6eae5a23b4a0d1e_mingliub.ttc_b8743970 - its quite a long file name, but googling shows that the WinSxS folder does exist. And whats more corruption of it may well result in a failure to boot. Kinda the reason that I am interested in exploring what resides on bad sectors. I am going to continue to experiment in this area :-) Thanks for your detailed instructions Theodore. Cheers -Al -- View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26462205.html Sent from the sleuthkit-users mailing list archive at Nabble.com. |
|
From: Theodore P. <te...@gm...> - 2009-11-22 01:55:31
|
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. On Sat, Nov 21, 2009 at 10:04 AM, Theodore Pham <te...@gm...> wrote: > Run mmls -i raw /dev/sdb > > That will print out the partition table with the absolute sector start > and end values. > > Next, you will want to use ifind with the -o argument to tell it what > absolute sector the partition begins at and the -d argument to > indicate the relative sector number (absolute sector number - absolute > sector number of partition start) 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 141 <dd image or /dev device> > > BTW, if you use a dd image, you may be able to drop the -i raw. > > 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. 1 cluster = multiple sectors and cluster size is > defined by the file system format of the partition. > > 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. > > On Sat, Nov 21, 2009 at 6:33 AM, Al Grant <big...@gm...> wrote: >> >> 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:~$ sudo badblocks -b 512 -vs /dev/sdb >> Checking blocks 0 to 312581807 >> Checking for bad blocks (read-only test): 22817408done, 4:46 elapsed >> 22817432done, 5:55 elapsed >> 22817433done, 6:18 elapsed >> 22817434done, 6:42 elapsed >> 22817435done, 7:05 elapsed >> 22817436done, 7:28 elapsed >> 22817437done, 7:51 elapsed >> 22817438done, 8:14 elapsed >> 22817439done, 8:37 elapsed >> 22817440 >> 22817441 >> >> For example how do I determine which partition 22817441 resides on? >> >> -Al >> >> -- >> View this message in context: http://old.nabble.com/icat-and-ifind----Help-with----Please-DO-NOT-hijack-threads-tp26452166p26455702.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 >> > |
|
From: Theodore P. <te...@gm...> - 2009-11-22 02:51:21
|
On Sat, Nov 21, 2009 at 8:47 PM, Theodore Pham <te...@gm...> 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. |
|
From: Al G. <big...@gm...> - 2009-11-22 07:35:21
|
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 <te...@gm...> 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.
|
|
From: Simson G. <si...@ac...> - 2009-11-22 18:30:18
|
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) |
|
From: Theodore P. <te...@gm...> - 2009-11-22 15:29:49
|
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 <big...@gm...> 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 <te...@gm...> 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 > |
|
From: Simson G. <si...@ac...> - 2009-11-22 18:35:35
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X