17 replies to this topic

[LinkoVitch]

Hiya
I have read a few threads, sites, where the rarety and cost of EPROMS is brought up. What type of EPROMS does a Jag Cart require? I take it 2MBytes typically of storage but am guessing that this can span several chips.

I did a quick search and found that 512K EPROMS are availible for £9.99 so 2 making 1 MB brings the cost of the cart to £20 (plus your save ram etc etc).

Is this about right? Or do Jag carts need EPROMS of a specific type/speed ?

[LinkoVitch]

just to stay true to form I messed the prices up £9.99 was for an 8MB EPROM.. 512K ones are only £2.49

I guess then that these are not suitable for carts?

[Thunderbird]

The way to go these days is to develop code on the alpine board and then burn it onto a CD to use a bypass cart to load with. It costs an order of magnitude (or 3 or 4) less to make a CD than to make a cart game. There's a lot of bypass stuff in development from what I'm hearing. It's the reason I made JUGS DD in the first place. Making carts is a huge pain in the butt!!!

[Thunderbird]

The way to go these days is to develop code on the alpine board and then burn it onto a CD to use a bypass cart to load with. It costs an order of magnitude (or 3 or 4) less to make a CD than to make a cart game. There's a lot of bypass stuff in development from what I'm hearing. It's the reason I made JUGS DD in the first place. Making carts is a huge pain in the butt!!!

[LinkoVitch]

I was thinking this myself.. although there is something nice about a cart.. Plus I have always wanted to make a cart

Whats the issue with producing Jag CD's that don't require a bypass cart? I am guessing they are encrypted, and that they also have bad block protection on the disc?

[Thunderbird]

LinkoVitch said:

I was thinking this myself.. although there is something nice about a cart.. Plus I have always wanted to make a cart

Whats the issue with producing Jag CD's that don't require a bypass cart?  I am guessing they are encrypted, and that they also have bad block protection on the disc?

You got it. The encryption protected Atari from losing their royalties on every game like what happened with the 2600.

[LinkoVitch]

I am sure I have seen the encryption keys downloadable somewhere. If they are availible, then is it not possible to encrypt the disc's that are home made, so they work?

[atarifan49]

LinkoVitch said:

I am sure I have seen the encryption keys downloadable somewhere.  If they are availible, then is it not possible to encrypt the disc's that are home made, so they work?

What you're referring to is the universal encrypted header for the cartridge. The actual encryption keys are still no found at this time.

It was available on www.cgexpo.com. Don't know where it's available now.



Glenn

[LinkoVitch]

didn't hasbro release them into the community?

What type of encryption is it? symetric? if so, has no mad man yet set asside some cpu cycles and had a damn good go at cracking it?

[Thunderbird]

LinkoVitch said:

didn't hasbro release them into the community?

What type of encryption is it? symetric?  if so, has no mad man yet set asside some cpu cycles and had a damn good go at cracking it?

I attempted to crack it but found it was easier to simply hack the thing for the BattleSphere original release.

There's details of my process on various websites but essentially I rigged a little 8-bit CPU to change (increment) unused values in our code in a RAM soldered in place of a cart ROM and reset the Jaguar. If the Jag booted to the red screen it would try again. This was a simple time delay. If the game booted then it would wiggle a line that told the CPU that it succeeded in finding a valid.

In other words some bogus data was stuck into our binary until the checksum matched the value the Jag was looking for. If the data was good our game would run and halt the testing process. If data was bad then the game would not run and after a suitable time period waiting to be sure the game was not running the process was tried again with another bogus value.

It took months for a bank of 8 Jaguars to figure it out!

Man that felt good!

[gusbucket13]

That is interesting Thunderbird, would it not be possible now you know what the encryption was looking for ie the value inserted - to reverse engineer it and come up with the encryption code itself. sort of saying heres the answer now what was the problem I know, but when you have lots of answers - like using quadratic equations in algebra you can eventually establish values for the equation and solve it.

I guess that you never actually got to see the successful cheat values inserted by your hacking rig up or you would have worked this one back for yourself and obtained the encryption code.

Cudos on doing that anyway - it was pioneering work that had to be done by someone or the death knell really would have been sounded for the Jag!

Cheers
Gusbucket13

[LinkoVitch]

i read on a site that the current hack is a backdoor past the encryption that was built in incase the actual key was ever lost. It also explained the way the encryption works. something along the lines of.

The first 8K of data on the cart is the checksum of the cart. If you then run the key over the cart data the checksum should match the one on the cart.

So if this is the case, doesn't that mean the Jag knows the key. so it must have it stored somewhere. If you disassemble the standard Jag bootROM surley the key is stored within that?

