sleuthkit-users Mailing List for The Sleuth Kit (Page 189)
Brought to you by:
carrier
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(1) |
Feb
(20) |
Mar
(60) |
Apr
(40) |
May
(24) |
Jun
(28) |
Jul
(18) |
Aug
(27) |
Sep
(6) |
Oct
(14) |
Nov
(15) |
Dec
(22) |
2004 |
Jan
(34) |
Feb
(13) |
Mar
(28) |
Apr
(23) |
May
(27) |
Jun
(26) |
Jul
(37) |
Aug
(19) |
Sep
(20) |
Oct
(39) |
Nov
(17) |
Dec
(9) |
2005 |
Jan
(45) |
Feb
(43) |
Mar
(66) |
Apr
(36) |
May
(19) |
Jun
(64) |
Jul
(10) |
Aug
(11) |
Sep
(35) |
Oct
(6) |
Nov
(4) |
Dec
(13) |
2006 |
Jan
(52) |
Feb
(34) |
Mar
(39) |
Apr
(39) |
May
(37) |
Jun
(15) |
Jul
(13) |
Aug
(48) |
Sep
(9) |
Oct
(10) |
Nov
(47) |
Dec
(13) |
2007 |
Jan
(25) |
Feb
(4) |
Mar
(2) |
Apr
(29) |
May
(11) |
Jun
(19) |
Jul
(13) |
Aug
(15) |
Sep
(30) |
Oct
(12) |
Nov
(10) |
Dec
(13) |
2008 |
Jan
(2) |
Feb
(54) |
Mar
(58) |
Apr
(43) |
May
(10) |
Jun
(27) |
Jul
(25) |
Aug
(27) |
Sep
(48) |
Oct
(69) |
Nov
(55) |
Dec
(43) |
2009 |
Jan
(26) |
Feb
(36) |
Mar
(28) |
Apr
(27) |
May
(55) |
Jun
(9) |
Jul
(19) |
Aug
(16) |
Sep
(15) |
Oct
(17) |
Nov
(70) |
Dec
(21) |
2010 |
Jan
(56) |
Feb
(59) |
Mar
(53) |
Apr
(32) |
May
(25) |
Jun
(31) |
Jul
(36) |
Aug
(11) |
Sep
(37) |
Oct
(19) |
Nov
(23) |
Dec
(6) |
2011 |
Jan
(21) |
Feb
(20) |
Mar
(30) |
Apr
(30) |
May
(74) |
Jun
(50) |
Jul
(34) |
Aug
(34) |
Sep
(12) |
Oct
(33) |
Nov
(10) |
Dec
(8) |
2012 |
Jan
(23) |
Feb
(57) |
Mar
(26) |
Apr
(14) |
May
(27) |
Jun
(27) |
Jul
(60) |
Aug
(88) |
Sep
(13) |
Oct
(36) |
Nov
(97) |
Dec
(85) |
2013 |
Jan
(60) |
Feb
(24) |
Mar
(43) |
Apr
(32) |
May
(22) |
Jun
(38) |
Jul
(51) |
Aug
(50) |
Sep
(76) |
Oct
(65) |
Nov
(25) |
Dec
(30) |
2014 |
Jan
(19) |
Feb
(41) |
Mar
(43) |
Apr
(28) |
May
(61) |
Jun
(12) |
Jul
(10) |
Aug
(37) |
Sep
(76) |
Oct
(31) |
Nov
(41) |
Dec
(12) |
2015 |
Jan
(33) |
Feb
(28) |
Mar
(53) |
Apr
(22) |
May
(29) |
Jun
(20) |
Jul
(15) |
Aug
(17) |
Sep
(52) |
Oct
(3) |
Nov
(18) |
Dec
(21) |
2016 |
Jan
(20) |
Feb
(8) |
Mar
(21) |
Apr
(7) |
May
(13) |
Jun
(35) |
Jul
(34) |
Aug
(11) |
Sep
(14) |
Oct
(22) |
Nov
(31) |
Dec
(23) |
2017 |
Jan
(20) |
Feb
(7) |
Mar
(5) |
Apr
(6) |
May
(6) |
Jun
(22) |
Jul
(11) |
Aug
(16) |
Sep
(8) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2018 |
Jan
|
Feb
|
Mar
(16) |
Apr
(2) |
May
(6) |
Jun
(5) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
|
Nov
(16) |
Dec
(13) |
2019 |
Jan
|
Feb
(1) |
Mar
(25) |
Apr
(9) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2024 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: philippe J. <ph....@ab...> - 2004-11-12 10:37:16
|
Hello, I'm coming back into this list after a year :-) And I have a question. I'm trying to imaging on Mac OS X to use autopsy. Autopsy is working well but - I can't image a usb drive : Ordinateur-de-moi:/Volumes/PHIL_USB moi$ dd if=/dev/disk2s1 of=/Users/moi/image_clefusb/image_clefusb.img dd: /dev/disk2s1: Device busy How can I change this ? Thank you very much, I use usualy autopsy on Linux system, and I'm discovering Mac OS X...hum some change... Philippe Jarlov France |
From: Brian C. <ca...@sl...> - 2004-11-11 15:38:13
|
What type of file system is the image? What is the block / cluster size? Is it for all files or just some of them? Can you run 'istat' on one of the files that has a different output and send me the output? brian On Nov 11, 2004, at 5:38 AM, neutrino neutrino wrote: > I have been doing tests that was meant to show that the tool "sorter" > used on a common image will produce the same output independant of > Operation System. However, when I ran "sorter" on a FreeBSD-5.2.1 > systems it produce files that were different to other systems (solaris > sparc/ redhat i386). > > Comparing output files from the redhat system to what was produced on > the FreeBSD system in a hex editor, I found that the FreeBSD system > always differs at the offset 0x3400. I ran "ktrace" (Kernel Trace) on > the "sorter" command that I was using in FreeBSD. What I found was > when "icat" was reading the target file, it got to a point where it > switched from doing a direct read, to using lseek before a read > statement. > > Further investigation using a hex editor I found that the problem > seems to be a miscalcuation on the lseek. It seems to skip 1024 bytes > at offset 0x3400. > > I am not a programmer, and I have dont have the time to investigate to > much further, but I thought I would report it. Having a quick look at > the source, I was guessing the problem may be in the OFF_T macro. But > I could easily be wrong. |
From: neutrino n. <neu...@ho...> - 2004-11-11 10:39:10
|
I have been doing tests that was meant to show that the tool "sorter" used on a common image will produce the same output independant of Operation System. However, when I ran "sorter" on a FreeBSD-5.2.1 systems it produce files that were different to other systems (solaris sparc/ redhat i386). Comparing output files from the redhat system to what was produced on the FreeBSD system in a hex editor, I found that the FreeBSD system always differs at the offset 0x3400. I ran "ktrace" (Kernel Trace) on the "sorter" command that I was using in FreeBSD. What I found was when "icat" was reading the target file, it got to a point where it switched from doing a direct read, to using lseek before a read statement. Further investigation using a hex editor I found that the problem seems to be a miscalcuation on the lseek. It seems to skip 1024 bytes at offset 0x3400. I am not a programmer, and I have dont have the time to investigate to much further, but I thought I would report it. Having a quick look at the source, I was guessing the problem may be in the OFF_T macro. But I could easily be wrong. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.com/ |
From: Brian C. <ca...@sl...> - 2004-11-02 23:56:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After spending 2 hours in line voting, I have released TSK 1.73. There are a couple of bug fixes, a few updates, and four new tools (which will be discussed in the next Sleuth Kit Informer). http://www.sleuthkit.org/sleuthkit/ Bug Fixes * Now compiles & runs on 64-bit AMD Linux systems * Fixed NTFS errors when $MFT was very fragmented Major Updates * New Journal tools for Ext3 (jls & jcat) * New support for UFS2 * New diskstat tool to detect Host Protected Area of disk (Linux Only) * New sigfind tool to find binary signature values in a file * Improved fsstat and istat output for Ext3 * Improved fsstat and istat output for UFS brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBiB6sOK1gLsdFTIsRAmbDAJ0faKA4V0g3Pg1lxCHf6qy/6vsYigCfZg/s yzyPoNNYU8HCRGCmpgqerWw= =cC1g -----END PGP SIGNATURE----- |
From: Paul S. <pa...@vn...> - 2004-10-28 23:28:34
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian, I have an AMD64 system running SuSE 9.1. I had said before that I'd test,= =20 and I'll do what I can. The day job is very busy right now though. If you= =20 have a test plan, that would be most helpful. At the very least I can=20 compile and run a few basic tests. Paul On October 28, 2004 15:16, Brian Carrier wrote: > I'm looking for people interested in playing with the new TSK version > that includes support for 64-bit machines. There are actually very few > changes, but I have done only limited testing on a machine in the > sourceforge compile farm. > > Let me know if you are interested and I'll send it to you tonight. > > brian > > > > > ------------------------------------------------------- > This Newsletter Sponsored by: Macrovision > For reliable Linux application installations, use the industry's leading > setup authoring tool, InstallShield X. Learn more and evaluate > today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/ > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBgYCTbu2E+kpEvNgRAmnGAKCiTIMmGAzlGbwvN8SRqvC9j3pqygCfdYQg yr7MQmmceJsanCq7yRuMSLg=3D =3D1n9R =2D----END PGP SIGNATURE----- |
From: Brian C. <ca...@ce...> - 2004-10-28 19:16:59
|
I'm looking for people interested in playing with the new TSK version that includes support for 64-bit machines. There are actually very few changes, but I have done only limited testing on a machine in the sourceforge compile farm. Let me know if you are interested and I'll send it to you tonight. brian |
From: Eagle I. S. I. <in...@ea...> - 2004-10-24 15:10:01
|
Brian, Actually, the File Analysis window shows no files at all. I switched to a 2.4.27 kernel to make sure it wasn't any with the 2.6 kernel, and even tried a fresh install of TSK, but the same results occurred. Before I opened this email, I started a search for an ascii string that I know exists, to see how it would fare. I'll report back when it completes. If there's anything else you'd like me to check, I'm happy to. Niall. -----Original Message----- From: Brian Carrier [mailto:ca...@sl...] Sent: Sunday, October 24, 2004 9:28 AM To: Eagle Investigative Services, Inc. Cc: sle...@li... Subject: Re: [sleuthkit-users] Unusual behavior On Oct 23, 2004, at 9:44 PM, Eagle Investigative Services, Inc. wrote: > I'm using the latest Sluthkit and Autopsy. > > I separated out the partition from a raw image file and symlinked it > into Autopsy. It's an NTFS partition. > > ... > > Any idea what's going on here. I've viewed hundreds of images on this > partition with another tool...I was looking for a one step way to > thumnail them....... Are there more files and directories that are shown in the normal file analysis view? Or does that have only a few files as well? brian |
From: Brian C. <ca...@sl...> - 2004-10-24 14:27:55
|
On Oct 23, 2004, at 9:44 PM, Eagle Investigative Services, Inc. wrote: > I'm using the latest Sluthkit and Autopsy. > > I separated out the partition from a raw image file and symlinked it > into > Autopsy. It's an NTFS partition. > > ... > > Any idea what's going on here. I've viewed hundreds of images on this > partition with another tool...I was looking for a one step way to > thumnail > them....... Are there more files and directories that are shown in the normal file analysis view? Or does that have only a few files as well? brian |
From: Eagle I. S. I. <in...@ea...> - 2004-10-24 02:44:02
|
I'm using the latest Sluthkit and Autopsy. I separated out the partition from a raw image file and symlinked it into Autopsy. It's an NTFS partition. (The extracted partition sits on a Firewire drive, if that matters) Anyway, when I choose File Type and the choose to save only the graphic images and make thumbnails, and hi OK, the sorter immediately executes and almost immediately produces a result: Images: /evidence/brew/Compaq/images/brewpart.dd Files (3) Allocated (0) Unallocated (3) Files Skipped (3) Non Files (3) - all subsequent entries are 0. I've used this many times before and fully expected it to take a few hours.....it returned these results in less than 1 second. Any idea what's going on here. I've viewed hundreds of images on this partition with another tool...I was looking for a one step way to thumnail them....... Niall. |
From: Brian C. <ca...@sl...> - 2004-10-23 01:37:23
|
OpenBSD wipes the block pointers in the inode when it deletes a file, so there isn't much you can do for recovery. Your best bet is to do some keyword searching on the partition for words that you know are in the files. brian On Oct 22, 2004, at 6:57 AM, vattini giacomo wrote: > I hope that someone could helpme. > So this was the situation from my partition > /franzi/franzi i deleted two files faq1.html faq2.html |
From: vattini g. <ha...@ya...> - 2004-10-22 11:57:46
|
I hope that someone could helpme. So this was the situation from my partition /franzi/franzi i deleted two files faq1.html faq2.html transleted in italian i do not no how to having them back.So i will appriciate very much for help My situation So OpenBSD3.5 disklabel wd0 cylinders: 16383 total sectors: 58605120 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a: 1638000 24161760 4.2BSD 2048 16384 328 # (Cyl. 23970 - 25594) b: 614880 25799760 swap # (Cyl. 25595 - 26204) c: 58605120 0 unused 0 0 # (Cyl. 0 - 58139) d: 4095504 26414640 4.2BSD 2048 16384 328 # (Cyl. 26205 - 30267) e: 7167888 30510144 4.2BSD 2048 16384 328 # (Cyl. 30268 - 37378) f: 1433376 37678032 4.2BSD 2048 16384 328 # (Cyl. 37379 - 38800) g: 1638000 39111408 4.2BSD 2048 16384 328 # (Cyl. 38801 - 40425) h: 5983672 40749408 4.2BSD 2048 16384 328 # (Cyl. 40426 - 46362*) i: 16386299 63 unknown # (Cyl. 0*- 16256*) k: 7036469 16386363 ext2fs # (Cyl. 16256*- 23236*) l: 11872035 46733085 unused 0 0 # (Cyl. 46362*- 58139) df= Filesystem 512-blocks Used Avail Capacity Mounted on /dev/wd0a 1611884 90244 1441048 6% / /dev/wd0h 5884532 311092 5279216 6% /franzi /dev/wd0f 1407260 16 1336884 0% /tmp /dev/wd0e 7053100 4078776 2621672 61% /usr /dev/wd0g 1611884 22656 1508636 1% /var So i think i need some image of wd0h where is /franzi/frazi but i think the space is not enough which command do i have to digit ?I'm lost i just make install about the programm sleuthkit thanks christian ___________________________________ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica Scaricalo ora! http://it.messenger.yahoo.it |
From: Angus M. <an...@n-...> - 2004-10-19 20:26:31
|
I am pleased to be able to announce that the programme for the e-crime and= =20 computer evidence conference, to be held in Monaco in March 2005, has now=20 been finalised. =46ull details are on the conference www site at http://www.ecce-conference= =2Ecom/ |
From: Brian C. <ca...@sl...> - 2004-10-18 02:41:14
|
I'm still not quite sure what you did. Was /dev/sdc1 mounted on both /home/marc and /media/jaz? If so, you basically copied files from the 'work' folder to the root directory and now all directories have the corresponding files with a size of 0? Did you try to run fsck and check lost+found? It would seem that Linux would put the data somewhere instead of just losing it. If the files were deleted, then you will need to rely on a tool like foremost to recover the files .... I would make an image of the disk and then run fsck on it though... brian On Oct 16, 2004, at 2:16 PM, Marc Mausch wrote: > Hello, > > when intending to backup my data on /dev/sdc1 (mounted on /home/marc) > , I errorneously entered > mount /dev/sdc1 /media/jaz > instead of > mount /dev/sdd1 /media/jaz > > Then I drag&dropped with the Konqueror from /home/marc/work to > /media/jaz. I don`t know why it worked, but it did. Mayby because the > Konquerer has been open at /home/marc/work prior to the false > mounting. > > The result is that I now have the complete directory structure of my > data on /dev/sdc1, but without any bit of data (all files are 0 B). > > Is there any chance to recover the data? Filesystem is ext3 (SuSE 8.1) > |
From: Brian C. <ca...@sl...> - 2004-10-18 02:32:38
|
I rarely use Cygwin, but I do know of several people on this list that use it on Cygwin with no issues..... What browser are you using? I know that some versions of IE had issues, but that was a couple of years ago and I thought they had been fixed. brian On Oct 12, 2004, at 10:31 AM, Kalisiak Alex Contr 914 CS/SCBN wrote: > > This is going to sound like a terminally newbie question, but I'm > having trouble with Autopsy running on Cygwin/Windows XP. > > When I open the Autopsy browser, none of the graphics appear, they > just show the broken link image. I corrected this before, by modifying > "$PICTDIR" in define.pl. That was a year ago, and for the life of me I > can't get it to work again. (I want to say changing it from > "$INSTALLDIR/pict/" to "./pict/" corrected it, but it doesn't seem to > be the fix this time). > > Has anyone experienced this problem before, or have any advice? > > Thanks in advance for any help or patience! > > - Alex Kalisiak |
From: Marc M. <mar...@we...> - 2004-10-16 19:17:17
|
Hello, when intending to backup my data on /dev/sdc1 (mounted on /home/marc) , I = errorneously entered mount /dev/sdc1 /media/jaz instead of mount /dev/sdd1 /media/jaz Then I drag&dropped with the Konqueror from /home/marc/work to /media/jaz.= I don`t know why it worked, but it did. Mayby because the Konquerer has b= een open at /home/marc/work prior to the false mounting.=20 The result is that I now have the complete directory structure of my data = on /dev/sdc1, but without any bit of data (all files are 0 B). Is there any chance to recover the data=3F Filesystem is ext3 (SuSE 8.1) Thanks & best regards, --=20 Marc=A0Mausch =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/=3Fmc=3D021193 |
From: Kalisiak A. C. 9. CS/S. <Ale...@ni...> - 2004-10-12 15:32:12
|
Sleuthkit 1.71 Autopsy 2.02 To All - This is going to sound like a terminally newbie question, but I'm having trouble with Autopsy running on Cygwin/Windows XP. When I open the Autopsy browser, none of the graphics appear, they just show the broken link image. I corrected this before, by modifying "$PICTDIR" in define.pl. That was a year ago, and for the life of me I can't get it to work again. (I want to say changing it from "$INSTALLDIR/pict/" to "./pict/" corrected it, but it doesn't seem to be the fix this time). Has anyone experienced this problem before, or have any advice? Thanks in advance for any help or patience! - Alex Kalisiak |
From: Brian C. <ca...@sl...> - 2004-10-12 14:27:49
|
On Oct 12, 2004, at 6:53 AM, Joerg Friedrich wrote: > Hi, > > I encountered the same problem as Hans-Peter: > see: > http://sourceforge.net/mailarchive/forum.php? > thread_id=5697461&forum_id=10358 > btw: I also use Debian Sarge, sleuthkit 1.72. There seems to be an issue with Debian Sarge and some pointers in TSK. (it prefers (uintptr_t over only (int)). I'll send you the latest version to see if it helps. brian |
From: Joerg F. <Joe...@un...> - 2004-10-12 11:53:35
|
Hi, I encountered the same problem as Hans-Peter: see: http://sourceforge.net/mailarchive/forum.php?thread_id=3D5697461&forum_id= =3D10358 root@hitchhiker:/mnt# fsstat -v -f ntfs disk.p1.dd ntfs_mft_lookup: Processing MFT 0 fs_read_random: read offs 65536 len 1024 (mft read) fsstat: Incorrect update sequence value in MFT entry Update Value: 0x0 Actual Value: 0x993 Replacement Value: 0x0 This is typically because of a corrupted entry root@hitchhiker:/mnt# fsstat -v -f ntfs disk.p2.dd ntfs_mft_lookup: Processing MFT 0 fs_read_random: read offs 8192 len 1024 (mft read) fsstat: Incorrect update sequence value in MFT entry Update Value: 0x0 Actual Value: 0x28 Replacement Value: 0x0 This is typically because of a corrupted entry root@hitchhiker:/mnt# fsstat -v -f ntfs disk.p3.dd ntfs_mft_lookup: Processing MFT 0 fs_read_random: read offs 16384 len 1024 (mft read) fsstat: Incorrect update sequence value in MFT entry Update Value: 0x0 Actual Value: 0x23 Replacement Value: 0x0 This is typically because of a corrupted entry I attached the MFTs. Hope this helps debugging this problem btw: I also use Debian Sarge, sleuthkit 1.72. I created a hd-image with dd and splitted the three partitions. with the help of mmls. maybe you need also this info: root@hitchhiker:/mnt# file disk.* disk.dd: x86 boot sector disk.p1.dd: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 255, hidden sectors 63, dos < 4.0 BootSector (0x80) disk.p2.dd: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", reserved sectors 0, Media descriptor 0xf8, heads 255, hidden sectors 63, dos < 4.0 BootSector (0x80) disk.p3.dd: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", sectors/cluster 2, reserved sectors 0, Media descriptor 0xf8, heads 255, hidden sectors 63, dos < 4.0 BootSector (0x80) --=20 J=F6rg Friedrich There are only 10 types of people: Those who understand binary and those who don't. |
From: Brian C. <ca...@sl...> - 2004-10-07 02:07:17
|
On Oct 6, 2004, at 2:07 PM, Lisa Muir wrote: > Brian, > > No, this was a 120 GB Hitachi IDE drive. The disk was formatted > originally ext2 with one primary partition by moi. > > Any thoughts on how the Md5 might has been modified? Well, you ran fsck on the file system, which fixed what ever problems were causing it to not mount before. So, that would cause the MD5 to change. I find it very strange that you could run 'mke2fs' on the disk device and not a partition device and it would find the file system that was originally inside of a partition.... brian |
From: Brian C. <ca...@sl...> - 2004-10-07 02:04:36
|
On Oct 6, 2004, at 7:45 PM, Geovane Goncalves wrote: > Yes, my situation is this, I thought that I would be possible to mount=20= > the entire hard disk (with its partitions- swap, ext3 ...) from its=20 > image "dd" and to analyze it in the autopsy. > I made the search for strings but I cannot visualize the structure of=20= > directories=A0of the system=A0files. yea, you need to split it up into partitions. (I swear that is the=20 next major addition to TSK and Autopsy). You probably imported the=20 image as a raw or swap type image and therefore the file system and=20 partition table structure is ignored because there shouldn't be one for=20= those types. brian |
From: Lisa M. <34....@gm...> - 2004-10-06 19:07:53
|
Brian, No, this was a 120 GB Hitachi IDE drive. The disk was formatted originally ext2 with one primary partition by moi. Any thoughts on how the Md5 might has been modified? Lisa, On Wed, 6 Oct 2004 10:55:27 -0500, Brian Carrier <ca...@sl...> wrote: > > On Oct 6, 2004, at 8:48 AM, Lisa Muir wrote: > > > Brian/LT, > > > > With LT's kind assistance and guidance, I was able to get access to > > the filesystem. I used the following process: > > > > # mk2fs -S /dev/hdb > > > > which wrote just the superblock. > > > > I ran e2fsck and after it had completed I was able to mount the > > filesystem and browse the filesystem. All files appeared to be there > > and appeared to be the correct size. > > > > #fdisk -lu disk.dd > > > > gave the error that there was no valid partition table. > > Did the disk ever have more than one partition? Was this a USB token > or a real disk? > > brian > > |
From: Brian C. <ca...@sl...> - 2004-10-06 15:56:52
|
On Oct 6, 2004, at 8:48 AM, Lisa Muir wrote: > Brian/LT, > > With LT's kind assistance and guidance, I was able to get access to > the filesystem. I used the following process: > > # mk2fs -S /dev/hdb > > which wrote just the superblock. > > I ran e2fsck and after it had completed I was able to mount the > filesystem and browse the filesystem. All files appeared to be there > and appeared to be the correct size. > > #fdisk -lu disk.dd > > gave the error that there was no valid partition table. Did the disk ever have more than one partition? Was this a USB token or a real disk? brian |
From: Brian C. <ca...@sl...> - 2004-10-06 15:54:39
|
On Oct 6, 2004, at 7:45 AM, Andrass Ziska Davidsen wrote: > Dear sleuthkit-users, > > I have a disk image from which I need to recover deleted files. The > system is ext3fs. I have The Sleuth Kit and Autopsy up and running. > My question is then: Is there any guarantee for that the inodes are > deleted sequentially and in the same order as in the log? Nope. They are deleted in the order that they are in the directory and the timeline is accurate to only the second. The ordering in the timeline in that second is based on how Perl sorts them in the internal 'mactime' data structure. There is nano-second resolution in the inode, but TSK currently ignores that. > Or: Is it possible that the inodes from line 5 to 24 all belong to the > same dir (...0331/NONLIN or ...etc/0412 Clamp)? I would say that it is unlikely. The inode value (the number before the name) of files in the same directory should be somewhat close (inodes are allocated in the same block group as their parent directory). So, based on the above range I would guess that there are a few directories (I would need the 'fsstat' output though that contains the block group sizes). > Should I from the information in the timeline use `dls` to extract the > blocks mentioned between 11:42 and 11:46 and then try to analyse the > blocks with `foremost` (or similar)? Or should I do a > dls -f ext3fs /mnt/image.dd start-stop Well, you don't know which blocks were allocated by those files... You can identify the block groups that were used by those files (using the inode numbers and the 'fsstat' output) and extract the unallocated blocks from those groups. Then run 'foremost'. If your files do not have a known header and footer though, 'foremost' will not help. brian |
From: Lisa M. <34....@gm...> - 2004-10-06 13:49:52
|
Brian/LT, With LT's kind assistance and guidance, I was able to get access to the filesystem. I used the following process: # mk2fs -S /dev/hdb which wrote just the superblock. I ran e2fsck and after it had completed I was able to mount the filesystem and browse the filesystem. All files appeared to be there and appeared to be the correct size. #fdisk -lu disk.dd gave the error that there was no valid partition table. Also, when I did an md5sum on the image file, the md5 didn't match the original md5 of the drive that was imaged. So somewhere the file was altered. Now, in my case, I'm not sure if the process modified the file, or my screwing around with the entire thing modified the file..as I plodded through a few different things before going down this last path.....however, I'm going to replicate this secnario with two smaller drives, to see if it happens again. My thinking for a test is to format a drive, write 1k to the superblock. Make sure it's screwed and can't mount, the run the two commands again and see what occurs in a controlled manner. Thankfully, this was an unneeded file, and simply an experiment but it was a great learning experience. Thank you Brian and LT for your patience. On Mon, 4 Oct 2004 21:35:27 -0700 (PDT), Linux Tard <lin...@ya...> wrote: > > > --- Lisa Muir <34....@gm...> wrote: > > > Here is the output of gpart: > > > > > > Begin scan... > > Possible partition(DOS FAT), size(10mb), > > offset(338mb) > > End scan. > > > > Checking partitions... > > Partition(Primary DOS with 12 bit FAT): primary > > Ok. > > > > Guessed primary partition table: > > Primary partition(1) > > type: 001(0x01)(Primary DOS with 12 bit FAT) > > size: 10mb #s(20739) s(693126-713864) > > chs: (43/37/1)-(44/111/12)d > > (43/37/1)-(44/111/12)r > > > > Primary partition(2) > > type: 000(0x00)(unused) > > size: 0mb #s(0) s(0-0) > > chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r > > > > Primary partition(3) > > type: 000(0x00)(unused) > > size: 0mb #s(0) s(0-0) > > chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r > > > > Primary partition(4) > > type: 000(0x00)(unused) > > size: 0mb #s(0) s(0-0) > > chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r > > > > Which is incorrect, since I know it was definitely > > an ext2 partition. > > > > I didn't have too much time to play with it > > today..... > > > > Lisa- > > > > yes Lisa, but because you dd from another device with > different partition. gpart reads that info. > > -lt > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail is new and improved - Check it out! > > > http://promotions.yahoo.com/new_mail > |
From: Andrass Z. D. <az...@li...> - 2004-10-06 12:45:19
|
Dear sleuthkit-users, I have a disk image from which I need to recover deleted files. The system is ext3fs. I have The Sleuth Kit and Autopsy up and running. (I would like to excuse my bad knowledge of the terminology.) I am aware that inode pointers are nulled at deletion, therefore I have no info on how the blocks are (were) joined. I have made a timeline around when the files were deleted. The entries are like in the following excerpt (might look bad due to word wrapping): 0 .a. drwxrwxrwx 115 100 12451900 <sdb1.img-dead-12451900> 0 .a. drwxrwxrwx 509 100 2998404 <sdb1.img-dead-2998404> 0 .a. d/drwxrwxrwx 115 100 5554256 /home/samba/pub/Projects/0412/doc/Memo (deleted) 0 .a. d/drwxrwxrwx 115 100 8257636 /home/samba/pub/Projects/0331/NONLIN (deleted) 0 .a. drwxrwxrwx 524 100 13877367 <sdb1.img-dead-13877367> 0 .a. drwxrwxrwx 115 100 8257636 <sdb1.img-dead-8257636> 0 .a. drwxrwxrwx 504 100 12812364 <sdb1.img-dead-12812364> 0 .a. drwxrwxrwx 505 100 12255345 <sdb1.img-dead-12255345> 0 .a. drwxrwxrwx 504 100 11223152 <sdb1.img-dead-11223152> Fri Oct 01 2004 11:42:36 0 .a. drwxrwxrwx 505 100 7553144 <sdb1.img-dead-7553144> 0 .a. drwxrwxrwx 507 100 4423788 <sdb1.img-dead-4423788> 0 .a. drwxrwxrwx 510 100 12812405 <sdb1.img-dead-12812405> 0 .a. drwxrwxrwx 505 100 11534455 <sdb1.img-dead-11534455> 0 .a. drwxrwxrwx 504 100 12812410 <sdb1.img-dead-12812410> 0 .a. drwxrwxrwx 505 100 6733944 <sdb1.img-dead-6733944> 0 .a. drwxrwxrwx 505 100 6389880 <sdb1.img-dead-6389880> 0 .a. drwxrwxrwx 505 100 3981345 <sdb1.img-dead-3981345> 0 .a. drwxrwxrwx 505 100 11305068 <sdb1.img-dead-11305068> 0 .a. drwxrwxrwx 507 100 7913597 <sdb1.img-dead-7913597> 0 .a. drwxrwxrwx 505 100 9732192 <sdb1.img-dead-9732192> 0 .a. drwxrwxrwx 505 100 12206157 <sdb1.img-dead-12206157> 0 .a. drwxrwxrwx 504 100 2867317 <sdb1.img-dead-2867317> 0 .a. drwxrwxrwx 505 100 3162206 <sdb1.img-dead-3162206> 0 .a. drwxrwxrwx 504 100 2621515 <sdb1.img-dead-2621515> 0 .a. d/drwxrwxrwx 511 100 3899448 /home/samba/pub/Projects/0412/etc/0412 Clamp (deleted) 0 .a. drwxrwxrwx 505 100 12468314 <sdb1.img-dead-12468314> 0 .a. d/drwxrwxrwx 507 100 4423788 /home/samba/pub/Projects/0416/dwg/Refs (deleted) 0 .a. drwxrwxrwx 505 100 8683640 <sdb1.img-dead-8683640> 0 .a. drwxrwxrwx 500 500 5046321 <sdb1.img-dead-5046321> 0 .a. drwxrwxrwx 505 100 6094953 <sdb1.img-dead-6094953> My question is then: Is there any guarantee for that the inodes are deleted sequentially and in the same order as in the log? Or: Is it possible that the inodes from line 5 to 24 all belong to the same dir (...0331/NONLIN or ...etc/0412 Clamp)? (The log is from rsync stdout which caused the deletion (due to my misunderstanding of some flags)) At least I know that the incident happened somewhere between 11:42 and 11:46, but the number of files is 10000+. The backup procedures have been off for some time, but we have recovered around 9000 of the files. I need to get the last 1000 as well, and they were only stored on that disk. Should I from the information in the timeline use `dls` to extract the blocks mentioned between 11:42 and 11:46 and then try to analyse the blocks with `foremost` (or similar)? Or should I do a dls -f ext3fs /mnt/image.dd start-stop where start is, say, lowest block number (7th column) within window and stop is highest block number within window? Please give me som advice, as this is my first (and last)? regards andrass -- Andrass Ziska Davidsen LICengineering A/S Ehlersvej 24 DK-2900 Hellerup DENMARK tel. (+45) 39 62 16 42 fax. (+45) 39 62 54 80 |