I also cracked games on the Amiga. It being 68000 based, it was a whole new game for me. (Pardon the pun there).
I cracked a bunch of things, but the first was "Empire: War game of the century", and that was only fitting, as it was also the first PC game that I ever cracked. (Using Microsoft's CodeView, and Norton Utilities of all things). But the one game that I really remember was a game called Foundation's Waste. I couldn't tell you what kind of game it was, what the object of the game was or anything, but here is the stuff that I CAN tell you. It had a nasty protection that none of the copiers would copy. I tried everything in my arsenal, and couldn't get a working copy. Best of all, when your copy didn't work, it played Vincent Price's laugh from Michael Jackson's Thriller. I laughed really hard the first time it did it. This was also one of those games that was all based off of sector locations on the disk. There was no real directory, and you just booted the disk to get the game to run. So, I had a tool that would read a sector, and disassemble it. So, I started with the boot sector, went to the next sector that it chained to, and a couple of sectors later, I found the protection check, and the call to the digitzed laughter. I couldn't resist. My crack of the game came up, and played the laugh, and THEN loaded the game and let you play it. I thought it was the ultimate F*CK YOU to the authors who thought they were being cute.
On the PC, another beauty of copy protection was a "port" of Nintendo's Popeye from the arcades. The protection was in a .com file that the included batch file ran. It checked the disk, and if the protection passed, it ran the NORMAL .exe there. Crack? Delete the .com file, and rename the .exe. DONE! A crack without modifying any code.
There was also this game called Mean Streets by Access Software. When you ran it, it checked the key disk in text mode, and if it passed, it THEN switched to graphics mode. It was VERY easy to crack, as you could use debug, codeview, turbo debugger, almost anything, as they didn't change the video mode, which was what stopped you from using most of those tools.
Monday, August 11, 2008
Speaking of Z-80, The Verifone Tranz 380x2
I worked for a company that used a TON of VeriFone credit card terminals. We used the Zon Jr., the Tranz 330, and eventually the Tranz 380x2.
Before I detail the cracking, let me describe the operation of the terminals. The terminals ran a custom language called TCL (Terminal Control Language). It has NOTHING to do with the Linux hosted language of the same name. The memory in the terminals was laid out with an address from 0-999. When you wrote code, you used specific memory locations. For instance, when you press the "1" key, the code in memory location 107 gets kicked off. We nicknamed the code "License Plate Language" for reasons that you'll soon see.
Let's say that you wanted to write some code to get a 5 digit number from the keypad, and store it in memory location 150. The code would look like this:
B5.5
G
P112
K1.5
U150
*K
Now, this code would select a buffer to use (buffer 5), clear it, display what's in memory location 112 (presumably a prompt that said "Enter 5 digits" or some such), then, accept 5 numeric characters from the keypad, store it in 150, and return to idle.
Now, on with the story. We used thousands of these terminals, so our VeriFone salesman was ALWAYS bringing us new stuff. He brought us a new Tranz 380. Nice terminal, it had lots of memory, but it was of the "batch storage" type, not the code storage type, so it was of virtually no use to us. Then, someone at VeriFone got smart, and decided to modify the firmware to take that big glob of memory, and split it. Thus making *2* distinct code banks, and making the terminal act like 2 terminals! (You could load a COMPLETE firmware image on both sides of the unit, and toggle back and forth). For us, this meant that we could do a TON more work on the terminals than previously. But, in the process of writing this new code, they also put in a small form of copy protection. We found this out as the salesman is in the conference room talking to the muckity mucks about this terminal, which was delivered to me. While he was talking to them about the terminal, my friend Mike (now my Co-Worker Mike), and I had opened the unit up (4 phillips head screws), removed the EPROM, and copied it. Put the unit back together, and had it waiting when they came to take it back.
When the firmware in this unit booted, it checked a memory location in the battery backed RAM area, and if a bit was set in it, it continued to boot like normal. BUT, if that bit was CLEAR, it would calculate a "Lock code", and ask you to enter the "Unlock code". When I threw our copied EPROM into my 380, and saw this, I was both shocked, AND delighted! :-)
The terminals ran a Z-80 variant, it MIGHT have been a Z-180. Anyway, so, I whipped out the disassembler, and ran it through the code. This new Lock/Unlock code was at the VERY END of the ROM. (As you could imagine new code was just tacked into the first free space, at the end of the existing code). I studied it, saw the checking of the bit in the memory location, so my quick fix was to made a "Load Chip" (which I had modified the Lock/Unlock code to WRITE that bit into memory), and the normal "Run Chip", which was the normal code which would now find it's bit set, and run like normal. This was a solution to get us going, but not one that really made me happy. So, I released this hack to shipping, who played with it for a while, while I worked on a better solution. I studied their algorithm, and as you'd expect from someone used to writing code to do communications over the modem, and parsing of packets, the protection was VERY simple. As it turns out, I took their verification routine, and re-ordered the instructions so that now, it asked for the LOCK code, and gave you back the unlock code.
I had made a VeriFone Tranz 380x2 Keygen, using their code, and running on THEIR hardware. I thought it was funny, and I had a good time doing it.
Before I detail the cracking, let me describe the operation of the terminals. The terminals ran a custom language called TCL (Terminal Control Language). It has NOTHING to do with the Linux hosted language of the same name. The memory in the terminals was laid out with an address from 0-999. When you wrote code, you used specific memory locations. For instance, when you press the "1" key, the code in memory location 107 gets kicked off. We nicknamed the code "License Plate Language" for reasons that you'll soon see.
Let's say that you wanted to write some code to get a 5 digit number from the keypad, and store it in memory location 150. The code would look like this:
B5.5
G
P112
K1.5
U150
*K
Now, this code would select a buffer to use (buffer 5), clear it, display what's in memory location 112 (presumably a prompt that said "Enter 5 digits" or some such), then, accept 5 numeric characters from the keypad, store it in 150, and return to idle.
Now, on with the story. We used thousands of these terminals, so our VeriFone salesman was ALWAYS bringing us new stuff. He brought us a new Tranz 380. Nice terminal, it had lots of memory, but it was of the "batch storage" type, not the code storage type, so it was of virtually no use to us. Then, someone at VeriFone got smart, and decided to modify the firmware to take that big glob of memory, and split it. Thus making *2* distinct code banks, and making the terminal act like 2 terminals! (You could load a COMPLETE firmware image on both sides of the unit, and toggle back and forth). For us, this meant that we could do a TON more work on the terminals than previously. But, in the process of writing this new code, they also put in a small form of copy protection. We found this out as the salesman is in the conference room talking to the muckity mucks about this terminal, which was delivered to me. While he was talking to them about the terminal, my friend Mike (now my Co-Worker Mike), and I had opened the unit up (4 phillips head screws), removed the EPROM, and copied it. Put the unit back together, and had it waiting when they came to take it back.
When the firmware in this unit booted, it checked a memory location in the battery backed RAM area, and if a bit was set in it, it continued to boot like normal. BUT, if that bit was CLEAR, it would calculate a "Lock code", and ask you to enter the "Unlock code". When I threw our copied EPROM into my 380, and saw this, I was both shocked, AND delighted! :-)
The terminals ran a Z-80 variant, it MIGHT have been a Z-180. Anyway, so, I whipped out the disassembler, and ran it through the code. This new Lock/Unlock code was at the VERY END of the ROM. (As you could imagine new code was just tacked into the first free space, at the end of the existing code). I studied it, saw the checking of the bit in the memory location, so my quick fix was to made a "Load Chip" (which I had modified the Lock/Unlock code to WRITE that bit into memory), and the normal "Run Chip", which was the normal code which would now find it's bit set, and run like normal. This was a solution to get us going, but not one that really made me happy. So, I released this hack to shipping, who played with it for a while, while I worked on a better solution. I studied their algorithm, and as you'd expect from someone used to writing code to do communications over the modem, and parsing of packets, the protection was VERY simple. As it turns out, I took their verification routine, and re-ordered the instructions so that now, it asked for the LOCK code, and gave you back the unlock code.
I had made a VeriFone Tranz 380x2 Keygen, using their code, and running on THEIR hardware. I thought it was funny, and I had a good time doing it.
TRS-80 "Backup Limited" Games
In late 1984 a friend who had just purchased a TRS-80 Model 4 showed me a couple of games from Radio Shack that were on what they deemed "Backup limited disks". This was a floppy with both the game program, AND a copy program for the disk. At the time, these games were all but uncopyable, so you had to use THEIR copy program to copy them. (It kept a count, and would only allow you to make 2 copies, or something like that. And furthermore, you couldn't copy a copy). So, I looked around in the code, and being new to Z-80 at that time, there was nothing that I could really do with them. So, we left them on the shelf while I learned. About a month later, someone had published an alternative DOS to TRSDOS. It was smaller, faster, AND included a built-in machine language monitor! And best of all, this monitor could be invoked on startup as the only thing running. So, it would start the boot process, look for you to be pressing 1-2-3 on the numeric keypad, and if you were, it stopped loading the whole OS, and just loaded the monitor.
Now, this is a Z-80 based system as I mentioned earlier, this is important in that there wasn't the notion of multi-tasking, memory protection, or any of those "new fangled high level concepts". This was a simple machine with 64K of memory.
So, here's how I attacked the "Backup Limited" games. I would load the monitor, and clear memory with one of it's built-in commands. Then, I would boot the game from the original disk. Once it was loaded I would swap the new DOS disk back in, and reboot back into the monitor. From the monitor, it was a TRIVIAL matter to save the contents of memory into a disk file. So, once the monitor loaded, I would browse through memory, and find the spot where the game code began, and ended, and save that chunk into a file on a new clean disk. I did this for EVERY game they offered, and it worked EVERY TIME.
If you are wondering how it was so easy, it's simple really. The games were built around, and probably ON TRSDOS. SO, they loaded at what is normally the LOWEST available address with TRSDOS running. On the other hand, this new DOS, and the monitor specifically, loaded at a much LOWER address, since it was much smaller, and allowed me access to memory that would normally be written over by a monitor, or any other program that got loaded.
Oddly enough, I was unable to dump the cassette based games this way, they appeared to load LOWER in memory, and when the monitor loaded, it overwrote part of the game.
The ones that I distinctly remember dumping were Frogger, and Zaxxon. I know there were more, as we did everything that Radio Shack had.
Now, this is a Z-80 based system as I mentioned earlier, this is important in that there wasn't the notion of multi-tasking, memory protection, or any of those "new fangled high level concepts". This was a simple machine with 64K of memory.
So, here's how I attacked the "Backup Limited" games. I would load the monitor, and clear memory with one of it's built-in commands. Then, I would boot the game from the original disk. Once it was loaded I would swap the new DOS disk back in, and reboot back into the monitor. From the monitor, it was a TRIVIAL matter to save the contents of memory into a disk file. So, once the monitor loaded, I would browse through memory, and find the spot where the game code began, and ended, and save that chunk into a file on a new clean disk. I did this for EVERY game they offered, and it worked EVERY TIME.
If you are wondering how it was so easy, it's simple really. The games were built around, and probably ON TRSDOS. SO, they loaded at what is normally the LOWEST available address with TRSDOS running. On the other hand, this new DOS, and the monitor specifically, loaded at a much LOWER address, since it was much smaller, and allowed me access to memory that would normally be written over by a monitor, or any other program that got loaded.
Oddly enough, I was unable to dump the cassette based games this way, they appeared to load LOWER in memory, and when the monitor loaded, it overwrote part of the game.
The ones that I distinctly remember dumping were Frogger, and Zaxxon. I know there were more, as we did everything that Radio Shack had.
Saturday, August 9, 2008
Deadbolt 64
For those of you without any experience with the C-64, let me describe a component that is paramount to this next story. The C-64 had a built-in BASIC interpreter. So, you could just turn it on, and start typing a BASIC program in, and run it. As anyone who has done ancient BASIC could tell you, protecting a program that must be in unpacked, unencrypted form is nearly impossible. Being that the default operating mode of the C-64 was in "Enter BASIC code" mode, there were some things that programmers did to try to protect their code. The Commodore had commands that could change the background color, change the text color, clear the screen, those kinda things. Well, the programmers would embed comments (REM statements) in their code that did things like change the text color to be the same as the background color. Or embed CLEAR SCREEN commands so that you would get a line of code, and then the screen would clear before you could read it. This worked pretty well on the screen, but if you printed it out, all protection was lost.
So, a couple of companies introduced what was called "BASIC Compilers". These were just programs that changed the BASIC keywords into their appropriate tokens, and then called the build in BASIC to execute those tokens. This sped up your code, as it allowed the compiler to convert ALL the keywords into tokens at compile time, and at runtime, it just funneled them into the interpreter, thus speeding things up. The 2 companies that made these products were Commodore who made their own called "PetSpeed", named after the Pet computer which preceded the VIC-20, and Skyle's Electric Works produced one called "Blitz!". And these afforded SOME amount of protection to programmers for a while.
There was a company that produced a copy protection that was written in BASIC, and compiled with PetSpeed. This product was called "Deadbolt 64". It was sold in the back of ALL of the Commodore magazines. Some of the smaller software publishers fell for this, and bought it to protect their games. In case you haven't determined it yet from reading my OTHER posts, off the shelf copy protection is most often a BAD idea, as once it has been cracked, the crack works for most everything that uses it. This was the case for Deadbolt 64.
When I first saw it, I was SHOCKED that anyone would do protection in BASIC. But, when I began to look around, and see that there weren't any "decompilers" for PetSpeed like there was Blitz! it began to make sense. So, with no other tools at my disposal, I began to "Shotgun it". This involves loading the code into memory, and blanking out segments of it with 00's, and then running it to see what happens. It was with this technique that I found the section of the code that did the disk check, and made the decision on if the results of that check were good. Painstakingly I narrowed it down to 1 byte that had to be changed to 00 to crack deadbolt. From that time on, when I got a deadbolt 64 protected game, I would change that 1 byte, and it would be done. Always the same byte, in always the same place. How handy! So, with this technique in place, I felt I was set for any deadbolt 64 game.
In the summer if '85 the "Commodore Association Southeast" CASE show came to Nashville. It was at this show that I met Jim Butterfield, and some other Commodore dignitaries. I also met the guys selling a product called "Superkit 1541". Which was a new copy program for the 64. We hung around their booth, and talked to them about cracking and the like. (As the authors were 2 very good, and very notable crackers "The Goose" and "The DOD".) We were hanging out when a guy who had written 2 adventure games came by to taunt us for not being able to copy his games. Matter of fact, he was SO sure, he loaned us copies of the games, so that we could try to copy them, and fail. Yeah, you see this coming, they were protected with Deadbolt 64. One of the games was entitled Krakatoa. When I cracked it using my 1 byte method, one of my friends began saying that his game had been "Krakatoa'ed". :-)
This guy (the author), didn't realize that he was walking into the lion's den when he did that. We were NOT the people you wanted to challenge. He had not only drank the Deadbolt kool-aid, he had went back for 2nds, and maybe even 3rds. (As they no doubt told him that there was NO WAY it could be copied, or cracked).
So, a couple of companies introduced what was called "BASIC Compilers". These were just programs that changed the BASIC keywords into their appropriate tokens, and then called the build in BASIC to execute those tokens. This sped up your code, as it allowed the compiler to convert ALL the keywords into tokens at compile time, and at runtime, it just funneled them into the interpreter, thus speeding things up. The 2 companies that made these products were Commodore who made their own called "PetSpeed", named after the Pet computer which preceded the VIC-20, and Skyle's Electric Works produced one called "Blitz!". And these afforded SOME amount of protection to programmers for a while.
There was a company that produced a copy protection that was written in BASIC, and compiled with PetSpeed. This product was called "Deadbolt 64". It was sold in the back of ALL of the Commodore magazines. Some of the smaller software publishers fell for this, and bought it to protect their games. In case you haven't determined it yet from reading my OTHER posts, off the shelf copy protection is most often a BAD idea, as once it has been cracked, the crack works for most everything that uses it. This was the case for Deadbolt 64.
When I first saw it, I was SHOCKED that anyone would do protection in BASIC. But, when I began to look around, and see that there weren't any "decompilers" for PetSpeed like there was Blitz! it began to make sense. So, with no other tools at my disposal, I began to "Shotgun it". This involves loading the code into memory, and blanking out segments of it with 00's, and then running it to see what happens. It was with this technique that I found the section of the code that did the disk check, and made the decision on if the results of that check were good. Painstakingly I narrowed it down to 1 byte that had to be changed to 00 to crack deadbolt. From that time on, when I got a deadbolt 64 protected game, I would change that 1 byte, and it would be done. Always the same byte, in always the same place. How handy! So, with this technique in place, I felt I was set for any deadbolt 64 game.
In the summer if '85 the "Commodore Association Southeast" CASE show came to Nashville. It was at this show that I met Jim Butterfield, and some other Commodore dignitaries. I also met the guys selling a product called "Superkit 1541". Which was a new copy program for the 64. We hung around their booth, and talked to them about cracking and the like. (As the authors were 2 very good, and very notable crackers "The Goose" and "The DOD".) We were hanging out when a guy who had written 2 adventure games came by to taunt us for not being able to copy his games. Matter of fact, he was SO sure, he loaned us copies of the games, so that we could try to copy them, and fail. Yeah, you see this coming, they were protected with Deadbolt 64. One of the games was entitled Krakatoa. When I cracked it using my 1 byte method, one of my friends began saying that his game had been "Krakatoa'ed". :-)
This guy (the author), didn't realize that he was walking into the lion's den when he did that. We were NOT the people you wanted to challenge. He had not only drank the Deadbolt kool-aid, he had went back for 2nds, and maybe even 3rds. (As they no doubt told him that there was NO WAY it could be copied, or cracked).
The Early Days
I began this whole adventure by chance, not really by choice. I was introduced to pinball at the ripe old age of 7 by my father. At this point in time there was very little of what you would call electronics. Everything was electrical, but not really electronic. I'm pretty sure that the game that I played was Bally's Mystic Gate.
From the moment I played it, I was hooked on gaming. From there, it was flipper pinball, and eventually Space Invaders. I went through a phase of owning the home video game systems, Atari 2600, 5200, and a few of the Pong variants, but it was the introduction of the home computer that really set my world aflame. I lucked out and managed to get into the "Computer Math" class that my high school was just starting up, and became exposed to BASIC programming. It was the between semester transfer of a kid from another school that had had computers for 2-3 years that really got me going. I was a good BASIC programming student, but NEVER thought outside the box until he arrived. He introduced me to PEEK, and POKE, and showed me how to do some TRULY odd things on our lovely TRS-80 Model 3. He even brought copies of some games for the TRS-80, and gave me copies! The world was a marvelous place! Not only could I play games on the computer, I could get them for free! We had some games show up that we couldn't copy, so I talked the computer teacher into purchasing a copy program for the TRS-80. It was called Clone, and had a unicorn, or pegasus on it's "title screen". My life of piracy had begun!
Over the next 2 years, I got pretty much every TRS-80 game there was, and left copies in the disk box in the computer room. It was amazing how fast the students could get their programming work done when there was a video game payoff at the end. So the teacher didn't object.
During the summers, and most evenings, I spent my time living in an arcade. I was there almost all the time, and came to know the video game mechanic pretty well (Mike). He was 9 years older than me, but we hit it off immediately. I found out that he had just purchased a Commodore VIC-20, and some cartridges, and he invited me over to check it out. Being an EE like he was, he had taken a video game montior, and modified it to accept the composite output that the VIC offered, so his screen was SUPER crisp. We had a good time playing the games, and talking about computers, and then Commodore introduced the Commodore 64. He bought one shortly after, and a floppy drive to go with it. He purchased a few games on floppy, and I told him about how we had copied the games at school using a program called Clone. He picked up a magazine, and low and behold there was an ad for a Commodore Copy Program called Clone. He ordered a copy, and for a while, we were getting software from the stores, copying it, and returning it for a refund. You see, in those days, the stores knew NOTHING about software, and to them it was just another item. So, Toys R Us for example, had a HUGE selection of software, and thought NOTHING about allowing you to return it. To them, it was no different from a bike, or a swimming pool, customer satisfation was guaranteed, so they would refund you with no real hassles. Since computers were relatively big ticket items, almost every store had them. And software to go along with them as an adder. We copied software from: K-Mart, Target, Hill's Department Store, Sears, Toy R Us, and a local mall computer store called P. S. Computers, and probably a bunch that I can't recall. But invariably all good things must end, and so it did with our copying, as we purchased an Electronic Arts game called Archon, and Clone couldn't copy it.
Due to my software knowlege, and Mike's hardware skills, we were quickly accepted as friends at P. S. Computers. It was here that we met a kid who had obtained a copy of a NEW copy program called DiSector 2. Not only would it copy everything we threw at it, but it had a little program called "Arts Backup" that was made specifically for cracking those EA games! So, the quest for all games continued! We started hearing about bulletin board systems (BBSes) where people with C-64s got together, and traded software! It was an amazing thing! We started calling out to the local boards, and trading software (The stuff that we COULD trade, as you couldn't easily trade a still protected game). We met a lot of local people this way, and traded a lot of software. It was a few months later, that I met a kid named Darren, (Dr. Who as his BBS name was). He was experimenting with removing the copy protection from games so that they could be uploaded to the BBSes. What he called "cracking". So, we sat down at Mike's house, and he showed me how to crack a couple of games that he had done before, and I was in love! No, not with him, with cracking! By this time Mike's floppy disk box was FULL of copied, uncracked games, so Mike would pick me up at my parent's house on Friday night, and I would hack until he got up on Sunday morning, and took me home. (Where I would go to sleep, and sleep until school time on Monday). I cracked A LOT of stuff, and began to get quite the reputation amongst the locals in Nashville. So much so that Darren began to resent me as HE had taught me how, and here *I* was becoming famous for it. This came to a head when P.S. Computers got in a new game, and decided to have a showdown between us. The game was Gamestar Football. It took me a few hours at Mike's house to get it done, but I had it done before P.S. Computers opened the next day, and more importantly before Darren had. (I even put my name on the scoreboard that showed at the start of the game.) Just to be complete, the first game that I ever cracked was an accident. Before Darren showed me how to do it the correct way, I was playing the copied games from the disk box, and was loading up "Scroll of Abadon" by Access Software, when I remembered that it sucked. So, I pressed "Run/Stop" RESTORE (the equivalent of CTRL-C on a DOS app), and it returned to the READY prompt. Well, being curious, I did the automatic response "list", and a small BASIC program was displayed to the screen. This was puzzling, as the loader for the game was an assembly language app. I threw in a blank disk, and tried to save it. It wouldn't save (Disk drive was probably in the middle of checking the protection or something when I stopped the program, leaving it in a weird state). I tried to PRINT it to the printer, that wouldn't work. (It never occured to me to unplug the power to the floppy drive, and reset it). So, I found some paper, and a pen, and transcribed it from the monitor. Once I had it down, I cycled power on the 64, and typed it back in with the game disk in the drive. It loaded and played the game! That was cool! So, I file copied the files from the game disk to the blank I mentioned earlier. (so as to NOT copy the bad sectors used for the protection over). Once this was done, I ran my typed in program on the NEW disk, and it ran. Woohoo I had cracked a game. Albeit by complete accident, but it still counted! :-)
And thus began my cracking career.
Over the next 2 years, I got pretty much every TRS-80 game there was, and left copies in the disk box in the computer room. It was amazing how fast the students could get their programming work done when there was a video game payoff at the end. So the teacher didn't object.
During the summers, and most evenings, I spent my time living in an arcade. I was there almost all the time, and came to know the video game mechanic pretty well (Mike). He was 9 years older than me, but we hit it off immediately. I found out that he had just purchased a Commodore VIC-20, and some cartridges, and he invited me over to check it out. Being an EE like he was, he had taken a video game montior, and modified it to accept the composite output that the VIC offered, so his screen was SUPER crisp. We had a good time playing the games, and talking about computers, and then Commodore introduced the Commodore 64. He bought one shortly after, and a floppy drive to go with it. He purchased a few games on floppy, and I told him about how we had copied the games at school using a program called Clone. He picked up a magazine, and low and behold there was an ad for a Commodore Copy Program called Clone. He ordered a copy, and for a while, we were getting software from the stores, copying it, and returning it for a refund. You see, in those days, the stores knew NOTHING about software, and to them it was just another item. So, Toys R Us for example, had a HUGE selection of software, and thought NOTHING about allowing you to return it. To them, it was no different from a bike, or a swimming pool, customer satisfation was guaranteed, so they would refund you with no real hassles. Since computers were relatively big ticket items, almost every store had them. And software to go along with them as an adder. We copied software from: K-Mart, Target, Hill's Department Store, Sears, Toy R Us, and a local mall computer store called P. S. Computers, and probably a bunch that I can't recall. But invariably all good things must end, and so it did with our copying, as we purchased an Electronic Arts game called Archon, and Clone couldn't copy it.
Due to my software knowlege, and Mike's hardware skills, we were quickly accepted as friends at P. S. Computers. It was here that we met a kid who had obtained a copy of a NEW copy program called DiSector 2. Not only would it copy everything we threw at it, but it had a little program called "Arts Backup" that was made specifically for cracking those EA games! So, the quest for all games continued! We started hearing about bulletin board systems (BBSes) where people with C-64s got together, and traded software! It was an amazing thing! We started calling out to the local boards, and trading software (The stuff that we COULD trade, as you couldn't easily trade a still protected game). We met a lot of local people this way, and traded a lot of software. It was a few months later, that I met a kid named Darren, (Dr. Who as his BBS name was). He was experimenting with removing the copy protection from games so that they could be uploaded to the BBSes. What he called "cracking". So, we sat down at Mike's house, and he showed me how to crack a couple of games that he had done before, and I was in love! No, not with him, with cracking! By this time Mike's floppy disk box was FULL of copied, uncracked games, so Mike would pick me up at my parent's house on Friday night, and I would hack until he got up on Sunday morning, and took me home. (Where I would go to sleep, and sleep until school time on Monday). I cracked A LOT of stuff, and began to get quite the reputation amongst the locals in Nashville. So much so that Darren began to resent me as HE had taught me how, and here *I* was becoming famous for it. This came to a head when P.S. Computers got in a new game, and decided to have a showdown between us. The game was Gamestar Football. It took me a few hours at Mike's house to get it done, but I had it done before P.S. Computers opened the next day, and more importantly before Darren had. (I even put my name on the scoreboard that showed at the start of the game.) Just to be complete, the first game that I ever cracked was an accident. Before Darren showed me how to do it the correct way, I was playing the copied games from the disk box, and was loading up "Scroll of Abadon" by Access Software, when I remembered that it sucked. So, I pressed "Run/Stop" RESTORE (the equivalent of CTRL-C on a DOS app), and it returned to the READY prompt. Well, being curious, I did the automatic response "list", and a small BASIC program was displayed to the screen. This was puzzling, as the loader for the game was an assembly language app. I threw in a blank disk, and tried to save it. It wouldn't save (Disk drive was probably in the middle of checking the protection or something when I stopped the program, leaving it in a weird state). I tried to PRINT it to the printer, that wouldn't work. (It never occured to me to unplug the power to the floppy drive, and reset it). So, I found some paper, and a pen, and transcribed it from the monitor. Once I had it down, I cycled power on the 64, and typed it back in with the game disk in the drive. It loaded and played the game! That was cool! So, I file copied the files from the game disk to the blank I mentioned earlier. (so as to NOT copy the bad sectors used for the protection over). Once this was done, I ran my typed in program on the NEW disk, and it ran. Woohoo I had cracked a game. Albeit by complete accident, but it still counted! :-)
And thus began my cracking career.
Wednesday, August 6, 2008
Rob Northen's Copylock
This protection originated on the Atari ST (or at least Wikipedia says it did). I first saw it on a game called Castle Master. The game itself was a piece of junk, but the protection had my attention from the beginning.
When you ran the protected game, the first thing that got executed was the Copylock loader which was attached to the game's .exe at the publisher. This loader would check some sectors on the floppy, and if everything was kosher, it would unencrypt the game, and jump to it to start it.
Now a quick tour through the X86 architecture in order to facilitate greater understanding of the subject matter to follow. The X86 has provisions in the hardware to assist in the debugging of programs. We are specifically referring to the interrupt (or INT) vectors. In DOS, these vectors pointed to a function that would handle things like a Divide by 0 error, a key press on the keyboard, or a timer tick happening. There were also a couple for use by debuggers. There were the single step interrupt (INT 1), and the general debug interrupt (INT 3). The way they worked is like this. When you were using a debugger, and wanted to break at a specific address, the debugger would replace the op-code at that address with the INT 3 call (which was a $CC op-code). Then, when the processor got to that address, it would call the function pointed to by the INT 3 vector in memory. (Which pointed to a function in the debugger which showed you the registers, the current instruction, and the like). Then, let's say that you want to single step some lines to watch the values change. When this was happening, the debugger would set the trace bit in the flags register. This caused the processor to execute 1 instruction, and then call the function pointed to by the INT 1 vector in memory. So, if you think about it, this allows you to execute a line, and see the results. Pretty handy if you ask me!
Now we'll talk about how Copylock used these to it's advantage. When you first starting executing the loader, it would setup the INT 1 & INT 3 vectors to point to a couple of it's internal functions, and then call INT 3 out of the blue. A closer examination of this code showed that it was there to enable/disable the decryption. (More on why this was necessary later). This set the trace flag as mentioned above, and then returned. Upon returning, 1 "normal" instruction would be executed, and then INT 1 would be called by the processor. (As it thinks a debugger is running). The interesting thing here is what the INT1 handler did! It would re-encrypt the last instruction, and unencrypt the NEXT instruction. Just in time for it to be executed. So, this meant that if you broke in with you handy debugger (Soft-Ice, or Turbo Debugger), then all you got to see was 1 instruction in the clear! As I said above, they used INT 3 to turn the encryption on and off. This was because being a DOS app, they had to call BIOS and DOS functions to get anything done, and since THEY weren't encrypted, they had to turn off the INT 1 handler before calling any function not belonging to them. Now, just in case you think that you could do all this INT handling manually, and look at the instructions, there were a bunch of loops, and useless crap added to make it painfully time consuming to do so. (And, with them owning both debugger INTs, you couldn't single step, or set a breakpoint either!).
Now a little about the disk protection itself:
The way the "verification track" was laid out on the key disk was as 1 long track. A normal track is broken up into sectors, and has a sector header, sector trailer on it. This track was written as 1 long track with no sector breaks in it. One of my big regrets was that I never tried the CopyIIPC option board on it to see if it would make a working copy. At the time nothing else would. The genius of this protection was that they encrypted the game with checksums from the sectors on the protected track. So, during the "verification phase", they would read a sector, and checksum it. They would then use this checksum as one of the keys for the decryption of the game. Thus, if the reads are wrong, the game won't work. Also, if you zipped up the game, and sent it to someone, they couldn't unpack it, as they didn't have a working copy, and thus didn't have the correct decryption keys.
This little piece of heaven took me a month to get worked out. Here's how I did it.
I wrote a loader that used the timer tick interrupt (INT 8, which triggered 18.xx times a second), to watch for the INT 1, INT 3 vectors to change. When they did, it grabbed the INT 3 address, and saved it off, and changed those it to point to me. When they turned the decryption ON, or OFF, I incremented an internal counter. After they did it X times, (I think it was 13), they were DONE with the protection check, and were ready to process the relocation table, and jump to the game's entry point. This is where the REAL weakness was exposed. When you, as the person at the game company, ran the Copylock installer, it read the header from the .exe file, and stored it inside the resulting executable. Furthermore, they left the relocation table in it's original form. So, when the last INT 3 happened, I opened an output file, wrote out the exe header (which he was nice enough to leave for me), followed by the relocation table, followed by the actual game code. Then, it closed the file, and returned from the interrupt. This was a nice "Smack in the face", as when I was done saving out the unprotected copy, the game ran as though "I was never there". :-)
OK, in case you are wondering how I found out about the code inside that nasty encryption, here's how: I loaded up the game using good old DOS debug, and modified the INT 1 handler so that when it wrote out the unencrypted bytes to the normal place, it also saved me a copy in HIGH memory away from anything that it might need to use. Then, when the game exited I just went into high memory, and saved it out, and ran it through a disassembler so that I could print it out, and chew on it.
This is the one protection that I'm the proudest of not only finding a way around, but actually making a tool that I gave to our European people to use on originals when they got them from the shops. (And it worked everytime!) The first use was on some crappy Soccer Manager game. They called me from the U.K. to have me talk them through using it. After that, they were off to the races!
But that's NOT where the story ends. A few months after my tool was distributed to our folks, we started seeing games that weren't wrapped by the Copylock wrapper, but instead had a function call in them that did all the nasty stuff mentioned above, and just returned a 1 or a 0 to state whether it had worked. As I noted in the NFO file for S.T.U.N. Runner, "Copylock in a call, the stupidest idea EVER!". It was only a shadow of it's old self, as you could just jump over the call, and the compare, and right into the game, and you were done.
Well, that's it for tonight. Hope you enjoyed this, and if you have any questions, feel free to ask!
When you ran the protected game, the first thing that got executed was the Copylock loader which was attached to the game's .exe at the publisher. This loader would check some sectors on the floppy, and if everything was kosher, it would unencrypt the game, and jump to it to start it.
Now a quick tour through the X86 architecture in order to facilitate greater understanding of the subject matter to follow. The X86 has provisions in the hardware to assist in the debugging of programs. We are specifically referring to the interrupt (or INT) vectors. In DOS, these vectors pointed to a function that would handle things like a Divide by 0 error, a key press on the keyboard, or a timer tick happening. There were also a couple for use by debuggers. There were the single step interrupt (INT 1), and the general debug interrupt (INT 3). The way they worked is like this. When you were using a debugger, and wanted to break at a specific address, the debugger would replace the op-code at that address with the INT 3 call (which was a $CC op-code). Then, when the processor got to that address, it would call the function pointed to by the INT 3 vector in memory. (Which pointed to a function in the debugger which showed you the registers, the current instruction, and the like). Then, let's say that you want to single step some lines to watch the values change. When this was happening, the debugger would set the trace bit in the flags register. This caused the processor to execute 1 instruction, and then call the function pointed to by the INT 1 vector in memory. So, if you think about it, this allows you to execute a line, and see the results. Pretty handy if you ask me!
Now we'll talk about how Copylock used these to it's advantage. When you first starting executing the loader, it would setup the INT 1 & INT 3 vectors to point to a couple of it's internal functions, and then call INT 3 out of the blue. A closer examination of this code showed that it was there to enable/disable the decryption. (More on why this was necessary later). This set the trace flag as mentioned above, and then returned. Upon returning, 1 "normal" instruction would be executed, and then INT 1 would be called by the processor. (As it thinks a debugger is running). The interesting thing here is what the INT1 handler did! It would re-encrypt the last instruction, and unencrypt the NEXT instruction. Just in time for it to be executed. So, this meant that if you broke in with you handy debugger (Soft-Ice, or Turbo Debugger), then all you got to see was 1 instruction in the clear! As I said above, they used INT 3 to turn the encryption on and off. This was because being a DOS app, they had to call BIOS and DOS functions to get anything done, and since THEY weren't encrypted, they had to turn off the INT 1 handler before calling any function not belonging to them. Now, just in case you think that you could do all this INT handling manually, and look at the instructions, there were a bunch of loops, and useless crap added to make it painfully time consuming to do so. (And, with them owning both debugger INTs, you couldn't single step, or set a breakpoint either!).
Now a little about the disk protection itself:
The way the "verification track" was laid out on the key disk was as 1 long track. A normal track is broken up into sectors, and has a sector header, sector trailer on it. This track was written as 1 long track with no sector breaks in it. One of my big regrets was that I never tried the CopyIIPC option board on it to see if it would make a working copy. At the time nothing else would. The genius of this protection was that they encrypted the game with checksums from the sectors on the protected track. So, during the "verification phase", they would read a sector, and checksum it. They would then use this checksum as one of the keys for the decryption of the game. Thus, if the reads are wrong, the game won't work. Also, if you zipped up the game, and sent it to someone, they couldn't unpack it, as they didn't have a working copy, and thus didn't have the correct decryption keys.
This little piece of heaven took me a month to get worked out. Here's how I did it.
I wrote a loader that used the timer tick interrupt (INT 8, which triggered 18.xx times a second), to watch for the INT 1, INT 3 vectors to change. When they did, it grabbed the INT 3 address, and saved it off, and changed those it to point to me. When they turned the decryption ON, or OFF, I incremented an internal counter. After they did it X times, (I think it was 13), they were DONE with the protection check, and were ready to process the relocation table, and jump to the game's entry point. This is where the REAL weakness was exposed. When you, as the person at the game company, ran the Copylock installer, it read the header from the .exe file, and stored it inside the resulting executable. Furthermore, they left the relocation table in it's original form. So, when the last INT 3 happened, I opened an output file, wrote out the exe header (which he was nice enough to leave for me), followed by the relocation table, followed by the actual game code. Then, it closed the file, and returned from the interrupt. This was a nice "Smack in the face", as when I was done saving out the unprotected copy, the game ran as though "I was never there". :-)
OK, in case you are wondering how I found out about the code inside that nasty encryption, here's how: I loaded up the game using good old DOS debug, and modified the INT 1 handler so that when it wrote out the unencrypted bytes to the normal place, it also saved me a copy in HIGH memory away from anything that it might need to use. Then, when the game exited I just went into high memory, and saved it out, and ran it through a disassembler so that I could print it out, and chew on it.
This is the one protection that I'm the proudest of not only finding a way around, but actually making a tool that I gave to our European people to use on originals when they got them from the shops. (And it worked everytime!) The first use was on some crappy Soccer Manager game. They called me from the U.K. to have me talk them through using it. After that, they were off to the races!
But that's NOT where the story ends. A few months after my tool was distributed to our folks, we started seeing games that weren't wrapped by the Copylock wrapper, but instead had a function call in them that did all the nasty stuff mentioned above, and just returned a 1 or a 0 to state whether it had worked. As I noted in the NFO file for S.T.U.N. Runner, "Copylock in a call, the stupidest idea EVER!". It was only a shadow of it's old self, as you could just jump over the call, and the compare, and right into the game, and you were done.
Well, that's it for tonight. Hope you enjoyed this, and if you have any questions, feel free to ask!
Tuesday, August 5, 2008
Eric Zmiro's Best Protection Kit
This was a protection system that was on the Titus games released from France. I always got them from Funakashi in a TeleDisk file, and had to unpack them to a floppy and go from there.
Eric is obviously the programmer of the protection, and in most cases also the programmer of the game that the protection was on. In the latter releases it had become quite nasty, that's why I was glad to have gotten in early. Here's the story:
The "Best Protection Kit" was released in stages. It was almost like Eric didn't really have the time to devote to getting it all worked out the FIRST time, so he implemented pieces along the way. The way that this protection worked was it had a small .com loader that performed the disk check, and then if it passed, it loaded and executed the game's .exe. Simple enough in theory. The problem was, his loader was encrypted, and had all kinds of nasty anti-debug tricks in it to try to stop me from doing what I wanted to do. And the game's .exe was packed with his custom packer which produced an .SQZ file. In the early days, his encryption was relatively weak, so I unencrypted the whole loader, and found the code that unpacked the .SQZ file in memory, and then jumped to it. I pulled the decompression code out, and made a stand-alone program that would load, unpack, and save the .SQZ files back to the HD in bare .exe format.
So, when a new Titus game came out, I deleted the .com loader, and ran the tool that Eric had helped me to make, on his .SQZ file, and I had a working version of the game, with no protection.
He never figured this out, and all the way up to the last Titus game that I saw, my tool worked like a charm.
Funny comment. JROK had a go at one of his protections back circa '90 or so, and referred to him as Eric "How do I love me" Zmiro.
Eric is obviously the programmer of the protection, and in most cases also the programmer of the game that the protection was on. In the latter releases it had become quite nasty, that's why I was glad to have gotten in early. Here's the story:
The "Best Protection Kit" was released in stages. It was almost like Eric didn't really have the time to devote to getting it all worked out the FIRST time, so he implemented pieces along the way. The way that this protection worked was it had a small .com loader that performed the disk check, and then if it passed, it loaded and executed the game's .exe. Simple enough in theory. The problem was, his loader was encrypted, and had all kinds of nasty anti-debug tricks in it to try to stop me from doing what I wanted to do. And the game's .exe was packed with his custom packer which produced an .SQZ file. In the early days, his encryption was relatively weak, so I unencrypted the whole loader, and found the code that unpacked the .SQZ file in memory, and then jumped to it. I pulled the decompression code out, and made a stand-alone program that would load, unpack, and save the .SQZ files back to the HD in bare .exe format.
So, when a new Titus game came out, I deleted the .com loader, and ran the tool that Eric had helped me to make, on his .SQZ file, and I had a working version of the game, with no protection.
He never figured this out, and all the way up to the last Titus game that I saw, my tool worked like a charm.
Funny comment. JROK had a go at one of his protections back circa '90 or so, and referred to him as Eric "How do I love me" Zmiro.
Hello and welcome!
Sometime in the summer of '09 will mark my 25th anniversary of being a copy protection tourist. During this time, I've looked at literally 1000's of different protection schemes from the stupid, to the stupendously elaborate. On my blog here, I plan to tell you about some of them, and tell you some stories from my life behind the patch.
You might be asking yourself what a "copy protection tourist" is, well, let me explain. If I get a software package with copy protection on it, I HAVE to pull out the toolkit and have a look under the hood. I have always said that some people work crossword puzzles, I examine protection code.
Throughout the years I have undoubtedly cost some programmers some money with my exploits, and I'm sorry for that, but for what it's worth, some of you guys really made me work for it!
I'll start off with one from Europe circa 1991. It was a DOS game (CGA/EGA graphics) called Superman. Published by some no-name publisher. This game had the WORST copy protection I have ever seen on it. That's not just hyperbole either, wait till you see it. Upon listing the directory of the floppy, I saw files similar to this:
runme.bat
superman.exe
s2.exe
(and some unimportant data files)
So, being brave, I ran the batch file. It went into graphics mode, and popped up a doc check (Enter this word from this page of the manual). I entered Fabulous or some such as I always did, and of course it failed. When it failed, it set things back to text mode, and just exited. So, I looked at the batch file, and was SHOCKED at the contents. I'll try to reproduce the contents here:
@echo off
superman
if errorlevel 1 goto fail
S2
:fail
Here's how it worked: When you ran the batchfile it ran superman, which was ONLY the doc check program. When you entered your word, it checked it, and returned a value based on it:
if(DocCheckPass == true)
RetVal = 0;
else
RetVal = 1;
exit(RetVal);
And then had the batchfile make the decision on whether to run the game or not. So, the fix for this, was to delete superman.exe from the disk, rename S2.exe to Superman.exe, and clean up the batch file. This was so easy that I let Dave (Candyman) do it so that he could say he had cracked something.
That's it for THIS post. In the future I'll try to make the each post describe a protection system that I've seen. I hope you enjoyed it!
You might be asking yourself what a "copy protection tourist" is, well, let me explain. If I get a software package with copy protection on it, I HAVE to pull out the toolkit and have a look under the hood. I have always said that some people work crossword puzzles, I examine protection code.
Throughout the years I have undoubtedly cost some programmers some money with my exploits, and I'm sorry for that, but for what it's worth, some of you guys really made me work for it!
I'll start off with one from Europe circa 1991. It was a DOS game (CGA/EGA graphics) called Superman. Published by some no-name publisher. This game had the WORST copy protection I have ever seen on it. That's not just hyperbole either, wait till you see it. Upon listing the directory of the floppy, I saw files similar to this:
runme.bat
superman.exe
s2.exe
(and some unimportant data files)
So, being brave, I ran the batch file. It went into graphics mode, and popped up a doc check (Enter this word from this page of the manual). I entered Fabulous or some such as I always did, and of course it failed. When it failed, it set things back to text mode, and just exited. So, I looked at the batch file, and was SHOCKED at the contents. I'll try to reproduce the contents here:
@echo off
superman
if errorlevel 1 goto fail
S2
:fail
Here's how it worked: When you ran the batchfile it ran superman, which was ONLY the doc check program. When you entered your word, it checked it, and returned a value based on it:
if(DocCheckPass == true)
RetVal = 0;
else
RetVal = 1;
exit(RetVal);
And then had the batchfile make the decision on whether to run the game or not. So, the fix for this, was to delete superman.exe from the disk, rename S2.exe to Superman.exe, and clean up the batch file. This was so easy that I let Dave (Candyman) do it so that he could say he had cracked something.
That's it for THIS post. In the future I'll try to make the each post describe a protection system that I've seen. I hope you enjoyed it!
Subscribe to:
Posts (Atom)