How to fool cd-cops

SDG: If you burn 2 times the same image with the same writer, same firmware and same speed to media from the same batch, will then the angle between first and last sector be the same? In this case, you could just spread some twin sectors (with identical data for both “twins”) over the disc to make the angle fit, at least for cd-cops…

@Philamper: A crack for UT2003 is available => not what we want of course, but Sony doesn’t want it either, so they have again failed :slight_smile:

SDG: If you burn 2 times the same image with the same writer, same firmware and same speed to media from the same batch, will then the angle between first and last sector be the same? In this case, you could just spread some twin sectors (with identical data for both “twins”) over the disc to make the angle fit, at least for cd-cops…

Hopefully. But it may require a few burns in any case, since I’m running into prblems with slight variations in the media (around 2/3 are working. And these have to be done by hand, since I haven’t made any tools for them, yet.

Well, SDG this is good news if it works well.

It doesn’t matter if you can’t get a 100% success rate. As long as we can get a 60+% success rate on popular (LiteON / Plextor) drives on popular media (TraxDATA / Maxtor etc.) then that is useful enough for backup purposes.

I think that this is getting blown up a little.

I’ve gotten it to work on 1 specially modified image, have no source code, it took me almost 3 man-days to do, and it could still be just one of those things (ie, I have a different CD-Cops disc which I can copy fine, modifying it or not.).

I don’t know enough about CD-Cops or C++ to do it.

For some reason, when I try to patch a file, the patched image is coming out bigger than the original (but this is a SD2 weak sector scanner and patcher, not a CD-Cops on, in any case.)

Also, It occurs to me that the seek time on the original would have to be greater than that of the copy, or else adding sectors would not work…

If it is shorter, then what about removing 1 byte from each sector? Would RS be able to take care of that? I don’t think so, but it’s worth a shot.

On another note, perhaps the CD-Cops discussion should go into another thread.

Sorry :slight_smile:

SDG: You can simply add enough sectors to get something between 180 and 360 degree to fix the angle in that case…of course, this will increase the seek time, but one pitch of 1,6µm shouldn’t hurt…i doubt that the times can reliably be checked that accurately.

SDG: You can simply add enough sectors to get something between 180 and 360 degree to fix the angle in that case…of course, this will increase the seek time, but one pitch of 1,6µm shouldn’t hurt…

How accurate is the algorithm?

On another note, what’s the keyboard code for:

µ ? It’s incovenient to copy it from the character map.

/me codes program to calculate distances from center.

I have µ on Alt-Gr + M. German keyboards are good :slight_smile:

How does one measure a seek time in C++, or determine the last sector of the drive in one?

I’m thinking of maybe a program like:

User inserts a copy of the CD made with CloneCD, etc.
float seektime = Seekfromfirsttolast();
insert100twinsectors();
burnnewimage();
float copyseek = seekfromfirsttolast();
float seekdelaypersector = (seektime - copyseek)/100;
User inserts original
float orginalseek = Seekfromfirsttolast();
if (originalseek < copyseek)
{
wraparounddisc();
}
else
{
float difference = originalseek - copyseek;
int dummysectors = difference/seekdelaypersector;
insertdummietwin(dummysectors);
}

Think this would work?

What about problems with different drives having different amounts that they go backwards to compensate for having inaccurate seeks? Would 100 dummies be enough to compensate for that?

Your problem is not C++ specific.

You will have to go into ASPI programming to solve that. The language you choose is not important.

You will have to go into ASPI programming to solve that. The language you choose is not important.

Okay, how do I implement ASPI calls in C++?

I remembered that spath sent me a PM on this issue once, which I had forgotten about.

Looking at it, my eyes kind of glazed over and created a popping sound, but I know there are some better programmers here (everywhere!), so I’ll post the article link.

http://www.cdrlabs.com/articles/index.php?articleid=3 , and the second in the series is:

http://www.cdrlabs.com/articles/index.php?articleid=4 (Spying on ASPI traffic)

Can anybody shed some light on ‘angles between sectors’ on a cd? How can you measure ‘angles’ on a cd? Maybe some links?

OK, my idea about that:

Angle between sectors: Draw a line through each of the sectors you want to get the angle between, so that these lines go through the center of the CD. The angle between the lines is the angle between the sectors.

How to measure:
When seeking, there are 2 operations: The actual “seek” operation, which moves the laser to the correct position, and then, the drive has to wait till the sector you want to read is beneath the laser.

Lets say, the disc is spinning at 6000rpm (which would be something like 12x-30x CAV).
That means, one rotation of the disc takes 10 milliseconds. If you seek from one sector to another, with an angle of 180° between them, the drive will have to wait for a half rotation to be done, i.e. there will always be a 5ms part. The trick is to isolate that time from the time the drive needs to move the laser.

I’m looking forward to the maths required to do all that with a CLV reader :slight_smile:

Originally posted by alexnoe
[B]OK, my idea about that:

Angle between sectors: Draw a line through each of the sectors you want to get the angle between, so that these lines go through the center of the CD. The angle between the lines is the angle between the sectors.

How to measure:
When seeking, there are 2 operations: The actual “seek” operation, which moves the laser to the correct position, and then, the drive has to wait till the sector you want to read is beneath the laser.

Lets say, the disc is spinning at 6000rpm (which would be something like 12x-30x CAV).
That means, one rotation of the disc takes 10 milliseconds. If you seek from one sector to another, with an angle of 180° between them, the drive will have to wait for a half rotation to be done, i.e. there will always be a 5ms part. The trick is to isolate that time from the time the drive needs to move the laser.

I’m looking forward to the maths required to do all that with a CLV reader :slight_smile: [/B]

will that work because drives don’t always have the disc spinning at a constant speed ?

@SirDavidGuy

How do you think CDCops works?

Originally posted by Upp3rd0G
[B]@SirDavidGuy

How do you think CDCops works? [/B]

Same way as alexnoe.

will that work because drives don’t always have the disc spinning at a constant speed ?

Yes, because the rotation time relative to the speed will always be the same.

But what about people having a 4x drive?
How would this protection work if people had slow drives.
Most games state as minimum config a 4x drive…

This would be hard for any CLV drive, regardless whether 2x, 4x or 8x. As far as I remember, some of these drives didn’t play CD-Cops discs at all.