Two-disk replica of Prince of Persia
A recent discussion of a buggy crack for Lords of Conquest raised the issue of preserving the original bits from protected software.
So I'm exploring a different approach -- instead of patching games to bypass copy-protection code (ie: 'cracking') why not devise methods of satisfying the copy-protection checks without patching the code?
For example, the primary protection in Prince of Persia hides zero-bits between bytes on the disk, where they can't ordinarily be read or copied unless software intentionally manupulates the controller's state-machine to find it. Here's a sample from Beneath Apple ProDOS showing how the controller would ordinarily read the disk (top) and how the copy-protection detects a hidden pattern (bottom):
My own notes from that signature shows it as two columns of nibbles. The disk controller would ordinarily read the nibbles in the left-hand column, discarding the hidden 0-bits. The copy-protection routine synchronizes the controller so that it reads the nibbles in the right column, discarding the embedded 0-bits that would ordinarily be embedded in the middle of the
The hidden bits make the original signature difficult to copy, but it's possible to craft an easy-to-copy signature that satisfies the original signature check because the software merely verifies that it can extract the pattern
E7 FC EE E7 FC EE EE FC after it manipulates the controller's state-machine and receives an
EE "start" signal. In fact, it could be an ordinary data sector so long as it meets the copy-protection's requirements as follows:
- The sector starts with standard data-start
D5 AA AD
- There is a group of
E7 E7 E7nibbles that starts within the first 255 bytes, without any prior instances of E7
- There are some throwaway nibbles to give the program sufficient time to manipulate the controller's state-machine
- There is an
EEnibble to signal the start of the signature
- Immediately after the
EEnibble, the signature pattern follows
E7 FC EE E7 FC EE EE FC
All the nibbles used in the copy-protection are valid nibbles for ordinary data, so it simply entails intentionally making data that is recorded with a pattern that will bring the controller back into normal synchronization followed by data that would ordinarily be encoded with the nibbles in the signature.
One candidate for sector data would be:
00 AC 00 AC AC AC C0 10 E0 24 88 78 BC 10 E0 24 E0 10
When that data is 6-and-2 encoded, the RWTS transforms the top 6-bits of each byte into the nibble pattern:
96 E7 E7 E7 96 96 CB F3 FC EE E7 FC EE E7 FC EE EE FC
That pattern satisfies the copy-protection routine because:
- Upon reading the
E7 E7 E7nibbles, the copy-protection routine manipulates the controller's synchronization to force it out-of-sync
96 96nibbles pass by harmlessly while the copy-protection routine is adjusting controller's synchronization
- The nibble pattern
CB F3 FCcontains a bit-pattern 11001011 11110011 11111100 that forces the controller back into normal synchronization
- The rest of the data directly encodes as the
EEstart signal and the
E7 FC EE E7 FC EE EE FCsignature pattern
The result is a sector that's copyable, error-free, and still satisfies the copy-protection's signatgure check.
BONUS: because the sector is error-free, the rest of the sector is available to store data -- so long as we ensure that its 6-and-2 encoding doesn't accidentally store any
E7 nibbles prior to the impersonated signature. (The copy-protection routine is sensitive to that!) In this instance, I used the extra space to store a patch to fix a bug in Prince of Persia's KEYS routine, which affects gameplay when played on the keyboard on an Apple //e or //c. And I modified 6 bits of the boot sector to make it load the bonus sector and call the patch routine.
|Prince of Persia side A with KEYS bugfix and copyable-signature||227.5 KB|
|Prince of Persia side B with KEYS bugfix and copyable-signature||227.5 KB|