Copy Protection details

[sarnau]

The problem is that pasti in transfer mode will not let me save what I have until the error in sector 79 occurs but instead it terminates the whole process. I end up with no image at all.

Can you post the PASTI logfile, when running in verbose mode?

[snoopy]

I think I've already tried to use verbose mode a while ago. As far as I can remember pasti wanted me to use a hard disk.
Since it's been a few months ago and my memory of this is not so fresh, I'll try again this week.

[snoopy]

Hey, forum's back online!!! Great. As far as I see we didn't lose anything in this thread... Let's go on with even more dedication.
Ok, after some time trying, I was able to revive my old HDD and dumped one of the disks via verbose mode as far as Pasti would read it (on track 79 it breaks operation).
There wasn't any logfile... maybe I just didn't see it... anyway, here's the the stx... I'll check for the logfile later and post it...

[mr.vince]

We heard that Turrican has been a troublesome title to image, so IFW decided to give it a full analysation pass. He does not have an account here, this is why I am posting this bit of information. It's straight from an email, in case it sounds familiar and private...:

The protection is not what you might think it is, but impossible to guess without seeing the bit cells...
It's one type of very powerful Copylock, probably the best version.
Impossible to copy, data can only be generated.

It contains "no flux reversal" areas.
In theory you can only read the data bits with the WD177x FDC.
However what it does is, that it checks both the *clock* and the *data* bits in the mfm encoding, more over all of them have to be 0.
You should understand that is impossible in theory, for two reasons:
- the lack of flux reversals increase the gain on the head, eventually leading to an amplified level that generates a fake flux reversal (the so called "weak bits")
- the pll and data separator can't lock onto the clock bits either, so (depending on fdc type) would eventually lose framing and make cell sizes random and might as well inject a 0 or 1 bit as a bonus (weak bits again, but depends on fdc).

If you create an analog copy (drive to drive,such as Cyclone on Amiga, similar things exist for the ST I am sure) of such disk, the drive reads no flux reversals for an extended period of time, and the other drive tries to write that.
If you write that data with the other drive, what you get back is weak bits, instead of the "no flux reversal" area.
Therefore, even a copy made with analog equipment would never ever work, as the original has no flux reversal at the protected signature, the copy will have weak bits instead.
Naturally, other, simpler copying methods wouldn't work either.

One sector is shifted by a bit cell.
On a WD177x, when you read a data block, the fdc locks onto the sector, and disables further re-syncs caused by mfm marks.
Therefore if you have a data block written shifted by a bitcell and synced properly, you'd be able to read data bits as well as clock bits!
Now that's all nice, but if that was something that can be written with a normal controller it would be effort wasted.
So how about checking that we have a "no flux reversal" area instead? That as you know by now is impossible to write anyway

See attached pictures to understand what happens for real:
First you read sector 0; p1 and p2 at different positions (the number on the left is the bitcell position)
The data block gets locked on the marks at the line highlighted by yellow on p1.
The AM detector is turned off at this point. The FDC reads, and ignores the marks as expected (the bitshifted marks on p2 yellow line), ie continues to stream at the same data bit alignment.

Now read sector 16 instead.
The data block that must be locked onto is shifted by a single cell, in other words, clock and data bits shifted into each others position, see p3.
You can read the clock bits now.


P1

p1.PNG

P2

p2.PNG

P3

p3.PNG

[ijor]

We heard that Turrican has been a troublesome title to image, so IFW decided to give it a full analysation pass. He does not have an account here, this is why I am posting this bit of information. It's straight from an email, in case it sounds familiar and private...:
The protection is not what you might think it is, but impossible to guess without seeing the bit cells...

Possibly just for the records ... Please note that there is no relation whatsoever with the protection and what makes difficult to image this title using the standard Pasti imaging tool. The imaging tool can easily image other titles with the same protection, even ones having a later and a bit more advanced variation.

[mr.vince]

What problem does the Pasti imaging tool have with this title?

[sarnau]

Hey, forum's back online!!! Great. As far as I see we didn't lose anything in this thread... Let's go on with even more dedication.
Ok, after some time trying, I was able to revive my old HDD and dumped one of the disks via verbose mode as far as Pasti would read it (on track 79 it breaks operation).
There wasn't any logfile... maybe I just didn't see it... anyway, here's the the stx... I'll check for the logfile later and post it...

Doesn't load in Steem Anything special with it?

[DrCoolZic]

What problem does the Pasti imaging tool have with this title?

Insnt it related to the so called "non physical alteration of the track"... long area without flux transitions not handled correctly by drives ... Please Ijor provides more information

What is the CTA program you seems to have used to analyze Turrican ?

[ijor]

What problem does the Pasti imaging tool have with this title?

It is because of an undocumented FDC bug, that affects tracks with a sector header under the index. I implemented a workaround at some point, but I think the workaround is not integrated in the public release of the imaging tool.

Insnt it related to the so called "non physical alteration of the track"... long area without flux transitions not handled correctly by drives...

Hi Jean. No, it has no relation with this.

[ijor]

Doesn't load in Steem Anything special with it?

It won't load, of course, because the file is truncated. If you want to produce something that would load (althought it would probably fail to run), then omit the problematic track. Specify tracks 0-78 when imaging the disk.

I seem to recall I have one of those Power Pack IV disks. Would need to check it.

[mr.vince]

What is the CTA program you seems to have used to analyze Turrican ?

This is the SPS Analyser:

sps_analyser.pdf

It is because of an undocumented FDC bug, that affects tracks with a sector header under the index. I implemented a workaround at some point, but I think the workaround is not integrated in the public release of the imaging tool.

Does this cause a lockup in the controller, or in the imaging tool?

[sarnau]

