Ways how SW testing copy protection

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

Moderators: DrCoolZic, Brume

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

Ways how SW testing copy protection

Postby AtariZoll » Sun Jan 26, 2014 6:16 pm

I put thread in this section, but it is general copy protection, preservation related.
I see some nice SW which displays, analyses floppy images, images of copies, but I think that is useful to know how particular protection is tested in SW self. It will help to check is image really good, especially in cases of some delayed copy protection, what will be not activated with shorter tests.

There are some nice examples on Markus Fritze's site. http://www.sarnau.info/start#atari_st_s ... nformation
I want here some overview and maybe some list of interesting protections, and those which can be unnoticed with shorter tests.

In begin protections and tests were usually pretty basic. Common system was to have some track(s) with different sector count than normal tracks. SW tested sector presence usually with XBIOS #8 TOS call. Was pretty easy to crack, and possible to copy with better copy SW on Atari self.
As example I can give ECO (Ocean) . There are some tracks with only 1 sector, and unformatted larger area. DrCoolZic described it as weirdest tracks. Don't know was it because condition of floppy, or way how duplication is made, but in fact location of sector on track is irrelevant, since there is only test about presence of certain sector, and not presence of usual sectors.

SImilar, but better and harder to copy is when some special sector # is used - like $F7 - what is not possible to create by format on ST, because it is command to generate CRC. Present in many games. Example: Virus . Check may be via XBIOS too, as it is in Dungeon Master (but it has more protections).

By later games often code for protection check is well hidden, encrypted, so analyzing it is pretty hard. Even just listing all used systems would be long.

What is most interesting are so called delayed protections. It may be that protection check self activates only in later stages, but I saw more cases when check is done before play start, but in case of failing game will start normally. SW writes something somewhere, and if it is not correct, game will not work normally at some later stages - may be crash, diverse errors, or just not possible to go ahead, finish. And this is where bad images may pass shorter tests most likely. And that was exactly the goal of authors - Rob Northen self recommended to use it instead of simple compare and stopping SW to work. However, in bigger % of cases, according to my experiences tracing SW will show exact place where write occurs after protection check - in Case of Copylock it is easy to find end of check and writing self. Very late Copylock versions were nastier - writing was well hidden in decrypted part, so hard to detect.
I think that most useful would be some list of such protections.
Example: To Be On Top - problems will show only when entering specific rooms in game.

Hopefully some can add own experiences. I will add by time others ...
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
Brume
Red eyes
Red eyes
Posts: 4101
Joined: Mon Apr 22, 2002 10:16 am
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby Brume » Sun Jan 26, 2014 6:20 pm

Interesting thread, thanks for it :)
Do you have more examples of delayed protections?

gothmog
Atari freak
Atari freak
Posts: 53
Joined: Thu Apr 01, 2004 5:23 pm

Re: Ways how SW testing copy protection

Postby gothmog » Sun Jan 26, 2014 10:20 pm

I have fully reverse engineered Dungeon Master and Chaos Strikes Back for Atari ST. I have studied and documented the copy protection, cleverly mixed in the program.
Have a look here to download the source code: http://www.dungeon-master.com/forum/vie ... 25&t=29805

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

Re: Ways how SW testing copy protection

Postby JimDrew » Sun Jan 26, 2014 11:07 pm

That's pretty impressive. I know what it is like to reverse engineer something. I spent about 20 hours a day (yes really), over a rotating schedule of not knowing if the sun was setting or rising over an 18 month period to completely reverse engineer the Mac II hardware and Mac OS6, followed by reverse engineering OS7.x. This was necessary for creating my color Macintosh emulation. Of course, this was my job and I was getting paid to do this - something that you probably did not.
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 Jan 27, 2014 8:03 am

I am finishing up version 1.1 of my copy protection document. Since last version I have learned a lot so the document has more protections and more detailed explanations.

However the document is still on what protection mechanisms is placed on Floppy Disk and not on how they are used. So it is complementary to what Sarnau or Gothmog explain on their site.
For example I would just mention that a Rob Nothern protection can use a long sector with some hidden keys but not how this information is used.

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

Re: Ways how SW testing copy protection

Postby AtariZoll » Mon Jan 27, 2014 8:48 am

gothmog wrote:I have fully reverse engineered Dungeon Master and Chaos Strikes Back for Atari ST. I have studied and documented the copy protection, cleverly mixed in the program.
Have a look here to download the source code: http://www.dungeon-master.com/forum/vie ... 25&t=29805


I will look into it ... It would be second case of reverse engineering of DM/CSB - Paul R. Stevens did it earlier and made exact replica of Atari versions with CSB for Windows.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: Ways how SW testing copy protection

