Ways how SW testing copy protection

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

Moderators: DrCoolZic, Brume

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 549
Joined: Mon Nov 04, 2013 5:23 pm

Re: Ways how SW testing copy protection

Postby JimDrew » Sun Nov 09, 2014 11:38 pm

Yeah, I should probably make an archive with the SDK and SCP image file format and make a link on the downloads page.
I am the flux ninja

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

Re: Ways how SW testing copy protection

Postby DrCoolZic » Mon Nov 10, 2014 1:45 pm

As you know there many games that use what I call shifted tracks.
Usually very hard to reproduce on real Atari and also causing problem for HW duplicators

If I remember correctly if you replicate all the sector but the track is not shifted the protection fails.
I would like to know how this is checked. It could be by measuring time to find position of specific sector on track but more probably by making a read track and looking at layout.
Times of lore is a good example of shifted track
timeoflore-layout.PNG

Notice also that side 1 has a very strange pattern but not part of protection?

The problem is that the disk imaged by Stefan viewtopic.php?f=102&t=26976&p=261528#p261528 has problems on track 70-72
However you might be able to test the generated stx to see how the "shifted layout" is tested?
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:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Mon Nov 10, 2014 1:50 pm

There is a protection that I call invalid character in gap
The game bob morane uses invalid char F7 between two sectors
bobmorane-intra.PNG

as well as a bunch of F7 invalid char at end of track.
bobmorane-inter.PNG


I would be interested to know how this is tested by the game.
I suspect a read track and then looking for F7 between the two sectors and at end of last sector?
You do not have the required permissions to view the files attached to this post.

User avatar
npomarede
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Ways how SW testing copy protection

Postby npomarede » Mon Nov 10, 2014 1:55 pm

DrCoolZic wrote:As you know there many games that use what I call shifted tracks.
Usually very hard to reproduce on real Atari and also causing problem for HW duplicators

If I remember correctly if you replicate all the sector but the track is not shifted the protection fails.
I would like to know how this is checked. It could be by measuring time to find position of specific sector on track but more probably by making a read track and looking at layout.

Different methods could be used :
- if all tracks contains sectors 1 to 10 in the same orders, then you can do a "force interrupt on index pulse", then immediately after do a "read sector 1" and measure how many time it takes to complete. Knowing the initial shifting algo and the current head's position, it's then easy to see if the delay to read sector 1 matches the expected layout.
- do a read track and search for a known pattern that is written at the beginning of each track : same here, you should find the pattern at a different position depending on the track number. If not, the disk is a bad copy.

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

Re: Ways how SW testing copy protection

Postby DrCoolZic » Mon Nov 10, 2014 2:23 pm

npomarede wrote:
DrCoolZic wrote:As you know there many games that use what I call shifted tracks.

Different methods could be used :
- if all tracks contains sectors 1 to 10 in the same orders, then you can do a "force interrupt on index pulse", then immediately after do a "read sector 1" and measure how many time it takes to complete. Knowing the initial shifting algo and the current head's position, it's then easy to see if the delay to read sector 1 matches the expected layout.


If I understand correctly time between index and end of read last sector? This should be more than 200 ms
In shifted track I have seen extreme cases:
- ID field starts just before index. So with normal read track you may miss the ID because char stuck in FIFO
- One that caused problem with Aufit was one or two a1 sync mark before index and real start of ID just after index!!! On real Atari do not expect to see anything for reason above.
And in emulator it is a pain because if you start "decoding" flux at index you wont find the fisrt sync mark and therefore just ignore the first ID
One of the reason you need multiple revolutions sampled ;)

Computer Hits Volume 2 (Beau Jolly) one to two sync mark on all tracks of disk 2 :)

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 549
Joined: Mon Nov 04, 2013 5:23 pm

Re: Ways how SW testing copy protection

Postby JimDrew » Mon Nov 10, 2014 9:13 pm

There are several Amiga programs that use this protection. These work fine with .scp image files under WinUAE, etc. With these programs, we use two revolutions in the image capture and the disk emulation uses the first revolution, the second revolution, and then back to the first.
I am the flux ninja

User avatar
npomarede
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Ways how SW testing copy protection

Postby npomarede » Mon Nov 10, 2014 10:11 pm

DrCoolZic wrote:If I understand correctly time between index and end of read last sector? This should be more than 200 ms
In shifted track I have seen extreme cases:
- ID field starts just before index. So with normal read track you may miss the ID because char stuck in FIFO

Having the sector's ID field in the last 16 bytes of a track is only a problem when you use "read track", but it won't prevent the WD1772 from finding this sector, so it's still possible to measure the time it took between receiving the index pulse in the status register and reading the whole sector.
- One that caused problem with Aufit was one or two a1 sync mark before index and real start of ID just after index!!! On real Atari do not expect to see anything for reason above.
And in emulator it is a pain because if you start "decoding" flux at index you wont find the fisrt sync mark and therefore just ignore the first ID
One of the reason you need multiple revolutions sampled ;)
Computer Hits Volume 2 (Beau Jolly) one to two sync mark on all tracks of disk 2 :)

Well, emulators are a different problem, it can depend on the method used to image the disk (store MFM data as in CTR/SCP, store result of a read track as in pasti, ...).
But on a real HW, it should be rather easy to check if the tracks are correctly shifted and if the floppy is a genuine one or a bad copy.

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

Re: Ways how SW testing copy protection