Simply retrieve the key and use that to generate the checksum data. (means games boot slower at first whilst the Jag checks the values. But I guess it should work.

Or possibly even, make a modified bootrom, so you stick in your cart. The jag then generates the checksum it expects to find in the 8K, and if it doesn't match, instead of going red screen on us, it simply echos the value to screen/carts NVRAM. If this worked you could use a jag as a crypt jag. and when you write something you could get it to generate the code you need for that line of carts.

I am going to have to have a stab are dissassembling the Jag rom see if I can make any sence out of it. Does anyone have a memory map of the Jag?

[atarifan49]

LinkoVitch said:

i read on a site that the current hack is a backdoor past the encryption that was built in incase the actual key was ever lost.  It also explained the way the encryption works.  something along the lines of.

There's a rumor of a backdoor. Haven't seen anybody actually confirm this. Maybe the universal header that's available is that backdoor?

LinkoVitch said:

The first 8K of data on the cart is the checksum of the cart.  If you then run the key over the cart data the checksum should match the one on the cart.

The first 8k (or $2000 hex bytes - memory locations $800000 to $801FFF) contains an RSA encrypted program for the GPU. This encrypted program is a MD5 algorithm that is a digest of the cartridge. To put it in layman's terms - a checksum but more elaborate.

Locations $800400 to $80040C contain boot up parameters for the Jaguar (cart start address, whether the cart is 8, 16 or 32bit wide, and whether to do the start up Atari/spinning cube).

The remainder after that is just filled with $FF hex bytes.

LinkoVitch said:

So if this is the case, doesn't that mean the Jag knows the key.  so it must have it stored somewhere.  If you disassemble the standard Jag bootROM surley the key is stored within that?

The Jag only knows the public key. It does not contain the private key. Two keys are need to encrypt a Jaguar cart or CD game. Only one key is needed to decrypt and perform the authenctication.

Plus just knowing the numbers in the key is not enough. To use it with the programs that Atari wrote to encrypt games, the numbers were stored in a text file in a certain way. Here's the actual public key that is in every Jaguar boot ROM for the cartridge:

public:
dc.b $2f,$c5,$0f,$79,$b7,$96,$1b,$10
dc.b $a2,$ea,$46,$ab,$a1,$f0,$1d,$af
dc.b $c5,$c7,$94,$c0,$08,$b9,$81,$80
dc.b $5e,$5b,$93,$f5,$03,$02,$41,$fe
dc.b $75,$b7,$1c,$e8,$e7,$22,$79,$a3
dc.b $d5,$be,$30,$45,$f9,$ea,$35,$d9
dc.b $8a,$0a,$15,$40,$b4,$b4,$e8,$4e
dc.b $a6,$dd,$17,$ee,$42,$33,$10,$0d
dc.b $f9

Key things to note about this number. It is 65 bytes long. Only 518 bits of it are used (65 bytes = 520 bits). Upper two bits of the first number are not used. Last number is always odd value. Both the public and private key are a very large prime number!

LinkoVitch said:

Simply retrieve the key and use that to generate the checksum data.  (means games boot slower at first whilst the Jag checks the values.  But I guess it should work.

You still would need the appropriate private key to make it all work. But since the universal header is available, no need to do this for the cartridge. Better to devote effort to the CD key.

LinkoVitch said:

Or possibly even, make a modified bootrom, so you stick in your cart.  The jag then generates the checksum it expects to find in the 8K, and if it doesn't match, instead of going red screen on us, it simply echos the value to screen/carts NVRAM.  If this worked you could use a jag as a crypt jag.  and when you write something you could get it to generate the code you need for that line of carts.

The point is not to have to modify Jags just to boot stuff.


Glenn

[LinkoVitch]

atarifan49 said:

There's a rumor of a backdoor.  Haven't seen anybody actually confirm this.  Maybe the universal header that's available is that backdoor?

Yup, this is what I read. The test the guy did was to copy a cart to an Alpine board, test it worked on an unmodified Jag (used the Alphine as a flashcart). Then modify 1 bit of the data on the cart, test again. cart failed. Then he copied the universal header (which is the backdoor) over the current hash and the game worked fine, and booted faster as the Jag didn't do the auth check.

atarifan49 said:

The first 8k (or $2000 hex bytes - memory locations $800000 to $801FFF) contains an RSA encrypted program for the GPU.  This encrypted program is a MD5 algorithm that is a digest of the cartridge.  To put it in layman's terms - a checksum but more elaborate.

Locations $800400 to $80040C contain boot up parameters for the Jaguar (cart start address, whether the cart is 8, 16 or 32bit wide, and whether to do the start up Atari/spinning cube).

The remainder after that is just filled with $FF hex bytes.

I didn't realise it had so much in it. Using RSA makes sence as to why the backdoor (I thought symmetric would be used, but then couldn't see the need for a backdoor ). Also explains why it takes so long to generate the digest if it's using RSA.

atarifan49 said:

The Jag only knows the public key.  It does not contain the private key.  Two keys are need to encrypt a Jaguar cart or CD game.  Only one key is needed to decrypt and perform the authenctication.

Still if it's not a symmetric key pair it's easier to crack. All wee need is a cray and a week I am sure if you set asside a PC long enough we could get this here key.

atarifan49 said:

Plus just knowing the numbers in the key is not enough.  To use it with the programs that Atari wrote to encrypt games, the numbers were stored in a text file in a certain way.

I am sure once you have the key, writing the software to do the crypt is faily basic in comparison.

atarifan49 said:

Key things to note about this number.  It is 65 bytes long.  Only 518 bits of it are used (65 bytes = 520 bits).  Upper two bits of the first number are not used.  Last number is always odd value.  Both the public and private key are a very large prime number!

but it's not impossible! this is the good point!

atarifan49 said:

You still would need the appropriate private key to make it all work.  But since the universal header is available, no need to do this for the cartridge.  Better to devote effort to the CD key.

I was assuming that this would be the same key as for the CD's. But then, if the carts have a backdoor, surely the CD's must too have a similar backdoor built in? Or the same universal header may work?

I think the problem with CD's would be the bad block protection, but I am sure this could be got around with modern CD writing technology (clone CD etc)

atarifan49 said:

The point is not to have to modify Jags just to boot stuff.

Sorry, you misunderstood me. I meant the developer has ONE jag that they use to generate the necissary hash which is the one with the modified ROM. Once this is done, the hash is simply copied onto the carts and works in any other jag. probably not possible

[atarifan49]

LinkoVitch said:

Yup, this is what I read.  The test the guy did was to copy a cart to an Alpine board, test it worked on an unmodified Jag (used the Alphine as a flashcart).  Then modify 1 bit of the data on the cart, test again.  cart failed.  Then he copied the universal header (which is the backdoor) over the current hash and the game worked fine, and booted faster as the Jag didn't do the auth check.

That was me. That's what I did to verify the universal header was the real McCoy. I can't remember which cart image I used. If it was Raiden or Dino Dudes.

LinkoVitch said:

I am sure once you have the key, writing the software to do the crypt is faily basic in comparison.

Why write the software when I have it. But it's useless without the keys.

LinkoVitch said:

I was assuming that this would be the same key as for the CD's.  But then, if the carts have a backdoor, surely the CD's must too have a similar backdoor built in?  Or the same universal header may work?

I think the problem with CD's would be the bad block protection, but I am sure this could be got around with modern CD writing technology (clone CD etc)

Unforuntately, they are not the same. I do know the public key value for the CD also. And they are different for CD and cart. So the private keys are going to be different.

I don't know where everyone is getting this bad block protection idea. There are no intentional bad blocks on Jaguar CDs. The whole CD is just one large multisession audio CD. Data is stored as raw audio data. Intentional bad blocks are not in Atari's specification for the Jaguar CD format that's described in the developers manual.

The last track of the CD in the last session contains the authentication data. A track that contains a length of data around 153k bytes. This is a RSA encrypted MD5 digest program for the GPU to run and perform data checks on the CD data to ensure it's an approved Atari released game.

If people are getting bad block indications from CD copying software, that is due to the fact that the Jaguar CD format is not a recognized CD format so the CD copying software just doesn't know how to interpret it's layout (IMHO).


Glenn

[LinkoVitch]

atarifan49 said:

That was me.  That's what I did to verify the universal header was the real McCoy.  I can't remember which cart image I used.  If it was Raiden or Dino Dudes.

Congrats then

atarifan49 said:

Why write the software when I have it.  But it's useless without the keys.

Ah right, with you.. well we just need the key then

atarifan49 said:

Unforuntately, they are not the same.  I do know the public key value for the CD also.  And they are different for CD and cart.  So the private keys are going to be different.

Bummer. Still it's still possible to find. perhaps launching a Seti Esq shared crack attempt on the key would be worthwhile? Split the keyspace up and then clients connect to a server to report if they found it, and get their next work range of the keyspace to search. If enough people did it, I am sure that the key would be found quite quickly.

atarifan49 said:

I don't know where everyone is getting this bad block protection idea.  There are no intentional bad blocks on Jaguar CDs.  The whole CD is just one large multisession audio CD.  Data is stored as raw audio data.  Intentional bad blocks are not in Atari's specification for the Jaguar CD format that's described in the developers manual.

Not sure where I saw it, possibly in some random blurb somewhere. I just assumed it was true. One less thing to worry about

atarifan49 said:

The last track of the CD in the last session contains the authentication data.  A track that contains a length of data around 153k bytes.  This is a RSA encrypted MD5 digest program for the GPU to run and perform data checks on the CD data to ensure it's an approved Atari released game.

Which explains why when booting the jag CD seeks to the outter edge and then back in again. Amazing what you learn.

So is it possible to replace that with a universal block also.

(obviously a different one though)

[Thunderbird]

I for one wouldn't mind if the source for the encryption stuff was made available to look at. I'd love to be able to try and reverse engineer the cart scheme. This could provide clues to the CD scheme. I would like to be able to make bootable CD's that don't require a bypass for one thing.

[atarifan49]

Thunderbird said:

I for one wouldn't mind if the source for the encryption stuff was made available to look at. I'd love to be able to try and reverse engineer the cart scheme. This could provide clues to the CD scheme. I would like to be able to make bootable CD's that don't require a bypass for one thing.

It is. I put together a CD for B&C to sell that contains the source code.

No one seemed to care. So if you want it, call Bruce and order it.


Glenn