Copy Protection Information: Weak Bits, Bit-rate ...

A forum about Atari protected floppy disks analysis, preservation, emulation, tools

Moderators: DrCoolZic, Brume

ijor
Hardware Guru
Hardware Guru
Posts: 3023
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Sun Dec 31, 2006 6:21 pm

Hi jean,

DrCoolZic wrote:I will probably not continue to publish anymore on this thread ?


You are more than welcome to keep publishing, in this thread, in another thread of the Pasti sub-forum, or wherever you like and consider appropiate.

Obviously it would have been easier to get help but I know that not all people like to share their knowledge.


Sorry, but I think there is no more unfair comment than that one. I doubt you will find many people here that constantly share his knowledge as I always did and as I keep doing.

I always answered each and every one of your questions the best I can. Didn't I? Is there any question of you that I didn't ever answer?

Actually, I got angry precisely when you didn't ask. As Obo pointed, it wasn't the most correct way. But I am afraid I am only human.

Now, as I said before. I am sure you are a good guy and didn't mean any harm. On my side I didn't mean either, and if I did, I apologize.

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Sun Dec 31, 2006 6:36 pm

DrCoolZic wrote:But, nevertheless I will continue to collect information, perform test on the subject and update my document accordingly (at least for me). Obviously it would have been easier to get help but I know that not all people like to share their knowledge.

I've very much enjoyed reading your document, which as progressed so much since the early revisions. Information on specific ST protections has been very hard to find, so it's refreshing to find someone willing to document what they know/discover. I'm familiar with the fdc and many of the techniques used, though I'd rarely found details on the tricks using variable bit-cell widths.

I have to admit I sometimes find ijor's responses a little frustrating. He has contributed a lot to the Atari community, and does have great experience of this subject, but sometimes it's a bit difficult to tap that knowledge. He'll correct your mistakes and answer specific questions, but you'll probably not get much beyond what you've asked without asking a new question. I don't mean this to be a criticism, just a difference in us all :)

I'd really like to know more about what was required to simulate some of the PASTI images, as that would require knowing the specifics of each protection. Even knowledge of what the specific protections check on the original disk would be useful, so reproductions could aim to satisfy those without needing to reproduce every flux transition on the original.

Keep up the good work guys, and Happy New Year!

ijor
Hardware Guru
Hardware Guru
Posts: 3023
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Sun Dec 31, 2006 10:57 pm

Hi Simon,

obo wrote:I have to admit I sometimes find ijor's responses a little frustrating. He has contributed a lot to the Atari community, and does have great experience of this subject, but sometimes it's a bit difficult to tap that knowledge. He'll correct your mistakes and answer specific questions, but you'll probably not get much beyond what you've asked without asking a new question.


Oh, so now there are two against one. I give up :)

Seriously, what do you expect? What would you like "beyond"? Do you expect me to answer with a whole book covering all possible FDC/Pasti/Protections/disks related topics? Do you expect me to guess what you would like to ask but you didn't, or what you might be possibly interested to know?

Information on specific ST protections has been very hard to find...


There are virtually no ST specific protections. They are almost all generic and would apply to any similar system. Most of them are even completely generic and apply to any system.

The topic is not the most easily to find on-line, but it is not impossible. There are even a couple of ST specific books. The books are a bit outdated, and probably don't cover the latest protections developed in Europe. But those ones are widely known and I think you are already quite familiar with them.

If you wanted me to publish a structured table of all the possible ST protections, then I am afraid I have no such a thing. Not even something partial or close to that.

The only thing I could elaborate about this is the possible concepts of protections. You just need to think what a user system can't reproduce. From the top of my head, they are:

- The lack of the FDC capability of writing some bytes at format time.
- Weak bits.
- The fact that the FDC uses a fixed and constant bit-rate.
- Strong DC erased.
- Physical alteration of the disk surface.

Note that only the first one is somehow (but not completely) ST specific. Actually it is not even ST, but WD FDC specific.

