Issues dumping PC disc with "Code Lock" copy protection

[scsi_wuzzy]

I've got a copy of Tropico for PC that I'm having issues dumping. I believe it's a US copy, but it doesn't appear to match the copy in the database.

BurnOut says the disc has "Code Lock" copy protection. I couldn't find anything about that protection online, but it seems to be similar to SafeDisc in that there are a number of intentional bad sectors on the disc. One thing that is bizarre about this disc, that I've never seen with any of the other discs I've dumped, is that you can physically see where the error sectors are on the disc. There's a line, maybe about 2mm wide, where the silver is a completely different color. It's maybe 3-4mm from the start of the data on the disc. I've ripped tons of discs with SafeDisc, etc. and I've never seen one before where I could physically see the defects, so this is something new for me. It looks similar to...you know how some manufactured discs you can see a line where the data ends? It's like that, except in the data and very narrow. I know it sounds like some kind of disc rot or something, but I really don't think it is. The disc looks good and all the files can be copied without issue.

So far, I've tried to dump the disc with DiscImageCreator on a PX-760A and a PX-716AL and with Alcohol 120% on an ASUS BD drive and a LG BD drive. DIC reports that there is in fact a protected file, and the 716 and 760 both report C2 errors, though not with a consistent number of bits (in contrast to SafeDisc where you generally see 312 bit C2 errors). Here's what is in the C2 log from the 716AL: https://pastebin.com/DQntkqMr

Also note that this list of errors is different between rips. The number of C2 bits is different, but also the reported list of sectors is different (e.g., the above list includes LBA 10022, but other times I rip that sector won't be there). Here it is when I ripped with the 716AL again (at a different speed): https://pastebin.com/tvQnSVt9

The the list is also different between rips when I use the 760A -- neither can produce a consistent image.

The even bigger problem, though, is that the resulting image produced by DIC is unusable. Despite the fact that it looks like all the reported C2 errors are intentional, if I open the image with CDMage, it reports that the "Data track has errors in the file system" and none of the files are present. However, the disc itself is in fairly good shape, and, as I mentioned previously, I'm able to copy all the files off without issue.

Additionally, I was able to image the disc with Alcohol 120%, and it produced an image with no filesystem errors (just errors corresponding to the protection sectors). However, it looks like even Alcohol 120% probably won't be able to reliably image the disc. I've just started imaging on another drive (it takes like 16+ hours to image the disc due to the errors -- I started it one night before I went to bed, expecting to see the results in the morning, but it was still running when I got up and for most of the rest of the day), and so far the reported error sectors don't look like they map to what is present in the image I already made.

Does anyone have any experience / advice on how to properly dump this disc?

On another note, Alcohol sometimes reports "Disc read error" and sometimes reports "Read data examination error." Does anyone know the difference between these two errors?

Edit: I forgot to link the log files! Here are the logs from the 716AL ripping at 8x: https://www.dropbox.com/s/xjmwh5diirdkr … gs.7z?dl=0. ECCEDC reports a mix of bad MSF, user data doesn't match, and invalid sync for the protected sectors.

[Nexy]

This seems like another ring protection similar to Laserlock and CD Ring Protect. Jackal or Reentrant will have to chime in here if they have ever dealt with that particular protection, and if there is a method of dumping it. I gave up trying to dump discs with these protections as the results are inconsistent and we have no way of knowing if the dump is good or not.

[scsi_wuzzy]

I gave up trying to dump discs with these protections as the results are inconsistent and we have no way of knowing if the dump is good or not.

I don't know anything about Laserlock or CD Ring Protect, but I'm kinda getting the feeling that, for this disc, it would probably be best to just completely ignore every sector on which the protected file exists and replace those with 0x55 sectors in the image file. I'm not convinced there's any real data in that region at all. I may build such an image and see if it works to satisfy the CD check in a disc emulator. Such an image wouldn't be "archival" quality, I guess (although, if there's not any real data there anyway, maybe it is?).

In any case, right now I'm just dumping for my own purposes and not submitting my dumps to the database, so "working" is probably good enough. I've come across a few of my personal discs where I couldn't get "archival" quality dumps, but I think this is the first one that's due to the copy protection and not just due to the disc being damaged.

[LoStraniero91]

I've only dealt with CodeLock once, and I can tell you it's a weird one: it's a mixture of both LaserLock (due of the rings) and SafeDisc (due of the errors being in a pattern instead of all bunched up together like your everyday ring protection).
Your best bet to dump a CodeLock protected game is to use CloneCD with a non-Plextor drive.

I think Jackal will be able to assist you even better.

[scsi_wuzzy]

I've only dealt with CodeLock once, and I can tell you it's a weird one: it's a mixture of both LaserLock (due of the rings) and SafeDisc (due of the errors being in a pattern instead of all bunched up together like your everyday ring protection).
Your best bet to dump a CodeLock protected game is to use CloneCD with a non-Plextor drive.