Postby AtariZoll » Mon Jan 27, 2014 9:30 am

DrCoolZic wrote:I am finishing up version 1.1 of my copy protection document. Since last version I have learned a lot so the document has more protections and more detailed explanations.
However the document is still on what protection mechanisms is placed on Floppy Disk and not on how they are used. So it is complementary to what Sarnau or Gothmog explain on their site.
For example I would just mention that a Rob Nothern protection can use a long sector with some hidden keys but not how this information is used.


My intention with this thread is exactly to write about 'complementary' to your documents - so SW side of protection checks. Unfortunately, I did not make any docs about copy protection checks what I saw, traced, so now can talk mostly from head. Actually, here I don't want to go in some deep analysis of used codes. Mostly to talk about them, and helping preservation.

Rob Northens usage of 'long sector' : I call it rather track read. And it is used in many other protections - for instance in Markus Fritze's ones ( Twinworld, Tom and Ghost) . The essence of protection is that there are some specific patterns written in sector gap space, and code for protection check seeks them, after track read command. First version of Copylock is based on that. What is special in Copylock is way how code is hidden from crackers - encrypted code, what decrypts on fly using CPU trace mode, and crypting back right after execution, so it is never visible.
Really good 'track with pattern protections' have patterns not writeable with regular ST HW.
Later Copylock (after 1990) is based on 1 sector written with lower density, and comparing read speeds. However it still uses track read before speed compare. Funny thing is that track read is pretty useless - pirate copy done with standard track format will pass check. Don't know what was R.N.'s intention with it - likely just to confuse, as most of code is.
Unfortunately, to go deeply in some better copy protection checking code needs lot of time. Much faster is to find way how to fool it :D
Recent case: Skate Wars from UBI Soft: uses XBIOS #8 to read some non-standard sectors, after that does track read and compares some values. If it is successful writes some values in RAM, which will be used later indirectly, so hard to trace. Main code is encrypted. With tracing in Steem Debugger it is not hard to see all crucial writes to RAM - in all 3 protection checks used. In any case, AUFIT converted it well from SCP to STX :D

@Brume: As said, I did not write down what saw. And saw about 20 cases of 'delayed protection' . Hopefully will doc them in future.
Bad Company from Logotron is one which uses it - and on later levels progress is impossible if protection check failed.
Btw. not only copy protections, but 'manual protections' can have same delayed effect. Probably most known case is Carrier Command .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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 Jan 27, 2014 10:54 am

Very interesting information.

AtariZoll wrote:Recent case: Skate Wars from UBI Soft: uses XBIOS #8 to read some non-standard sectors, after that does track read and compares some values. If it is successful writes some values in RAM, which will be used later indirectly, so hard to trace. Main code is encrypted. With tracing in Steem Debugger it is not hard to see all crucial writes to RAM - in all 3 protection checks used. In any case, AUFIT converted it well from SCP to STX :D

Would you have the SCP file available somewhere?

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

Re: Ways how SW testing copy protection

Postby AtariZoll » Mon Jan 27, 2014 12:39 pm

StefanL uploaded it to Atarimania ftp, and it is still there. Login parameters: url: ftp.atarimania.com , user: atarimania , pasw: atarimaniaftp .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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 Jan 27, 2014 1:41 pm

got it thanks 8)

jok
Atari freak
Atari freak
Posts: 72
Joined: Wed Dec 19, 2012 3:06 pm

Re: Ways how SW testing copy protection

Postby jok » Tue Jan 28, 2014 8:45 am

gothmog wrote:I have fully reverse engineered Dungeon Master and Chaos Strikes Back for Atari ST. I have studied and documented the copy protection, cleverly mixed in the program.
Have a look here to download the source code: http://www.dungeon-master.com/forum/vie ... 25&t=29805


Wow, wow wow. Just browsed through the archive and I am very impressed! Incredible effort!

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

Re: Ways how SW testing copy protection

Postby AtariZoll » Tue Jan 28, 2014 10:25 am

I just looked why Power Drift fails with Pasti . Details here: viewtopic.php?f=47&t=25997
So, if I'm correct this can't be converted to working Pasti image. Talking about 3 floppy release (even if 3rd is not needed with DS drive).
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: Ways how SW testing copy protection

Postby AtariZoll » Mon Feb 24, 2014 9:31 am

James Pond , GBH edition: protection self is nothing special, but fact that it is with 11 sectors/track, so some 880KB DS floppy, while real data of game is only some 340KB . There are many fake files . I guess that aim was confusing crackers + making copies unreliable .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
Stefan jL
Atari God
Atari God
Posts: 1235
Joined: Thu May 09, 2002 3:21 pm
Location: Sweden
Contact:

Re: Ways how SW testing copy protection

