Jump to content
IGNORED

Lynx Encryption?


cdoty

Recommended Posts

Excellent work! :thumbsup: :thumbsup:

 

Mitch

 

Thanks!

 

So I wanted to share with everybody the Atari ST assembly code for the encryption process that I commented up. It's pretty easy to follow now. At this point, I know how the encryption works. Now what I need to know is how Lynx ROMs are organized, what the directory thing is, and how the hash and boot loader play into things.

 

Here's my commented version of the assembly code:

 

lynxenc.68k.tar.gz

 

I'm pretty sure I could work out how the ROM files are organized by carefully examining the hash and directory stuff in the assembly code, but frankly I'm tired of staring at it. Does anybody have any clear documentation on the lynx rom format both pre and and post encryption? Does anybody have a clear explanation of how Harry's miniloader works? It appears to me that only the boot loader is ever encrypted.

 

I need more details on the ROM format before I can write a tool for taking a loader, executable, directory entry and calculating the hash, encrypting the bootloader, and packing it all together into a valid ROM image that could run on the hardware. Has anybody bothered to disassemble the 6502 loader that is in the above assembly file? It contains some byte blocks containing a 6502 loader for a 1 Mbit cart and one for 2 Mbit cart. What makes them different? What does the boot loader have to accomplish?

 

Now that the encryption is out of the way, I can worry about more important things like how to write a loader for Karri's 8 Mbit cart prototype. I'm itching to get the groundwork laid so that I can start working on my RPG for the Lynx. It's about time somebody wrote one.

 

--Wookie

Link to comment
Share on other sites

I need more details on the ROM format before I can write a tool for taking a loader, executable, directory entry and calculating the hash, encrypting the bootloader, and packing it all together into a valid ROM image that could run on the hardware. Has anybody bothered to disassemble the 6502 loader that is in the above assembly file? It contains some byte blocks containing a 6502 loader for a 1 Mbit cart and one for 2 Mbit cart. What makes them different? What does the boot loader have to accomplish?

 

Now that the encryption is out of the way, I can worry about more important things like how to write a loader for Karri's 8 Mbit cart prototype. I'm itching to get the groundwork laid so that I can start working on my RPG for the Lynx. It's about time somebody wrote one.

 

--Wookie

 

The rest of the ROM is already solved. I have a linker template that creates the entire cart using a few macros and the cc65 linker.

 

If you download my solitaire sources look into solitaire/cart/directory.s

 

But now I need to disassemble the bootloader-pieces the 3 block and the 5 block versions. I would like to create a bootloader application that would understand the block structure and be able to do the first upload.

 

Thanks for finding the solution to the question that has been in the air for some time now.

 

--

Karri

PS. this has also given me a new insight to the numerous old prototype ROM's that will not boot in a real Lynx. Time to pick up them for a second go.

Edited by karri
Link to comment
Share on other sites

 

The rest of the ROM is already solved. I have a linker template that creates the entire cart using a few macros and the cc65 linker.

 

If you download my solitaire sources look into solitaire/cart/directory.s

 

But now I need to disassemble the bootloader-pieces the 3 block and the 5 block versions. I would like to create a bootloader application that would understand the block structure and be able to do the first upload.

 

Thanks for finding the solution to the question that has been in the air for some time now.

 

--

Karri

PS. this has also given me a new insight to the numerous old prototype ROM's that will not boot in a real Lynx. Time to pick up them for a second go.

 

That's what I figured. I'll take a look at your code and I can help you with writing new bootloaders. My next step is to secure a dev cart so I can try out rom images on real hardware. I think I remember you once said that you would make dev carts for people who contribute to the Lynx homebrew community. Do I qualify now? :) I've never actually done the last couple of steps where you take a schematic, turn it in to a board layout and have the board made by a PCB house. I know enough electronics that I can design them and I can solder SMD's and stuff to put boards together. But I've never actually done it myself.

 

Will you help me get things together to place an order for a board and parts to build one of your dev cart designs myself? Money isn't an issue, just a lack of experience. I'm not sure what the PCB houses are looking for and I'm not sure whether you have them stuff the board or if you order the parts and build it yourself. I've always wanted to learn how to do all of that.

 