Postby DrCoolZic » Mon Nov 10, 2014 10:32 pm

All this is clear and corroborate what I think and written in my protection doc...
but if AtariZoll could have a look at the actual code it would be nice to confirm how this is done for example in times of lore or computer hits vol2

Would interested also to get confirmation about bob morane.
Under Steem seems like track 50 is accessed each time you hit play but again if not too difficult to analyze code ...

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

Re: Ways how SW testing copy protection

Postby DrCoolZic » Tue Nov 11, 2014 5:32 pm

Anybody can make image of Wizball Ocean Ed?
Preferably Kryoflux and 5 rev min
some interesting prot
thanks

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

Re: Ways how SW testing copy protection

Postby DrCoolZic » Thu Nov 13, 2014 5:13 pm

Thanks for information provided in this thread and others ...
I have updated the Atari FD protection document to version 1.3

Lot of work !!!
- Added detail analysis of protections on many new games that have been discussed recently on Atari Forum. Including ECO, Golden Axe, Jupiter Masterdrive, Maupiti Island, Obitus, Time of Lore, Vroom, Wizball, Z-out ...
- Now protection are grouped into two categories: data prot / timing prot
- Added Fuzzy track prot
- More details on Invalid ID field
- More details on shifted tracks
- Added write splice, Sync mark descriptions
- Chapter on preservation
- fixed lot of errors + clarification
...
document is too big to be uploaded (about 7MB) so directly available at http://info-coach.fr/atari/documents/_m ... ection.pdf

User avatar
kodak80
Captain Atari
Captain Atari
Posts: 436
Joined: Sat Nov 09, 2013 12:05 am
Location: Brisbane, Australia
Contact:

Re: Ways how SW testing copy protection

Postby kodak80 » Thu Nov 13, 2014 11:33 pm

Jean, the links don't seem to be clickable for me in the PDF. They are showing as blue and underlined but I cannot click on them to open the associated links. I am using Adobe Reader 11.

I thought it was about time I read this document and start to get an understanding of how the protection and floppy disks work.
Atari Falcon 030 | Atari 1040 STE | Atari 1040 STFM | Atari 1040 STF | Kryoflux & Supercard Pro Flux boards
Admin of Atari ST Review Magazine Archive: http://www.ataristreview.com

User avatar
Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2578
Joined: Thu Dec 15, 2005 2:15 am
Location: France

Re: Ways how SW testing copy protection

Postby Maartau » Fri Nov 14, 2014 12:08 am

DrCoolZic wrote:I have updated the Atari FD protection document to version 1.3


Nice job :thumbs: ...

kodak80 wrote:Jean, the links don't seem to be clickable for me in the PDF. They are showing as blue and underlined but I cannot click on them to open the associated links.


Same for me ...
Member of :
- aTaRi LeGeNd ,
- eLiTe ! ,
- NoExTrA .

[2017-10-18] & more...

-> "Cleaning/checking my ST mess " & "Back @ my (delayed) projects" <-
-> Slowed due to serious health troubles <-

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 549
Joined: Mon Nov 04, 2013 5:23 pm

Re: Ways how SW testing copy protection

Postby JimDrew » Fri Nov 14, 2014 1:15 am

Hmm... worked for me - using FIrefox.
I am the flux ninja

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

Re: Ways how SW testing copy protection

Postby DrCoolZic » Fri Nov 14, 2014 8:29 am

Sorry I messed up during word to pdf conversion and the hyperlinks were not converted properly
Problem is now fixed you should be able to get a working version following the original link. http://info-coach.fr/atari/documents/_m ... ection.pdf

Internal hyperlinks should now work. Tested with Acrobat reader and Pro as well as Chrome / Firefox and IE
Be aware that many browsers use cache for recently visited documents so you may need to do a refresh.
The document should now show version 1.3a

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

Re: Ways how SW testing copy protection

Postby DrCoolZic » Wed Dec 03, 2014 3:14 pm

For people interested in WD1772 emulation.
I was playing with Aufit2 prototype on some test cases and I came again across an interesting sequence. Not sure if used protection?

As you know normally WD1772 only reads id/data fields after exactly three $4489 sync marks. So 2, 4, etc wont work.
But there is an interesting case: exactly seven sync marks. So you have something like A1A1A1A1A1A1A1FExxxxxxxx
In that case it seems like the WD1772 reads the 3 A1 and expect an IAM as it receives an A1 instead it reset the ID sequence and therefore the following 3 A1 FE are detected as "normal" ID field :)
I have found this on Colorado and Panzer does read this ID but with a CRC error (Not sure if this is on purpose or not)
Not sure either if this is part of a protection as described in 2.1.16 Invalid sync mark sequence of my doc. Note that this ID is located a the very end of track (almost over the index)

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

Re: Ways how SW testing copy protection

Postby DrCoolZic » Wed Dec 03, 2014 3:39 pm

I was not reading the same bytes in Aufit2 and Panzer so I investigated.

I found that reading the same address with Panzer several time was returning different values???

I did the same with Aufit and got the same results
colorado_fuzzy_id.PNG

As you can see there are few bits "out of band" at the beginning of the ID and this is generating fuzzy values in the ID
The IAM / Track / Side are always the same but the sector number, sector lenght, and CRC are random ....
Not sure if done on purpose but this would be another case of fuzzy bytes. This time in ID ???
You do not have the required permissions to view the files attached to this post.


Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 3 guests