I think Jackal will be able to assist you even better.

Thanks, this is helpful! It turns out there are actually some details I missed in the redump Wiki about CodeLock as well. I think I must've searched for "Code Lock" (with a space) previously, since that's what Burnout calls it, but the Wiki has some details buried in an article on CodeLock.

Indeed, based on what the Wiki says, Plextors are known to have issues with this protection. I've ordered a cheap Optiarc drive, since it sounds like maybe they're a good bet for this type of protection. Hopefully it won't still take 18 hours of reading to work like my LG did, lol!

[sarami]

/viewtopic.php?p=37722#p37722
be opcode replaces the original data to 0x55. I think it's not correct.

[Jackal]

Try clonecd with a non-plextor drive. It should read single errors and the error sectors are 5 sectors apart, or a multiple of 5 sectors IIRC. That's how you'll know if the dump is correct.

[scsi_wuzzy]

Try clonecd with a non-plextor drive. It should read single errors and the error sectors are 5 sectors apart, or a multiple of 5 sectors IIRC. That's how you'll know if the dump is correct.

I got hold of an Optiarc drive, and I'm currently dumping the disc with that. Right now I'm using Alcohol, but I plan to try CloneCD and probably CD Manipulator as well.

Right now it looks there's...kind of a pattern? Maybe multiple patterns separated by larger groups of good sectors? It starts off with 3 bad sectors, 8 good sectors, 3 bad sectors.

But then there're 23 good sectors and a pattern starts with 3 good, 3 bad, 3 good.

Then 23 good sectors and a pattern of 3 bad, 13 good, 3 bad, 8 good, 3 bad, 3 good...

There's definitely some kinda pattern. I'll look at it in more detail once it's done and post an update. And, as I said, I'll dump in other software as well.

Edit: The Alcohol read got done. Errors look like they're always groups of three, and lots of sectors that were reported as "bad" by my Asus weren't reported bad here. Based on the description here, though, it sounds like maybe the Asus rip is good? At initial glance, it looks like all the Asus errors are in groups of 5, 10, or 15 sectors. So, if they're meant to be a multiple of 5, that sounds right. But then the Optiarc has substantially fewer errors...all groups of 3 with varying distances between them.

Edit 2: Here is the list of bad sectors from CDMage for both the Asus and the Optiarc: https://www.dropbox.com/s/8eu918bz0jg07 … 20.7z?dl=0. The Asus has 3779 bad sectors, in groups of 5, 10, or 15. The Optiarc has 2281 bad sectors, in groups of 3.

Edit 3: If I look at one of the sectors that the Asus errors on but the Optiarc doesn't, like sector 2464 for example, the data section is all 0. If I look at one near there that they both read successfully, like 2466, it's all 0 also.

Edit 4: Using CD Manipulator, I got 2,274 errors. I think each error is a three sector block. 2,274 / 3 = 758, which is the number of errors for one of the European releases of Tropico: https://redump.info/disc/53929/. Is that just a coincidence, though?

[scsi_wuzzy]

After spending some time with this, it looks like my Optiarc 7290H reads blocks of 3 bad sectors. Most other drives read blocks of 5 or more.

Whether the Optiarc is "right" or not I can't say, but I was able to get two reads from it with the same number of bad sectors: 2274. One of those dumps was with CDManipulator, and one with Aaru. The CloneCD dump was very similar, but it had two extra sectors that were marked as bad (for a total of 2276).

Using CD Tool, though, I was able to read the two extra sectors that CloneCD marked as bad. I can understand how CloneCD ended up marking these two bad, though -- it took a number of retries and at one point I had to eject and reinsert the disc to wipe the drive cache (or some kind of cache -- it kept erroring and then read it immediately upon reinsertion).

I suspect Aaru is a good dumper for these discs. For bad sectors, it (by default) makes 5 passes at reading each one, and each pass consists of one forward read and one backward read. I think that approach might help avoid the drive getting "stuck" on marking a sector bad that isn't. I haven't verified this is the case, though. This approach also makes Aaru take ages to read a disc. The log says it took 50422 seconds, or about 14 hours I guess.

One issue with Aaru, at least in terms of getting its dump to match the ones produced by other software, is that it doesn't replace bad sectors with 0x55. It instead zeroes out the whole sector, including the sync, header, etc. That should be a relatively easy software fix for such images, though. For now, I used CDMage and imported the bad sectors from the CDManipulator rip. The dumps then matched. I haven't bothered to make sure that the bad sector list matches between the two, but I suspect it does. I'll check that next.

So, I think maybe I have a good rip?

[Jackal]

I think CodeLock is always single errors. If it reads in blocks of 2 or more errors then something is wrong with your drive or drivers or the read mode that is used. The correct error count is most likely 758 for your disc, just like the Europe one. Do you have any other drives that you could try? And no point in retrying sectors. Either the drive reads them or it doesn't. Plextors are unable to read single errors.