Speaking of documentation, is there a lynx dev wiki somewhere that coalesces all of the lynx development info we know? I've seen various technical documents spread all over the place and we've got this board of course. If there isn't a central place to find all of that, I think we should start one. I've got my own hosting account at dreamhost that I run several domains on. It would be trivial to set one up there.

 

--Wookie

Edited by Wookie
Link to comment
Share on other sites

Yes, you qualify ;)

 

Just send me you snail-mail address.

 

Another thing you could buy is a FTDI module. My devflash serial works with too low voltages for sending data to the PC. Besides the FTDI USB-ComLynx works at full speed 62500 bauds.

 

To have a wiki site for the Lynx would be really great. I have a cvs repository with everything I have found for the Lynx. And there is also some other things better suit for private email.

 

--

Karri

Link to comment
Share on other sites

Another thing you could buy is a FTDI module. My devflash serial works with too low voltages for sending data to the PC. Besides the FTDI USB-ComLynx works at full speed 62500 bauds.

--

Karri

 

We could revise your design to use an FTDI usb-to-serial chip instead of using the line level shift chip you were using. I've already got experience writing PC code for talking to the FTDI chips. I wrote an open source library for talking to the CopyNES board that uses an FTDI chip for it's serial connection: libcopynes

 

--Wookie

Link to comment
Share on other sites

Wow ! Congratulations, I've been following this thread since the beginning and it's a big step for the lynx scene.

 

That is true. There are many small annoying things is the boot process I would love to fix. If we can build in the encryption process into the normal linking process then we can freely change the content of the boot loader also. It is then completely up to the programmer to fine tune everything.

 

Some things that I would like to set at boot time are:

- ComLynx to open collector so that it does not disturb other Lynxes

- Audio I/O bit to a known state. It it different on Lynx I and Lynx II.

- Speed up the process by skipping the startup sprite and directory stuff (if possible). Just decrypt the first 50 bytes and read in the init code to a fixed place and jump there.

--

Karri

Link to comment
Share on other sites

We could revise your design to use an FTDI usb-to-serial chip instead of using the line level shift chip you were using. I've already got experience writing PC code for talking to the FTDI chips. I wrote an open source library for talking to the CopyNES board that uses an FTDI chip for it's serial connection: libcopynes

 

You seem to be using mercury for version control.

 

Perhaps the FTDI on a cart is the way to go. I have parts for a small run of carts but the PCB is still not designed.

 

--

Karri

Link to comment
Share on other sites

 

You seem to be using mercury for version control.

 

Perhaps the FTDI on a cart is the way to go. I have parts for a small run of carts but the PCB is still not designed.

 

--

Karri

 

It's called mercurial actually and yes, that's what I use now. It is like git, except more user friendly. It is a distributed revision control system.

 

--Wookie

Link to comment
Share on other sites

Some things that I would like to set at boot time are:

- ComLynx to open collector so that it does not disturb other Lynxes

- Audio I/O bit to a known state. It it different on Lynx I and Lynx II.

- Speed up the process by skipping the startup sprite and directory stuff (if possible). Just decrypt the first 50 bytes and read in the init code to a fixed place and jump there.

--

Karri

 

These are all excellent and something we can do now. I'm almost certain now that the decryption process only decrypts two "frames" of up to 250 bytes (5 blocks of 50 bytes). That means that we've got roughly 500 bytes to work with. The examples we've seen so far have 3 blocks in the first frame that decrypts to offset 0 of the boot memory and 5 blocks in the second frame that decrypts to offset 0x100 (256) of the boot memory.

 

I think the next step is to disassemble 6502 boot loader code found in the assembly file I was tracing out and disassemble Harry's mini loader to see how he changed things. The goal is to have assembly source listings for the "regular" boot loader so that we can then make the changes we need.

 

