tracks vs sessions in CD: clear definition?

Set aside for a moment the concept of tracks (bear with me).

Let's talk of sessions.

Sessions mean "writing sessions".

The idea is (was) to be able to use WORM (Write Once Read Many) media such as CD-ROM's for "incremental" writing.

The idea is that a "subsequent" session imports (actually "can import" as it is an option) all the addressing info of the previous session(s).
There is an additional complication with open and closed (or finalized) sessions, but let's go by order.

Practical example
You start a writing session, let's call it WS1 on a new media and write to it only one file, File1.
The writing software writes the File1 (in the sense of the actual bytes of the contents of File1) and a "session" data that consists in the addressing data that allow you to later find the File1, in practice a directory entry.
Then you end the session (but do not "close" it).
The disc has 1 session and 1 file.
A certain amount of space on the media has been used and CANNOT be reused.
You decide to add another file, File2, you start the writing session WS2, import the addressing info for File1, then add the File2 and end the session, additionally "closing" it.
The disc has now 2 sessions and 2 files, BUT the File1 does not "belong" to WS2, it is physically in an "earlier" space and actually "remains belonging" to WS1, BUT the addressing info for that file has been duplicated in WS2.
Most Cd-related software ONLY reads LAST session and you are not allowed to add a session to a multi-session disc where the last session has been closed.
But the importing of previous session is optional, so you can - as an example - "hide" a file on a CD by simply writing a later session to it without importing the previous session.

What the one (or the other) software may (or may not) see/detect is another thing, but you can inspect the file with a hex editor to make sure (personally I would trust more Isobuster than Cdroller, but you never know).

Now let's get to tracks.

Tracks do not really exist, the term is a "confusion" between "Audio track" and "track" (as used for data in - say - floppy or hard disks that are made of tracks that are concentric circles and that used to be made of a given number of sectors).

Data on a CD (that was born to record audio, not data) is arranged like on a vinyl disk it is a spiral (though "opposite", i.e. going from the center to the outside)
http//www.themechwarrior.com/wp-content/uploads/2015/02/CD-spiral.gif
"a track" on an audio CD is a synonym of "a song", see also
https://en.wikipedia.org/wiki/Track_(CD)
http//www.herongyang.com/CD-DVD/CD-TOC-Where-Is-Located.html

jaclaz

One 'fun' format to look at is UDF. In this case the directory is stored at the end of the data and files can be apparently deleted or modified. Obviously the original data remains, but the index/directory will point to new data. By scanning the disk for each directory, each iteration of the disk could be reconstructed, though Windows or OS/X will only see the final version.

Each new directory with or without files will be a new session.

I have read that audio and video CDs have tracks. (So it means data CDs do not) But I have seen that data CDs also have tracks.

You seem to be confusing your conclusions with factual information. That way you will not get anything useful out of anything.

You don't identify your sources … so it's difficult to know if they're good (and that it is you who may have failed to read them well), or if they are bad (and you should try to forget them as soon as you can), or if you draw conclusions to insufficient data .

I don't quite like Paul Crowley's book "CD and DVD Forensics" (ed. 1) because so much of it is useful only if you have the CD/DVD Inspector software. The part I like was republished in the book "Alternate Date Storage Forensics".

I see there's a second edition out now … it might have improved.

If you want to go deeper, look for Kris Kaspersky's book "CD Cracking Uncovered". It's really for the programmer-type of reader, and his language is a bit on the gnarly side as well, but you'll still get a lot of stuff out of it, provided that you have the hardware and software background. And know how to skip things, like Solomon-Reed coding.

I don't know of any useful secondary sources, so then it's a matter of reading primary sources.

You *have* to start with CD-DA (audio CD). That's where tracks are defined (even if (corrected jaclaz) seem to say that don't really exist, they do exist). The source is the 'Red book' from Philips, published in 1980. There is a secondary standard that repeats much of the information IEC 60908 (ed. 2, 1999). Warning It takes great calm of mind to read it.

Read https://en.wikipedia.org/wiki/Hidden_track and consider the forensic issues. Do your tools help with those examples at all? Should they?

