In this case it didn't deter them either, because I became aware of a crack for Big Race USA that will happily play the game from a CD image. My "gaming" classic Mac is a Power Macintosh 7300 with a 800MHz Sonnet G4, an ATI Rage Orion (a Mac-specific 16MB Rage 128GL which has fewer compatibility problems with older games than the Radeons), a gig of RAM and two 18GB SCSI drives. That's more than enough space to save disk images for games and most of the games (that don't require redbook audio tracks) play from one, which is both faster and less wear on the optical drive. Big Race USA and Fantastic Journey both refuse to.
The Web runs a unique executable, but the others use a more or less common runtime. This gave me hope that Fantastic Journey could be broken in the same way that Big Race was. Let's have a look.
Power Mac executables are stored in the data fork in Preferred Executable Format, or PEF (parenthetically 68K apps classically used CODE resources, but CFM-68K apps can be in the data fork too). When we compare the crack and the original executable, they differ in exactly four bytes, or one PowerPC instruction. Here is the disassembly of the original function up to and including the change:
_check_protection: mflr r0 stw r31,-4(r1) stw r0,8(r1) stwu r1,-320(r1) bl .-340
Conveniently there are symbols in this build, so it's pretty obvious what this function is called and what it does. The first four instructions are consistent with a PowerPC function prologue; it then calls another function. This second function must be what does the actual CD check, because the crack replaces it with li r3,1. r3 is conventionally where the return value is passed, so we've just stubbed out the call and said that the check passed. That's enough to start the game as it never checks for the presence of the disc again.
Unfortunately the porters got smarter by the time Fantastic Journey was released because there are no symbols in the build anywhere. And because those leading instructions (assuming they're even using the same function in the same way) are very common — mflr would lead almost any non-leaf function — there are just way too many hits in the file to find our target. But there's another way around it. While riffling through the PEF string table I found both the CD's name (FJOURNEY) and the string .AppleCD. This string is the device driver the executable is looking for, or in other words, it's not enough just to have a volume mounted called FJOURNEY; it must be mounted using that driver to prove it's a disc. My preference for disk images on the classic Mac is Disk Copy, which directly mount on the desktop. I still had the non-working image of the Fantastic Journey CD, so I mounted it and fired up TattleTech to see what driver the volume was mounted as. It reports it as .HDI. The string .AppleCD only appears once in the entire file, so if this is our check, then that's where we do it. Note that there is a length byte directly before the string, so we change that to $04 from $08 and overwrite the first four characters with .HDI to change the driver. (This means that this executable will now only work with a disk image copy of Fantastic Journey. Sounds fine to me.)And with that, the game boots:
Let's get a few rounds in before bed. This principle probably works for other games too: if you only see a single .AppleCD string in the executable, you'll likely have success with a similar in-place patch. Take that, inconvenient copy protection.
No comments:
Post a Comment
Comments are subject to moderation. Be nice.