MAGICLON - Copying software protected disks

[AGiambra]

Back in the 80's I was a burgeoning nerd.  Back then game and utility disks used a lot of software protection schemes (bad sectors, skewing, etc.).  I got to thinking, once a program was fully loaded into memory and running, if you could somehow dump the contents of memory to a disk you ought to be able to reload those contents and fire up the software again.

 

During interrupt processing, the Atari stores everything it needs on the stack to return to the program before jumping to the interrupt code.  When the interrupt is done, it issues an RTI instruction.  The RTI causes the processor to reload the info from the stack and jump back to the program.

 

So if a game was running and, during an interrupt, you dumped everything in memory to a disk, you ought to be able to reload the contents of the disk to memory and then issue an RTI to cause the processor to pick up where it left off.  (It's a little more complicated but I don't want to write a book here).

 

Back then I began work on a program called MAGICLON (Magic Clone) but I could never get it working.  Like the nerd I am, I recently dusted this program off and worked on it again.  I figured out what I was doing wrong and finally got it working.  It does not work on every single disk, but it works on about 2/3 of them.  Some of the disks I successfully tested it on were Frogger, Mig Alley Ace, Micro League Baseball and Atariwriter.

 

Here's how to use it:

 

Boot from the MAGICLON disk and run MAGICLON.  It will prompt you to press SELECT.  Insert the game or utility disk in Drive 1 and press SELECT.  The software will load and execute.

 