Sessions … they don't enter the picture until you reach CD-R (and closely related standards), but you probably need to take in CD-ROM before you do. Read the 'Yellow book' (1988, also from Philips), or the secondary standards ISO/IEC 10149 (2nd ed from 1995), or ECMA 130 (2nd ed. from 1996).

For sessions (as in multiple sessions) (and packet writing and much more), it's the 'Orange Book' in at least three parts (CD-MO, CD-WO = CD-R and CD-RW), the third part also divided in three parts (at least.) ECMA 394 and ECMA 395 cover parts of Part 2 and Part 3.

The Orange book will probably break you, if it hasn't happened already.

I don't know of any short cuts. There may be courses – check InfinaDyne as a possibility.

ECMA standard you can download for free. ISO 101491995 is available for free (http//standards.iso.org/ittf/PubliclyAvailableStandards/). The IEC standard is commercial as far as I know, so you have to purchase. It used to be possible to get the colour book from Philips, but they seem to have hidden that page so I can't find it again. IIR, some of them required NDA.

And I haven't even mentioned Video CD or CD Video. (Yes, they are distinct.) But there are probably coloured book for them as well (Video CD is 'White Book').

And as for sessions, why do a CD shows 3 sessions although there is only 1 file in it. It was burned one time and only 1 file burned. So how can it show 3 sessions, each with a seperate track?]

When you image the CD with FTK imager, it just acquires 1 session, but if you do it with cdroller it acquires all those 3 sessions.

If you haven't figured out yet that you need to validate your tools, now's the time. How do you know that any of the tools you have mentioned works as it should?

Why do CDs have such problems in terms of forensics?

They really don't. However … it's easy to presume that CDs are easy-to-acquire knowledge, possible to pick up in half an hour.

You *have* to start with CD-DA (audio CD). That's where tracks are defined (even if yunus seem to say that don't really exist, they do exist). The source is the 'Red book' from Philips, published in 1980. There is a secondary standard that repeats much of the information IEC 60908 (ed. 2, 1999). Warning It takes great calm of mind to read it.

For the record, yunus is the OP, whilst jaclaz did say that they don't really exist in the same way as someone familiar with floppy and hard disks devices normally intend a track (a given number of sectors) but that they do exist as audio tracks (and of course data tracks, depending on content).

The concept is explained in Isobuster's online help quite nicely
https://www.isobuster.com/help/cd_dvd_layout

A continuous non-interrupted, in ascending order addressable, set of logical blocks of which the start address is recorded in the TOC (or DVD structures) is called a track. A CD or DVD contains one or more tracks and a track is always located in a session. So in fact the most simple CD or DVD layout is a disc containing one session with one track. Tracks are made up from blocks which were mastered or recorded in different modes but basically you can distinguish two different kinds of tracks. Audio tracks and Data tracks. Audio tracks are always mastered or recorded in one mode Audio. Data tracks can be recorded in the 2 modes 1 or 2 and in case of 2, different Forms are possible as well.

jaclaz

Thanks colleagues for your contributions. Jaclaz that was informative and completely agree.

By the way athulin, I have tried the following tools to acquire CD images, and each one produces different results/different hashes, and while one tool is good in one aspect, the other seems good in another aspect.

I have tried FTK, it has not acquired all sessions in a multisession CD.
I have tried Encase, it even has not proceeded further when it failed to read one sector. It completely stops there and produced a read error at sector X.
I have tried Isobuster, it missed the deleted files in UDF type CDs, failed to show deleted files.
I have tried CDroller, good software, but it also seemed to see only one session in a multisession CD.

So, no software seems to fully satisfy and cover the need of acquisition of CDs in all aspects. And it would not be pratical to acquire the same CD with each of these tools. One with FTK, another with ISObuster, another with Encase, another with CDroller.

As far as I see, unlike hard drives, there is no one single software nor format where everyone agrees upon. If I ask, what software must I use imaging a hard drive in forensically sound way", almost everyone will say/accept "use Encase or FTK". Ok, fine, clear and a definite answer.

