Re: [sleuthkit-users] CD Forensics

[<mm...@ta...>]

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
>