Re: [sleuthkit-users] CD Forensics
Brought to you by:
carrier
From: farmer d. <far...@ya...> - 2006-01-13 02:24:47
|
Matt, The early bird gets the bush ... ;) CDFS is pretty cool at times. I cover its use in my training class and include it on my boot CD because of its usefulness. It's come in handy a few times. Happy 2006! farmerdude --- mm...@ta... wrote: > Farmer, you beat me to it, CDFS is covered in our > Agile Risk Management > Article on CDR Forensics. > > Good Luck Nico. > > M Shannon > > ----- Original Message ----- > From: farmer dude <far...@ya...> > Date: Thursday, January 12, 2006 5:22 pm > Subject: Re: [sleuthkit-users] CD Forensics > > > Hi Nico, > > > > Try mounting as type "cdfs" (you'll most likely > need > > to get that driver and compile against your kernel > or > > use a Linux forensic boot CD that already has it) > and > > then viewing the file "/proc/cdfs". This will > show > > you every session and allow you to mount each as > ISO. > > > > regards, > > > > farmerdude > > > > http://www.farmerdude.com/ > > > > > > > > --- Nico Kalteis <nka...@gm...> wrote: > > > > > UPDATE! > > > > > > OK, so I was playing around a bit more. Here is > > > what I did with an > > > experimental CD-R: > > > > > > 1) Wrote two files to the CD using standard > WinXP > > > method (right-click and > > > Send To D:) > > > 2) Wrote one more file using same method > > > 3) Wrote one more file using same method > > > > > > At this point Windows showed four files on my > CD-R. > > > > > > I take the CD and put it into my Linux box. > > > > > > 1) I run readcd dev=/dev/cdrom -fulltoc > > > > > > As expected, I get output saying that there are > > > three sessions on that CD-R: > > > > > > Read speed: 5645 kB/s (CD 32x, DVD 4x). > > > Write speed: 1411 kB/s (CD 8x, DVD 1x). > > > TOC len: 180. First Session: 1 Last Session: 3. > > > 01 14 00 A0 00 00 00 00 01 20 00 > > > 01 14 00 A1 00 00 00 00 01 00 00 > > > 01 14 00 A2 00 00 00 00 00 06 03 > > > 01 14 00 01 00 00 00 00 00 02 00 > > > 01 54 00 B0 02 24 03 02 4F 3B 4A > > > 01 54 00 C0 A0 00 40 00 61 11 06 > > > 02 14 00 A0 00 00 00 00 02 20 00 > > > 02 14 00 A1 00 00 00 00 02 00 00 > > > 02 14 00 A2 00 00 00 00 02 2A 06 > > > 02 14 00 02 00 00 00 00 02 26 03 > > > 02 54 00 B0 04 0C 06 01 4F 3B 4A > > > 03 14 00 A0 00 00 00 00 03 20 00 > > > 03 14 00 A1 00 00 00 00 03 00 00 > > > 03 14 00 A2 00 00 00 00 04 12 09 > > > 03 14 00 03 00 00 00 00 04 0E 06 > > > 03 54 00 B0 05 30 09 01 4F 3B 4A > > > Lead out 1: 303 > > > Lead out 2: 12006 > > > Lead out 3: 19209 > > > > > > 2) I do a 'hexdump -C /dev/cdrom | less' > > > > > > Everything goes fine for a while. I see the two > > > files I wrote first and the > > > TOC. Then I see a 'hexdump: /dev/hdc: > Input/output > > > error'. > > > > > > 3) OK, so I try dcfldd (later I tried > unsuccessfully > > > using readcd. It > > > produced tons of I/O errors until it finally > froze > > > up. After rebooting I > > > look at the image file written by dcfldd (using > > > hexdump) and it ends right > > > where the original hexdump od /dev/cdrom ended. > > > > > > So, eventually I realized that the place the > > > hexdumps stopped and dcfldd > > > froze up was at blocksize (2048) * 303 (Lead Out > 1 > > > from readcd output > > > earlier). That tells me that everything is fine > > > while looking at the first > > > session only. But for some reason hexdump and > > > dcfldd won't show me the > > > other two sessions. Any ideas? > > > > > > For what it's worth, mounting the CD using -t > > > iso9660 and doing an ls -l > > > shows all four files. > > > > > > Again, thanks and enjoy the brain teaser! > > > > > > Nico > > > > > > > > > > > > On 1/12/06, Nico Kalteis <nka...@gm...> > wrote: > > > > > > > > I would like to thank everyone very much for > their > > > input. It has opened > > > > up some interesting additional avenues for > > > exploration, which I will do > > > > right away. > > > > > > > > To answer a couple of questions, I began to dd > > > (dcfldd, actually) the > > > > whole thing but started to run into heavy I/O > > > errors after about 55MB or > > > > so. Obtaining the image slowed to a crawl > where I > > > would get about 1MB every > > > > minute, which ended up becoming unfeasible for > > > this particular situation. I > > > > would have loved to get the whole thing, > but...oh > > > well. So, I did all of my > > > > analysis on the 50MB chunk. I did run it > through > > > foremost and all it found > > > > was just the one file. I was able to verify > that > > > finding fairly easily > > > > using hexdump since it abbreviates the data > with a > > > simple asterisk if the > > > > preceeding line occurs more than once. That > made > > > the 50+MB fairly easy to > > > > skim through manually. > > > > > > > > The link to http://www.agilerm.net/linux1.html > is > > > excellent! > > > > > > > > Thanks again for your time! > > > > > > > > Nico > > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do > you grep through > > log files > > for problems? Stop! Download the new AJAX search > engine that makes > > searching your log files as easy as surfing the > web. DOWNLOAD > > > SPLUNK!http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > _______________________________________________ > > sleuthkit-users mailing list > > > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > > http://www.sleuthkit.org > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do > you grep through log files > for problems? Stop! Download the new AJAX search > engine that makes > searching your log files as easy as surfing the > web. DOWNLOAD SPLUNK! > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |