Dissassembling ATRs

[8BIT 1337]

Is there any documentation on disassembling .atr's with copy protection?

 

My plan is this: I loved (and still love) Micro League Baseball. I'd love to be able to rip apart the game to see how it works. And I'd love to be able to rip apart the GM/Mgr disk to build my own with modern teams (and without having to enter everything by hand).

 

When I disassemble the main disk it it seems pretty obvious that it's copy protected though, and I haven't a *clue* how to go about cracking it. Suggestions?

[Bryan]

I'm not sure exactly what you mean. If you have an ATR, then you already have a cracked copy. There is no magic disassembler that will tell you how something works. Documenting a raw disassembly is always a long, complicated process.

 

To produce the most helpful disassembies, try using an interactive disassembler like DIS6502.

 

-Bry

 

http://www.atarimax.com/dis6502/

[Heaven/TQA]

1st step could be to walk through the disc with a disc editor just to browse the sectors.... maybe the team data is plain ascii text so you might be able to edit the data by hand...

 

was the baseball game able to edit the rooster? if so...then the built in editor might be better than via hex editor...

[8BIT 1337]

I'm not sure exactly what you mean. If you have an ATR, then you already have a cracked copy. There is no magic disassembler that will tell you how something works. Documenting a raw disassembly is always a long, complicated process.

 

To produce the most helpful disassembies, try using an interactive disassembler like DIS6502.

 

  -Bry

http://www.atarimax.com/dis6502/

 

I'm not very good at explaining myself sometimes....

 

I have looked at the code in Dis6502. But I think I'm seeing the situation described here, in the manual:

 

When you disassemble a boot disk (BOOTGAME.ATR for example), sometimes, you will see that only a small part of the code is readable and the rest is crypted. Usually the readable part contains a loop to modify the rest of the code. It is used to prevent people from disassembling the code. The simplest algorithm is to EOR all the crypted code with a value.

 

To be able to disassemble that kind of code, the best way would be to run the small part that transforms crypted code to readable (and executable) code and disassemble it after.

 

... And I don't have the foggiest idea as to how to identify the decryption algorthym. I guess when I said "copy protection" I really meant "decryption algorythym."

 

@Heaven/TQA: Yes, the game itself let you edit the rosters (and create new ones). I'm looking at creating a *lot* of new teams so using the program itself would take too long.

 

(I've found one great website for baseball stats - so all I'd have to do is manipulate those text files and I could have practically every team in history available).

 

Maybe my real problem is, as Bryan has mentioned, the disassembly itself. I *know* that the code won't be readable, and I do understand a little 6502, but perhaps I'm too used to the documentation available for the VCS and I'm a bit lost on the 8 bit.

[Bryan]

Ahh... Okay. I doubt the original used encrypted code, but I noticed that a lot of the 8-bit software floating around has been compressed. It's not really a problem if you just dump the RAM contents from an emulator after it loads, and disassemble that.

 

-Bry

[Plastron]

OK its a long time ago so forgive me if this is not correct

 

as i remember if you are using a boot disk then you have to ignor the first 6 bytes as they contain the boot load info. If you disassemble the first 6 bytes all will look a mess try starting you disassembly for byte 7 and see if it looks any better.

 

Also so if like me when i did games i put data in the middle of programs just to make you work that bit harder if you wanted to look at the code.

 

Andy

[Wrathchild]

Hi,

 

Here's a slightly radical approach, I'm using it currently to debug

the 'Combat' port I'm working on. :wink:

 

I took A800WinPlus (3.1, but 4 should be OK too) and modified

the sources a bit so that when using the debug statement 'TRON'

(trace on) the output is redirected to a file.

 

Therefore you work as follows:

Load emulator, enter debugger, set breakpoint, continue emulation.

Load your exe or boot the disk, when breakpoint is hit you enter

the debugger and start tracing. If you know the next breakpoint

this can be set before continuing, or just continue and use F8 to

break the emulation when ready and re-enter the debugger.

Type 'TROFF' to stop the debugging and close te output file.

 

The resulting output can be a pretty large file, especially if there

are little wait loops in the code, e.g.

LDA $14

loop: CMP $14

BEQ loop

 

If anyone fancies having a go with this I can upload a version

of the emulator with this enabled.

 

Regards,

Mark

[Plastron]

LOL

 

Do not do it on anything i wrote then as i used that wait routine many times in every game. With it you can move objects without any need to put them in the vbi

 

Andy