Curt Vendel Posted April 3, 2007 Share Posted April 3, 2007 Just making sure if these weren't already available, here ya go.... Lynx_Encrypt.zip Curt Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 3, 2007 Share Posted April 3, 2007 Hey cool, maybe someone can port it to the PC now. Or is there one already that I missed? Mitch Quote Link to comment Share on other sites More sharing options...
Curt Vendel Posted April 3, 2007 Author Share Posted April 3, 2007 I dunno, I'm not very active in Lynx dealings, but I'll be posting a lot more Lynx files and technical data shortly. Curt Hey cool, maybe someone can port it to the PC now. Or is there one already that I missed? Mitch Quote Link to comment Share on other sites More sharing options...
+karri Posted April 4, 2007 Share Posted April 4, 2007 Hey cool, maybe someone can port it to the PC now. Or is there one already that I missed? Mitch The Lynx decryption process at boot time is well understood and Harry has converted it to C-code. I have a Handy version that allows you to run the decryption in C and you can then start single-stepping from the cart loader. But the encryption process seems to need an emulated Amiga. It would be nice to include the encryption in the build process of the cc65 linker to get real Atari-signed carts -- Karri Quote Link to comment Share on other sites More sharing options...
+karri Posted April 4, 2007 Share Posted April 4, 2007 I tried to compile the encryption process on a PC. But there are a few bits missing still. Obviously the modulo is the public key also found in the Lynx ROM. The length of the key MAX_m is 51 bytes. static unsigned char N[MAX_m] = { 0x35, 0xB5, 0xA3, 0x94, 0x28, 0x06, 0xD8, 0xA2, 0x26, 0x95, 0xD7, 0x71, 0xB2, 0x3C, 0xFD, 0x56, 0x1C, 0x4A, 0x19, 0xB6, 0xA3, 0xB0, 0x26, 0x00, 0x36, 0x5A, 0x30, 0x6E, 0x3C, 0x4D, 0x63, 0x38, 0x1B, 0xD4, 0x1C, 0x13, 0x64, 0x89, 0x36, 0x4C, 0xF2, 0xBA, 0x2A, 0x58, 0xF4, 0xFE, 0xE1, 0xFD, 0xAC, 0x7E, 0x79 }; I also found a file called INPUT that looks almost as it would contain the values MAX_m, B, C (3 bytes missing). And a file MODULUS that contains N. The decryption process seems to operate in 51 byte blocks. Reading in the INPUT file I will then get: static unsigned char B[MAX_m] = { 0x00, 0x00, 0x35, 0xb9, 0xa9, 0x70, 0xdf, 0xac, 0x51, 0x73, 0x69, 0x20, 0x73, 0x69, 0x68, 0x54, 0x20, 0x2e, 0x74, 0x73, 0x65, 0x74, 0x20, 0x61, 0x20, 0x73, 0x69, 0x20, 0x73, 0x69, 0x68, 0x54, 0x0b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; static unsigned char C[MAX_m] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x67, 0x7d, 0x00, 0xae, 0xae, 0x9c, 0x0a, 0x4b, 0x75, 0xa1, 0x44, 0xc4, 0x5e, 0xe0, 0xba, 0x34, 0x20, 0x90, 0xb9, 0x72, 0x6c, 0xed, 0x2b, 0x82, 0x74, 0xda, 0xb1, 0x99, 0xb6, 0xbe, 0x9e, 0xd0, 0x39, 0x8f, 0x1b, // 3 bytes missing ? }; According to the docs A = B ** C mod N. I thought that I only would need the value C to encrypt a message B. And the Lynx would have a value D for doing the decryption like B = A ** D mod N. Usually the value D is fixed to something simple like 0x10001 while the private key C is large. Or am I missing something again? As usual... Well, I will try to compare my Lynx C-decryption routines with the published encryption routines to find out the value of D. Then finding out the missing bits of C should be possible be examining the Amiga process. -- Karri Quote Link to comment Share on other sites More sharing options...
semicolo Posted April 6, 2007 Share Posted April 6, 2007 How could we use this code without breaking the copyrights ? The first line of the files states RSA Data Security holds the rights. Quote Link to comment Share on other sites More sharing options...
+karri Posted April 6, 2007 Share Posted April 6, 2007 How could we use this code without breaking the copyrights ? The first line of the files states RSA Data Security holds the rights. Good question. On the other hand every SSL web browser uses this algorithm also. And the same is true on every credit card. So there is plenty to choose from. -- Karri Quote Link to comment Share on other sites More sharing options...
+karri Posted April 21, 2007 Share Posted April 21, 2007 I got some more information about the encryption process and the code in Curt's files don't contain enough info for doing the encryption. It is enough for decryption though. The public key is static unsigned char N[MAX_m] = { 0x35, 0xB5, 0xA3, 0x94, 0x28, 0x06, 0xD8, 0xA2, 0x26, 0x95, 0xD7, 0x71, 0xB2, 0x3C, 0xFD, 0x56, 0x1C, 0x4A, 0x19, 0xB6, 0xA3, 0xB0, 0x26, 0x00, 0x36, 0x5A, 0x30, 0x6E, 0x3C, 0x4D, 0x63, 0x38, 0x1B, 0xD4, 0x1C, 0x13, 0x64, 0x89, 0x36, 0x4C, 0xF2, 0xBA, 0x2A, 0x58, 0xF4, 0xFE, 0xE1, 0xFD, 0xAC, 0x7E, 0x79 }; as I stated earlier in this thread and the exponent for decryption is 3. But cracking a 408 bit RSA key is almost impossible. Even a 128 bit key should take a few lifetimes to crack. So the info to find the encryption key is not in this archive. PLAINTEXT = (ENCRYPTED ^ 3) % PUBLIC_KEY Wanted info is X, which Atari (or at least the Amiga encryption process) knows and we should find out. It is a 408 bit positive number: ENCRYPTED = (PLAINTEXT ^ X) % PUBLIC_KEY -- Karri Quote Link to comment Share on other sites More sharing options...
Nimtene Posted April 27, 2007 Share Posted April 27, 2007 These disks should provide some insight into the matter: Ebay: JS Atari Lynx Authentic Encryption System Disks Quote Link to comment Share on other sites More sharing options...
+karri Posted April 28, 2007 Share Posted April 28, 2007 These disks should provide some insight into the matter: Ebay: JS Atari Lynx Authentic Encryption System Disks Thanks for the link. Actually I have been working on these sources posted by Curt and they do not provide the correct decryption out of the box. Fortunately Harry decided to help me and his sources written from scratch by analysing the inner workings of the Lynx do the decryption correctly. I don't know the exact reason why there are 3 RSA disks instead of a single private key. My guess is that the authors were supersensitive for the private key to leak out. Therefore they encrypted the private key with another RSA key. In this way the private key was never anywhere except in RAM during the encryption process. That would explain the reason for 3 disks. I disk for the encrypted private key, one for the modulus (public key) and one for the exponent. Does anybody know if my guesses are correct? -- Karri Quote Link to comment Share on other sites More sharing options...
frenchcat Posted May 22, 2007 Share Posted May 22, 2007 (edited) How does the handy emulator works ? i don't really know the utility of these decryption ? We can emulate the system, and it seems you are able to use homebrew on a homemade cart, but why do we need decryption ? (sorry for this newbie question!) Edited May 22, 2007 by frenchcat Quote Link to comment Share on other sites More sharing options...
semicolo Posted May 25, 2007 Share Posted May 25, 2007 The games are encrypted and the decryption algorithm is in the lynx's bios, that's why it's needed for the emulator to play games. Homebrews need to be encrypted too, or else you'll get the "insert game" message. Quote Link to comment Share on other sites More sharing options...
Marco! Posted June 4, 2007 Share Posted June 4, 2007 Here's some info & files as well as well: http://www.cgexpo.com/encrypt/lynx.htm Harry Dodgson's walkthru page is linked to in the above link, but here it is just in case the above goes down http://www.provide.net/~hdodgson/encrypt.html Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.