Let's say you burn a CD-R and it is finalized. Later, if you put it into a CD drive with some OS running, is it possible for the OS to write to it ?

Obviously, this shouldn't typically happen, because of some conventions that are typically followed. But, can these conventions be disobeyed by some, possibly malicious, software? Or is the read-only rule enforced at the hardware level (by the CD drive)?

Note: By "write to it", I mean change any bit that has already been written or add a new bit. Also, OS also includes BIOS.

  • I've recently been thinking along these lines. The most secure ways to prevent such an attack on the disc's integrity would be to have a CD-ROM pressed instead of using a CD-R, and/or to use a drive without a write laser. The latter is obviously the less expensive option. But while this would solve the problem, it doesn't answer your question (and I, too, want to know the answer)! Dec 14, 2013 at 0:43

2 Answers 2


A CD burner works by firing precise beams of IR or UV laser radiation at a targeted point on the disc surface, where it interacts with a chemical dye. This dye changes optical reflectivity when exposed to such radiation, hence the term "burning". When reading it back, a lower intensity beam (usually at a different electromagnetic wavelength) scans over the disc and interprets the levels of reflectivity as a signal. When appropriately interpreted, this produces a stream of 0s and 1s.

There are two primary ways of encoding such data. The first is simply to assign "reflective" and "non-reflective" as 0 or 1 directly. One downside with this is that it is prone to errors. A speck of dust or a small scratch could corrupt the data, so extensive error detection and correction (e.g. parity) data blocks must be included. An alternative method is to use transitional encoding, which converts the transition of reflective to non-reflective and vice versa as 0 and 1 bits. This helps improve error detection and correction because long runs of reflective or non-reflective responses are simply ignored. Parity is still required, but to a lesser extent.

If the former method is used, it may be possible to etch more non-reflective bits (whether these are determined as 0 or 1, I am unsure). However, in my understanding, this simple version of encoding isn't commonly used.

If the latter method is used, things get more complicated. Causing a reflective bit to become non-reflective would break the transition (i.e. you'd have non-reflective followed by non-reflective) and simply destroy the bit. The parity would then correct the error, assuming there is enough remaining data. Since the read controller is aware of its position on the cylinder, trying to damage a single bit-pair in the hopes of offsetting the data in a way that allowed you to control it wouldn't work, as it would recognise that the bit-pair was destroyed and move on to the next bit pair, rather than shifting the stream by one bit.

The only trick I could see being feasible is to destroy the data to the point where the parity correction results in the wrong data, but this would not allow you to arbitrarily alter data - the results would be bound to a strict set of outcomes, based on the calculation of the parity. As such, it is relatively infeasible to modify the data on the disc in any meaningful way.

  • 1
    Thanks, I learned a lot from this (upvoted). But, it still doesn't answer whether software can cause this writing after the CD was "finalized". Jun 13, 2013 at 8:16
  • 1
    @onelineproof My understanding of "finalisation" from a CD-R perspective is that either the outer cylinder has an "EOF" marker written to it, and the inner cylinder has metadata written to it that says which cylinder the data ends at. As such, it may be possible to write data past that marker point, but the reader won't detect that it's there.
    – Polynomial
    Jun 13, 2013 at 8:28
  • This is fascinating! So CD-R still uses RLL (that sounds like what you're describing)? I would have thought that it'd be using a significantly more complicated encoding, with loads of SECDED error correction, not just parity bits. As for your mention of finalization, couldn't an attacker corrupt the EOF and modify the metadata so the cylinder the data ends at is farther on, since that would only need to involve changing one bit?
    – forest
    Dec 7, 2017 at 10:47

If I recall correctly this is forced physically as the dye used on the CD is different between a CD-R and CD-RW. The CD-R has only 1 coat of semi-metal alloy wheras a CD-RW has multiple. So physically it's impossible to overwrite a CD-R (changing a bit) you might be able to add bits (burning extra holes) but I'm unsure about that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .