|
 |
 |
 |
 |
|
 |
|
|
Author: Tom Wellicome
Date: 02-25-02 19:42
Hi
Call me rather stupid, irritating or just plain dumb but why cant someone write a program that can read protected ST disks. Surely if the ST can read the disk to load the game then similarly the ST could read the disk to copy it. I understand that as part of the protection routine disks were formatted to bizzarre numbers of tracks and sectors (in a way that would make a Mac + blush) but surely there must be some way of beating this. I've seen some programs that copy every nibble from the disk, but don't write the game back in the exact same way (i.e. any decent copy protection susses staight away) probably due to it being impossible to write it back in the same way. Surely however this would be less of a problem with a disk image?
Thoughts?
|
|
Reply To This Message
|
|
Author: Steem Authors
Date: 02-25-02 22:14
Hi,
I thought this too so I tried to write one. In theory it should work but at the moment it doesn't, the problem with disk protection routines is that if they don't work properly they are incredibly difficult to debug. I have absolutely no idea whether it is an emulation problem or some sort of disk imaging problem.
The good news is that an expert on disk protection has contacted me and is very kindly helping me to try and figure out what is wrong, so there is hope.
Russell Hayward
--
Steem - http://www.blimey.strayduck.com/
|
|
Reply To This Message
|
|
Author: Tom Wellicome
Date: 02-26-02 18:48
Blimey that is good news, it be much nicer to use originals if you do get it solved. Even if it were only a program that could read disks using the more generic protection routines like Rob Northen (or what ever his name was) than that would open up quite a few originals.
|
|
Reply To This Message
|
|
Author: Zippy
Date: 03-01-02 12:45
As well as cracking most ST disc protections over the years I also wrote some encryption/disc protection stuff too, so I guess I'm qualified to comment on this. :)
The biggest problem you'll have is timing... most of the major protection systems (eg. Rob Northen Copylock, Proto-scan etc.) used variable drive speed to make the disc "uncopyable" on a normal drive. The drive controller IC pulses the bits out to the drive head at a fixed speed - so by varying the spindle speed of the drive you could write long or short tracks, sectors or even groups of bytes within a sector.
This is all from memory (10 years ago!), so some of the figures may be slightly off, the theory is correct though... the ST drive ran at ~300 rpm, so by increasing that slightly (5% to 10%) you'd create a "short track", the index mark would come around quicker so the track would hold less bytes, but each byte would be physically "longer" on the disc's surface - so long as this was kept within reasonable boundaries the controller would still read it back in OK. Likewise with a long track, slow the drive down and the controller writes more bytes before the index mark comes around - the bytes are "shorter" on the disc, so come in quicker when reading back so you could fit maybe 10% extra on a track.
When checking protection on such discs there were a few methods - the basic one (eg. proto-scan) would be to create a buffer of say $2000 bytes of value $ff - then read the protected track (with a READ TRACK command to the disc controller - this reads the entire track with all sync bytes, sector markers etc.) into the buffer - then they'd start from the end of the buffer and count backwards towards the start until a value other than $ff was encountered - this would tell them how long the track was - if it was too short the protection would fail. No matter what sort of disc copier you used it's impossible to copy a long track in software alone, 'cause if the drive used for writing the track is running at 300 rpm (standard) it physically can't write all the data before the index mark comes around.
The "blitz cable" copier was good for copying that sort of protection though, 'cause it basically connected the destination drive directly to the source drive - so if bits were coming in quicker from a long track they'd be written out quicker too, likewise with short tracks - longer bits from short tracks would be recreated correctly even though the destination drive was still running at 300 rpm.
The more complex method of checking long/short tracks or sectors was to check the actual timing of bytes coming in from the controller. This is how Copylock worked... they would actually vary the drive's rotation speed WITHIN a single sector - so some bits would be physically different lengths on the disc's surface. They'd then compare/analyse eg., how quickly bits were coming in from the start + end of the sector in relation to the middle of the sector.
To get that working on an emulator would need a special reading program which was able to analyse + record (in the disc image file) the speed each byte was coming in from the disc controller - so that it could reproduce any differences accurately when loading the disc on the emulator. I'd imagine that would be very difficult to get working reliably, if it was possible on PC hardware at all... also, considering just about everything has been cracked and works on emulators anyways there doesn't seem much point in expending all the effort.
There's no foolproof way of reading data accurately off some of these protected sectors... they could be 256, 512 or 1024 byte sectors - or just be totally "special format" and have no sector headers or id's at all - eg. Maupiti island was like that - just one stream of data on each track (think it was something like $16d2 bytes per track).
Another nice one was War Heli - an old game but with really clever disc protection - they had duplicate sector id's on the same track - can't remember which sector was duplicated, say it was sector 2 - the track would look like - sector 1,2,3,4,5,2,6,7,8 - any normal program reading that is going to find the first sector 2, miss the second one then give a sector not found for sector 9. Reading it back in to check the protection was timing critical - they waited until sector 3 had just been read in (so sector 4 was currently under the drive's head) then requested sector 2 - they knew the "hidden" sector 2 would come around to the head before the "dummy" sector 2.
Anyways, what I've saying is that individual originals could be made to work with unique patches, but to get them all working would be very, very difficult - then again I never thought I'd see my sync encryption running on an emulator and someone managed that, so what do I know? :-))
|
|
Reply To This Message
|
|
Author: Zippy
Date: 03-01-02 12:52
Just re-reading that - I might have that wrong about copylock, it may not have changed the rotation speed within a sector, it might have been during one complete sector - so they'd compare the read timings for, say, sector 3 and 4 - sector 4 would come in quicker cause it was written as a long sector by slowing the drive down during writing, whereas sector 3 was written at the normall 300 rpm.
|
|
Reply To This Message
|
|
 |
 |
 |
 |
|
