86Box Now Supports the SafeDisc Copy Protection for CUE/BIN Image Files

Table of contents

While recently going through the latest commit messages for the incredible PC emulator 86Box in preparation for their release of version 5.0, I stumbled across commit 8944c92 with the following commit message: CD-ROM: Parity and CRC checking support, System Shock 2 now works with a directly mounted .CUE image as well.

My initial thought? “Wow, they just added support for the SafeDisc copy protection, this is awesome! I can play The Sims and Age of Empires 2 now!”.

Well, the games themselves were already compatible with 86Box, but it was the SafeDisc copy protection that rendered the games unusable.

Let me explain.

Wait, what is SafeDisc?

SafeDisc is a copy protection technology that was popular in the late 90s to the early 2000s. Coincidentally, two of my favorite titles, The Sims (including all their expansion packs and later “Deluxe” and “Complete Collection” editions) and Age of Empires 2, are protected with SafeDisc as well. Each time the protected application or game is started, SafeDisc performs various checks to ensure that the original disc is inserted into the user’s computer. If SafeDisc detects the original disc and passes all authentication steps, it decrypts the program data and launches the application. If authentication fails, the program won’t start, and you’ll receive an error message, typically asking you to insert the correct CD-ROM into your drive.

The term copy protection is very accurate: SafeDisc was effective at preventing copies written to blank CD-Rs, but not very effective at preventing dumping.

Depending on the version of SafeDisc, the tool incorporates various technologies to prevent copies:

• Intentionally bad sectors that cause read errors
• So-called “weak” sectors that exploit flaws in the EFM encoding
• ATIP detection being able to recognize CD-Rs
• Detection of virtual drives

The detection of virtual drives was quickly bypassed by drive emulation software, allowing it to “hide” the virtual drive from the rest of the system, making SafeDisc unable to detect it.

The ATIP detection tries to read the ATIP information of the disc. The ATIP is an area that sits “before” the data area of a (re)writable disc. It contains information about the characteristics of the disc, such as the type, manufacturer, and additional data that helps CD writers calibrate their writing parameters. If SafeDisc detects that you are running the application from a CD-R, it will refuse to work. To bypass the ATIP check, you must either use drive emulation software or a CD-ROM drive that can only read, but not write, CDs.

The “weak” sectors are an interesting phenomenon. When reading the disc, the weak sectors will read just fine like any other sector. However, when you try to write the image to a CD-R again, your CD writer will likely either refuse to burn the image during the process or the copy will not work. Before the data is sent to the laser that actually burns the data onto the disc, your CD writer will have to go through a step called “EFM encoding”.

The data within the weak sectors is laid out in a way that tries to confuse the EFM encoding by creating special patterns. To this day, making copies of the weak sectors is not easily possible with modern drives. During the authentication process, SafeDisc will try to read the weak sectors and refuse to work if they can’t be read correctly. Please note that the weak sectors only affect writing new copies, but not reading the original disc.

If you are interested in all the details regarding the weak sectors and how EFM works, there’s a great article about it available online.

Intentionally breaking data

To recap, we are - in theory - already clearing 3 out of the (up to) 4 checks SafeDisc implements:

• The virtual drive detection is not effective since we can emulate multiple drive models, and due to the full-system emulation, all applications will see a valid drive.
• The ATIP check will always pass since we are creating the image from a valid, original disc, so there’s no ATIP information to pass to SafeDisc.
• The weak sectors will always read fine since we are not working with a burned disc that’s potentially affected by the bad EFM encoding.

The most important part of SafeDisc, starting with the very first version, is the introduction of intentionally bad sectors. Reading CDs is hard. You are reading data with a laser from a thin metal layer with tiny grooves in it, through a thin sheet of clear plastic. That’s not reliable! To mitigate reading errors through smudges or scratched discs, CDs contain multiple levels of error detection and (to a degree) correction.

For demonstration purposes, I’ll work with a CUE/BIN dump I created from my original German Age of Empires 2 disc, which has a matching entry in the redump.org database.

When creating a dump file from a disc protected with SafeDisc, you’ll notice some read errors that will always show up, usually in the first 10000 sectors:

[LBA:    841] C2 error (bits:  312)                          
[LBA:    844] C2 error (bits:  312)                          
[LBA:    866] C2 error (bits:  312)                          
[LBA:    869] C2 error (bits:  312)                          
[LBA:    872] C2 error (bits:  312)                          
[LBA:    899] C2 error (bits:  312)                          
[LBA:    902] C2 error (bits:  312)                          
...                         
[LBA:   9961] C2 error (bits:  312)                             
[LBA:   9991] C2 error (bits:  312)                             
[LBA:  10006] C2 error (bits:  312)                             
[LBA:  10009] C2 error (bits:  312)                             
[LBA:  10012] C2 error (bits:  312)                             
[LBA:  10039] C2 error (bits:  312)                             
[LBA:  10042] C2 error (bits:  312)                             
media errors: 
 SCSI: 0
 C2: 812