There are of course a big number of simpler protections that the FDC does can reproduce. They can be as simple as just not using a standard FAT filesystem. I suppose this is not what you are interested.

There are a coutless number of variations and combinations. And I'm sure that Jean studied them in more detail than I did.

I'd really like to know more about what was required to simulate some of the PASTI images, as that would require knowing the specifics of each protection. Even knowledge of what the specific protections check on the original disk would be useful, so reproductions could aim to satisfy those without needing to reproduce every flux transition on the original.


As I said already, the Pasti tools have virtually no knowledge about the specifics of each protection. They just know some generic concepts. For example, the imaging tool measures timing for each sector. Then the DLL reproduces the timing. The DLL is not aware (it could be in theory, but it does not) if the sector or track you are reading is protected or not. It just reproduces the behavior read by the imaging tool.

This is by design, to be able to deal with protections and combinations that I didn't expect.

The Pasti images don't have a protection code or number. That is, there is nowhere in the image a mark saying, this is CopyLock, or something like that. I don't even have an internal database of which protection is used on each game. So that when somebody asks me that, then I have to make some analysis of the image for answering.

I think that 90%, possibly more, of this post I already answered to you in email, posted here or somewhere else in the forum. So as you can see, I don't have anything else as you seems to be expecting. So I am afraid if something is still missing, you would need to ask explicitely :)

Happy New Year

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1160
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Postby Greenious » Wed Jan 03, 2007 10:45 am

It is not always easy to elaborate on a subject where you don't have all the answers. It get's speculative, and you might end up giving the wrong information. I've done that a few times. (And been painfully corrected by Ijor, among other people, at a number of times) :oops:

Ijor seems to avoid that as much as possible, he wants to give correct answers, and while it does provide for your questions, you always get the feeling that he isn't telling you everything. :lol:

It can be frustrating at times.

But hang in there, just keep asking... 8)
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Wed Jan 03, 2007 6:41 pm

Ijor an I had an exchange of pms and hopefully we have been able to clarify our vision on better way to communicate...

Greenious wrote:But hang in there, just keep asking... 8)
Therefore yes I will continue to ask and update the document accordingly. :wink: Based on the number of times the thread has been viewed it seems that after all the subject is of interest to some people.

But you will have to be patient because I have several things going on in parallel and I would like to do more experiments before making a new release of the documentation.

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Wed Jan 03, 2007 11:55 pm

DrCoolZic wrote:Ijor an I had an exchange of pms and hopefully we have been able to clarify our vision on better way to communicate...

Excellent news. Its easy to misinterpret peoples meanings on a forum and especially so when your using a language that isn't your first so its good to hear that you've managed to get past that :) . Keep up the good work guys and yes we are reading and learning :) .
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

ppera

Postby ppera » Mon Jan 08, 2007 6:57 pm

I think that DrCoolZic did excellent job and made big effort to make documentation available here.
It is normal that there are mistakes and some bad explanations. Who works, makes mistakes.
Just keep up good work...

On the other side, ijor spends lot of time in 'pointless' discussions here, likes to explain with high language, often missing essence of things, but obviously some people is impressed with it. I don't want to say that he wrongs much, Obvisously he has big and wide technical knowledge, but maybe could improve his way of how sharing it...

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Wed Jan 10, 2007 10:25 pm

Thanks all for support.
A new version that include feedback from Ijor and Obo.

Also added a section on weak bits (not fuzzy bits). I had this in the back of my mind since the begining (see discussion at the very begining of the thread) and had confirmation(?) from the DM US patent... read the doc I hope it will make sense.
Also added section on invalid character during format as pointed by Ijor. Plus a lot of small modification/clean-up.
Unfortunately no new protection analysis, as I planned originally, because I did not had time but I wanted to get the above information written while still present in my mind.
As last time I have turn the "modification flag" in MS Word so it is easier to find what has changed sinve V0.6.
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Tue Sep 25, 2007 6:03 pm