Postby Stefan jL » Mon Feb 24, 2014 4:57 pm

hehe.. my copy of James Pond (GBH) has a part of the game Lotus (dont remember wich one of the three though) that you could even load and see loading screen and hear music before it crashes :)
Image

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 Feb 25, 2014 5:18 pm

I need help on Barbarian protection
First my version of barbarian is a two disks version. It seems that there is a one disk version? I got an IPF of this version and it crashes Steem :(

Protection reported by Markus http://www.sarnau.info/atari:protection_barbarian
On my two disks version Track 1.0 is a one sector track ... seems normal apart from maybe characters at the end:
one sector (loader?) followed for the rest of the track by 0x12 bytes but close before end of track there is an A1 sync followed by 8 0x09 char followed by bunch of 0x00

look like this
barbarian-end-track-0.0.PNG

are these characters used???

Markus reports test on track 79.0 For me the track looks unformatted?
barbarian-track79.0.PNG


Can someone "decode" the protection?
You do not have the required permissions to view the files attached to this post.

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: Ways how SW testing copy protection

Postby IFW » Tue Feb 25, 2014 6:16 pm

Have you tried Hatari?

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: Ways how SW testing copy protection

Postby IFW » Tue Feb 25, 2014 6:17 pm

btw: the only Barbarian IPF that comes from SPS is the Palace game on 1 disk; anything else you may have is home-made...

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

Re: Ways how SW testing copy protection

Postby AtariZoll » Tue Feb 25, 2014 6:32 pm

Barbarian (Psygnosys) has pretty basic test: track 0 read and checking is byte pos. $1C = $FF . Later data not tested . In STX no track 79 image at all.
Another part of protection is that tracks are with sectors #s 10-18 .
barbtread.png

Hardly that there is single floppy release of Barbarian Psyg. - older game.
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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 Feb 25, 2014 6:54 pm

IFW wrote:btw: the only Barbarian IPF that comes from SPS is the Palace game on 1 disk; anything else you may have is home-made...

Humm I wiil have to check where I got that from. Does not load either on Hatari

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 Feb 25, 2014 6:57 pm

AtariZoll wrote:Barbarian (Psygnosys) has pretty basic test: track 0 read and checking is byte pos. $1C = $FF . Later data not tested .
Hardly that there is single floppy release of Barbarian Psyg. - older game.

Sorry but I do not understand byte in $1c = $ff
1c of what? if read track answer is no if read first sector answer is no ???

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

Re: Ways how SW testing copy protection

Postby AtariZoll » Tue Feb 25, 2014 7:10 pm

DrCoolZic wrote:Sorry but I do not understand byte in $1c = $ff
1c of what? if read track answer is no if read first sector answer is no ???

It means byte at pos. $1C, so hex. 1C from track read buffer start. Or 29-th byte of track read.
As is shown in memory dump there is lot of $FF around. It must be visible at start of track.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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 Feb 25, 2014 7:53 pm

AtariZoll wrote:
DrCoolZic wrote:Sorry but I do not understand byte in $1c = $ff
1c of what? if read track answer is no if read first sector answer is no ???

It means byte at pos. $1C, so hex. 1C from track read buffer start. Or 29-th byte of track read.
As is shown in memory dump there is lot of $FF around. It must be visible at start of track.

I understand that 1c = 28 but character at position 28 is well before sync in the pre-index gap and no sign or no chance to read FF in this area.
The first FF (or 00 depending of bit shift) is at about 54 ???
This sound like what Markus was saying with apparently wrong track
This seems quick and simple: Byte 30 in Track 79 has to be either 0x00 or 0xFF. Maximum of 10 tries to figure that out…

So something else should happen when loading bytes in memory ????

Here is start of track
barbarian-start-track-0.0.PNG
You do not have the required permissions to view the files attached to this post.

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

Re: Ways how SW testing copy protection

Postby AtariZoll » Tue Feb 25, 2014 10:18 pm

Of course that it is before first sync, so before first and only sector - that's the point of protection. And bootsector is easy to copy as it must be regular.
I guess that WD1772 needs some time from index pulse to start track reading, therefore is difference . You should look some track dumps in Pasti images - which are made with WD1772 and compare them with scp track dumps - then will see average delay .
As may see, first $FF in pasti track dump is at pos. 8 .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

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

Re: Ways how SW testing copy protection

Postby JimDrew » Wed Feb 26, 2014 3:12 am

I am sure that there must be some space between the start of the track and the first bytes used after the index to accommodate for the differences between drive's index sensors.
I am the flux ninja

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

Re: Ways how SW testing copy protection

Postby AtariZoll » Wed Feb 26, 2014 7:44 am

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 ..
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.


Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 2 guests