My goal here is to take some of the mystery out of the copy protection system that is used in the Jaguar game system for the CD unit. I may not be able to answer every question on this subject or may be completely accurate. I can only convey my experience and knowledge I learned over the years in my attempt to understand exactly how it works. Since the time Atari went under in 1996 I had been on a quest to find or reverse engineer the private key used to encrypt Jaguar CD's. The Jaguar Community is fortunate that Curt Vendel was able to locate the particular floppy disk that contained the correct keys. I had an idea what the disk look like because I got this information from the man who was responsible for developing the Jaguar's copy protection system. And I knew what the key looked like because of various test keys that were found on some hard drives from Atari. I was able to convey this information to Curt where he used this to locate the missing disk. I am completely grateful to Curt for finding the encryption keys and releasing these keys to the Jaguar Community. I had considered the search for the encryption keys the equivalent of the "Holy Grail" for the Jaguar. I am also grateful that Hasbro Interactive had the wisdom to place the Jaguar in the public domain and allow us to continue developing for the system without the threat of legal action.
The Tramiel lead Atari tried to use the Jaguar as their attempt to get back into the business of video games. Atari was not doing so well with the booming business of IBM PC clones from the Asian market. Unfortunately, having technically advanced system is not enough to stay in business in today's video game market. You need solid hits and solid marketing strategies as a start. Atari eventually had to throw in the towel, or what I like to refer to as "had a heart attack." The Tramiel's did their best to bury the Jaguar in order to make it go away and never come back. But the Jaguar community did not allow that to happen. Through relentless effort of some developers, publishers, fans, and businesses the Jaguar is still a wonderful and happening system for those who love to play games on it.
As part of learning from the downfall of the 2600 that occurred in the early 80's, video game manufactures learned that they needed some sort of protection and control over their systems. They required a method in order to ensure people can't make illegal copies of the system's games and to ensure that only licensed games were developed and marketed for their system. These protection methods do vary.
Nintendo used a hardware chip on their NES system game cartridges that would unlock the game system by providing a special signal to the game console. Sony used a simple message recorded on their game CD's using special recording hardware (as best as I understand the PS1 protection system). Classic computer systems used bad sectors, fuzzy sectors, pseudo code, overwriting code, dongles (hardware keys), and many other developed techniques. And some, like Atari, used cryptography.
Since the 7800 game system, Atari used an authentication system based on cryptography using a public/private key system and a hash (checksum) generating system. They used this authentication style cryptography system in the 7800, Lynx, and Jaguar. The cryptography used in the Jaguar is based on RSA - which happens to be the initials of the three gentlemen who developed the one-way math functions used to encrypt/decrypt messages. The hash system is based on a system called MD5 which is a system to digest messages and create like a digital signature. You see this used a lot today to create a signature of a file in order to determine the integrity of the data that is contained in a file. MD5 is very useful for this because the same data, just order differently, will create different signature that make them unique like a fingerprint.
The RSA encryption algorithm is rather a simple mathematical process. The system relies on the use of very large prime numbers - numbers that only have itself and 1 that can be evenly divided into them (e.g., 11, 17). Another thing about prime numbers is that there isn't any easy way to generate them. Prime numbers don't recur in predictable patterns. And it's difficult to determine if a very, very large number is completely prime. To truly know this you would have to test by trying every number between the number itself and 1 to see if another number exists that can evenly divide into the number. Should you happen to chose a set of prime numbers that are large enough, it would take someone a long time to figure out what two numbers you had picked. But I don't want to turn this into a novel about RSA. I'm not an expert in it.
Since RSA is a public key based system it requires two keys to function - a private key and a public key. These keys are generated from the two prime numbers that would typically be generated from some source random data or information using a special program built for key generation. One key you hang onto and never release, and you probably already guess this - the private key. The other key you give out to the world - the public key.
Now, depending on how you employ these keys determines on whether you authenticate or encrypt a message. If you plan on sending a message to someone that only they can decrypt and read, you would use a public key to encrypt it. But this is not just any public key, but the public key that the person you are sending the encrypted message has provided to you. Since they should be the only one that has possession of their private key then only they would be the only one who can decrypt the message that you're sending to them. Only the private key can open that message.
But on the other hand, say you just want to authenticate a message. Authenticate by digitally signing the message to give the receiver assurance that you, and only you, had sent that message. You do this by using use your private key to encode a copy of the message with the original message. The receiver of the message would be able to decode the message using your public key and compare the two messages, the decoded message and original message and verify they match and were not altered. The Jaguar uses a method similar to this authentication method to ensure only game cartridges and CDs published for the Jaguar by Atari are able to run on the system.
We have a tendency in the Jaguar community to refer to the protection system as encryption. But it truly is just an authentication system. Atari employed this method in the 7800, Lynx, and Jaguar to ensure that they were the only ones publishing game for their system. They did not want to repeat mistakes that occurred during the 2600's downfall and eventual crash of the video game market during Christmas of 1983.
The Jaguar authentication is based on a 518-bit key. Why 518 bits? Why not 64, 128, 256? Dave Staugas, the programmer for the Lynx and Jaguar protection systems, told me he chose 518 because 512 bits makes up 64 bytes and that he added 6 more bits for good measure.
When I told him about my plans to try and reverse the key he told me that I was crazy and that there wasn't enough time left remaining in the existence of the universe to do that. I sat down and did some simple math figure out that he's right. Pretty mind blowing, huh? This is roughly based on the idea of using a Jaguar to try every permutation of 1's and 0's contained in 518 bits. I figure if I could successfully test one key per second by encrypting a known good set of data and compare the results with a known encrypted copy that it would take roughly 2.72e+148 years to try every bit combination. Now I could cut that time in half by eliminating all the even numbers since the key will be based on an odd number. But that only drops it down to 1.36e+148 years. No one would be around to care anymore!
Here are numbers I calculated: 2 raised to the power of 518 is approx. = 8.5809970751632621437273759988517e+155. Divide this by the number of seconds per year (31557600).
Now hiding under this authentication is a MD5 message digest of the cartridge or CD. It is believed that on the cartridge protection system for the Jaguar that the encryption header is decoded and then a special GPU or DSP program is run to perform the MD5 message digest function on the game cartridge contents (another reason my idea above wouldn't have worked either). One of the funny things about this is the 32-bit checksum that this message digest must generate. The number, in hexadecimal, is 0x03D0DEAD. Which when read out says, "3DO is dead!" 3DO was a competing game console company at the time when the Jaguar was in its prime. This MD5 program is modified so that the particular game cartridge contents that are being verified will generate that 0x03D0DEAD checksum. This modified program is then encoded using the RSA crypto system and placed in the header of the game cartridge (a special section of memory reserved for the encrypted program). This header is then decoded by the Jaguar boot code at startup and the MD5 program is executed and lets the Jaguar know whether to start the cartridge or not. Should a single bit within that cartridge be changed then the authentication process fails and the cartridge is not allowed to start.
The only way to get around the cartridge authentication system is 1) change the boot ROM used in the Jaguar with something like the BJL or Atari's developer ROM, 2) use a hardware bypass method that is loosely based on the flash cart (used in some early Songbird Jaguar releases), or 3) do what the 4-Play guys did for original Battlesphere release. They use a set of eight Jaguar's using specially built hardware and program code to try every combination of byte variations in the encryption header on the cartridge - each one trying a different range of numbers to distribute the work load among the eight Jaguar's. They had the Jaguar's running 24/7 for over 4 months and on backup power in case of power outages! The amazing thing is they did it and were the only one's outside of Atari to be able to publish a game for the Jaguar without having to go through Atari to get it properly encrypted!
Now, the CD is slightly different than the cartridge. The CD basically uses the same RSA and MD5 routines and key sizes. The CD does have a different public and private key than what is used for the cartridge. But for the CD, the contents of the second session, where the boot track lies, and beyond are run through the MD5 message digest, broken up into blocks of anywhere from 128k to 1M byte in size, in order to generate a hash table. This hash table is then encrypted, using the private key, and placed in the last track on the CD. It is placed there so the CD startup routine always knows where to find it.
Now, based on this you would think it would be easy to circumvent. Like maybe using an encryption track from another Jaguar CD, along with the boot track and some data tracks. Then have the ability to insert code of your own in there somewhere to get control of the system in order load a game you developed instead. But this is just not possible. When the CD boot code runs the authentication code takes control of the system and looks at the contents of the CD using the CDs table of contents (a.k.a. the TOC) and chooses three random blocks to on the CD to verify.
These blocks are randomly picked from the various tracks on the CD, except any tracks located in the first session. One of these blocks always comes from the boot track. The other two come from other tracks within the second session or beyond if there are 3 or more sessions on the CD. Also mixed with this authentication is a comparison of the CD's TOC to ensure no track has been altered. If any portion of the TOC does not match, the authentication fails. This particular feature makes it difficult to just do a simple copy Jaguar CD's using a standard CD copying tools. Atari chose the three random blocks to make the CD boot as quickly as possible. They were worried if authentication took too long that it would hurt the CD in sales, so they had to balance an effective authentication system with speed.
Making copies of an audio CD doesn't always produce exact copies since audio CD's don't use any truly effective error detection to know when the data wasn't read during the playback process. It's also not possible to do exact positioning of the laser on an audio CD when playing so you can't control how much data you have to read before you get to the exact position you want (this makes programming for the Jaguar CD a challenge). Also, most standard CD copying tools don't handle the Jaguar CD format very well because of its non-standard layout. Redbook audio standards were never intended to be used in a multi-session format. As you may see by now, Atari really put a lot of time and thinking into choosing the particular CD layout and protection methods that they employed in the Jaguar. Not only did this layout give them some marketing advantage (Jaguar CD's hold 720MB's as oppose to 640MB for standard data CDs) but its non-standard format was not supported by CD copying programs at the time (or even the majority of copying programs still made today).
The encryption track on the Jaguar CD contains an encrypted hash table that is 156,192 bytes in size. No matter how big or how small the CD is, this encrypted hash table is always 156,192 bytes in size. It is usually padded with zeros to give the track some additional bytes to make it large enough to place on a CD.
It's also interesting to note that within Atari only a small handful of employees had access to the encryption disk. I believe Leonard Tramiel himself kept close guard of this disk. Also, Atari had a secret employee who job was to encrypt game cartridge images for the company. Employee's were told that if they needed something encrypted that they were to place a copy of the file in a certain directory on their VAX/VMS network and that a new image file would be found there the next day (or something to that effect). I believe Dave Staugas was this secret employee since he was the guy who wrote the RSA and MD5 routines for the Jaguar and Lynx. He was a well liked by Jack Tramiel. He was also a very talented programmer. In my opinion, his RSA code for the Jaguar is a work of art. I have yet to determine the kind of math he employed in the program (have anyone ever heard of Montgomery coefficients?) and what kind of math or programming class that teaches that kind of stuff. Later on, when Atari merged with JTS, John Skruch was the employee who would encrypt cartridges and CDs. I believe the last product he did the encryption for was Iron Soldier 2 for Telegames. John Skruch was also the last employee of Atari, and probably the longest employed with them (he was there during Warner and Tramiel Atari's). Great guy if you ever get to meet him.
Well, I just spent the last several hours dumping my knowledge about an interesting part of the Jaguar - its protection system. I hope I provided you with some education about the Jaguar's authentication system and also hope you found some of the history enjoyable to read. You will find below a copy of the public and private key for the Jaguar CD just so you can see what they look like. Nothing fancy, just a collection of 65 bytes of numbers.
PUBLICD.KEY file
;public: |
private: |