Hello this is me again ...
Long time I had not work on the subject because "lack of time".

Anyway I am analyzing and updating documentation on two protections: One is about having 12 sectors (yes I said 12) on a track ...
And the other one is about intra-sector bit rate variation. Thanks to Ijor I now have track 1 of Colorado game in DC format.

I have analyzed the track and yes bingo it has the Macrodos protection: So sector is divided into 4 sections of 128 bytes and section 1 use normal 4 µs clock rate, section 2 use a 4.2 µs clock rate, section 3 a 3.8µs clock rate and section 4 a 4µs clock rate. So overall sector takes a normal time but sections differs .... Of course in order to find out you need to use a read sector command that gives you internal timing details like the one I have described in another thread. OK hold on for more details I will update my doc about this soon ...

But this is not the reason of this post. I found many other weird behaviors on this track and I want to discuss this one:
At the end of the track we find a sequence of 0 (actually FF but that's the same) followed by a sequence of sync byte $A1 (actually 6 which is a lot ...) followed by $FF
So with a read track command you get something like this:

Code: Select all

+ GAP4 282 bytes position=5990 time=191030 length=27641125
  0000 4005  f8 02 12 12 12 12 12 12 12 1f ff ff ff ff ff ff  ................
  0010 4164  e1 a1 a1 a1 a1 a1 a1 ff 0e a4 96 84 02 01 65 18  ..............e.
  0020 4069  40 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c  @...............
  0030 3941  9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9c 9d ff  ................
  0040 4069  ff ff ff ff ff ff ff ff ff ff ff fc 39 00 e8 e8  ............9...
  0050 4100  00 00 a0 01 80 0a 84 b6 03 f8 99 0f 80 00 16 54  ...............T
  0060 4005  af b9 00 00 bc 1f 45 80 a8 02 14 4e c0 04 08 12  ......E....N....
at the end of the track.

So I thought that it was a false sync sequence put at the end as part of the protection.
But here comes the interesting part: Now you send a bunch of "read address" commands to the FDC and ... guess what the above sequence is interpreted by the FDC as an address with a CRC error :?: :?: :!: :twisted: :roll: :megaphone:

We all know that an IDAM is marked by an $FE !!!
But did anybody knew that $FF was also apparently interpreted as an IDAM ???

Please let me know what you think ? This look strange to me and someone know or can test this would help.

Thanks ....

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Wed Sep 26, 2007 8:52 am

I did more experiments and yes $FF is equivalent to $FE as an IDAM ?

So:

Code: Select all

a1 a1 a1 fe 01 00 01 02 bc db
a1 a1 a1 ff 01 00 01 02 16 8a


Are equivalent !!!! Of course notice that the CRC is different.
Both ID fields, with these two values for IDAM, are read normally with read address command, and read sector command.

Amazing no? I will update my version of the wd1772 datasheet with this information.

Now question is: can this be used as a protection? Not sure. In most case it should be transparent to user: read address and read sector returns same information with $FE and $FF and as the IDAM is not part of what is read it should be transparent. However in the read track if you are looking for $FE IDAM then you are definitively in trouble.

In the specific case of the colorado track 1 the "ID field" with the $FF IDAM has also a CRC error and therefore is detected by the read address but cant be used for the read sector command (anyway there is no DATA field! after).

So yes actually it can of course be used as a protection ...

Edited:
The two CRC bytes are returned as part of the read address command. If you expect that the IDAM is a FE as normal then when you compute the CRC you will find an error but however the CRC status byte of the command indicate no problem. This hould be a good indication that the IDAM is FF and in fact this can be verified by checking the CRC with FF

Anybody knows about other "alternative" IAM IDAM DAM DDAM ?
My curent table is

Code: Select all

F5   write A1
F6   write C2
F7   write CRC
F8   DDAM
F9   ???
FA   ???
FB   DAM
FC   IAM
FD   ???
FE   IDAM
FF   IDAM

ijor
Hardware Guru
Hardware Guru
Posts: 3023
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Wed Sep 26, 2007 12:57 pm

DrCoolZic wrote:We all know that an IDAM is marked by an $FE !!!
But did anybody knew that $FF was also apparently interpreted as an IDAM ???...
Anybody knows about other "alternative" IAM IDAM DAM DDAM ?


Yes, it is well known, bit 0 is always ignored in the mark.
So $ff == $fe, $f9 == $f8, etc.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Wed Sep 26, 2007 3:28 pm

ijor wrote:Yes, it is well known, bit 0 is always ignored in the mark.
So $ff == $fe, $f9 == $f8, etc.
Very interesting. So many well known that I still do not know :oops:

So is it correct to have the following table ?:

Code: Select all

F5   write A1
F6   write C2
F7   write CRC
F8   DDAM
F9   DDAM
FA   DAM
FB   DAM
FC   IAM
FD   IAM
FE   IDAM
FF   IDAM

User avatar
megar
Atari maniac
Atari maniac
Posts: 85
Joined: Mon Nov 22, 2004 8:33 am
Location: East of France
Contact:

Postby megar » Wed Sep 26, 2007 6:13 pm

This informations are amazing ! I don't remember the Colorado game, I think I will investigate...

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Sat Oct 06, 2007 8:45 am

Hello some news and some questions ...

On the news front:
As you may know most of my documentation was based on collecting info, thinking and guessing ... apart from the fuzzy/weak bits and bits variation where I did lots of experiments.
So now it is time to confront the theory with the practice and therefore I started to analyze a batch of 100 diskettes with my protan program (as of today it checks for 21 of the protections described) ....
Very interesting: I crashed the program many times and ... found 5 more protections some of them are realy inventive and amazing ... Hold on I am documenting them ...

Now about question:
One of the games (Elvira from Accolade) gives results that do not make sense to me: on track 33 of diskette 4 the read track command get totally crazy: sometimes returns 62xx bytes (normal) but most of the time returns 12560 bytes! and even sometimes returns 20480 bytes!!!
In other words read track sometimes reads normally sometimes reads twice the tracks ans sometimes reads 3 time the track??? If you know that the read track is based on the index pulse (start with one and stop with the next) it does not make sense.
I originally thought that the track was unformated but
    1) seek verify would not work
    2) obviously would not be able to read correctly from time to time.
    3) read address works like a charm on this track.
    4) when the read track returns twice the normal number of bytes the "normal" buffer actually repeat itself (see attached doc)

