Continuing the series on floppy copy protection, [GloriousCow] examines Electronic Arts’ Interlock system. This was used from 1984 to 1987 for at least fourteen titles released on both 5.25″ and 3.5″ floppies. Although not officially advertised, in the duplication mark sector the string ELECTRONIC ARTS IBM INTERLOCK. appears, hence the name. Compared to other copy protection systems like Softguard Superlok this Interlock protection poses a number of somewhat extreme measures to enforce the copy protection.
Other than the typical issues that come with copying so-called ‘booter’ floppies that do not use DOS but boot directly into the game, the protection track with Interlock is rather easy to spot, as seen on the right. It’s the track that lights up like a Christmas tree with meta data, consisting out of non-consecutive sector IDs. Of note is the use of ‘deleted’ sector data marks (DDAM), which is a rarity in normal usage. Along with the other peculiarities of this track it requires an exact query-response from the disk to be accepted as genuine, including timings. This meant that trying to boot a straight dump of the magnetic surface and trying to run it in an emulated system failed to work.
Reverse-engineering Interlock starts with the stage 0 bootloader from the first sector, which actually patches the End-of-Track (EOT) table parameter to make the ridiculous number of sectors on the special track work. The bootloader then loads a logo, which is the last thing you’ll see if your copy is imperfect.
Decrypting the second stage bootloader required a bit of disassembly and reverse-engineering, which uncovered some measures against crackers. While the actual process of reverse-engineering and the uncovered details of Interlock are far too complex to summarize here, after many hours and the final victory over the handling of an intentional bad CRC the target game (Murder on the Zinderneuf from 1984) finally loaded in the emulator.
After confirming the process with a few other titles, it seems that Interlock is mostly broken, with the DOS-based title ArcticFox (1987) the last hurdle to clear. We just hope that [GloriousCow] is safe at this point from EA’s tame lawyers.
Interested in more copy protection deep dives? Check out the work [GloriousCow] has already done on investigating Softguard’s Superlok and Formaster’s Copy-Lock.
Can I point out that the contents of this article were very interesting, but I have never seen magnetic floppy data visualized…it is insane that we can store that information; which was once magnetically encoded, decoded, rendered, and displayed on a monitor with a resolution less than our watch-faces now have; in a picture we can view fully on said watch-face…
To be fair, it’s mostly a just a pretty picture that represents the decoded data on the disk instead of the raw flux transitions, which are much too fine and closely packed to render well. Also, since the idea of encoding with MFM was to avoid any long periods without a transition, the actual flux data appears rather low contrast and not very interesting to look at, by comparison.
We used to do the same with CDs, DVDs and BDs. Scans took multiple hours, but the images were much higher res – they not just scanned data, but reflectivity and all kinds of other stats – scratches showed up clearly, and you could actually read fingerprints off the scan.
Back in the day — so long ago that any possible statutes of limitation have well run — I wrote a program to randomly modify the startup code of copy protected games on a C64 and then try to start them. That simple thing bypassed the copy protection on a number of games. There were side effects like loader screens having garbage but the games themselves were fine.
That was the lazy guy’s cracking method. Not really fast, but it worked and I could do it while reading a book or watching TV. I assume it relied on most games bolting on copy protection after development was complete, so one only had to bypass one critical section.
I stumbled on it by random.
I remember back in the mid ’80’s, a friend of mine, who had wealthy parents, had purchased a C64 cartridge with a switch that would dump the contents of memory to a blank floppy disk and make it bootable. The end result was a game that would load from the floppy without whatever copy protection scheme was in use, at the time. Like the ones that would cause the 1541 to click the head back and forth like it did when a read error occurred.
Electronic Arts (EA) copy protection for Atari 8 Bit computers holds a special place in my heart.
Back in the day I put in so much effort into defeating EA copy protection, but I was never able to figure it out and it always bugged me! (The one that got away…)
So about 10 years ago, I got an emulator and I got back to work. I was on a mission to finally figure out EA copy protection, and I wasn’t going to give up until I had succeeded! I wanted those cracked EA disks to boot exactly like the store bought version! (Showing the EA logo, going through the normal booting process, etc.)
There are a few different variations of EA copy protection. The 1st version mainly used timing to verify if it was a genuine disk. On an EA disk, the 1st sectors of each track are lined up (for example the 1st sector of each track is located at exactly 12 noon on the disk) But on a disk formatted on a standard Atari drive, the 1st sector of each track is located in a random position on the disk (And would fail the EA copy protection timing test)
The 2nd and 3rd versions of EA copy protection mainly used double sectors to verify if the disk was genuine. There is 1 track on the disk with a bunch of duplicate sector numbers. And the copy protection routine looks for data from both versions of each double sector. And of course, when you format a disk on a standard Atari drive, it’s not possible to format a disk with double sectors.
Eventually I managed to figure out how to defeat (trick) all the versions of EA copy protection, but there was still 1 problem. The copy protection routine also did a CRC check of the data in RAM to see if that data had been altered. And I just couldn’t figure out how the CRC check worked!
But I didn’t want to let that problem defeat me, so I attacked the problem using another method. Instead of trying to crack the CRC check, I left it unmodified. Then I wrote a stealth routine to “patch out” all the alterations I had made just before the copy protection did it’s CRC check (It passes the CRC check because the data was restored to what the CRC check was expecting to see)
It was a lot of work figuring out how EA copy protection worked on the Atari 8 Bit, but it was a fun learning experience! I had mainly wanted to crack one specific EA game, but after all the work I put in, I decided to crack the entire EA catalog just for good measure!
I had created a very unique “crack” which essentially left all the copy protection routines intact, but instead “tricked” the copy protection routines into believing it was a genuine disk.
And just for fun, I even included a secret “Easter Egg” in my cracks (When activated, the EA logo will cycle through all the colors during the boot process instead of remaining as a shade of blue)
Nice work! There were a lot more fun protections to be seen on other platforms. In some ways I am lucky I am writing a PC emulator, and there was only so much you could do with the standard PC floppy controller.
Google/blogspot prevents me from leaving comment on the blog :(
Thats a good point. Zenith also shipped a bunch of computers with debugger build into BIOS. I recently decompiled a Zenith Z-386 ZBIOS because it looked quite unique https://github.com/raszpl/Zenith_ZBIOS. MFM-300 Monitor portion totally uses 0E000-0F000h, Zenith calls it Slushware RAM.
You can play with MFM Monitor BIOS online on Jeff Parsons website at https://www.pcjs.org/machines/pcx86/zenith/z150/cga/