Zippy was one of the most high-profile crackers on the Atari ST scene as a member of the Medway Boys and later Cynix. Zippy was responsible for creating more than 100 compilation disks (known as "menus" on the Atari ST). Thanks must go to Marco Breddin from www.microzeit.com for his "Borders" book trilogy that inspired this interview and provided the nostalgia trip that kept Zippy adding to it for the last 2 years. If you're at all interested in the Atari demo scene you can purchase his books from the Shop section on his website.
What was your first encounter with the Atari ST and the reason you bought it?
It all started with a ZX81 in 1981 and when I got a BBC micro a few years later I'd really become quite obsessed by all this new technology and just being around it and using it. Even at that time in the early 80's I think I'd already decided that I'd rather spend the day in a room full of computers than a room full of people, haha :)
Luckily my school did have a room full of BBC micros but there was no programming teacher or any sort of computer qualifications on offer. Playing with computer code was about all I was good at or interested in so after a personal meeting with the headmaster I was allowed to sit 4 college level computer modules (including a programming project), on my own, over 1985/86. It was around that time my parents gave me the "Computer Hacker" mug (see pic) for my birthday, maybe that was inspiration for what was to come later!
I didn't do too well on most of my other exams but I passed the 4 computer modules and so in 1987 was able to get a place on a 3 year computer course at college. It was amazing just how few people in my college class were already into programming or even had a computer at home, so I quickly hooked up with the one guy who seemed as enthusiastic about it all as me and it turned out that he owned one of the very early Atari 1040STF's (with single sided drive) that he'd bought to play with the new GFA Basic.
So it would be late '87 that I first saw an ST and when he showed me Defender of the Crown and Dungeon Master I was so impressed that I knew I had to get one for myself. I remember not even believing it at first when he said the ST was only displaying 16 colours as it looked so much better than the 8 colour BBC games! Of course the offer of piles of free software made the ST even more attractive and a few months later, around spring '88, I traded in my entire BBC system against a 520STFM "Super pack".
Looking back now it seems that if GFA Basic had been released first on the Amiga rather than the ST then I'd probably have ended up with an Amiga and a lot of things would have turned out very differently. When I had an Amiga for a while a few years later I really didn't get into it at all. The one thing I remember was when we linked up the two machines with a serial cable to play Stunt Car Racer... on the long straights the ST car would pull away from the Amiga car, presumably because it was a 3D game and the ST had a slightly faster processor. :) As for my college course, when it ended in 1990 only 5 of us (including me and my mate with the ST) out of a class of about 25 passed the final exams at the first attempt, so I guess having a computer at home really did help even if you were staying up to 5am hacking games on it!
Why did you call yourself Zippy?
I never used a name for the stuff I did on the BBC as it was really only spread through friends and at the local computer club, which at that time around the mid 80's was basically a room full of geeks copying software for 3 hours once a month. The other systems like the C64 and Atari 8 bit machines apparently had more of a scene with hack groups and intros but as I came to the ST from the BBC I'd really seen very little of that stuff.
I didn't use any name on the ST at first either, but later when I saw that everything was being spread with a group name/intro I wanted to be part of that and so thought of a silly name for myself, "Zippy", from the character in the kid's TV show Rainbow. I also used some other names (like "Mighty Clog" and "Milky Bar Kid") just for a change and to make it look like there were more members in the group and later in Cynix I mostly used the name "Absu" (from the Necronomicon). I probably used about 8 different names in total.
When and how did you start cracking in general? And on the ST?
The very first "crack" I ever saw was published in one of the Acorn computer magazines (Acorn User or Micro User), a few lines of machine code that disabled the copy protection on the BBC tape version of Elite. I was totally fascinated by the idea of understanding a computer so intimately that you could do something like that with just a few lines of code. It would be a while before I understood how it worked (it toggled the end of file flag on each data block via an interrupt), but it surely started my interest in "cracking".
By about '86 or so I'd done a fair bit of hacking on the BBC myself (mostly tape to disk hacks, trainers and menus) and was more interested in that side of things than the games themselves. To the point where I'd come home with a new game and load up the disassembler to check out the game boot code and look for any encryption or protection before even loading the game properly for the first time. It was the same on the ST later, where cracking the protection was usually more challenging and fun than playing the game. Effectively that was the "game" contained on that disk for me.
One of the early hacks I did on the BBC was a version of AMX Super Art, a paint program that worked with the AMX mouse which was a pretty amazing bit of kit for a kid to be playing with in the mid 80's. Super Art was a disk only program and too big to fit in RAM all at once. I didn't have a disk drive for my BBC at the time, but a neighbour who worked at the IBM plant in Greenock had let me copy all the Super Art files to tape on his system. By hacking the boot and file loading code I was able to put together my own version that ran from expansion RAM/ROM and even loaded faster than the original disk version. As with the copy protection hacking later, it was all about the challenge of getting around artificial restrictions in the software to make it do what I wanted on my hardware.
(Apparently there was a group of BBC micro guys at IBM Greenock in those days who copied all kinds of BBC software and even the full manuals, as my neighbour had given me piles of both. I can still clearly remember every page overlaid with "IBM GNK" from their photocopiers! His son was in my class at school but he really wasn't that interested beyond playing a few games, so I'd go around there just to talk to his dad about computers... nowadays someone would be calling in a squad of social workers, cops and lawyers to investigate what we were up to, haha. I saw the guy from IBM in the street a few years back and made a point to thank him for all the stuff, saying that he'd probably done more for me than any teacher or lecturer ever did!)
When I got the ST I really wasn't thinking much about hacking at all, the software I had then was just copies of unprotected stuff, or maybe the few games that could be copied with ACopy or Pro-Copy, but I still hadn't seen any cracked games with intros at that point.
The first game I hacked on the ST was the strategy game Empire. A few of us had bought the original game together and it had a manual protection, but somehow either the printed manual or disk was the wrong version and no matter how many times we tried entering words from the manual the game wouldn't play on any of our ST's. I had a copy of the disassembler MonST that I'd never used and knew almost nothing about the ST hardware but I had my "ST Internals" book on hand to explain the 68000 instruction set and the OS "Trap" calls, so thought it was worth taking a look before returning the game to the shop.
Luckily there was no "anti-hacker" protection on the program file at all and so within a few hours of tracing through the code the game was hacked and the manual protection bypassed. I just edited the file using Disk Doctor and wouldn't have known how to add an intro to it even if I'd wanted to. Having hacked that one relatively easily I thought maybe this was something I could start doing again on a small scale on this new system as the 68000 instruction set seemed so elegant and really was a joy to work with. (As an aside, I only ever hacked one game on the PC as looking at x86 code is really no fun at all and would give anyone a permanent headache).
Around that time in late '88 I got talking to another guy with an ST from one of the other computer classes at college and he gave me some disks that changed my entire life with the ST. The main 2 disks were LSD/Was (Not was) menu 25 with IK+ and Pacmania and the Was (Not was) single disk crack of Giana Sisters where his loader and text file explained in detail all about the protection and how he had a laugh over a few beers while cracking it. The 68000 source code file for the crack loader was also on the disk. I'd never seen anything like that stuff before and thought it was just the coolest thing I'd ever seen.
For a nerdy, rebellious kid who was into all the 80's underground hardcore/punk music (bands like Bad Religion, DRI, Suicidal Tendencies and Agnostic Front) but had no musical (or social) skills, I guess this underground hacking scene was the next best thing to being in a punk rock band. Hell, I even got "Medway Boys", "Cynix" and Atari logo tattoos, haha. :) From the moment I saw that Giana Sisters crack I wanted nothing more than to be part of that scene and see if I had the skills to match what those guys were doing.
The crack loader itself started up with:
Cracked by Was (Not Was) I am the best. If you don't agree then I shall wait for your cracked version of GIANA SISTERS. and wait ... and wait ... and wait ... and wait ... and wait ... and wait ...
With each "and wait ..." appearing gradually as it loaded the 6 data files from disk.... pure genius!
I think it's also worth quoting most of the text file here too, as it's a great snapshot of those early days of the ST hacking scene:
You can see where I got the line "Do I make it sound easy... It wasn't!" for my War Heli crack years later, that was me saying to myself that I'd finally equalled those guys and so it was OK to bullshit at the same level. Of course all that bullshitting was just "playing to the crowd" and I don't think any of us really took it seriously. If you were there at the time you knew it was all meant in good fun and certainly it was always friendly when I met or talked to anyone from the other ST groups, despite what was sometimes said in scrollers. The ST scene probably wasn't big enough for any real animosity between the groups, the heart of it consisting of no more than 3 or 4 dozen guys at any one time, though there did seem to be some harsh words exchanged by some of the French guys at times.
The guy who gave me those first few disks said that this stuff was being sold openly for a few quid every weekend at the "Barras" (Barrowland) market right here in Glasgow, so my next step was to check that out. I should explain a little about the "Barras" market for those who don't know it. I'll just quote a current review I found on yelp.co.uk as it sums it up very well, especially at that time back in the 80's... "The Barras is a large indoor and outdoor market, now famous for dodgy characters, knock-off goods and Glaswegian banter". :)
A few years later FAST (the Federation Against Software Theft) would describe Glasgow as "the European capital of software piracy", with their chief executive Bob Hay saying "There have been a number of enforcement problems in Scotland in general, and Glasgow in particular." By that time there were 10 or more stalls openly selling hundreds of pirate ST and Amiga disks at the Barras every weekend, mostly around Gibson Street next to the famous Barrowland Ballroom. And there were a number of other similar, but smaller indoor markets around Glasgow too, most with pirate software for sale. I guess being the piracy capital was at least a step up from being known as the European murder capital!
Some of the commercial software pirates distributed leaflets after one of the usual Christmas-time police raids, announcing the end of piracy at the Barras and delivering a lengthy rant against the industry, politics and the media. Of course they were back the following week as usual. Included in the high-res scans is a contemporary newspaper clipping about FAST and police investigations against piracy at the Barras.
How did you end up joining the Medway Boys, and when was this?
By early '89 I'd got to know a few of the characters at the Barras and had worked out which guy had the best contacts for ST stuff, but I was still amazed when one day he casually mentioned that he was directly in touch with the Medway Boys down in Kent (the Medway being a river in SE England) and was even mentioned on the intros as "The President".
I couldn't ignore that opportunity so a few weeks later I'd managed to get a contact number (for "Wurzel" as it turned out, the guy who started the Medway Boys on the Commodore 64 and then switched to the ST in September '86) and during that first conversation I was accepted as a member and would start releasing stuff under their name. Even talking to someone else about hacking games was pretty amazing at that time and it felt special just to talk to the guy who'd created the famous Medway Boys boot sector virus protector.
Medway Boys menu 9 was the first one I released and pretty soon I basically took over putting the menus together as I was able to get hold of the original games much quicker than the other 2 guys. They still released the odd menu after that (hence there are 2 menu 13's) but mostly they'd just send me their stuff occasionally and I'd include it on the menus.
I met "Birdy" (from SCC - The Scottish Cracking Crew) at the Barras a few times and could maybe have joined up with him but the Medway Boys were more established and had a better reputation, plus it seemed like no one would ever be looking for the "Medway" Boys in Scotland, which was a bonus! :) "Birdy" was a good guy though, very laid back and seemed to treat the whole scene as just a bit of casual fun, unlike some of the rest of us who probably took things a bit too seriously at times.
I never did find out how "The President" got to know "Wurzel" in the first place... like a lot of stuff at the Barras you quickly learned to just accept things without asking too many questions. And sometimes one question was too many. :) It really was a unique time and place. When the cops weren't raiding the place (which happened occasionally, mostly around Christmas) some would be down there themselves for pirate software, sometimes even in uniform... those particular guys had no taste though, they had Amigas!
There was an ex-military guy (a Falklands war veteran from the Royal Marines) who was hired as "security" by one of the pirate stallholders. He soon saw how much money was being made and quit to open his own stall in the same building a few weeks later! Another time one of the stallholders arranged with all the others that from the following weekend they'd have a set minimum price for each disk... then he had his son open a new stall undercutting them all. I went on a road trip with one of the guys to meet some contacts down in England once and after I'd offered to take a turn of driving noticed immediately that the speedometer wasn't working. When I mentioned it the reply was "I know, I always unplug the sensor on the gearbox before long journeys to keep the mileage down", haha.
One of the guys who had a great sense of humour had a routine for whenever someone with a bad attitude returned a disk where they said a game didn't work on a late level. He'd say "I'm sorry to hear that, I'll tell you exactly where you can get a fully working version... go out of here down the stairs, take a right at the bottom onto Gibson Street, turn left at the end and walk along for about 10 minutes. When you're outside the Virgin Games store in Argyle Street go in and give them £25 and they'll give you a fully working copy". Or sometimes he'd say "Sorry, complaints department is only open for one day per year and unfortunately it was yesterday!". :)
One time I was offered an almost new laser printer that was still full of the letterheaded paper from the nearby office it had just been stolen from. All this was just a typical weekend at the Barras. With all the dodgy stuff going on I have to say that none of those guys ever did me a bad turn. Like I said... a truly unique time and place. A couple of quotes from early 90's computer magazines highlight some of the attempts to combat piracy at the Barras:
It's very different there today, some parts have been cleaned up and a lot of it has been demolished, replaced by new flats and businesses. By the end of the 90's that open, uncontrolled piracy of the Barras had basically shifted to the internet, with services like Napster and sites like Newzbin appearing out of the chaos, at least until the momentum of the authorities and legislation eventually caught up with them too.
Describe your group chemistry...
I mostly talked to that one guy ("Wurzel") but only ever met him once. I was down in London for a computer show in 1990 and had arranged to take a train out to his place in Chatham (on the river Medway), but with me not understanding the English accent of the train station announcer too well I ended up on a train to Chartham instead, haha! So by the time I realised the journey was taking much longer than expected, got off the train and walked to another station to get back to Chatham, I ended up only meeting "Wurzel" for a couple of hours before I had to head back to London.
"Wurzel" was a really laid back guy with a great sense of humour, as you can see on an early version of the "Gamecracker" (that targeted Rob Northen's Copylock protection) where he said "This program is Public Domain and is endorsed by BOB HAY (FAST) and ROB himself ". :) As we lived at opposite ends of the country there really wasn't any direct interaction, but we'd talk on the 'phone about code and ST protection stuff and would send disks back and forward regularly. The other original Medway Boys member ("Trojan") lived in Brighton but I never met him and we only talked on the 'phone a few times.
For those early menus we had no artist or coder, unlike some of the bigger groups, so it was mostly just me throwing together whatever I could for a menu and the quality wasn't great, but the goal was simply to get the games out there and copyable ASAP so it didn't seem to matter too much what the menu looked like. A little while later I met an ST artist ("P. Crawford") at the Barras and you can see his stuff from menu 24 to 49 where things started to look a bit better. He only did about 10 pictures so I re-used them a few times, but some like the "Eddie" (Iron Maiden) ones were really memorable.
From menu 50 "Wizpop" had joined and the menu graphics reached a new level, with a lot of his work over the next 50 menus being some of the best stuff I'd seen on the ST. My coding skills improved over that period too so things were looking a bit more "professional" and comparable to other groups, though I must admit I did overdo it with that crappy "picture flipping" menu code. :) "Wizpop" was another guy from the London area but again I only met him once, while I was in London for the CES show around 1992. He was older than all the rest of us and had long grey hair, a beard and was covered in tattoos, so he looked kinda like one of those cool wizards that he'd draw in his pictures!
The one time that I met Rob (Was (Not was)/Vapour) was at that same show (CES) in London and he said that he thought I just wanted to do stuff on my own and wasn't bothered about being in a group at all... and he was probably right. Maybe he felt the same way. I also met one of the well known French crackers at that show and he didn't seem to speak much English, but just kept repeating "I want to fuuuck an English giiirl". It was like we'd walked into an X-rated version of the TV show "'Allo 'Allo"... a surreal moment in the middle of a geek fest and I never did find out if he succeeded in cracking that particular challenge. :)
What was life like in the British scene?
Almost like a job. :) That's why in the end by the mid 90's I was glad to have been involved but also glad that it was all over and I had time to do other things. Sometimes if there was a difficult new protection to hack I'd be up until maybe 2 or 3 AM working on it but would eventually get stuck on one part and give it up for the night. I'd be lying in bed still thinking about it half an hour later, come up with a new idea to try and get back up and go at it again until 4 or 5, then have to be up again before 8 for college. I can't even imagine having so much free time and energy now, never mind devoting it all to one thing.
At the height of it I was trading disks with quite a few guys by post: Pompey Pirates (in Portsmouth - apparently "Alien" was even more anti-social than me and only spoke to group members, so I dealt with Des, "The Juggler"), MCA (in the Netherlands, that was my only contact in mainland Europe), Sub-Humans in Turkey (in Edinburgh), Hal (in Liverpool), Wizpop (in London), Andy the 'Arfling from the BBC (in London) and indirectly with Derek MD (also in London), as well as our original suppliers in England. There would be packages of disks coming and going every few days and meetings with the local guys who had their own contacts, so there would typically be around 10-20 disks of new "scene" stuff appearing every week but during the busiest times it could be as many as 30-40.
l was really into horror movies at the time as well and luckily for me there was a certain crossover between the ST/Amiga pirate scenes and the underground horror movie trading scene in the UK, so just by asking around via the ST scene I'd been able to make some top level contacts. That whole scene of trading un-cut movies on VHS was created by very strict censorship laws passed here in the mid 80's, meaning that a long list of (mostly) horror movies were banned from sale or import. I actually had an original copy of "The Evil Dead" that was sent to me from the US confiscated by UK customs. It was pretty ironic that after years of getting packages of pirate software from the MCA in the Netherlands (a lot of which were opened by UK customs but never confiscated) that I bought a genuine, original movie from the US and it got seized and destroyed!
With the packages of disks and movies arriving almost daily, sometimes I'd stand by the window in the morning watching the postman and would feel a little disappointed if he walked straight past my house, haha. Of course anyone who was heavily involved in the postal trading scene back then could probably say the same thing.
Looking back now through my old address book from that time I can count over 60 names that were related to the ST scene, but only a few would be sent every new release. I also found an old 'phone bill covering March to May 1993, it had 345 calls totalling 2968 minutes and the bill was for £122.44! And that was just the outgoing calls, eventually it got so crazy with random incoming calls at all hours that I had to change my number and was a lot more careful with giving it out after that.
The UK scene seemed to be more about releasing compacted multi-game menus than "single" cracks and as I'd started relatively late I just followed the standard that had already been set by guys like LSD/Was (Not was) and then Automation. The Pompey Pirates seemed to do the same. There was always pressure to take advantage of our fast original supply and as that got better and faster I'd generally only put games on a menu if it didn't delay the release by more than a few days. So unlike other UK groups I was still doing quite a lot of "single" cracks as well just to get the stuff out there ASAP and it really did feel like a race at times. With nearly all the ST "scene" stuff being easily available for download today it's easy to overlook or forget just how important the speed of new releases was back then.
When we reached menu 100 it felt like a good place to stop and around that time I started Cynix with the intention of taking a slightly different direction. Things had become a bit quieter by then and so I was finally able to spend more time coding and did some better intros including the full screen scroller intro that was originally meant to be part of a BBC Mega demo. (The BBC Demo was actually released in June 2019, only 28 years late!).
EGB and some of the other guys from Edinburgh also joined Cynix and that helped a lot with the quality of the intros too, so as I'd hoped the releases looked a bit different to the earlier Medway Boys stuff and more like the European crews. Our old groups and names were maybe becoming a little notorious by then so it was good that most people thought Cynix was a whole new group and I'd still occasionally release a few Medway Boys cracks to keep up the pretense.
Who came up with name Cynix and does it mean anything?
I was into the metal band "Cynic" at the time and was just gonna call the new group "Cynic"... I mentioned that to EGB in Edinburgh and he thought for a second and said "How about Cynix, with an X?" and I said "Yeah, that's even better". So we kinda both came up with the name together. A lot of folk seem to pronounce it "Sy-Nex" , but it was always intended to be like "Cynics".
How well known was Cynix?
One of our guys down in Warrington set up a P.O. Box for people to write to and the details were mentioned on a few Cynix intros. I only ever got to see one bundle of letters and by that time some were over a year old, but people had written from Poland, Slovenia, Czechoslovakia, Yugoslavia, Iceland, Sweden, Finland, Greece, Germany, Holland, France, Spain, Australia, New Zealand, Ireland and of course Scotland, England and Wales. It was amazing to think how far the disks must have spread, before the days of the internet or even widespread modem use.
Who do you rate as the best hacker and group on the ST?
For me, Rob (Was (Not was)/Vapour) was the best individual hacker on the ST, but the best group was the Replicants as they were active the entire time and had it all... very fast new releases that worked, the best group of hackers (Dom, Snake, R..AL, Ratboy, Maxi, Illegal for a while too) and coders that made so many great and original intros. All the other groups seemed to be lacking at least one of those things at some point.
The Medway Boys were one of the early cracking groups in Europe. By the beginning of 1991, the Medway Boys released The Ultimate Game Cracker. How well did it work?
I didn't make that myself, it was done by "Wurzel", but it was a good idea and the kind of thing I might have done if I hadn't been so busy with the new releases.
It was basically the disk read/write code ripped from "pro-copy" with a search for the 4 most common disk protection check routines (Rob Northen, Protoscan, US Gold and Gremlin Graphics), which would be bypassed if found, then a "cracked" version of the game would be written to a new disk. I'm sure it was useful for some guys who couldn't otherwise make a working copy of an original, as it did work on quite a few games when the first version was released in 1989 including some Rob Northen "Copylock" disks which would otherwise have been uncopyable.
I remember in the early days soon after I'd got my ST someone had brought a copy protected original of Gauntlet II to the local computer club (long before we'd see a cracked version) and we sat there all night trying to make a working copy of it with all the various versions of Acopy, Pro-copy and other copiers. All of which would fail... but it was fun trying all the same. The Gamecracker would have been another fun thing to try, the excitement of not knowing whether you'd be playing that game tomorrow or not was all part of the fun in those days.
As the original games started using compression and encryption more and more often the Gamecracker would become less effective, as it could only find the specific protection code just sitting there exposed on a sector of the disk, but in its day it was a useful, fun tool and the intro picture Wizpop did for the final version was pretty cool too.
Later, when the Rob Northen Copylock "internal" protection check was finally decrypted by hand (by SSR, one of the guys in Edinburgh - it took him 14 hours single stepping in MonST!) I spotted a weakness... once the (uncopyable) non-standard data rate of the protected sector was confirmed as present only the first 24 bytes of the sector were used to calculate the unique 4 byte key for that specific "keydisk".
That meant if only the "key" part of the protected sector was copied over but the custom timings part was left intact it was possible to make a kind of "copier" for the Copylock protection, where a non-working copy could be written to any other working "keydisk" to make a fully working copy, allowing suppliers to upload or send non-working copies of games to be hacked.
The trick was that it was possible to only partially overwrite the protected sector by starting a sector write then monitoring the DMA address pointer and aborting the write command at precisely the right moment while the sector was being overwritten. I found that aborting the write command when the DMA pointer was 80 bytes into the sector buffer resulted in 48 bytes being written to the disk, enough to guarantee those 24 crucial "key" bytes at the start of the sector were definitely overwritten.
The code for that part was quite simple:
lea $50(a0),a6 ;a0 is DMA buffer, a6 now 80 bytes into buffer move.w #$2700,sr ;disable interrupts move.w #$a2,$ffff8604.w ;execute write sector command on FDC clr.l -(sp) ;clear a longword on stack for workspace .1 move.b $ffff8609.w,1(a7) ;get DMA address pointer high byte move.b $ffff860b.w,2(a7) ;get DMA address pointer mid byte move.b $ffff860d.w,3(a7) ;get DMA address pointer low byte cmp.l (a7),a6 ;compare DMA address pointer to our limit bgt.s .1 ;and loop until 80 bytes passed to FDC move.w #$d0,$ffff8604.w ;immediately terminate FDC command
This allowed only the unique key part in the first 24 bytes of the protected sector to be changed while leaving the remaining bytes with their non-standard timings intact. So long as enough of the custom timing area was still detected from the original, remaining bytes of the protected sector then the protection check would pass and the modified key would be calculated correctly and returned as valid.
It's fair to say that the Copylock trace encryption was quite effective as I didn't see the code fully decrypted by anyone until late '91, which made it possible to make the "copier" in January '92, relatively late in the ST scene days.
There was a slightly bizarre system where software companies would sometimes indirectly send cracking groups a few original copies of a game on release if they agreed not to crack it. I never really saw the point of that idea as for me the fun was in cracking the game rather than playing it and all those games would end up cracked by some other group anyway... but it did give me a few original copylock keydisks to overwrite with my "copier", so I wasn't complaining. :)
Did you link to a BBS to be up-to-date and stay in contact with the underground cracking scene?
I was too busy hacking the games so I didn't get involved much in that side of things until relatively late on. The modems were still very expensive at that time, a 9600 cost over £1200 at first and later when I got a 28800 modem it cost £880 (and that was a special offer of a boxed twin pack for £1499+VAT!), more than double the price of my ST. Everyone was using US Robotics "courier" modems as they were always pushing the speed limits upwards with their own proprietary standards before the official standards were set and would only connect at full speed to another courier. A couple of my postal contacts had 9600 and 14400 HST couriers before I got my first modem so everything would be uploaded once I'd posted it to them anyway. It may sound crazy now, but I just enjoyed hacking the games and really wasn't that bothered about whether it took a day or two longer for them to get uploaded or not.
One night I got a call from a well known guy in the ST scene who I'd never dealt with before and during the conversation I agreed to send him our latest releases. A few hours later that same night I get a call from an old contact who had been uploading our stuff for a while, saying that he's just heard the news but this new guy also has a modem and it would seriously screw things up if he was able to upload any of our stuff first. So I have to call the new guy back, explain the situation and say sorry but I actually can't supply you after all. He understood and was totally fine about it, as he was able to download the stuff maybe a little later himself anyway, but you can see why I wasn't exactly in a hurry to be more involved in the modem trading scene. A few years later I was out shopping when the hourly news came on the radio in the shop. After a few minutes they announced that a major piracy ring had just been busted in Liverpool that morning, with the ringleader being named as... the guy I was very nearly directly supplying.
More than once I was offered a free modem by one of the bigger ST BBS's but with various restrictions attached about not uploading to certain competing boards, basically politics I had no interest in dealing with. So I declined the offers and continued to post stuff out to my usual contacts until I bought my first modem, a 14400 courier, the following year. A few times some of my postal contacts even asked if I'd delay sending a particular new game to other guys they knew also had a modem, to guarantee them the first upload. By that time I thought it was all getting a bit silly... or maybe the opposite, too serious. I remember someone telling me I should have a manager to handle all this side stuff and then we both laughed, but they had a point. :)
The US BBS scene took off for the European crews because free calls were possible with hacked AT&T "calling cards" (a system intended to allow Americans to call back home while they were in Europe) which might explain why nearly all the cracking groups were in Europe but most of the major BBS's were in the US! There was a whole scene involved with getting these calling card numbers and calling around contacts for new ones when the one you were using was blocked. "Blue box" and "Black box" hacks were sometimes used on the 'phone system for free calls as well, but that was less common at the time I was involved. As the pirate 16 bit BBS scene really took off and the PC scene soon followed in the early 90's everything became much more time pressured, competitive and commercial.
Which game had the hardest encryption? And why?
I think this can be split into 2 categories.
The first was the type with lots of "anti-hacker" protection like trace encryption, checksums, page zero code over the exception vectors, self modifying code, special disk formats etc. The best of these that I saw would include titles like War Heli, Maupiti Island, Toki, Parasol Stars, Kick Off II, Damocles and Pirates.
The second type were those written in an interpreted, high level language which by itself made them extremely difficult to understand and crack without them using any "anti-hacker" or encryption code at all. This would be games like Future Wars, Operation Stealth, Loom, Monkey Island, Bargon Attack, Ween, Freedom, Emmanuelle and the Level 9 adventures. All those games used an "Enter a code from the manual" type of protection system and had no disk copy protection at all. Presumably because program code accessing the disk hardware would have been easy to spot, whereas "printed manual check" code was indistinguishable from the normal game code.
Games like War Heli, Toki and Parasol Stars had layer after layer of encryption and checksums - a method to verify that the protection check code hadn't been modified, usually by adding or xor'ing together all the bytes in a certain memory range and then crashing or freezing the game if a change (hack) was detected. Finding the checksums after decrypting the code was often the hardest part as they were quite easy to disguise within the normal game code, sometimes the few lines of checksum code would even be spread out individually over multiple distant pages of normal code so that they couldn't be recognised all together as a unit.
Pirates was the first game I remember seeing with multiple layers of encryption on the front end and then multiple checksums and more encryption within the main game code, as well as password protection. They even used the disk protection "key" number along with a checksum of the main code to decrypt another part of the main code. That was in September '89 and definitely the best effort I'd seen up to that point. A few years later in '92 things had moved on and Parasol Stars had so many checksums, including 2 in a high level language, that it took about 5 days to crack and required well over 50 changes to the main game code.
If a game was still crashing and I suspected hidden checksums were to blame then occasionally the only solution was to spend hours manually searching through the entire game code one page at a time in MonST looking for anything "suspicious". I had to do that with Kick Off II as it had so many well hidden checksums that I actually missed one, resulting in the game crashing after being played for a while. That was one of the very few times that I had to release a fixed version of a crack a few days later, the only other one I can remember was Super Cars where I initially missed a protection check they'd hidden on level 6. I heard that the Replicants also had to release a fixed version of Kick Off II after missing a checksum so I didn't feel so bad about my mistake! The later version (Final Whistle) also had a very nice protection, with 6 disk protection checks, 9 separate checksums and a nice little routine that checked the file order on the disk and then used that along with a checksum of a raw sector read from the encrypted main file.
If a checksum was implemented particularly well then the "fail" condition would corrupt some of the game data and cause a crash in part of the code completely unrelated to the checksum. War Heli was like that and had so many separate encryptions and checksums that it took more than a full week to find and bypass them all. They even tried to hide the lives counter, with it starting at 8 and decreasing by 2 each time, I never saw that in any other game. I read recently that it was written by Swiss ex-hackers and it all made sense!
Maupiti Island also had a very nice protection, with layers of encryption, multiple checksums, self modifying code and a special disk format that had no valid sectors so appeared to be unformatted but actually had 5842 raw bytes per track with over 450 files stored across both disks. All the data from the original disks had to be dumped manually one track at a time and then everything reconstructed back onto standard disks (10 x 512 byte sectors per track), as well as creating a custom file loader to patch into their file system code. I added a RAM disk and support for an external drive as well 'cause it wasn't much extra work and it made loading a lot less painful than on the original.
The original game didn't seem to be very widely distributed in the UK so I didn't get hold of it until a few weeks after it had been released and with it taking days to crack and rewrite all the loading code I was getting more and more paranoid each day that some other group would release their version before I'd finished! I don't think anyone else cracked the English release at all but there were apparently a few cracks of the French version. Call my cynical, but maybe it was because I protected my cracked version with my sync/trace encryption wrapper that there were no other releases of the English version, haha. :)
The second type of protection, the high level interpreted stuff, was difficult because the code that handled the protection check wasn't directly written in 68000 but was encoded inside the instructions of the high level language and there was no way to "read" that code. It would be like trying to hack a normal game by modifying the CPU microcode (the very low level operations carried out to implement each individual 68000 instruction) without actually knowing any of the 68000 instructions, almost impossible to do without causing the whole program to malfunction. Of course compiled high level language games were no problem as the game logic had already been translated into 68000 code by the compiler, but a few French companies like Coktel Vision and Delphine used an interpreted system for their adventure type games.
The Coktel Vision game Freedom was the first I saw of that type, in February '89, and I very nearly gave up on it after finding nothing directly referencing the "colour code chart" protection within the main game code at all! At around 3 or 4 AM I finally gave up on trying to modify the 68000 code and as a last resort started to look for an attack on the data used to store the colour code information itself.
In a separate data file, a few pages away from some text relating to the colours on the code chart I found a distinct data table with nearly 200 similar 4 byte entries. Hoping this was the colour code table I tried copying the contents of a single 4 byte entry over the entire table, the theory being that this might make every "colour code chart" question accept the same colour as an answer. Apparently they were storing the row and column numbers from the printed chart along with the actual colours in this table, as the game would now ask for the same chart position every time! :) I didn't consider it a "clean" crack at all as it was really just a lucky last try guess, but at least it worked and I never did see another crack of the English version of that game. I did their later release, Emmanuelle, in exactly the same way.
In late '89 Delphine released Future Wars and it used a similar but much more advanced high level interpreter system. I spent over a week tracing through the code trying to hack it but could see I was making basically no progress at all and eventually gave up, again concluding that it may not even be possible to hack it by directly modifying the 68000 code in the usual way.
A few weeks later I was really impressed when I heard that Axe from Delight had succeeded in hacking it. That first hack needed 1MB of RAM to run, which to me made it all the more amazing... that the method he'd found to crack it was so crazy that it even needed extra RAM in the machine! :) At least I didn't feel like such a failure for giving up on it myself after reading his text intro saying that he'd had some help from 3 other guys:
======================================== = = = DELIGHT brings you: = = = = FUTURE WARS - Time Travellers = = = ======================================== = It took us very long to crack this = = game. As it is written in one of = = those SHIT-languages, it was again = = AXE's job. (Hey, that's me!) = = I am very thankful for the help I = = got from the following guys: = = David Lightman (new member) = = Elf (a crazy Amiga-freak) = = Wanderer (F.O.F.) = = For some hints for the game read the = = READ_ME.TXT on this disk. = ======================================== = Now is the 19th of December still = = in 1989. This crack is a Christmas- = = present to all lamers on this world. = ========================================
That was the only time that I gave up on trying to crack a game on the ST, although I did go back to it later. When Operation Stealth was released the following year it used the same interpreted high level language system but I was a bit more experienced on the ST by then and was able to crack it in about 3 days by developing a whole new technique just for this type of code. Then I went back and cracked Future Wars using the same method in only about 4 hours and later was able to hack Loom, Monkey Island, Bargon Attack and Ween in the same way.
With Operation Stealth I already knew that all the conventional methods would fail just like with Future Wars so I ended up just spending hours and hours manually stepping through the code in MonST, going with the theory I mentioned elsewhere that the key to success was simply not giving up. Eventually I started to notice a pattern with the code always returning to a certain sub-routine, but with slightly different values in register A0 each time. So I set a breakpoint at the start of that code and found that the game would run for some time before always dropping back into MonST at that breakpoint.
This was the breakthrough as it turned out that the sub-routine was basically handling the "PC" (Program Counter) for the high level language code and register A0 pointed to the next "instruction" to be executed from the high level program. So it was then possible to "trace" the high level code and follow which way it flowed depending on the pass or fail of the protection check.
The crack was patched into the 68000 code that read the next instruction from the high level language program and would detect when the interpreter was running the protection check routine and then modify the high level data to force it down the "pass" route.
This is the interpreter monitoring code for the Future Wars crack, it was stored in low memory at $1000 and the original code was patched to jump to it with a "jsr $1000" instruction at the start of the "high level PC" routine. The original 2 instructions that were patched out for the jump are included from the "notyet" label and then it returns back to the original game code.
crack cmp.b #$25,(a0) ;A0 holds the "high level Program Counter" bne notyet cmp.b #$0a,1(a0) ;so all these compares bne notyet cmp.b #$4f,$1c(a0) ;are waiting for the specific pattern bne notyet cmp.b #$2e,$1d(a0) ;of the protection code bne notyet cmp.b #$50,$1e(a0) ;to appear at the "high level PC". bne notyet cmp.b #$52,$1f(a0) ;If all pass then the high level bne notyet cmp.b #$22,$14(a0) ;interpreter is about to execute bne notyet cmp.b #$0a,$15(a0) ;the protection check routine bne notyet clr.b (a0) ;The interpreter is now running the protection clr.b 1(a0) ;code, so clear 4 specific bytes (instructions) clr.b $14(a0) ;in the high level program code to force clr.b $15(a0) ;execution of the "protection passed" code route notyet move.b (a0),d0 ;Get the next high level instruction and and.w #$ff,d0 ;continue to execute the high level code rts ;as normal
Much later I heard about an interesting but entirely different approach to cracking some of the tricky "Enter a word or colour from the manual" type protections. I don't know how successful this was in reality, but if a game used the standard OS random number generator (RNG) function to select which word to ask for apparently you could intercept that call and return a fixed value, making the game always ask for the same word! Quite a clever idea, especially considering it doesn't modify the game code at all, but I guess you'd need to be careful about other random game functions also being affected.
Thanks to Steem (the ST emulator) it was easy to try this theory out today, so I made a quick test by changing the OS RNG routine "seed" value (the initial timer based random number that all others would be derived from) to a preset number. That meant the OS RNG function would always return the same series of "random" numbers each time it was called, probably a bit more friendly to other random game features than returning exactly the same number every time. The RAM address of the RNG "seed" value is different for each TOS version, as is the address of the actual RNG routine itself, so the hack has to search the TOS ROM code to find the appropriate address to modify.
I ran the following simple hack code to preset the "seed" value before running the games and it actually worked for Freedom and Emmanuelle, making them always ask for the same colour codes every time! It didn't work for Future Wars or Operation Stealth though, presumably because they use their own random number generating code. It's still a nice idea though and if I'd thought of it 30 years ago then I'd have had at least one extra early night! :)
opt s- clr.l -(sp) move.w #$20,-(sp) trap #1 ;supervisor mode addq.l #6,sp move.l $4.w,a0 ;get start of OS code from reset vector lea $7ffe(a0),a1 ;check first 32K only loop addq.l #2,a0 cmp.l a0,a1 blt.s quit ;if not found in first 32K then exit cmp.l #$bb40e62d,(a0) ;search for unique constant in OS RNG routine bne.s loop move.l 6(a0),a0 ;extract RAM address of "seed" value from OS move.l #$12345678,(a0) ;and force it to a preset value quit move.l d0,-(sp) move.w #$20,-(sp) trap #1 ;back to user mode addq.l #6,sp clr.w -(sp) trap #1 ;exit
There was one really nice type of encryption that I never saw used by any game, but it was used to protect the code of a few demos and hacker intros. Maybe it was used in a game that I never looked at, or like the unofficial ST hardware scrolling "hack" maybe it wasn't more widely used for compatibility reasons due to it being so hardware timing critical.
"Sync protection", where the decryption key was in part calculated by periodically reading values from a timer or counter running in parallel with the main CPU, in theory meant that the decryption code had to run completely unmodified and uninterrupted as any deviation would cause the CPU and timer to get out of sync, corrupting the decryption.
I'd seen this technique used on the BBC micro a few times, actually on the only games that I'd given up trying to hack on it! There was a guy called Kevin Edwards who made some really insane sync protections on the BBC in the mid 80's, with multiple timers and interrupts running simultaneously plus self modifying decryption code including checksums. It was so complex that I guessed the only way the original game code could have been encrypted was by somehow running the decryption code itself. I learned later that this was correct and the decryption system actually ran a 256 iteration cycle that eventually produced the original data again, so the game code was encrypted by passing it through the decryption process 255 times. Pure genius! Apparently it was only hacked at the time with hardware modifications, the most common method being a hacked OS ROM that didn't clear RAM on reset allowing the game code to be dumped after decryption was complete, a similar idea to my ST "RAM dump" cartridge.
On the ST sync encryption was implemented using the low byte of the video address pointer (located at $ff8209), a fast updating 24 bit counter used by the video hardware as it processed screen data for output to the monitor. The CPU could be synchronised with the counter and then the decryption routine started, with the constantly changing counter value being included in the decryption calculations.
Just for the fun of seeing how it could be done I made a basic sync/trace encryption system myself and used it to protect a few intros. Each instruction of the main code would be decrypted, executed and then re-encrypted by the trace routine, where the decryption used every register (even the status register), used a checksum of the trace routine itself and also used the video counter value 3 times, while the main code modified the trace routine multiple times to change the checksum result. The hardest part was trying to devise a method to actually encrypt the main code!
Eventually I thought of a solution... by replacing each instruction of the main code with random data that would crash the CPU when it was decrypted and executed, that instruction wouldn't be re-encrypted by the trace routine. Then by dumping RAM after each crash the unique decryption key used for that instruction could be calculated and used to correctly encrypt the original instruction from the main code. Sometimes the random data would actually decrypt to a valid instruction that would be executed and re-encrypted, so it could take 4 or 5 attempts to find a random value that would cause a crash. It took hours to build up the 80+ encrypted instructions of the main code like that, but it worked.
At the time I thought it would be a real nightmare to hack, but there's actually a fairly simple method to crack it and like any loophole it's quite obvious when you know it. The crack was posted on an Atari forum by guys from the "East Cracking Group" and I have to say it's very clever! I wondered why I hadn't heard of these ECG guys before but when I was looking back through the Cynix PO Box stuff I found they'd actually sent a letter (from Dresden) back in January '93! The trick for the hack is that extra code can be inserted at the end of the decryption routine to save the exposed instructions and the CPU can then be re-sync'd with the counter to continue the decryption. Getting the CPU back in sync with the counter is the clever part and it relies on the fact that the counter is reset every video frame.
One PAL video frame = 313*128 = 40064 bus cycles, or 160256 CPU cycles, so for example if your extra hack code takes 60 CPU cycles then you had to waste 160196 CPU cycles and could then continue the decryption code with the CPU and counter perfectly back in sync! The method used to waste a specific number of CPU cycles was to have a large table of NOP (No Operation) instructions ending with an RTS (Return) instruction, then JSR (Jump) a certain distance into the table depending on how many cycles you needed to waste. A JSR to a specific address takes 20 cycles, an RTS takes 16 cycles and one NOP takes 4 cycles, so the table would have (160256-16-20) / 4 = 40055 NOP's followed by an RTS. A NOP instruction is 2 bytes long so to re-sync after spending 60 cycles as the example above you'd just JSR (60 / 4) * 2 = 30 bytes into the table.
Apologies to anyone who feel asleep during that last page. :)
Did you follow a certain cracking technique on every game? Did it work out most of the time?
Only the games that used a known protection type (the early Rob Northen "internal" and "external" checks being the most common examples) could be cracked in a "standard" way, everything else had to be approached in its own way depending on what was found.
In general, I'd say it takes 3 things to do that well. First is an intimate knowledge of the hardware, that is CPU instructions, exception vectors, interrupts, BIOS calls, timers, memory map, hardware registers etc. Anyone can learn that stuff from a book.
The second and most important thing is having the imagination to think up all manner of innovative ways to expose the code and then locate the few critical parts to modify. That's where experience coupled with at least a touch of autism is useful. :) The third thing is having the obsessive persistence to keep thinking up and trying new methods when one attempt after another has failed to work. To be fair, that touch of autism is probably more than a little helpful here too! Obviously you try the quickest and easiest ideas first and if they fail then each new method could take longer and longer to think of and attempt, so the difference between success and failure is often just the ability to keep thinking up new ideas and taking the time to try them.
Some guys preferred a "pure" method of going in through the front of encrypted code by hand and decrypting every instruction one at a time by single stepping and modifying the code as they go. I found that wasted a lot of time and was very rarely necessary and so would always try to find a shortcut that allowed the code to be dumped after it had decrypted itself. This was frowned upon by some hackers at the time, almost like it was considered "cheating", especially if it involved a hardware modification or use of additional, non-standard hardware. But with a pile of borrowed original games sitting there waiting to be hacked and returned there really was no time to waste on breaking down the protection code any more than was necessary for a good, clean crack. Of course being able to recognise exactly when that point was reached in each case was all part of the fun.
If the options were 10 hours to go in manually single stepping the code or to think up a potential loophole to exploit and get around it in an hour by using this or that interrupt, or crashing or freezing the decryption code or whatever, then I'd always go with the latter option. The objective was simply to make the disk copyable and if that could be achieved without even fully understanding how the encryption system worked or leaving some of it intact that was OK with me. That's how I came to make the hacking cartridge that allowed me to freeze the ST and dump memory at any time.
When I first got the book "ST Internals" I thought it was a bit strange that they'd used nearly 200 pages (40% of the whole book) for a commented listing of the BIOS code, thinking it was probably only to make the book look bigger! When I eventually started reading through it I soon changed my mind though.
Right there in the first few pages of the BIOS listing was the key to making the "RAM dump" cartridge. Almost the first thing that happens after a reset is that the cartridge port is checked and if valid code is found then it's executed before anything else happens. The cartridge code can then return execution to the BIOS where it checks if the memory configuration is valid (is it a cold or warm reset?) and then sets up and clears the RAM accordingly. For a warm reset it only clears to the previously determined RAM size to allow for a faster boot, for a cold reset the full RAM size is re-calculated and then completely cleared. A warm reset is chosen only if certain "memory valid" system variables are still set to specific values when checked immediately after the reset.
My ST had 2.5MB of RAM, so the trick was to have some simple cartridge code that on reset would copy the entire lower 512KB of RAM (where the game code would be located) to the area between 512K and 1MB, set the RAM size to 512KB to stop the BIOS clearing above that, set the "memory valid" locations as required to allow a warm reset and then exit back to the BIOS code to complete the reset and boot process as normal.
It was lucky that my ST had been upgraded from 512K to 2.5MB not long before, otherwise the cartridge idea would never have worked. A friend from the Barras made a hardcore DIY upgrade kit by soldering SIMM sockets to veroboard and then connecting loads of flying leads down to the ST mainboard. It looked horrible (see pic), but was pretty reliable except for one time when I had just finished hacking Parasol Stars and suddenly found lots of corrupted bytes spread throughout RAM. I had to spend about an hour going back through everything working out whether the changes were part of the hack or just random corruption. It was around then that the yellow bit of cardboard you can see in the picture was inserted between the 2 SIMMS to keep them steady!
The cartridge code was actually very simple, this was the very first version we burned to EPROMs and it worked!
dc.l $fa52235f ;magic longword to ID diagnostic cartridge clr.w $ff8240 ;make screen black (BIOS jumps here to start) move.b #2,$ff820a ;set screen to 50 hz mode lea 0,a0 ;source for copy, bottom of RAM lea $80000,a1 ;destination for copy, 512K into RAM .1 move.l (a0)+,(a1)+ ;copy eor.w #$777,$ff8240 ;flash screen to show dump is working cmp.l #$80000,a0 ;end copy at 512K blt .1 ;and loop clr.l $426.w ;clear reset vector to be sure we can boot move.l #$80000,$42e.w ;set top of RAM to 512K move.l #$752019f3,$420.w ;set memval1 move.l #$237698aa,$43a.w ;set memval2 move.l #$5555aaaa,$51a.w ;set memval3 move.w #$500,$424.w ;set memory configuration jmp (a6) ;return to BIOS and boot as normal
That allowed me to boot straight into MonST with a perfect copy of the game RAM (at the instant reset was pressed) sitting there from 512KB ready to be inspected. I could save that whole image to disk if required, take another memory dump and then load the first one back into RAM higher up (from 1MB to 1.5MB) and compare the 2 RAM dumps. That was extremely helpful as you could compare a protection "pass" and "fail" result, especially useful for those Rob Northen trace encrypted "internal" checks that contained a few lines of very well hidden code that would decrypt a few specific memory locations only if the protection check passed.
Some games and demos would freeze if they detected that a cartridge was inserted so I had to fit a toggle switch to the cartridge +5v line, so that the reset button could be held down before switching the cartridge on and then releasing the reset button.
Later the other 2 guys ("Wurzel" and "Trojan") made a much more advanced cartridge with a custom disassembler and graphics ripping tools, but I stuck with my simple "RAM dump" version as I was so familiar with using MonST by that point. They actually tried to release the advanced hacking cartridge commercially but there didn't seem to be much interest... one of the companies who basically sat on the test version for months without committing to anything eventually released their own version!
I had the "RAM dump" cartridge working long before any of the commercial "ripper" cartridges appeared and can't emphasise enough how useful it was. A few games did very sneaky stuff to try making even a RAM dump less useful... for example War Heli took a checksum of the protected disk sector and used the result to setup a hardware register (which would instantly be lost when reset was pressed) but in general being able to dump RAM at any time was an amazing tool and great time saver. Even on War Heli it still helped with getting around the many other layers of protection and ultimately did provide the solution to that hardware register trick... by modifying their code to store the checksum result in RAM where it could be dumped by the cartridge, then hard coding the result revealed by that dump directly into the hacked loader.
For the few guys who hacked even more stuff than I did without the help of a tool like that, I can only admire your dedication! And that goes especially for Rob (Was (Not was)/Vapour) who hacked everything with SID, the "Symbolic Interactive Debugger", one of the earliest debuggers available for the ST and described in a 1986 review as "inadequate for all but the simplest tasks, compared even to the tools available on the 8-bit computers". Maybe that's why Rob was (quote) "one of those guys who is never off his machine, hence the key clicks in the background whilst on the phone!". :)
On a scale of 1—10, how well would you say encryption was implemented on ST games in general?
It's hard to quantify that, it was definitely better than the encryption used on the BBC (with the exception of the Kevin Edwards VIA timer "sync" encryption stuff) but the encryption method itself wasn't as important as how well the decryption and disk protection code was protected with "anti-hacker" routines and checksums and that varied a lot. The basic problem with protecting code on the ST was that there was no hardware "secure boot" system so no matter how good the encryption system was there would always be the weak link of the unencrypted boot sector code to start an attack from.
These days the games consoles have a "secure boot" system where the processor boots from code hidden inside the hardware of the CPU or SoC (System on Chip) itself. That code can then safely load, decrypt and run the main boot code from an external ROM or disc without any unencrypted code being exposed at any time. So things have changed from the ST days when anyone could access at least the initial boot code but it was often very heavily protected in software, to today when no one can access the code (at least without very sophisticated and expensive hardware) but it has little or no software protection because it's basically unnecessary. Obviously the hardware protection method is superior, but from a "hacking for fun" perspective the 16 bit days of the ST and Amiga are hard to beat.
From late '97 I was doing a lot of DVD player hacking (for region code switching, macrovision disable etc.) and only ever saw one thing that was comparable to the "anti-hacker" stuff that was done on the ST. That was on some high end Pioneer players, where they had a hidden checksum routine built into the video decoding chip and the main processor would gradually copy the 2MB firmware code across, one byte at a time, to be checked. If the video chip didn't receive the full original firmware code plus the correct 4 byte checksum value within 6 minutes of starting to play a disc then it would lock up, freezing the player! The obvious solution was just to correct the checksum bytes for the required firmware changes, but they were using a complex checksum algorithm that couldn't easily be guessed. Another idea was to use a double sized firmware chip and store the original image in the top half to be copied across for the checksum. Luckily that wasn't needed as a loophole was found. :)
There was enough blank space (filled with $ff bytes) at the end of the firmware code to fit a hacked version of the routine that copied the firmware bytes across to the video chip. By storing a table of the modified firmware addresses along with their original bytes it was possible to parse the address being processed for the checksum and always copy across the expected byte, either from the original code or from the modifications table. When the checksum address reached the blank area at the end of the firmware (where the hack code was now located) the modified checksum routine would just copy across blank ($ff) bytes until the end of the firmware was reached. So the video chip would always see the full original image even though about 500 bytes had actually been changed!
If only they'd thought to fill that blank space at the end of the firmware with random bytes instead of a constant value then the hack wouldn't have been possible. It was still a decent attempt though, but I wouldn't put it even in the top 20 of the "anti-hacker" stuff I saw on the ST.
Looking back to your active period, did the encryption level raise over time?
The most commonly used protection system (Rob Northen "Copylock") definitely evolved and improved over time. First it was just the basic "internal" check which was usually easy to remove once you understood how it worked. It was a chunk (just over 2K) of quite well protected "trace" encrypted code, meaning that each individual instruction was automatically decrypted, executed and then re-encrypted as it was running, which was very effective in hiding exactly what was going on inside. It also used the bus error, address error, illegal instruction and divide by zero exception vectors to make it even more difficult to reverse engineer.
The weakness was that the hidden code was basically only checking for the presence of the protected sector on the disk and then calculating a unique 4 byte (longword) key from the sector data and returning that value in register D0. So it could often be bypassed quite easily by reading the key from the disk using their own code and then replacing the entire protection code block with a simple "move.l #key,d0" instruction.
At least that's how it would be done for what you'd call a "clean" hack. The alternative method was just to force the branch immediately following the key compare instruction and that was usually fine, but occasionally they'd have further hidden checks of the key pages later. That's why it was best to simulate the "protection passed" condition as closely as possible, so that hopefully any less obvious additional key checks would pass as well.
To be fair to Rob Northen he did include the following advice for game developers along with his encrypted protection code:
All very good advice! Using multiple, diverse, hidden checksums to make sure the protection code hadn't been modified was definitely the way to go, but thankfully it wasn't done all that often by those using an "off the shelf" protection system like Copylock.
A little later the "external" Copylock protection system appeared, which had the same front end trace encryption as the "internal" version but now the complete main program file of the game was included inside the encryption wrapper. That was more difficult to remove as a simple bypass wasn't possible and the encrypted file had to be extracted intact.
The first time I saw the "external" encryption used was on Rodeo Games and I can still remember those few days of sitting in lectures at college trying to think up new ways to hack it and then being desperate to get home and try them out! Luckily a loophole had been left open and some code running on the keyboard interrupt could be used to monitor progress of the decryption and then freeze the Copylock code just as it completed, allowing the fully decrypted program file to be dumped out before it had been relocated.
Other interrupt vectors that I tried had been locked out and shut down... maybe they overlooked the keyboard interrupt thinking it wasn't called often enough to be useful, but if I sat there quickly twirling the mouse around while the decryption process was running then the keyboard interrupt freeze code worked perfectly almost every time.
The method was simple enough, let the encrypted main file load as normal, then while it was decrypting, dump RAM and note the contents of a particular address near the start of the encryption wrapper code. That address and data word were then edited into the first 2 lines of the source code below, that code assembled and the resulting program run.
That would quit back to the desktop but leave the address monitoring code running on the keyboard interrupt from low memory, just waiting for the contents of that specific memory location to change which would only happen once the decryption process was completed. The encrypted main file was then run again, this time while moving the mouse around and watching the screen flashing. Once the screen stopped flashing due to the freeze loop in the monitoring code the process was complete and RAM could be dumped again to expose the fully decrypted program file.
address equ $12fe2 ;in this case wait until address $12fe2 <> $a47c check equ $a47c ;then freeze for RAM dump opt s- clr.l -(sp) move.w #$20,-(sp) trap #1 ;supervisor mode addq.l #6,sp move.l d0,d7 move.l $118.w,(old+2) ;save the standard keyboard interrupt handler move.w #check,address ;initialise the check address lea crack,a0 ;copy the address monitoring code lea $380.w,a1 ;down to low memory loop move.l (a0)+,(a1)+ ;copy cmp.l #end,a0 ble loop ;and loop move.l #$380,$118.w ;re-direct keyboard interrupt to monitoring code move.l d7,-(sp) move.w #$20,-(sp) trap #1 ;and back to user mode for exit to desktop addq.l #6,sp clr.w -(sp) ;exit, while leaving the address monitor code trap #1 ;running on the keyboard interrupt crack addq.w #1,$ffff8240.w ;flash screen so we know it's running cmp.w #check,address ;compare address to "still encrypted" word beq old ;if not changed yet then exit to BIOS code ok bra.s ok ;word changed so freeze as decryption complete old jmp 0 ;jump to standard keyboard interrupt code end dc.w 0 ;end of monitoring code for copy
Later the "internal" Copylock checks were improved a lot by hiding some unique trace encrypted code inside each one, usually to decrypt a few specific longwords from the game data. Cadaver was the first game I saw like that and they used 5 separate Copylock "internal" protection routines with the extra hidden code, one for each level, just as mentioned in the "Suggestions for better protection" list above! It took about 3-4 days to work out what it was doing and remove all the checks and I also had to make a trainer (cheat mode) to allow for proper testing of all levels, but it was definitely one of the better protected games that I'd seen by that time in October '90.
The Copylock system was so widely used that Rob Northen became quite well known for it. So much so that Wizpop made a menu picture dedicated to him with Garfield looking at a "Disk Doctor" screen showing the famous Rob Northen copyright sector from a Copylock disk. Wizpop did quite a few Garfield graphics but that one (from menu #54) and the one for menu #100 are probably my 2 favourites of all the menu pictures.
But the best protections were still those unique, custom made ones that were designed by the game programmers themselves and added in multiple places and layers rather than simply as a single afterthought. Games like Dungeon Master and War Heli had some of the best protection on the ST and both were released in 1987, so in that respect the level of those rare, advanced and unique protection systems probably stayed about the same over time. Special (non-standard) format disks did become more common later, as another barrier against copying, meaning that custom disk copiers occasionally had to be added to a crack or the entire disk had to be converted to standard format as part of the crack.
I never actually looked at the Dungeon Master protection myself as it was cracked before I even got my ST, but it's been fully analysed and documented over the years on various sites, probably the most comprehensive one being on the Dungeon Master Encyclopaedia site.
A lot was made about how long it took the crackers to beat the protection but to be fair I think the main reason it took so long to fully crack was that the game itself took months to complete. With the protection being checked throughout the game and the "failure mode" made part of the game itself the whole thing had to be played right to the end to properly test the crack and reveal the extent of the protection. If an identical protection system had been used on a simple shooting game that could be fully tested in a few hours by adding an infinite lives trainer then it would almost certainly have been successfully cracked within a few days or weeks just like everything else.
Did someone buy the games which you cracked as a group?
Some original games were bought and others came as working or non-working copies off originals from contacts locally or in England. We had a few good original suppliers and BBS traders (Quattro, Gino, Quaser, Supreme, Hal) in the North West of England, but mostly the original games came from the "video shop guy" I'll mention in the next part.
It was crazy where some of the original games came from though. One of our suppliers in England would sometimes send an original game back directly to the software company with a note saying how bad it was. Occasionally, if he got lucky, they'd send him their next game on the day of its release. There was a young guy I knew from the local computer club who would buy an original game, then once it was cracked he'd take it back to the shop saying it didn't work on his ST. Usually they'd exchange it for another title, sometimes more than once even. Of course that couldn't last and pretty soon all the local shops refused to sell him any more games.
One of the guys at the Barras had a Happy Computers "Discovery" cartridge (a hardware disk copier) for his ST and would sometimes buy bigger releases to sell "happy" copies from day one regardless of any disk protection, so we'd occasionally buy stuff from him at the weekend. Usually pirate copies would sell for £2 to £3 but if the guy with the "happy" copier was the only one at the Barras selling a big new title he'd charge around double that. I remember buying a copy of Populous from him on a Saturday morning and then taking the cracked version back down there on the Sunday... I'd seen that guy head butt someone over an argument about an original game once so I was probably lucky to get out of there alive, haha. :)
If the games had been "uncrackable" then more of the guys at the Barras would just have used hardware copiers like the "happy" cartridge to copy them anyway, as they had no problem with buying hardware when it was needed. When the PC based CD recorders started to appear in the mid 90's the first guy at the Barras to buy one paid £5000 for a Yamaha CDR100 (at first blank discs cost £50 each and were filled with 100's of "zip" floppy disk images and sold for £100), a few more bought the same recorder when the price dropped to £3500 and by the time it had hit £1500 they all had them! Yamaha UK must have done pretty well out of the Barras at that time.
One type of copy protection that the hardware copiers definitely couldn't handle was an extremely rare, but simple and effective method where the surface of the original disk was physically damaged. I'm only aware of 2 releases of that type... the Databyte version of Boulder Dash Construction Kit from 1986 and ST Diagnostics by PCA (Progressive Computer Applications) from 1987. I only saw the PCA diagnostic utility relatively recently as it's a very rare original, but the unique nature of the copy protection makes it worth mentioning. The original disk had to be write enabled and the protection code would attempt to format tracks 45, 76 and 78. If the format command for track 45 returned an error, or if no error was returned by the format commands for tracks 76 and 78 (the physically modified area of the disk) then the protection check failed and the program would quit back to desktop. Uncopyable without DIY modification of the disk, but easy enough to crack at least!
That kind of physical disk damage must have made one hell of a noise when the disk spun and would surely wear out the disk drive heads eventually!
Yup, exactly... I assume that's why it wasn't used more widely, seems like it would likely damage the drive eventually.
Do you know of any other copy protection methods that the hardware copiers couldn't handle?
I only heard of one other protection method that was basically uncopyable even for the hardware copiers. It was only used on one ST title, "Audio Sculpture", a music utility made by French demo/cracking scene guys. I never saw it myself but the code had multiple layers of sync/trace protection and other nasty anti-hacker stuff. The Amiga version was apparently totally unprotected.
The protection had a sector spanning the end of track boundary and was so timing critical of the drive rotation speed (and thus track length) that it had to be individually created on a single disk and then the protection check modified by reading back exactly what had been written to the disk on that specific occasion. Even creating it again on the same drive would give slightly different results each time, so it would be no good for mass production.
How did you manage to be so fast with new cracks back then?
By the time we'd reached menu 20 or so one of the other guys I knew at the Barras said he'd made a very useful local contact. A guy who owned a video shop had been bringing in the latest video rental releases and would leave them for a day or two in return for the latest ST software. Then we found that the video shop guy ("Mike of Trend") knew the owner of a local computer shop ("BP Micros" in Kilmarnock Road in Glasgow) and they had an arrangement where he could borrow any of the latest ST games for a few days in exchange for a loan of the latest video releases.
He hadn't been doing much of that for himself because he couldn't copy most of the original games, but it didn't take long for that relationship to be expanded and our guy would soon be dropping into the computer shop with new videos more than once a week, at the same time checking for any new ST releases. Over the following few years I think that proved to be the best source of original ST games anywhere in the UK and probably one of the best in Europe, with literally hundreds of games supplied during that time.
Sometimes it got pretty hectic when we knew a new game had just been released but our guy couldn't borrow any more originals from the shop until we'd given back the ones we already had! I rarely dealt with the video shop guy myself and didn't have my own car at the time, so there were a few other local ST guys (like "Jobil" and Eddie) who lived near the shop and provided crucial help in quickly moving the original games back and forward across town to and from my place.
Once a game was hacked it would be returned to the shop and go back on the shelf for sale, with no one knowing where it had been for the previous few days. At busy times there could be 3 or 4 new games every week and we couldn't keep the originals for too long, so over time I made some custom tools to speed up certain tasks like filing and packing special format disks or bypassing a particular encryption system. When I got my first hard drive it really helped improve efficiency too, especially when filing/packing "raw data" games... that was a real sight to behold, imagine a 20MB SCSI drive, interface board and bare power supply sitting in a clear plastic "tupperware" box with holes for the cables and fan cut out with scissors. :)
Approximately how long did it take to compress the games onto the menu disks?
It was generally under an hour, maybe 30-50 mins to pack most disks.
Later my ram disk "zip load" thing made it a lot easier and automatic. Most raw data games were using the Rob Northen disk code by then so they were all passing standard parameters to the loader, so I made a util to rip the raw data from all 160 tracks (80 tracks x 2 sides) into separate files, pack all the files separately then join them all back into one block. Then patch the Rob Northen loading code to my own loader that worked it all out and pulled the required bits out of the big file to depack and copy back to the load address. And if you had extra RAM the whole disk would be loaded at the start then run from RAM.
What was the purpose of cracking games for The Medway Boys?
Hacking games in general I guess had two purposes. The challenge and fun of overcoming the protection, especially when it was a difficult one and you had to develop whole new techniques to get around it. And secondly to get the games out there and copyable for everyone. I knew how much I'd enjoyed and learned from all that free pirate software as a kid on my BBC micro so it seemed natural to want that opportunity to continue for others on the 16 bit machines.
Every home computer going back to the 8 bit days had some fancy copier programs that could copy (some) protected software, Rob Northen himself even sold a protected disk copier for the BBC Micro! If you had the coding skills then cracking just seemed like a DIY extension of that and it was also a good way to learn programming.
Would you admit that computer games were too expensive back then and most of the games didn't manage to justify the price?
It's very subjective but I guess the best games were worth the cost. The cost of games increased maybe 3 to 5x from the 8 bit to 16 bit machines but the relative development costs increased even more than that so it's a complex subject. I was very selective but I did buy some original games and didn't grudge what I'd paid for them.
Have you ever cracked Thalion/Eclipse games?
I'm pretty sure I never cracked any Thalion or Eclipse games as they seemed to be released in mainland Europe weeks before the UK, so I'd always get a cracked version by some other group (usually Empire or Replicants) before I was even offered an original. It seemed to work that way with the Ready Soft games like Space Ace and Dragon's Lair too... a Replicants crack would generally appear before an original was even mentioned over here. I was quite happy about that though, 'cause I heard the special disk format and protection on those titles made them tricky to crack, meaning a lot of work for what were really quite poor quality games. So I was glad the Replicants ("Maxi", usually) had worked out a method to hack them and I didn't have to bother even looking at them myself. :)
I always thought it was a bit pointless to spend time on a game that had already been hacked, the main objective being simply that a working and copyable version of every ST game was made available. Once a game was already hacked much of the challenge of doing it myself was gone too, as that protection had already been defeated. I did sometimes file/pack other groups releases to fill up a menu, but it really was taking up all my time just hacking the games that I got hold of "first", never mind doing stuff that had already been done by someone else.
Looking back to all this underground activity, do you regret what you have done?
No regrets. I look back on it as one of the best times of my life and I still have close friends today that I made in the ST scene.
With Sinister Developments, you converted famous Atari games to the STE and Falcon, like Centipede, Asteroids and Galaxian or Space Invaders. Tell us about your ambitions back then...
It was the Cynix members in Edinburgh who were doing that stuff, I wasn't actually involved in making any of those games and it wasn't until later when we started on the Atari Jaguar game that I was involved in the game development side of things.
You also were involved in Jaguar game development at a time where Atari went into bankruptcy. Tell us about your efforts to get “Slam Racer” out ...
By '93/94 we thought commercial game development was an option but the ST market was just about finished, so when Atari released the Jaguar console in '94 it was the natural alternative and we decided to try making an overhead style racing game.
From the start things didn't look good as the support from Atari was very poor. We had 2 different types of development kits, the official Atari one and a 3rd party version made by Cross Products. The Atari kit would only trace about 100 instructions before it crashed and had to be re-booted. The Cross Products kit was even worse and would only trace maybe 20-30 instructions before it crashed. So as actual debugging tools both were pretty much useless and despite many promises of fixes and software updates from both companies neither kit ever became any more reliable.
I remember complaining to Cross Products about the instability of their development kit and the reply was basically "Deal with it, the official Atari kit crashes as well". So both "professional" development kits were effectively no more use than the "game download" copiers like the Wildcard or Magicom that were available for the Super Nintendo console for about 5-10% of the cost.
The Jaguar had no OS (or even BIOS) and Atari supplied no software libraries or even decent example code, so absolutely everything had to be worked out and written from scratch by reading the hardware specifications. The biggest joke of all was when we typed in some of the example code for the object processor (graphics/sprite chip) from the reference manual and it didn't even work. When we mentioned this to Atari they said "We know it doesn't work, but if you manage to get it working could you send us the fixed code?". That was the level of support that was being offered so it's no surprise that Atari didn't have a host of games ready for release themselves.
The actual hardware design was seriously flawed as well, with the 2 custom DSP chips having only a few K of RAM each, the slow 68000 had to be used as the main processor which resulted in crippling bus contention with the blitter and object processor. I was told by another Jaguar developer that the original design had specified a 68030 to properly handle the multi bus mastering, but it was changed to a 68000 for cost reasons. Without the forced cycle interleaving system implemented in the ST and Amiga apparently the 68000 could lock up the bus, often making it faster to run the individual processors separately in series than together in parallel.
By early 1995 we had a basic, playable demo running and took it to a distributor in England who agreed to release the game when it was completed. We continued development but later that year it was clear that Atari was pulling the plug on new game releases and so the game was abandoned.
The most positive thing I could say about the Jaguar today would be that its DSP's still have the best instruction mnemonic I've ever seen... SHARQ, for SHift, Arithmetic, Right, Quick. They even called it the "coolest instruction" in the reference manual. :)
What did you personally experience from your Atari ST scene days?
My coding and hacking skills improved, I made some good friends and decided that the computer gaming industry wasn't for me.
What do you miss the most of those Atari ST times?
The main thing would be the kind of people you could meet simply by owning a home computer in those days. In the 80's and even in the early 90's to some extent it was still quite a niche hobby, most people had no interest in or reason to own a home computer so it was just the real pioneers and enthusiasts and that created a unique group. In those days the people who would ridicule you just for owning a computer would be the same people today who would ridicule you for not owning the latest, most fashionable computer, an iPhone. Quite a turnaround in only 30 years.
Another thing would be the constant leaps forward in hardware and software. It seemed like there was much more competition in hardware and software back then and always some new thing on the horizon to look forward to. Today it seems like only small steps forward in comparison and it's all become very corporate, uniform and boring. I also miss the simple days when we knew what every bit of software running on our computers actually did and had actively chosen to run it!
BTW if you enjoy some nostalgia for those early days then check out the TV show "Halt and catch fire", it really captures the spirit of the time quite well. Also the books "Hackers" by Steven Levy and "The Soul of a new Machine" by Tracy Kidder are great for insights into that pioneering culture of the 60's to early 80's.
In regard to hacking, I miss the times when there was a single, final version of a program to hack! The ease of internet software updating has made hacking the current version sometimes feel like taking part in a beta test to improve the protection, haha.
A good example... back in 2009, along with a few other guys I was involved in making the first ever Blu-ray player firmware hack that allowed switching of the Blu-ray region. The firmware was packed/encrypted and checksummed but there was a small chunk of visible ARM boot code that did some diagnostics then unpacked/decrypted the main code into RAM and ran it. The depack/decrypt was done in hardware so we had nothing to go on to reverse engineer those algorithms to access the main code. The checksum was weak and quite easy to hack but without being able to examine the main code we were stuck with no way to progress.
After staring at the boot code for days I noticed they were passing some text like "DRAM sizing" and "Stack setting" to a hardware register and guessed it might be a serial port being used for diagnostics... sure enough when we hooked up the player's internal serial port to a PC terminal program the text appeared! Revealing the hardware address of the serial port in the unencrypted ARM code was their one mistake, as I had the idea to modify the firmware to dump the entire RAM contents out of the serial port (to be saved by the PC) just after the depack/decrypt was complete. It took about 2 hours to dump the RAM out of the serial port to the PC but it worked and I was then able to hack the main code to allow switching of the player region codes, modifying the boot code to patch the main code after depack/decrypt but before it was run.
Within a few days of our hacked firmware being released the player manufacturer had pushed out a beta firmware update that specifically closed down our method of region switching. A few weeks later they released the next full version with strong checksums and a whole new encryption wrapper, making the same hack impossible.
In a way the ability to update online automatically brings us close to the self adapting protection that Richard Aplin imagined back in 1991, in his famous hidden text rant from the startup sequence of the Amiga version of Final Fight:
Some things were conveniently simple back in the 80's and 90's. :)
Your statement to the downfall of the Atari Corporation?
I heard that you were responsible for creating unprotected versions of games for compilations or budget re-releases such as The Hit Squad or Kixx. If this is true, how did it come about?
Yes, around '91/92 I was actually paid by Rob Northen Computing (the guy who made the most common copy protection on the ST/Amiga) to hack some ST games! I still have some of those disks and it was titles like Iron Lord, Shinobi, Afterburner, Golden Axe, Microprose Soccer, Forgotten Worlds, Ghouls 'n' Ghosts, LED Storm, Predator 2, Dynasty Wars, Strider, King of Chicago, TV Sports Football, Strider 2, Last Duel, Star Wars Trilogy and ESWAT.
Rob had been asked by the games companies to put together some cheap game compilations on the ST and Amiga, with each one having around 3-5 older games. To keep costs down they were to be packed onto as few disks as possible and they couldn't be on special format or protected disks as that would make the duplication more complicated and expensive.
A friend in England who was active on the Amiga hacking scene knew Rob and was doing the Amiga stuff for him and so the ST titles ended up being passed on to me. Some like Afterburner and Shinobi I had to do from scratch as I'd never done them myself before, but for others I just used the existing Medway Boys or Cynix release after confirming it was definitely the same version, removing the intro and adding a small text menu.
There always seemed to be a rush to get the master disks to the duplicators so I'd often have to send them by a special "same day" train delivery service, which meant dropping them off in person at the main train station in Glasgow so that they could be collected from another station in England a few hours later. I remember thinking it was pretty funny that these guys were distributing my hacks faster than I did myself. :)
Thank you very much for your time!
If you have any idea what should go in this box, please let me know! :)