sleuthkit-users

RE: [sleuthkit-users] CD Forensics

[Kalisiak A. C. <Ale...@ni...>]

You might want to look up ISO9660 standards. You could probably use that to
figure exactly where the file table should be for any given CD media. . .

 

From what I remember though, 

 

Single session / closed disc: File table first, then files

Multi-session: (old data) files, then file table

 

It sounds like the user saved a bit of data on there, saved it as an open
session, then created another session (or more) after that.

 

Have you DD'ed the whole thing, and maybe ran foremost or anything yet?

 

- Alex Kalisiak

DMS/Exchange Administrator

Niagara Falls IAP-ARS

Comm: 716.236.3310

DSN: 238.3310

ale...@ni...

 

  _____  

From: sle...@li...
[mailto:sle...@li...] On Behalf Of Nico
Kalteis
Sent: Thursday, January 12, 2006 10:12 AM
To: sle...@li...
Subject: [sleuthkit-users] CD Forensics

 

Good morning!

This doesn't pertain directly to TSK, but I thought some of you might be
able to offer me some insight into this issue.

I was recently tasked with looking at a CD-R.  There was only a single file
of about 55KB.  However, when checking the properties under Windows it
showed that the used space was somewhere in the vicinity of ~580MB, which
equalled the capacity of the CD-R.  We suspected that there was more data
than just that one file. 

We proceeded to get a bit-level image using dcfldd with various
(conv=noerror,sync) and got to about 50MB when we started getting errors
that simply slowed the read process down dramatically.  The CD was heavily
scratched, which might have caused the issue.  However, when looking at the
CD image we did get using hexedit and hexdump, we did only see that one file
followed eventually by the file table.  It appears that the CD format was
UDF and that only that one file was on the disk. 

I tried to replicate the scenario by writing a single file of similar size
to a new CD-R using various methods native to XP as well as using Nero.  But
in each case the amount of used space according to the Windows properties
sheet was in the KB range, which I expected based on file size + file table.
But nowhere near the full capacity of the CD. 

Has anybody run into this or does anybody have any insight?  Do you think
there might be more data?  Since it's a CD-R I really doubt that anybody
would write files to the CD and be able to mess with the file table.
Particularly the person in question. 

Also, does anybody have anymore info on the location of the file table?  On
some CD-Rs and CD-RWs I see the file table at the very beginning of the CD
before the files themselves, and on others I see the files first followed
eventually by the file table. 

Thank you VERY much for your time and interest.

Cheers!

Nico

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
> 

Re: [sleuthkit-users] CD Forensics

[Nico K. <nka...@gm...>]

Thanks to both of you!  I'll try that first thing.  I should mention that I
did see that in the article.  However, the article said that mounting the C=
D
normally (which defaults to iso9660) only showed one session's worth of dat=
a
while mounting it CDFS showed all session which could be individually
mounted.  When I mounted the CD using iso9660 (I don't have the CDFS driver=
s
yet) I saw all four files, i.e. all sessions' data.  Based on the article I
only expected to see the one file written in the most recent section.

<Time passes as I installed the CDFS driver>

OK, so I couldn't resist and installed the CDFS driver before finishing thi=
s
email.  It worked! I mounted it with CDFS and can do a hexdump on the
individual ISOs.  Very cool.

Thanks again everyone for your help.  This was a most invaluable experience=
.

Cheers!

Nico


On 1/12/06, mm...@ta... <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=3D/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=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> >
>

Re: [sleuthkit-users] CD Forensics

[farmer d. <far...@ya...>]

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