C2 errors are reading errors that can be corrected to a certain degree by the drive’s error correction capabilities. If the damage is too severe, the drive will start to interpolate the missing data with a “best guess”. For CD audio, this is not a big deal: You either don’t hear the side effects of the interpolation or you’ll get a crackling or popping noise for a fraction of a second. But for a CD-ROM containing data, that’s not acceptable; even if we flip one single bit, the data will be invalid.

For this reason, CD-ROMs contain a second, higher level of error correction and detection: EDC/ECC.

A sector on a standard Mode 1 CD-ROM contains 2352 bytes of data (excluding subchannel information which are not relevant here), and in CUE/BIN images, we capture all 2352 bytes. 2048 bytes are dedicated to the “usable” data itself, and the 288 bytes “above” contain the error correction information. From these 288 bytes, the lower 4 bytes are reserved for error detection using a CRC checksum. Then, there’s a “gap” of 8 reserved bytes, followed by 276 bytes of error correction information using parity data.

When a drive reads a sector, it will check the 2048 data bytes against the 4 bytes of the checksum. If the checksum matches, it knows that the sector is good and tells the operating system that it could read the sector without problems. Otherwise, if the data and checksum don’t match, the drive knows that it read incorrect data and tries to rebuild the missing data using the 276 bytes of parity data. Assuming the read error is not too severe, the parity data contains enough information to reconstruct the original data. In this case, the drive will also report a good read to the operating system.

However, if there is too much original data missing, the error correction will fail because there’s not enough parity information to reconstruct the missing bits. Then, the drive will return a reading error to the operating system.

SafeDisc intentionally places damaged sectors on the disc. It doesn’t contain any game data; it is only there for internal use by SafeDisc itself. During the authentication process, SafeDisc instructs the drive to (randomly) read some of the intentionally bad sectors. And unlike the weak sectors, the sectors need to be unreadable. If the drive can read the deliberately damaged sectors, the authentication will fail, and SafeDisc reports the disc as missing or a copy.

Using bad sectors serves two purposes: Many drives will try really hard to correct the bad sectors, sometimes needing hours for a simple copy. Earlier software wasn’t designed with this protection in mind, so it would often simply fail if it encountered a reading error. Why would you want to burn bad data in the first place? And speaking of burning, many earlier disc copying software couldn’t burn bad data. The software or the drive would either refuse to work, or silently rebuild the checksum fields to “match” the user data it could read, fixing the reading errors that should not be fixed.

Sometimes, fixing errors is not good

So, if SafeDisc can read the damaged sectors, it knows it is a copy. And until the commit mentioned at the beginning of this article, 86Box couldn’t emulate read errors. Even though the image is dumped correctly and contains the “bad” sectors, filled with dummy data to ensure a broken checksum and invalid parity information, 86Box’s drive emulation would happily report a good read. And yes, this breaks SafeDisc.

To demonstrate the emulation flaw, I loaded the image I created from my original disc into 86Box and ran a surface scan with an old version of IsoBuster.

With the old drive emulation code, the disc reads without errors, even though it should have 812 errors:

When I run the surface scan with the new drive emulation code, the 812 errors are reported correctly as reading errors:

And while the game previously wouldn’t pass the copy protection, asking me to insert the correct CD-ROM into the drive…

… it now allows me to go back to medieval times!

About version compatibility

Age of Empires 2 is using the very old SafeDisc 1.30.010. SafeDisc 1.x only uses the intentional reading errors to detect copies. Especially the ATIP checks and the virtual drive detection are a novelty to SafeDisc 3.x and 4.x. The newest disc using SafeDisc I own is my copy of The Sims: Complete Collection, which uses SafeDisc 4.50.000. Right now, I couldn’t get the game to work on 86Box 5.0, using the stable build with the old dynarec. When it tries to perform the copy protection, the application segfaults. This is not related to the game, but also happens when starting The Sims Creator that’s bundled with the game and also does the SafeDisc check. I also tried with build 7706 using the new dynarec and ran into the same issue.

So while earlier versions of SafeDisc now seem to work just fine, you might run into problems with “newer” games. Time to dust off my stash of discs to get some more samples…

Thanks, dear 86Box team - keep up your great work, you are awesome!

Do you have any comments or suggestions regarding this article? Please drop an e-mail to feedback@felsqualle.com!