Then I thought they were playing tricks on bits width/position ... but this could potentially result in more or less bytes reab but certainly not in the track content repeated two or more times ?????
I also read the track with the DC cartridge in flux transition mode and it returns what looks like garbage (lots lots of no flux/long flux transition to be more precise) .... need further analysis
I also tried to use pasti on the program and it chokes with "read track error ... cancelled by user"

While we are on the crazy side it looks like (not 100% reproducible) if you turn on the Atari put the diskette and read track 33 immediately you get correct results, but if you read other tracks before and now read track 33 you getting wrong results ????

Anybody has idea about what is going on ???
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Mon Oct 08, 2007 1:54 pm

DrCoolZic wrote:One of the games (Elvira from Accolade) gives results that do not make sense to me: on track 33 of diskette 4 the read track command get totally crazy: sometimes returns 62xx bytes (normal) but most of the time returns 12560 bytes! and even sometimes returns 20480 bytes!!!
It seems that it is a problem with the floppy disk drive !!!
I could read this track on another machine as well as analyze it with the DC cartridge.

Therefore I have changed, in my STe, the Epson SDM-380 FD drive by a Sony MP-F11W-5DU dive and things seems much better (except the drive is much more noisy).

I am still getting from time to time bad read on this track but only occasionally instead of the inverse. I am still trying to figure out what was going on. It looks like the FD drive is missing the index pulse from time to time on a read track, but why on track 33 of this disk only ???? This will probably stay a mystery.