Karri, I know you're big in using the cc65 toolchain, that's fine, I can help with that, but I'm now the defacto maintainer of the NESHLA (NES High Level Assembler) now and I'm trying to make it support the Lynx as well as the NES. A couple months ago, I forked the NESHLA code and cleaned it up to use the GNU autotools and to compile and run on linux. When I'm done with it I want it to be a generic 6502 HLA. I also want it to have a Lynx standard library like the NES standard library that comes with it. As you can see, I prefer Linux over Windows and for these old machines, I prefer a good macro/high level assembler over a C compiler. In the end I want to lower the bar for Lynx development and to have solid development tools that are freely available.

 

--Wookie

Edited by Wookie
Link to comment
Share on other sites

Karri, I know you're big in using the cc65 toolchain, that's fine, I can help with that, but I'm now the defacto maintainer of the NESHLA (NES High Level Assembler) now and I'm trying to make it support the Lynx as well as the NES.

 

I have nothing against different programming languages. In minigame competitions I always code in asm. My smallest Lynx othello fits in 1k. This is not possible with C.

 

My Stardreamer uses Suzy math that Thomas coded entirely in asm. It is the fastest 3D matrix package I have seen for the Lynx.

 

But C is good for porting games from one system to another. And C is very readable.

 

If NESHLA has good macro support that can be used to code faster then it may attract programmers.

--

Karri

Link to comment
Share on other sites

But C is good for porting games from one system to another. And C is very readable.

 

If NESHLA has good macro support that can be used to code faster then it may attract programmers.

--

Karri

 

I like C. I don't think it is a bad choice for Lynx games. NESHLA is an interesting mix of C and assembler. Instead of making macros like a traditional macro assembler, it lets you define blocks of assembly wrapped in a C-like function definition. It lets you code in C-like style but the body of the "functions" are just assembly. It's interesting. To each his own I guess :)

 

--Wookie

Link to comment
Share on other sites

Awesome work!

 

BTW, has the Lynx ROM been disasembled or at least documented somewhere? I'm looking through the loader code, and there are calls to the lynx ROM, I don't ever remember seeing any docs on the ROM functions. I mean from FE00 to FFF7.

 

Most of the ROM is just the decryption part. I got most of it from Harry Dodgson. This work of modeling the Lynx decryption process was heavily based on that. But I have not seen a commented dump of the ROM ever.

 

Now as we know more it should be much easier to understand the ROM correctly.

 

It would be a good thing to create a documented assembly listing of the ROM, The fixed 5 block encrypted bootloader part. And the changing 3 block encrypted bootloader part.

 

--

Karri

Link to comment
Share on other sites

Most of the ROM is just the decryption part. I got most of it from Harry Dodgson. This work of modeling the Lynx decryption process was heavily based on that. But I have not seen a commented dump of the ROM ever.

 

Now as we know more it should be much easier to understand the ROM correctly.

 

It would be a good thing to create a documented assembly listing of the ROM, The fixed 5 block encrypted bootloader part. And the changing 3 block encrypted bootloader part.

 

I was fooling around with the bootloader (at least part of it anyway) and the Lynx ROM in IDA Pro. The Lynx ROM does seem to be mostly the decryption routines, and the bit to display the "INSERT GAME" sprite if the cart check fails. There is some code of the decryption routines copied from the ROM $FEC1 and what I think is the SCB of the INSERT GAME sprite to $5000. This code might be self-modifying, else why copy it to $5000 to run?

Edited by Shawn Jefferson
Link to comment
Share on other sites

Most of the ROM is just the decryption part. I got most of it from Harry Dodgson. This work of modeling the Lynx decryption process was heavily based on that. But I have not seen a commented dump of the ROM ever.

 

Now as we know more it should be much easier to understand the ROM correctly.

 

It would be a good thing to create a documented assembly listing of the ROM, The fixed 5 block encrypted bootloader part. And the changing 3 block encrypted bootloader part.

 

I was fooling around with the bootloader (at least part of it anyway) and the Lynx ROM in IDA Pro. The Lynx ROM does seem to be mostly the decryption routines, and the bit to display the "INSERT GAME" sprite if the cart check fails. There is some code of the decryption routines copied from the ROM $FEC1 and what I think is the SCB of the INSERT GAME sprite to $5000. This code might be self-modifying, else why copy it to $5000 to run?

 

Because Suzy cannot see the ROM at all. All sprites must be in RAM.

 

