A new CD-Cops thought

After reading the "A Tages Dialog" thread, a new idea comes to mind.

Inserting nonsense sectors with tracking info that isn't correct...

It would slow down the read, making the guard module think that the angle is different than what it really is.

How exactly does CD-Cops check the physical angle of the disc? Spath...?

> How exactly does CD-Cops check the physical angle of
> the disc? Spath...?

IF CD-Cops really checks for that angle (which I don't know),
then I see no other possibility than by timing seek commands.
This should be fairly easy to check if you have an opened
external drive : during the authentication period you should
see the laser moving several times from start to end.
For more details ask blackcheck, he made some tests
on the reliability of this method. As far as I'm concerned,
until I get my hands on a CDcops .exe I don't know how it works.

How would you time the seek to check the angle? I read that this is how it checks, but don't see quite how.

And would the extra "fake" sectors slow down the seek enough to make a meaningful difference on the interpreted angle of the disc?

cdcops checks the cd by timing read commands. for sure.

i'm not really sure how it works exactly tough.

here's my theory :

let's say the rough length (in sectors) of one loop (close to the edge of the disc) is x.
CDCops reads the last sector, then lastsector-x and so on.

by playing with x for each read you can find some sort of 'line'
on the disc that can be read faster than other 'lines'.
(this is of course no real line but the term should help you get the idea.)

this 'line' is the same for all discs comming from the same glass
master.

enough theory, some more facts:

cdcops calculates a 8 bit value based on the timing. then you
have to enter a serial number that is checked against this
8bit value. this is because you cannot know the angle before
the disc is pressed.

i have implemented this theory and it does work somehow, but
it's not very reliable.
i stopped playing with cdcops pretty soon ( because i figured out
that weak sectors should be far more easy to implement...)

16 bit in later versions as well.

How did you implement it?

by bruteforcing



for (int i=0;i<10;i++) {
for ( int x=20;x > 0; x--) {
Read(LASTSECTOR);
time[x]+=Read(LASTSECTOR-x);
}
}

lastsector-= fastest x val;

and so on...


edit: fixed a bug ;P

---

Last edited by blackcheck; 14-08-2002 at 01:26.

Wouldn't calculating the new 8bit (or 16bit) value for a copy not be simpler?!

But guess that's not the purpose of this forum

Yes, indeed!

Any ideas on how CD-Cops generates the key based on the seek times?

I don't have any CD-Cops originals or exe's. So I don't know much about this protection, but reading their site, it looks like they also do it this way to get the correct number for their glass master, and since the exe contains the same checksum code, one can extract that part and write a generic checksum program to unlock the copy.

But this board is meant to discuss how the CD protection works and not how to circumvent it.

I have the exe for "Super Alpha" - Definately CD-COPS protected, but not the original CD.

I guess, and this is only a theory, that

CD-COPS might do this:

If say we have two sectors on the outer edge of the CD which are in the same "line" and are quite close to each other, CD-COPS reads from the first to the second (a short distance - eg 50 degrees), giving a value for the seek. Given that the CD always spins in the same direction, when CD-COPS next seeks from the second to the first, the CD reader has to spin the CD right round (eg 310 degrees).

By adding together the values or getting a value from seeking the first then seeking the first again (in someway that the reader has to spin the CD round completely) - CD-COPS gets the time to seek 360 degrees.

By dividing the values for "first to second" and "second to first" by this value, it can get the precise angles (eg: 51.9812 degrees and 308.1298 degrees)

It then converts these measurements into a key via a series of encryption algorithms.

This angle will be the same for every CD produced from one glass master.

I have tried to implement this method, but given that it is not hugely reliable, CD-COPS must have a lot of rechecks and averaging of measurements as well.

The person who can really explain this though is Venom386 (The DT developer) - because DT 3.17 can emulate CD-COPS so I presume that he obviously has a pretty good understanding of how it works.

But what is needed is the encryption algorithm, there must be at least two, since there are 2 different key sizes.

LinkData change the algorithm from time to time - so knowing it is not particularly useful. As soon as a utility to decrypt CDCOPS becomes available - LinkData change the encryption system.

Trying to work out the encryption algorithm used will be very difficult won't it? - You can be your bottom dollar that LinkData won't use some nice, simple, commonly used algorithm - Probably one of their own.

I'll check with the author of the CD-Cops decrypter, then.

I have tried all the decryptors for CD-COPS now.

Yes, that works fine, but what I am saying is that it only works for some versions of CD-COPS.

CD-COPS decryptor only works with some exes. Having tried it on a range of protected exes, it works on about 50% of them. I suppose if you built in version checking and then using the appropriate decryptor - fine.

I was clearly wrong about the algorithm being overly complex though.

Sorry SDG.

I guess you'll have to ask McLallo.

Remember though exe is encrypted using the file date / time, which is what the decryptors use to extract the executable I believe.

Is this a forum which discusses the technical aspects of Optical Storage discussions or on hacking software and making illegal copies?
It is much more fun to try to re-invent a new protection yourself, than just to hack the work of others and then call yourself intelligent because you can use other people's programs like SoftIce and Bushound.

Everyone:
The authentication method used by CD-Cops is relevant to this forum
for technical reasons (for instance bushound logs are welcome).
But discussions about decrypting CD-cops binaries, generating new
codes, breaking the software protection or anything else not related
to cd technology do not belong to this forum and will be deleted.

Agreed.

Generating new CD-COPS codes for LEGAL backups is a nice idea but pointless given that there is:

- DTools 3.17
- The CD-COPS emulator (a member of the Star-Force team kindly gave me the link - I am not kidding)

The only aspect of CD-COPS that we can discuss is how CD-COPS calculates the CD angles (relevant to emulation the impossible 1:1 copy). That would also be a little pointless - Venom knows the answer.

Damn, CD-COPS is a very clever protection, very difficult to implement reliably. Even Tagés is easier (I think)

@ Spath / CopyDude

Having done most rev-engineering work with SoftICE & TurboDebugger (and that is not an awful lot - I usually do stuff without rev-engineering other software) - what is bushound?

what an embarrassing n00bi question

http://www.google.com/search?q=bushound

i have some cdcops logs at home but haven't been there for
quite some time. maybe next week.

The first answer that came up in the search was

"BUSHOUND DETAILS

Bushound is a simple..."

Oh jesus... I was having a bad day yesterday.

haha click the google link !

internet feedback ?

excuse me