Insert a single density formatted blank disk in Drive 1.  Now press OPTION, SELECT and START.  The software will freeze and the entire contents of memory will be written to the disk.  When this is done, the software will run again.  (Note:  If you press OPTION, SELECT and START and nothing happens, you've inserted a program that MAGICLON cannot copy).

 

To reload the software from the disk you created, boot from the MAGICLON disk again.  Run MAGIREAD.  Once again you will be prompted to press SELECT.  Insert the disk you created previously and press SELECT.  The disk will be read into memory and the game or utility that was copied will run starting at the exact place it was when you copied it.

 

If anyone is interested in how it works, I'll supply the details.

 

 

 

Edited September 7, 2023 by AGiambra

[+Larry]

I just read this post.  Interesting!  Are there any specific hardware requirements for expanded memory, etc.  Where does your code "hide?"  I'll check this out today.  I have a lot of original software from the 80's that should be good candidates. 

[AGiambra]

Hi Larry.  No there are no specific hardware requirements.

 

MAGICLON works as follows:

 

A patched version of the 800 OS is loaded into memory.  Normally, a deferred vertical blank interrupt runs 60 times per second.  My patch intercepts this and points it to code which resides at $C700.  This code checks to see if the OPTION, SELECT and START key is pressed.  If not, control returns to the exit of the interrupt.  If it has been pressed, the code dumps all of memory from $0000 to $BFFF to the disk beginning at sector 323.  Sectors 321 and 322 are then written with code which makes the disk bootable to a patched version of the 800 OS. A patch allows the 800 OS to boot from sector 321 instead of sector 1.  The boot sector points to a small program, READ1, which reads the rest of the disk into memory again.  The real boot sector at sector 1 contains a loader program which installs the 800 OS into memory and boots it.

 

Since the memory was dumped during an interrupt, the READER program loads everything back into memory and then treats the system as if it were simply returning from an interrupt by issuing an RTI.  This is the part it took me years to figure out.  In order to get the system to think it was returning from an interrupt, I had to save all the info that the system needs to do this and store it on the disk.  After many, many tests and after poring through lots and lots of articles about how the 6502 processes interrupts, I finally figured it out.

 

Here's a disk with all my code on it.

 

OS is the 800 Operating System

OSPATCH  contains patches which point to VBI to a program called SECT1

SECT1 is the code residing at $C700 which dumps all of memory to the disk.

READ1 is the code which re-reads the disk into memory and executes an RTI to start it again.

INST is the code which installs the boot sector on the disk.  The boot sector contains a program which loads the 800 OS into memory.  This version of the OS is modified so that when it initializes it boots from sector 321.

MAKEBOOT.BAS reads all of the preceding programs in order and creates the MAGICLON program.

MAKELET.BAS creates MAGILET.

 

If you end up testing it with your own utilities and games, please let me know how successful it is.  In my own testing, it worked on about 2/3 of the programs.

 

Also, if you downloaded the original version of MAGICLON and MAGIREAD which I posted earlier, this disk contains some updated code which should make the programs even more reliable.

 

Have fun!

 

 

MAGICLONE.atr

Edited October 2, 2023 by AGiambra

[+slx]

Thanks for sharing this! I suppose with everything cracked by now it is more interesting as a historical artifact than a practical tool for latecomer pirates but nevertheless interesting. 
 

I assume it requires an XL/XE/Incognito to allow loading of the patched OS and won‘t work on software that doesn‘t use System Vblank routines or games that load more data (e.g. levels) from disc (although those could be adapted by copying that information to the cracked floppy in addition to the memory dump. 

[AGiambra]

Yes, it was more of a personal challenge than anything else.  Back in the 80s, I just couldn't get it to work properly.  It worked on maybe 2 out of every 10 programs I tested it on and it always bothered me that I couldn't get that last piece to work.  Finally, some recent articles I read told me the part I had been missing and I returned to it just to see if I could finally finish it.

 

You are correct; it required an XL/XE because when you load the 800 OS it frees up about 14K which I needed to for my own software.  And yes, if a game turned off the VB interrupt, it screwed up my program.

 

I actually found a document I wrote when I was first developing it.  I was planning on selling it at the time if I could get it working reliably.  The document talks about the things you mentioned, that if the game loaded more data from the disc, my software may not work as well.

 

So here I am, writing a copy program during a time when you can download almost any Atari game for free.  I guess it's a form of mania....hah hah.

 

[AGiambra]

As I said in my first post, I began working on MAGICLON in the early 80s.  There were a lot of things I did not quite understand about interrupt processing and so MAGICLON always "kind of" worked.  Being an ultimate perfectionist, it bugged the crap out of me that it didn't work perfectly.  In the 80s I finally put it away, but every so often (at 5 or 10 year intervals) I would return to the project for another attempt.

 

In a nutshell, it works like this:  The first thing that happens is a copy of the 800 OS is loaded into memory.  Since it only occupies 10K, it frees up memory from C000 to CFFF.  This is where my code resides.  I intercept the interrupt that checks if the START key was pressed and point it to my code.  When the user presses START, OPTION and SELECT together, it causes an interrupt which jumps to my code.  I write all the contents of memory from $0000 to $BFFF to the disk.

 

The biggest problem I had was getting the copied software to run after it was reloaded into memory.  Remember, I captured all the data and wrote it to disk during an interrupt.  So after all the data is reloaded into memory, I should have been able to execute an RTI instruction (return from interrupt) and the Atari should have picked up exactly where it left off when the data was captured.  This was the thing that I could not get to work from the 80s all the way up to last year.  That's when I pored through all the documentation I could find and finally learned that the one piece of information I should have captured and saved on the disk was the stack pointer.  If the stack pointer is not set properly, when you issue an RTI instruction the Atari will not access the stack at the correct location.  Once I learned this, I saved the stack pointer on the disk and voila, the next time I ran the program, the copied software started right up at the exact spot where it had been interrupted.

 

This should have been the end of the story but when testing a game called Way Out, the screen had garbage on it after it was reloaded.  The program worked okay, but there was junk on the screen.  Why?

 

Well, it turns out that saving everything in memory is not quite enough.  There are two special chips in the Atari besides the processor called GTIA and ANTIC.  They are responsible for what goes on the TV screen.  And here I faced the biggest challenge.  I also needed to save the contents of certain memory locations within these chips.  But guess what?  You can write to the registers in these chips, but you cannot read back what you just wrote.  So if a game stored a value, 12 say, in $D009, my software had no way of reading that value from the chip.  This kept the program from being perfect until I had my final brainstorm.  Why not scan all the code that is loaded into memory looking for instructions that write to either the GTIA or and ANTIC chip.  Typically the code would look like this:

 

LDA #$12

STA $D009

 

Once I found the store instruction, I could simply back up and capture the value that was to be stored.  One final problem existed.  Often, you'd find code like this:

 

LDA #$12

STA $D006

STA $D008

STA $D009

 

If I wanted to find out what was stored in $D009, I couldn't just back up to the prior instruction.  I needed to make sure the previous instruction was also not a STORE command.  If it was, I needed to keep backing up until I found the LOAD instruction.  As I processed each STORE command, I built a table of each location that had been accessed and what value was in it.

 

Now with the table stored on disk, when the disk was reloaded, the final thing that happens is I access the table and write all the proper values back into the GTIA and ANTIC registers.  To my ultimate delight, when I reloaded the Way Out game and it restarted, the screen was clear of garbage.  It looked exactly the way it looked when the program was initially dumped.

 

Only 40 plus years to get the program running perfectly.  That's not too bad....I guess.  Hah hah.

 

 

 

[_The Doctor__]

You got so excited telling us about it you forgot to put the atr in the post

[+CharlieChaplin]

Your Magiclon program seems to be quite similar to The Freezer! which was sold commercially. That program also copies an 800 OS into memory and adds some extra code to activate The Freezer! and then copy the whole memory to diskette. Furthermore The Freezer! works with Start, Select and Option (afair Select + Option to freeze a program, Start to write it to diskette).

 

But programs freezed with The Freezer! were self-booting diskettes and did not require a special loader program (or the loader was simply added to every disk, together with the old + patched 800 OS). Of course it could not freeze 64k XL/XE programs nor programs that were loading stuff after the program had started (levels, maps, etc.).

 

The English Software Company mostly used non-standard boot-tapes, where every block had more than 128 Bytes of data (usually 1K blocks), but most of the time that was the only protection they used for their tapes. With The Freezer! all those 48k RAM tapes could be freezed easily (with some programs you had to freeze at a certain point, e.g. I remember that you had to freeze Colossus Chess 3 and Mercenary 48k exactly when the on-screen loading counter reached 000, if you waited one second longer it would not freeze anymore). And there were a few programs where you first had to lose one life, before they were working correctly...

 

 

 

 

THEFREEZER.zip Freezer_examples.zip

[+CharlieChaplin]

1 hour ago, _The Doctor__ said:

You got so excited telling us about it you forgot to put the atr in the post

 

post #1 ? and source in post #3 ?

 

But maybe the latest updates (mentioned in the post a few hours ago) are missing there...?!?

 

 

[_The Doctor__]

so you think he went back and replaced the .atr's in the old posts and didn't notate any of them were updated or changed in those posts in any way?

[AGiambra]

I heard about the Freezer but never knew much about it so I appreciate your post.

 

I was so excited to get MAGICLON working that I just wanted to tell someone about it.  I didn't think anyone would want it though.

 

But since you asked, I am attaching it to this post.  A caveat:  It does not work on all programs.  If the game turns off interrupts, then when you press SELECT, START and OPTION together, nothing happens.

 

Having said that, here is how to use it:

 

Run MAGICLON.  It will display a screen that says PRESS SELECT.  Insert the disk you want to copy and press SELECT.  The game will load.

 

Once the software is running, remove the original disk (IMPORTANT).  Insert a formatted disk and press START, SELECT and OPTION at the same time.  The system will write to the disk.  Be patient; it has to copy a lot of data.

 

To run the copied program, run MAGIREAD.  At the SELECT screen, insert the disk that was crated and press SELECT.  The software will load and run.

 

IF START, SELECT AND OPTION do not work, try running MAGIBRK.  This version will write out the data disk when the break key it pressed.  Sometimes if one way does not work, the other does.  If neither work, well, you just cannot copy that software.

 

Edited September 7, 2023 by AGiambra

[AGiambra]

I downloaded your copy of the Freezer and used it to copy Way Out.  When it reloaded, the same garbage appeared on the screen that my program initially had.  Apparently the Freezer does not copy the registers of the ANTIC and GTIC chip.  MAGICLON does and when reloaded, no garbage appears on the screen.  Makes me feel good that MAGICLON is better than the Freezer.  Hah.

[Rybags]

You can't save/restore most HW registers with software alone since they generally have different functions between read/write.

In theory a hardware device could shadow register writes to it's own external Ram which could aid in a restore process.

 

I did a similar program in the day though it worked by just doing a warmstart to get the game going.

In the modern day this sort of thing isn't very relevant since emulation allows us to do easy cycle by cycle debug and writing memory out for later restore to emulated or real machine is pretty simple as well.

[AGiambra]

I am always up to a good challenge.  When CharlieChaplin said that the Freezer creates a self-booting disk that does not require a special loading program, I thought, "I can do that!"'

 

Attached is a new version of MAGICLON that no longer requires MAGIREAD.  Like the Freezer, it will create a self-booting disk that loads directly into the copied software.  But unlike the Freezer, it will restore the GTIA and ANTIC registers so that the copied software will run correctly.  Have fun!

 

PS  I removed earlier versions of the ATR just to avoid confusion.

 

 

 

 

 

MAGICLON.atr

Edited October 1, 2023 by AGiambra

[+CharlieChaplin]

Some questions...

 

- does Magiclon or Magibrk switch off Atari Basic ? Or do I have to press Select + Option (or Select, then Option) to switch off Atari Basic on the XL/XE ?

 

- pressing Select, a disk is booted - could I also boot a tape ? You said in one post that "I intercept the interrupt that checks if the START key was pressed and point it to my code. ", so that sounds to me that booting/freezing tapes (with Start or Start+Option) are not possible with your program ?

 

 

[AGiambra]

Good question. No, MAGICLON does not turn off BASIC.  Here is the correct procedure:

 

Insert the disk with MAGICLON.  Press OPTION and boot your system.  If you do not press OPTION, when you run MAGICLON a warning message will appear: "REMOVE CARTRIDGE" and it will not proceed.  Since you have pressed OPTION when booting, MAGICLON will reboot the system with BASIC disabled.   It works the same as the TRANSLATOR disk.

 

MAGICLON does not intercept the START key until after SELECT is pressed and it loads itself into memory.  Also, when I intercept the START key, my program only checks if START, OPTION and SELECT are pressed.  All other combinations are treated normally.

 

I have modified MAGICLON so that you can load cassette files as well.  Simply press START and then press SELECT. The system will beep waiting for the cassette.  At this point load your cassette in the normal manner.

 

Finally, I've made improvements to MAGICLON and have attached a new ATR.  The name MAGIBRK has been changed to MAGILET.  When you use MAGILET, pressing any key on the keyboard dumps the running game/program to disk.

 

Hope this helps.

 

 

 

MAGICLON.atr

Edited October 2, 2023 by AGiambra