Hey, forum's back online!!! Great. As far as I see we didn't lose anything in this thread... Let's go on with even more dedication.
Ok, after some time trying, I was able to revive my old HDD and dumped one of the disks via verbose mode as far as Pasti would read it (on track 79 it breaks operation).
There wasn't any logfile... maybe I just didn't see it... anyway, here's the the stx... I'll check for the logfile later and post it...

As suggested: please dump only track 0..78 and post that file.

[ijor]

Does this cause a lockup in the controller, or in the imaging tool?

It isn't exactly a lockup. The bug prevents the imaging tool to perform a correct track analysis. The software detects the problem and sets an internal error. The track is still retried several times. Sometimes one of the retries is ok. Otherwise, after all the retries are exhausted, you get a fatal error.

[DrCoolZic]

I just completed the analysis of Turrican and I have some questions

...
It contains "no flux reversal" areas.
...
- the lack of flux reversals increase the gain on the head, eventually leading to an amplified level that generates a fake flux reversal (the so called "weak bits")

While it is true that the AGC is probably pushed to the max value I have never seen fake flux transitions. Otherwise it would not be possible to image correctly with the KryoFlux device.

- the pll and data separator can't lock onto the clock bits either, so (depending on fdc type) would eventually lose framing and make cell sizes random and might as well inject a 0 or 1 bit as a bonus (weak bits again, but depends on fdc).

Lack of transition should not affect the DPLL (should stay stuck to last transitions values). But of course at end of no transition area the first few bits will arrive on a PLL with may be wrong frequency and position.

If you create an analog copy (drive to drive,such as Cyclone on Amiga, similar things exist for the ST I am sure) of such disk, the drive reads no flux reversals for an extended period of time, and the other drive tries to write that.
If you write that data with the other drive, what you get back is weak bits, instead of the "no flux reversal" area.
Therefore, even a copy made with analog equipment would never ever work, as the original has no flux reversal at the protected signature, the copy will have weak bits instead.

Don't know about cyclone but on Atari an analog copier like Blitz should write the write the no flux transition area as it just blindly copy the data out of one FD to the data in of the other FD. Of course as usual analog copy should be avoided as no checking is performed.

One sector is shifted by a bit cell.

This is a nice trick

So how about checking that we have a "no flux reversal" area instead? That as you know by now is impossible to write anyway

You mean with a WD1772? I guess it is possible to write with KryoFlux ?

I also have a question for Ijor if he is looking at this thread. Sometime in the past you have written something like:

Based on special non physical alteration(s) of a track (like strong erasure) that can’t be reproduced by digital copier like Discovery Cartridge. From the point of view of the flux transition level, the protection is about a long area without flux transitions. A normal drive can't create such a long spacing between two flux transitions. This is a limitation of the drive, and not a limitation of the controller. So this protection defeats hardware like the Discovery Cartridge.” ???

I do not understand why it is not possible? I understand that no transition area can cause problem when reading (due to AGC) but why when writing?
Does this imply that it will not be possible to write back Turrican image using the KryoFlux board ?

[Dio]

Hmmm. An erase signal is usually a high-frequency AC signal (i.e. fast enough that the magnetic domains are left in a random state), but a constant value at the head is a DC signal, so I can see that the effects it would produce on the disk should be different...?

I would have thought Kryoflux could in theory completely erase a track by writing very high frequency data to it, but that might be filtered out by the drive electronics of course.

[DrCoolZic]

This message is for Markus (sarnau)

I have completed the analysis of the Colorado track 1 (I only have one track ! thanks to Ijor and the Discovery Cartridge )

I think that you might have miss something in this game protection http://www.sarnau.info/atari:protection_colorado

As far as I know Colorado uses the Macrodos protection from Speedlock. Hard to find information on this one
As far as I understand this protection uses an intra-gap bit rate variation. This mean that the clock goes up to 4.2 µs for about 80 bytes or so and goes down to 3.8 µs for 80 bytes.
This protection cannot be found by looking at the sector length as there are as many "speedy bytes" as "slow bytes" resulting in a sector of about 16487 µs very close to the normal 16480 µs sector length.
The only way to detect this kind of protection is by measuring the "chunks of bytes" transmitted through the DMA

You will find attached a plot of the sector 1 as produced by my KFAnalyze program. viewtopic.php?f=95&t=21709#p194181

[sarnau]

Weird, I looked at the code. Maybe I somehow got an image of an incomplete hack?

[DrCoolZic]

There is not so much information on the macrodos protection. May be Ijor would have more info. But it would make sense that the program test for this hard to generate bit rate variation

[ijor]

I just completed the analysis of Turrican and I have some questions
...
I also have a question for Ijor if he is looking at this thread. Sometime in the past you have written something like:
I do not understand why it is not possible? I understand that no transition area can cause problem when reading (due to AGC) but why when writing?
Does this imply that it will not be possible to write back Turrican image using the KryoFlux board ?

As with most protections, this is always about what you can or cannot write, not about reading. This has (almost) nothing to do with the AGC. As you are saying, you can read the protection without problems (otherwise the protection wouldn't work).

It is not possible to reproduce the exact magnetic state of this protection with a standard drive. Consumer drives were not designed for erasing, let alone this type (DC) of erasing. Because this is a limitation at the drive side, a custom controller can't help here.

However, it is possible to emulate the protection behaviour, at a certain degree, with some trickery. I can't say for sure, though, how much reliable this is. It probably depends on both drives (the writing and the reading one), and on the disk as well.

[ijor]

Weird, I looked at the code. Maybe I somehow got an image of an incomplete hack?

As Jean is saying, the protection on Colorado is present on track 1 sector 1. The custom variable bitrate is, of course, fully checked by the software. You can use a Pasti breakpoint to stop execution when reading the protected sector.