[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cracked Software
I seem to remember a discussion about EA game protection schemes at an apple
II user group meeting many years ago, and the consensus of opinion amongst
several of our 'code crunchers' was that the EA scheme comprised a nibble
count AND a track synchronisation scheme, the rattle heard is the heads
switching back and forth between two tracks. The catch was that it appeared
to us that EA were writing these two tracks with drive speeds set some %
faster than standard, resulting in less nibbles per track than there should
have been. Anybody trying to copy these disks with drives set on standard
speed would always end up with extra nibbles in the copied tracks, even
using copyIIplus etc., thus they were hard (But not impossible :-) to copy
properly. Just a recollection here, I could be wrong. The meeting was over
ten years ago.
Cheers
John M. Davies
David Empson wrote in message
<1dd3970.1aa2pkm2pe5mwN@dempson.actrix.gen.nz>...
>Steve Mentzer <!smentzer@ecom.net> wrote:
>
>> >
>> > Anyhow.....One type of protection that always intrigued me was the
>> >EA protection........ya know the clickity clickity click sound that
>> >popped up every so often. Anyone know how they did that? I'd love it
[snip-]
>When talking about GCR-formatted disks (5.25" in particular) "nibbles"
>are raw disk bytes, which are usually 8 bits. (In traditional usage, a
>nibble is 4 bits, not 4 bytes.)
>
>With 6-and-2 encoding (DOS 3.3 and later) there are about 66 8-bit
>values that can be reliably written and read back again by the disk
>controller.
>
>(The restrictions include having bit 7 set, no more than two consecutive
>zero bits, and only one pair of consecutive zero bits within a byte.)
>
>"Nibble counting" works on the principle of writing "illegal" nibble
>values. Reading the disk back in a traditional manner will not
>correctly read these illegal bytes, and a copy made from this will
>differ slightly from the original.
>
>The copy-protected program simply counts how many nibbles are present on
>the protected track (or tracks), and if it differs by more than a very
>small amount, then the disk is assumed to be a copy.
>
>I don't think nibble counting requires any special seek methods, though
>a technique as you describe could use nibble counting over a partial
>track. As you said, I expect it would be unreliable on disks that were
>out of tolerance for their rotation speed.
>
>--
>David Empson
>dempson@actrix.gen.nz
>Snail mail: P.O. Box 27-103, Wellington, New Zealand