But when it comes to CDs, there is no such situation. "Which software and what format must CDs be imaged in? No answer. So I take it is still a grey area.

Finally, let me update my question like this Is there any software to be used in forensic imaging of CDs/DVDs, which will acquire all sessions, all tracks and all files, including the deleted ones in UDF format CDs?

As far as I see, unlike hard drives, there is no one single software nor format where everyone agrees upon. If I ask, what software must I use imaging a hard drive in forensically sound way", almost everyone will say/accept "use Encase or FTK". Ok, fine, clear and a definite answer.

But when it comes to CDs, there is no such situation. "Which software and what format must CDs be imaged in? No answer. So I take it is still a grey area.

Finally, let me update my question like this Is there any software to be used in forensic imaging of CDs/DVDs, which will acquire all sessions, all tracks and all files, including the deleted ones in UDF format CDs?

Well, "use Encase or FTK" sounds to me a little bit too "imperative", however your updated question is a very valid one, see
http//www.forensicfocus.com/Forums/viewtopic/t=10723/

Though I understand how athulin might not somehow *like* Infinadyne's specific tool
http//www.infinadyne.com/cddvd_inspector.html
my guess is that is still one of the best tools around for specific CD/DVD forensics.

Never used it personally, what I can say having been using in the good ol'days Accuburn-R (an archiving product from the same people) is that it was VERY good and I never found anything with the same capabilities, though many years later a nice thingy using the same generic concept was created as open source
http//dvdisaster.net/en/

Back to topic, more generally the issue with CD/DVD imaging is that the CD/DVD reader itself is a "black box" and most OS's tend to treat it (actually the disc inside them) more as a "logical" device than a "physical device", the result being that IF the CD/DVD is either partially defective or actually has *something to hide* in it, the image is not as exact as it should, under Linux you can use readom (was once named readcd) to extract sectors or something similar, remember that by design an optical media has 2352 bytes per sector (or more) of which only 2048 are actually used for data (the rest is ECC) see also the wodim "raw" modes.

In practice most common tools make an .iso image instead of a RAW (.bin) image, the concept is well explained in the Magiciso online help
http//www.magiciso.com/tutorials/miso-whatiso.htm
very similar to "logical extraction" vs. "physical extraction" used in phones.

jaclaz

I have tried Encase, it even has not proceeded further when it failed to read one sector. It completely stops there and produced a read error at sector X.

Is it important to use Encase? In that case, bring the problem to Guidance's door.

I have seen the same problem – traced to a) my old CD reader, which was configured to retry reading 127 times on finding a bad sector, and b) to EnCase which, when it got the 'failed read' from the CD module, immediately retried without realizing that the CD reader hadn't done anything else but retrying for the past 8 minutes.

I ended up using CloneCD from Slysoft instead. It at least knew how to reconfigure the CD reader to only do one or two retries, and then move on.

On a very bad test CD, Encase was not finished after three hours, and CloneCD did the job (though with bad sectors) in five minutes.

It's ages since I used Encase, but I think I could drag and drop a CloneCD image straight into EnCase, and make it work. Never had to deal with complex CD's though.

DVD is much cleaner – though you still have to handle bad sectors – it was designed to be digital from the start.

I have tried Isobuster, it missed the deleted files in UDF type CDs, failed to show deleted files.

But that's a different kind of problem, isn't it? If IsoBuster does a clean image, fine. If it doesn't do the later processing that you want, have a chat with IsoBuster about it, as well as try to import the image to one of the tools you know do the job.

As far as I see, unlike hard drives, there is no one single software nor format where everyone agrees upon.

Infinadyne CD/DVD Inspector probably comes closest.

Finally, let me update my question like this Is there any software to be used in forensic imaging of CDs/DVDs, which will acquire all sessions, all tracks and all files, including the deleted ones in UDF format CDs?

I can't name any. The reason is that I have never seen a test suite for each of those imaging situations, and never run a test using such a test suite.

However … in the cases I had to deal with CDs, CloneCD did the job for me. But again, I never tried to build a test suite, never tried to do systematic testing. (At the time I still had the illusion that someone surely must have done that already, and it was just a question of finding the test report.)