So it seems that the problem was a combination of a marginal (?) diskette with a marginal (?) FD drive ???

ijor
Hardware Guru
Hardware Guru
Posts: 3023
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Mon Oct 08, 2007 5:50 pm

DrCoolZic wrote:One of the games (Elvira from Accolade) gives results that do not make sense to me: on track 33 of diskette 4 the read track command get totally crazy: sometimes returns 62xx bytes (normal) but most of the time returns 12560 bytes! and even sometimes returns 20480 bytes!!!


It's a bug on the FDC.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Tue Oct 09, 2007 8:45 am

ijor wrote:
DrCoolZic wrote:One of the games (Elvira from Accolade) gives results that do not make sense to me: on track 33 of diskette 4 the read track command get totally crazy: sometimes returns 62xx bytes (normal) but most of the time returns 12560 bytes! and even sometimes returns 20480 bytes!!!


It's a bug on the FDC.
Can you please elaborate on which condition this bug show up ? Special track/sector content ? Floppy drive problem ?
Even with my new floppy drive it sometimes gives wrong result, but this only happen on this track of this floppy, however has already mentioned sounds more like the drive is missing one index pulse ???????
I tried on 3 different systems and getting strange result on two of them ????

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Tue Oct 09, 2007 3:39 pm

I have question about a game call Ikari Warriors From Elite

The Track 1 has only one sector of 512 bytes. The sector has fuzzy bits and therefore does not read correctly.
I looked at the rest of the track (that is a GAP4 of over 5400 bytes!!!) and it is full of "random" bytes.
I did an analysis with the DC cartridge and found lots of MFM timings violations (short or long transitions) ... but I also found some $C2 and $A1 sync bytes with missing clock 8O
Anybody knows about some protections hidden in this game ???
Last edited by DrCoolZic on Fri Oct 12, 2007 2:48 pm, edited 1 time in total.

User avatar
woody.cool
Atari freak
Atari freak
Posts: 72
Joined: Mon Oct 08, 2007 7:06 pm
Location: Northampton, England (UK)

Postby woody.cool » Wed Oct 10, 2007 8:43 am

I don't know whether this was just luck, but I've copied numerous ORIGINAL Atari ST games in my Amiga 1200 using X-Copy Professional and to my surprise it has a high success rate!

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Fri Oct 12, 2007 2:47 pm

OK here we go for a new version ( v0.8 ) of the documents. Added 5 new protections ... The more interesting are sector within sector that allows to define tracks with 12 sectors or more and Sector Over Index pulse which is an iterresting variation of data over index pulse.
This is a major release with a lot of added information. What is new also is that most of the information has been verified on real original diskettes ...

Also publish is a first version of game protection doc based on my initial experiments. So far I have done about 40 games, because it takes alot of time ... These games are used to test my protan program and to show practical example in the doc. So it is a long process as for any large modification of protan I use the games as a regression test suite ... So some of them have been analyzed more than 20 times ....

Enjoy
Jean
You do not have the required permissions to view the files attached to this post.

Zenichiro
Atari User
Atari User
Posts: 38
Joined: Wed Jan 04, 2006 4:20 pm
Location: Liverpool

Postby Zenichiro » Fri Oct 12, 2007 5:18 pm

Is this information being added to the wiki? Maybe that would be a good idea?

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Copy Protection Information: Weak Bits, Bit-rate ...

Postby DrCoolZic » Fri Sep 24, 2010 8:04 am

Long time without information !!!
If you want to look at the latest version 0.9 of this document please goto http://info-coach.fr/atari/software/protection.php

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Copy Protection Information: Weak Bits, Bit-rate ...

Postby DrCoolZic » Mon Oct 31, 2011 3:20 pm

May 2006 first post ;)

New thread on the subject and new version of my protection document is available viewtopic.php?f=95&t=21952


Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 1 guest