Ways how SW testing copy protection

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

Moderators: DrCoolZic, Brume

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 Feb 26, 2014 10:49 am

AtariZoll wrote:Yes, SW never expects specific data on concrete location in track dump (track read buffer). Usually $A1 is used as 'marker' . In case of Barbarian Psyg. there is 11x $FF, according to screenshot posted by DrCoolZic . So, it has +-5 bytes tolerance . I don't know is it really enough ...
What is most interesting in this case is STX image of game, available online: it is most likely made by Ijor self . Only 75 tracks are in STX, and there is no dump of track 0 at all ! Only 512 bytes of bootsector. Furthermore, there is no content shown on screenshot few posts above - the result of performed track read command in Steem Debugger. That content is btw. not correct track content, as there is lot of $FF further. So, only thing what I may assuming is that it is special hack for this particular title, edition. Performed after detecting specific conditions - like buffer address, content of bootsector, I guess.
And here may lie the reason why author is not much interested in publishing sources. Probably there are more similar hacks ..

I suppose you are referring to image provided in http://www.planetemu.net/roms/atari-st-games-stx
I have downloaded the images and yes they must have been done by Ijor as the "Tool" field is CC. This imply images done with Discovery Cartridge and this imager was never released ...
I have looked at the image using my PastiRead program (viewtopic.php?f=47&t=19904&start=25#p244419) and there is no track description for this track
Here the beginning of the dump:

Code: Select all

Pasti file version 3.0 Image Tool=CC - Number of tracks=75 - (0-15)
Track 00.0 6295 bytes 1 sect FuzBytes=No Flag=01  SDesc RecSize=544 (16-31)
   Sector T=0  H=0 SN=1   S=2 CRC=6FCA bitPos=700    Time=0     Flags=00    Off=0      (32-47)
   Start of Track data 48
      Reading Sector 1 512 bytes (48-559)
Track 01.0 6294 bytes 9 sect FuzBytes=No Flag=01  SDesc RecSize=4768 (560-575)
   Sector T=1  H=0 SN=10  S=2 CRC=2160 bitPos=702    Time=0     Flags=00    Off=0      (576-591)
   Sector T=1  H=0 SN=11  S=2 CRC=1053 bitPos=5614   Time=0     Flags=00    Off=512    (592-607)
   Sector T=1  H=0 SN=12  S=2 CRC=87CA bitPos=10526  Time=0     Flags=00    Off=1024   (608-623)
   Sector T=1  H=0 SN=13  S=2 CRC=B6F9 bitPos=15438  Time=0     Flags=00    Off=1536   (624-639)
   Sector T=1  H=0 SN=14  S=2 CRC=E5AC bitPos=20350  Time=0     Flags=00    Off=2048   (640-655)
   Sector T=1  H=0 SN=15  S=2 CRC=D49F bitPos=25262  Time=0     Flags=00    Off=2560   (656-671)
   Sector T=1  H=0 SN=16  S=2 CRC=998C bitPos=30174  Time=0     Flags=00    Off=3072   (672-687)
   Sector T=1  H=0 SN=17  S=2 CRC=A8BF bitPos=35086  Time=0     Flags=00    Off=3584   (688-703)
   Sector T=1  H=0 SN=18  S=2 CRC=FBEA bitPos=39998  Time=0     Flags=00    Off=4096   (704-719)
   Start of Track data 720
      Reading Sector 10 512 bytes (720-1231)
      Reading Sector 11 512 bytes (1232-1743)
      Reading Sector 12 512 bytes (1744-2255)
      Reading Sector 13 512 bytes (2256-2767)
      Reading Sector 14 512 bytes (2768-3279)
      Reading Sector 15 512 bytes (3280-3791)
      Reading Sector 16 512 bytes (3792-4303)
      Reading Sector 17 512 bytes (4304-4815)
      Reading Sector 18 512 bytes (4816-5327)

So if Past lib provides FF it must be a hack ...
But I am surprise by what this protection check.
All normal tracks will have a sequence of chars (usually around 12) interpreted as 00 or FF before the first sync. This sequence is there to allow a better synchronization of the phase lock look by providing maximum flux transition.
So it like "check that this track is normal"?

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

Re: Ways how SW testing copy protection

Postby npomarede » Wed Feb 26, 2014 11:49 am

DrCoolZic wrote:So if Past lib provides FF it must be a hack ...
But I am surprise by what this protection check.
All normal tracks will have a sequence of chars (usually around 12) interpreted as 00 or FF before the first sync. This sequence is there to allow a better synchronization of the phase lock look by providing maximum flux transition.
So it like "check that this track is normal"?

Hello

Barbarian STX (2 disks, psygnosis 1987) works under my work in progress version of Hatari (I can start a game, don't know if another protection is checked later ?), so if there's a hack, it's not at the emulator side in pasti.dll, since I don't use it at all and I don't know how it works internally.
Maybe the STX images were hand-crafted after their dump to give the correct results. Using the STX images as any other STX images is enough to have the game work, no special behaviour is necessary.

Nicolas

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 Feb 26, 2014 12:24 pm

npomarede wrote:Barbarian STX (2 disks, psygnosis 1987) works under my work in progress version of Hatari (I can start a game, don't know if another protection is checked later ?), so if there's a hack, it's not at the emulator side in pasti.dll, since I don't use it at all and I don't know how it works internally.
Maybe the STX images were hand-crafted after their dump to give the correct results. Using the STX images as any other STX images is enough to have the game work, no special behaviour is necessary.

Nicolas

I suppose you are using the stx version I from planetemu
Can you also try the version generated by Aufit https://mega.co.nz/#!AhInCZKB!b7QOhC0Hc ... oIk83Ce4Ik
This version includes read track with no special 00 oor FF and seems to run OK on Steem

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Wed Feb 26, 2014 12:31 pm

Well, it reads actually track 78 and not 0 . Pasti status gives false info in this case from some reason - there stays track 0 when giving track read command .
And there is track dump of 78 in STX, although content is not much like what is in RAM. But I don't know exactly how DC track dumps should be interpreted.
Would be good to see content of track 78 based on scp dump ...
All this track read test seems pretty useless, and real protection is in non-standard sector numbers ??
What Pasti supplies in case of track read command and 'inserted' ST image is:
TreadSTpasti.png

And what Steem supplies:
TreadST_Steem.png

By standard there should be 12 zeros before sector ID field and sync. seq.
I tried to change content of track 78 beginning in STX image, but it resulted in crashes only.
You do not have the required permissions to view the files attached to this post.
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

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

Re: Ways how SW testing copy protection

Postby npomarede » Wed Feb 26, 2014 12:38 pm

DrCoolZic wrote:I suppose you are using the stx version I from planetemu
Can you also try the version generated by Aufit https://mega.co.nz/#!AhInCZKB!b7QOhC0Hc ... oIk83Ce4Ik
This version includes read track with no special 00 oor FF and seems to run OK on Steem

Can't test it now, as mega.co.nz considers my browser to be "too old" on the PC I'm using. Could you upload it somewhere else ? Else, it will have to wait until tomorrow.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Wed Feb 26, 2014 12:54 pm

Here is it - I DL-ed after second try.
Content of track 78 seems same as in case of org. STX file. But Steem and Pasti act very weird, and it is really hard to follow what is really going on. Getting pretty different contents after reading track and inaccurate infos in Pasti and FDC status ..
You do not have the required permissions to view the files attached to this post.
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

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

Re: Ways how SW testing copy protection

Postby npomarede » Wed Feb 26, 2014 1:13 pm

AtariZoll wrote:Here is it - I DL-ed after second try.
Content of track 78 seems same as in case of org. STX file. But Steem and Pasti act very weird, and it is really hard to follow what is really going on. Getting pretty different contents after reading track and inaccurate infos in Pasti and FDC status ..

This version "barbarian d1.stx" is crashing ; from what I see in my debug under Hatari when parsing your STX, there's only track image, but not sector data ? I think sectors were supposed to be there, so there's something wrong that prevent the sector headers to be parsed (or maybe it's just a bug in my debug log ?)

Also, the working "Barbarian (1987)(Psygnosis)(Disk 1 of 2)[!][b].stx" has no track 74-77, and track 78 has only a track image, with no sector and a sync value of 0xffff, which is not seen before. Maybe this 0xffff has nothing to do with the protection, but this track was clearly imaged differently.

Track 78 is different too :

Code: Select all

Barbarian (1987)(Psygnosis)(Disk 1 of 2)[!][b].stx"
  track  74 BlockSize=6290 FuzzySize=0 Sectors=0000 Flags=00c1 MFMSize=6268 TrackNb=78 Side=0 RecordType=cc TrackImage=yes (6269 bytes, sync=ffff) Timings=0,0
    track image data :
        000000: ff ff ff ff ff ff 03 00 00 00 00 00 00 00 00 00    ................
        000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
       .... only "00"


Code: Select all

barbarian d1.stx
  track  78 BlockSize=6342 FuzzySize=0 Sectors=0000 Flags=0061 MFMSize=6324 TrackNb=78 Side=0 RecordType=0 TrackImage=yes (6324 bytes, sync=0000) Timings=0,0
    track image data :
        000000: 7f ff ff ff ff ff ea aa aa aa aa aa aa aa aa aa    ................
        000010: aa aa bd 5b ea aa aa aa aa aa aa aa aa aa aa aa    ...[............
        000020: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ................
        000030: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ................
        000040: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ................
        000050: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ................
        000060: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ................
        000070: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ................
        ... then some "aa", "ff", "bd", "5b", ...


Nicolas

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 Feb 26, 2014 1:15 pm

OK this make more sense as track 78 is very weird. Does not contains any sync mark and therefore read track returns different contents on different reads.
Track look like this
barbarian track 78.0.PNG

As noted track strats with few 00/FF characters, followed by a large portin with AA/55 chars, followed by 00/FF chars.
Auffit detects some FF in the first 8 chars but not consistent (could be considered as fuzzy bytes)
I have also looked at the content of the Pasti file generated by Ijor
here is the beginning:

Code: Select all

Track 78.0 6269 bytes with 0 sectors
00000  FF FF FF FF FF FF 03 00 00 00 00 00 00 00 00 00   ÿÿÿÿÿÿ..........
00016  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00032  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00048  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00064  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00096  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00112  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00128  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00144  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00160  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00176  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00192  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

So it also show some FF in first characters.
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 » Wed Feb 26, 2014 1:22 pm

I have also made images of barbarian with SCP and it gives the same results
barbarian track 78.0-content.PNG

As you can see some FF followed by 55 (same as AA but shifted ==> clock or data part of the MFM)


By the in term of STX image this probably works by accident unless Ijor has imaged several times until getting the wanted result. Reason is that only one read track is stored and could be 00 or FF
This is somewhat similat to Power drift and the fuzzy read track. Except that in Power drift the transition have been placed in position to generate fuzzy bytes where here it is more random ...

For Aufit on the 5 revolutions only one contains 0xFF all other revolutions contains 0x00 so there is a fifty fivty chance to get 0xFF in the STX image ;)
You do not have the required permissions to view the files attached to this post.

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

Re: Ways how SW testing copy protection

Postby npomarede » Wed Feb 26, 2014 1:39 pm

DrCoolZic wrote:For Aufit on the 5 revolutions only one contains 0xFF all other revolutions contains 0x00 so there is a fifty fivty chance to get 0xFF in the STX image ;)

There must be something else, else it would mean that when a regular player want to start Barbarian on his ST, he would have a 50/50 chance to get a 0xff or a 0x00 and the protection would fail ?

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Wed Feb 26, 2014 1:45 pm

Value 0 is OK too in checking routine - I just did not mention it, as had always $FFs there with STX .
In any case, something is weird with Pasti DLL and this - as it gives lot of $FFs instead 8 of them when Ijor STX is used.
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Wed Feb 26, 2014 1:51 pm

npomarede wrote:This version "barbarian d1.stx" is crashing ; from what I see in my debug under Hatari when parsing your STX, there's only track image, but not sector data ? I think sectors were supposed to be there, so there's something wrong that prevent the sector headers to be parsed (or maybe it's just a bug in my debug log ?)

Also, the working "Barbarian (1987)(Psygnosis)(Disk 1 of 2)[!][b].stx" has no track 74-77, and track 78 has only a track image, with no sector and a sync value of 0xffff, which is not seen before. Maybe this 0xffff has nothing to do with the protection, but this track was clearly imaged differently.


Nicolas

Sectors are there, and are OK. As said, they are with #s 10-18 .And STX made from scp crashes sometimes in Steem too.
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

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 Feb 26, 2014 1:54 pm

npomarede wrote:
DrCoolZic wrote:For Aufit on the 5 revolutions only one contains 0xFF all other revolutions contains 0x00 so there is a fifty fivty chance to get 0xFF in the STX image ;)

There must be something else, else it would mean that when a regular player want to start Barbarian on his ST, he would have a 50/50 chance to get a 0xff or a 0x00 and the protection would fail ?

Yes and this is why this is retried 10 times

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 Feb 26, 2014 1:59 pm

AtariZoll wrote:Value 0 is OK too in checking routine - I just did not mention it, as had always $FFs there with STX .
In any case, something is weird with Pasti DLL and this - as it gives lot of $FFs instead 8 of them when Ijor STX is used.

If 00 or FF is tested then it should be OK all time. STX always gives FF because it has been sampled that way

The characters 00 and 55 are both magic because when shifted they give respectively FF and AA. So there presence can be checked even without sync char ...

What is weird is that when decoding flux transitions either sampled with KryoFlux or SuperCard Pro I have regions with 00/FF and regions with 55/AA
but Ijor image only contains FF and 00 but no AA/55 ??? He may have played some tricks during imaging ?

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 Feb 26, 2014 2:09 pm

Actually I do not know if this is used but I nice protection would be to check presence of FF and AA or presence of 00 and 55 on a track that does not have sync.
Here is a bit more of the track as decoded by Aufit:

Code: Select all

Track 78.0 6324 bytes with 0 sectors
00000  7F FF FF FF FF FF EA AA AA AA AA AA AA AA AA AA   .ÿÿÿÿÿꪪªªªªªªª
00016  AA AA BD 5B EA AA AA AA AA AA AA AA AA AA AA AA   ªª½[ꪪªªªªªªªªª
00032  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00048  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00064  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00080  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00096  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00112  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00128  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00144  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00160  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00176  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00192  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00208  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00224  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00240  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00256  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00272  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00288  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00304  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00320  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00336  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00352  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00368  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00384  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00400  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00416  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00432  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00448  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00464  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00480  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00496  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00512  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00528  AA AA AA AA AB FE EA BA FF FF FF FF FF FF FF FF   ªªªª«þêºÿÿÿÿÿÿÿÿ
00544  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF   ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00560  FF FF FF FF FF FF FF FF EA AA AA AA AA AA AA AA   ÿÿÿÿÿÿÿÿꪪªªªªª
00576  AA AA AA AA BD 5F AE BF AA AA AA AB AA AA EE FB   ªªªª½_®¿ªªª«ªªîû
00592  EF EF FF FF FF FF FF FF FF FF FF FF FF FF FF FF   ïïÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00608  FF FF FF FF FF FF FF FF EA AA AA AA AA AA AA AA   ÿÿÿÿÿÿÿÿꪪªªªªª
00624  AA AA AA AA BD 5B EA AA AA AA AA AA AA AA AA AA   ªªªª½[ꪪªªªªªªª
00640  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00656  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00672  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00688  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00704  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00720  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00736  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00752  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00768  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00784  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00800  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00816  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00832  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00848  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00864  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00880  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00896  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00912  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00928  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00944  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00960  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00976  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
00992  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01008  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01024  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01040  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01056  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01072  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01088  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01104  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01120  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01136  AA AA AA AA AA AA AB FE EA BA FF FF FF FF FF FF   ªªªªªª«þêºÿÿÿÿÿÿ
01152  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF   ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
01168  FF FF FF FF FF FF FF FF FF FF EA AA AA AA AA AA   ÿÿÿÿÿÿÿÿÿÿꪪªªª
01184  AA AA AA AA AA AA BD 5F AE BF AA AA AA AB EA AA   ªªªªªª½_®¿ªªª«êª
01200  EF BA AE AF BF FF FF FF FF FF FF FF FF FF FF FF   ïº®¯¿ÿÿÿÿÿÿÿÿÿÿÿ
01216  FF FF FF FF FF FF FF FF FF FF EA AA AA AA AA AA   ÿÿÿÿÿÿÿÿÿÿꪪªªª
01232  AA AA AA AA AA AA BD 5B EA AA AA AA AA AA AA AA   ªªªªªª½[ꪪªªªªª
01248  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01264  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01280  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª
01296  AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA   ªªªªªªªªªªªªªªªª

As you can see you have short sequences of FF that repeats between long sequences of AA.
Hard to detect by a copy program but easy to reproduce once dtected.

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 Feb 26, 2014 2:16 pm

DrCoolZic wrote:
AtariZoll wrote:Value 0 is OK too in checking routine - I just did not mention it, as had always $FFs there with STX .
In any case, something is weird with Pasti DLL and this - as it gives lot of $FFs instead 8 of them when Ijor STX is used.

If 00 or FF is tested then it should be OK all time. STX always gives FF because it has been sampled that way

The characters 00 55 FF and AA are magic because this is the same sequence of flux transitions shifted

What is weird is that when decoding flux transitions either sampled with KryoFlux or SuperCard Pro I have regions with 00/FF and regions with 55/AA
but Ijor image only contains FF and 00 but no AA/55 ??? He may have played some tricks during imaging ?

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

Re: Ways how SW testing copy protection

Postby npomarede » Wed Feb 26, 2014 2:22 pm

AtariZoll wrote:
npomarede wrote:This version "barbarian d1.stx" is crashing ; from what I see in my debug under Hatari when parsing your STX, there's only track image, but not sector data ? I think sectors were supposed to be there, so there's something wrong that prevent the sector headers to be parsed (or maybe it's just a bug in my debug log ?)

Sectors are there, and are OK. As said, they are with #s 10-18 .And STX made from scp crashes sometimes in Steem too.

Yes, sectors are correct, it wast just an error on my side when looking at the dump.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Wed Feb 26, 2014 2:54 pm

DrCoolZic wrote:If 00 or FF is tested then it should be OK all time. STX always gives FF because it has been sampled that way
The characters 00 and 55 are both magic because when shifted they give respectively FF and AA. So there presence can be checked even without sync char ...
What is weird is that when decoding flux transitions either sampled with KryoFlux or SuperCard Pro I have regions with 00/FF and regions with 55/AA
but Ijor image only contains FF and 00 but no AA/55 ??? He may have played some tricks during imaging ?

Yes, I know that STX will give same track image always. But what is in STX track content and what shows up in Steem Debugger after track read is pretty much different. There is max 10 try, as Sauron noticed too, but he talks about track 79 and byte 30 - may be some little different release ?
Additionally, there is lot of inaccurate info in Pasti status, what I never experienced before. Possible that is result of hack used for this . So, tricks in image, and in Pasti.dll too ? :D
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

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

Re: Ways how SW testing copy protection

Postby npomarede » Wed Feb 26, 2014 3:03 pm

AtariZoll wrote:Yes, I know that STX will give same track image always. But what is in STX track content and what shows up in Steem Debugger after track read is pretty much different. There is max 10 try, as Sauron noticed too, but he talks about track 79 and byte 30 - may be some little different release ?
Additionally, there is lot of inaccurate info in Pasti status, what I never experienced before. Possible that is result of hack used for this . So, tricks in image, and in Pasti.dll too ? :D

As I wrote above, I don't think there's a hack in pasti.dll for this, else it would not work under my STX implementation for Hatari.
I think Ijor (or whoever made this stx) looked at the protection, saw it required some specific bytes just at the start of the track and included only those bytes in the STX file, leaving the rest of the track empty, as it's not tested by the protection anyway.

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 Feb 26, 2014 3:16 pm

npomarede wrote:
AtariZoll wrote:Yes, I know that STX will give same track image always. But what is in STX track content and what shows up in Steem Debugger after track read is pretty much different. There is max 10 try, as Sauron noticed too, but he talks about track 79 and byte 30 - may be some little different release ?
Additionally, there is lot of inaccurate info in Pasti status, what I never experienced before. Possible that is result of hack used for this . So, tricks in image, and in Pasti.dll too ? :D

As I wrote above, I don't think there's a hack in pasti.dll for this, else it would not work under my STX implementation for Hatari.
I think Ijor (or whoever made this stx) looked at the protection, saw it required some specific bytes just at the start of the track and included only those bytes in the STX file, leaving the rest of the track empty, as it's not tested by the protection anyway.

Yes I think the only important thing is the few bytes at start of the track.
This is why I wonder why the file I produce with Aufit don't work on Hatari?

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

Re: Ways how SW testing copy protection

Postby npomarede » Wed Feb 26, 2014 3:21 pm

DrCoolZic wrote:This is why I wonder why the file I produce with Aufit don't work on Hatari?

Protection expects 0x00 or 0xff at position 30, but with your file, it's 0xaa, so it fails.

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 Feb 26, 2014 3:39 pm

npomarede wrote:
DrCoolZic wrote:This is why I wonder why the file I produce with Aufit don't work on Hatari?

Protection expects 0x00 or 0xff at position 30, but with your file, it's 0xaa, so it fails.

I wander why it works fine with Steem?


Can you try this version generated from SCP file
Barbarian scp d1.rar


or this one generated from rev2 of the KF file
barbarian d1-rev2.rar
You do not have the required permissions to view the files attached to this post.

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

Re: Ways how SW testing copy protection

Postby npomarede » Wed Feb 26, 2014 3:53 pm

Barbarian scp d1.rar works :

Code: Select all

  track  78 BlockSize=6342 FuzzySize=0 Sectors=0000 Flags=0061 MFMSize=6324 TrackNb=78 Side=0 RecordType=0 TrackImage=yes (6324 bytes, sync=0000) Timings=0,0
    track image data :
        000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

Track only contains 0x00, so protection will succeed :) I'm not sure the dump of track 78 or its conversion to STX is correct, it's quite unlikely a read track returns only 0x00

Same for barbarian d1-rev2.stx, it works in Hatari :

Code: Select all

  track  78 BlockSize=6342 FuzzySize=0 Sectors=0000 Flags=0061 MFMSize=6324 TrackNb=78 Side=0 RecordType=0 TrackImage=yes (6324 bytes, sync=0000) Timings=0,0
    track image data :
        000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

But here also, track is empty, so there may be a problem in the STX conversion.

Nicolas

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 Feb 26, 2014 4:42 pm

npomarede wrote:Barbarian scp d1.rar works :

Code: Select all

  track  78 BlockSize=6342 FuzzySize=0 Sectors=0000 Flags=0061 MFMSize=6324 TrackNb=78 Side=0 RecordType=0 TrackImage=yes (6324 bytes, sync=0000) Timings=0,0
    track image data :
        000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

Track only contains 0x00, so protection will succeed :) I'm not sure the dump of track 78 or its conversion to STX is correct, it's quite unlikely a read track returns only 0x00

Same for barbarian d1-rev2.stx, it works in Hatari :

Code: Select all

  track  78 BlockSize=6342 FuzzySize=0 Sectors=0000 Flags=0061 MFMSize=6324 TrackNb=78 Side=0 RecordType=0 TrackImage=yes (6324 bytes, sync=0000) Timings=0,0
    track image data :
        000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

But here also, track is empty, so there may be a problem in the STX conversion.

Nicolas

Also looked strange to me so I have analyzed the files with the KryoFlux CTA anlyzer which is suppose to gives very accurate results ...
and indeed the data are read as 00 even though the MFM data (on the right of the screen) vary from aaaa to 8888
barbarian track 78.0-cta.PNG


If shifted by one bit the data value is changed to FF and 55 and MFM changed to 5555 1111
barbarian track 78.0-cta-shifted.PNG


So due to the nature of the MFM it is possible in this case to read 00 in all places except at the end of the track (with readPasti read the track and go to the bottom).
Reason why sometimes values show or not are due to the fact that there a small portion at end of track that changes (as can been seen on the scattered chart) and if index is slightly off the these FF moves from end of track to beginning of track.

I have clean the disk and redone SCP and KryoFlux images and I am now getting consistent 00 for most of track.
I have also discovered that track 72 of disk 2 does not read correctly (CRC error on sector 18 even after cleaning several times) so the image must be wrong.
However this is at the end of the floppy and it might take time to reach this sector?

But this is an interesting test case.
I will try to find similar track on other floppies. I now have the image of the scattered chart "somewhere in my brain" and I should be able to recognize it if it shows (very unusual and very peculiar) ;)

Also it is interesting to know that it works as I have included images of many tracks that are not output by Pasti DC.
You probably know but Pasti DLL has a nice feature. If the emulator is trying to read a track that has not been image (no track image record) then it open a warning window. This is only a warning and the DLL probably provide a "standard empty track image" in this case
You do not have the required permissions to view the files attached to this post.

User avatar
dlfrsilver
Atari God
Atari God
Posts: 1386
Joined: Mon Jan 31, 2005 1:41 am
Contact:

Re: Ways how SW testing copy protection

Postby dlfrsilver » Wed Feb 26, 2014 6:06 pm

DrCoolZic wrote:
npomarede wrote:Barbarian scp d1.rar works :

Code: Select all

  track  78 BlockSize=6342 FuzzySize=0 Sectors=0000 Flags=0061 MFMSize=6324 TrackNb=78 Side=0 RecordType=0 TrackImage=yes (6324 bytes, sync=0000) Timings=0,0
    track image data :
        000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

Track only contains 0x00, so protection will succeed :) I'm not sure the dump of track 78 or its conversion to STX is correct, it's quite unlikely a read track returns only 0x00

Same for barbarian d1-rev2.stx, it works in Hatari :

Code: Select all

  track  78 BlockSize=6342 FuzzySize=0 Sectors=0000 Flags=0061 MFMSize=6324 TrackNb=78 Side=0 RecordType=0 TrackImage=yes (6324 bytes, sync=0000) Timings=0,0
    track image data :
        000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
        000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

But here also, track is empty, so there may be a problem in the STX conversion.

Nicolas

Also looked strange to me so I have analyzed the files with the KryoFlux CTA anlyzer which is suppose to gives very accurate results ...
and indeed the data are read as 00 even though the MFM data (on the right of the screen) vary from aaaa to 8888
barbarian track 78.0-cta.PNG


If shifted by one bit the data value is changed to FF and 55 and MFM changed to 5555 1111
barbarian track 78.0-cta-shifted.PNG


So due to the nature of the MFM it is possible in this case to read 00 in all places except at the end of the track (with readPasti read the track and go to the bottom).
Reason why sometimes values show or not are due to the fact that there a small portion at end of track that changes (as can been seen on the scattered chart) and if index is slightly off the these FF moves from end of track to beginning of track.

I have clean the disk and redone SCP and KryoFlux images and I am now getting consistent 00 for most of track.
I have also discovered that track 72 of disk 2 does not read correctly (CRC error on sector 18 even after cleaning several times) so the image must be wrong.
However this is at the end of the floppy and it might take time to reach this sector?

But this is an interesting test case.
I will try to find similar track on other floppies. I now have the image of the scattered chart "somewhere in my brain" and I should be able to recognize it if it shows (very unusual and very peculiar) ;)

Also it is interesting to know that it works as I have included images of many tracks that are not output by Pasti DC.
You probably know but Pasti DLL has a nice feature. If the emulator is trying to read a track that has not been image (no track image record) then it open a warning window. This is only a warning and the DLL probably provide a "standard empty track image" in this case


If it's like the amiga version, barbarian from psygnosis exist in 2 flavours (i mean 2 versions with a different disk format, this could explaining that).

I think i have a set of disk for barbarian from psygnosis for atari ST, once my move is done, i'll check for my disks, and i will dump them for you :)
Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !


Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 1 guest