--

Karri

  • Like 1
Link to comment
Share on other sites

If there's nothing else in the rom but decryption stuff, would it be useful to develop a free version of it for the emulators ?

 

Yes, it would. I think there is one out there that doesn't do the decryption, just sets up a few things and then jumps to the boot loader.

 

--Wookie

Link to comment
Share on other sites

If there's nothing else in the rom but decryption stuff, would it be useful to develop a free version of it for the emulators ?

 

Yes, it would. I think there is one out there that doesn't do the decryption, just sets up a few things and then jumps to the boot loader.

 

--Wookie

 

Actually when I got the decryption code from Harry I put it in Handy. I added a quickboot option to it that runs the decryption on the PC and just jumps to the loaded code. But my code sometimes crashed as I did not understand it. Now we can bypass this step completely on emulators.

 

--

Karri

Link to comment
Share on other sites

 

Actually when I got the decryption code from Harry I put it in Handy. I added a quickboot option to it that runs the decryption on the PC and just jumps to the loaded code. But my code sometimes crashed as I did not understand it. Now we can bypass this step completely on emulators.

 

--

Karri

 

Ah, yes. It was the framing "block count" bytes wasn't it. You weren't completely decrypting all of the data in the second frame of five blocks.

 

So does the ROM contain any software functions that games call? Or is it all init/decrypt code?

 

--Wookie

Link to comment
Share on other sites

Ah, yes. It was the framing "block count" bytes wasn't it. You weren't completely decrypting all of the data in the second frame of five blocks.

 

So does the ROM contain any software functions that games call? Or is it all init/decrypt code?

 

--Wookie

 

Nobody uses the ROM for anything AFAIK. But some programs may "forget" to initialize variables in low memory and crash if you bypass the decryption phase. At least I believe it is so. But I could run all my ROM images through a PC decrypting Handy and skip the ROM content completely to see if this is true.

 

--

Karri

  • Like 1
Link to comment
Share on other sites

 

I was fooling around with the bootloader (at least part of it anyway) and the Lynx ROM in IDA Pro. The Lynx ROM does seem to be mostly the decryption routines, and the bit to display the "INSERT GAME" sprite if the cart check fails. There is some code of the decryption routines copied from the ROM $FEC1 and what I think is the SCB of the INSERT GAME sprite to $5000. This code might be self-modifying, else why copy it to $5000 to run?

 

Because Suzy cannot see the ROM at all. All sprites must be in RAM.

 

--

Karri

 

There is also code copied to RAM at $5000 and run there (there is a jsr $5000 in the ROM).

 

 

Nobody uses the ROM for anything AFAIK. But some programs may "forget" to initialize variables in low memory and crash if you bypass the decryption phase. At least I believe it is so. But I could run all my ROM images through a PC decrypting Handy and skip the ROM content completely to see if this is true.

 

--

Karri

 

From my preliminary look at the ROM, I don't think there is much that gets initialized on zeropage. I'd be surprised if any of them need be setup at all by the ROM for the purposes of running games. Mikey is initialized (and Suzy, but I think that is just to dispaly the Insert Game sprite) in the ROM though, this may be required perhaps....

 

Oh, and a routine called at $FE00 that appears to turn the cart on and maybe also setup the block to read from. Harry's loader makes a call to this routine to prepare for reading. I think you'd have a better understanding than myself.

Edited by Shawn Jefferson
Link to comment
Share on other sites

Oh, and a routine called at $FE00 that appears to turn the cart on and maybe also setup the block to read from. Harry's loader makes a call to this routine to prepare for reading. I think you'd have a better understanding than myself.

 

As a matter of fact. I do not understand what happens at boot time. I have single stepped the booting for ages without understanding much. But now as the decryption is understood it should be easier to document the rest.

 

I still do not understand what happens after the blocks have been decrypted and placed in memory. There is probably some jsr calls from the rom. Or perhaps a jmp to some address in ram. If Harrys code call stuff in rom then it may have something more in it than just the math.

 

Yesterday I picked up my PSP again and compiled a new version of PLynx (Handy) for it. This time with some faster decryption support.

--

Karri

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...