Apple II Disk Copy Protection - ASTROSHOW

Apple II Disk Copy Protection - ASTROSHOW Apple II Disk Copy Protection In 1981/1982, I had a 50/50 business partner who provided me with an Apple II. I spent a year of nights and weekends producing a Pert Chart system unlike anything done before. (My partner showed it to Apple and, instead of buying it, produced MacProject - based on it near as I can tell…) Anyway, after I had essentially completed the project, my partner married a woman who had just gotten an MBA from Harvard. They secretly incorporated in Delaware then sent me an agreement to sign offering me 10% of the profits of the corporation. I was not to be part of the corporation. As everyone knows, businesses do not have to make profits in order to make the business owners rich. I saw this as a blatant attempt to steal all my work. A Patent lawyer in the D.C. area took pity on me and he wanted to learn more about software. He took me on essentially as a charity case because I had very little money. I had never provided my partner with the source code to the system and my partner had not realized the significance of that. That was the only leverage I had. An agreement was drawn up where I had to put all of the source code in escrow and provide two floppy disks containing the current software executables to my partner. If my partner liked what was on the floppies, he would give me $30,000. I got to keep the Apple II in any case. I had two weeks to deliver the floppies. I don?t work without backups. The Apple FORTRAN Compiler that I was using came on a copy-protected Floppy disk. I had never heard of copy-protection before and was somewhat surprised and dismayed by it. I bought some books, wrote some assembly language, converted it to Hex bytes, typed my code in byte-by-byte, and managed to copy the copy-protected disk. Fortunately I was successful because the disks only lasted about 6 months before wiping out. I managed to produce the copies in one week even though I had never used an Apple II before and I had never used 6502 Assembly language before. But I had over 20 years experience writing assembly language for other machines so by that time it was relatively easy. I figured my business partner would take the executable disks, make LOTS of copies, and sell the copies without providing me with the $30,000. Software in those days was like buying a pig-in-a-poke. You put glitzy graphics on a package and people would buy it for $100 never sure of what they would actually get. I think that is why piracy developed initially. I needed to copy-protect the disks containing the executable. I knew a lot about copy protection schemes on the Apple II by then. An Apple II floppy disk contains tracks (visualize circles of varying radii on the disk) and sectors (visualize each track containing 16 segments.) Each sector consisted of 16 “header records” each of which was followed by a “data record”. There was a “Gap” between the header records and the data records. The headers contained the sector number and the track number. There were also “self- sync” bytes on the disk that were unique from any other data. The bits on the disk were recorded continuously so you could not tell where a byte started. The self-sync bytes solved this problem. The system looked for the self-sync bytes and synchronized everything so that the byte boundaries were known so that the system would deliver proper bytes when you asked the system to read a byte. Reading a disk, under normal circumstances, involved asking for a specific track and sector. The system would read the headers looking for the one containing the correct data. When it found the header, it would report back then look for the next very next set of self-sync bytes, synchronize, then begin reading the data record. The gap was there because some time was wasted between reading the header and setting up for reading the data record. Copy protection schemes typically changed the data in the headers so that they contained illegal values. Normal copy programs would see the error, report it, and refuse to copy the disk. These programs reported the track and sector numbers so, if you knew what you were doing, you could fix the problem header, copy the disk, then reapply the error so that the software on the disk that was looking for that error would run. The actual disk write operations on the Apple II were entirely controlled by the system oftware. The system software was in assembly language and was published. It was not s secret. The actual disk-drive read and write routines could be viewed easily in assembly language. You could write your own read and write routines if you so desired and IF you really knew what you were doing. As part of my work backing up hard-to-copy disks for my own personal use only, I had developed a “full-track read” routine and a “full-track write” routine. The full-track write routine was extremely hard to write because you had to put all of the headers and data in a big buffer in memory. Then you had to write the self-sync bytes, the header record, a gap, self-sync bytes, the data record, a gap, self-sync bytes, the next header record, etc., etc. The difficult part was being able to deliver all of the bytes, switch from self-sync bytes to normal bytes all in one smooth operation. Normal bytes were spaced 40 microseconds apart so your disk write routine for normal bytes had to be a loop of exactly 40 microseconds. Self-sync bytes however were spaced 44 microseconds apart so when writing them, the loop had to be exactly 44 microseconds apart. In order to get exactly the right number of microseconds, I actually had to position my assembly language over a “page boundary” in memory so that one of the 2 microsecond instruction would be a 3 microsecond instruction. So I had an assembly language routine that could do a continuous full-track write and an assembly language routine that could do a continuous full-track read. I discovered that if I did a check-sum on a “normal” track read with my full-track read routine, the check sum was different each time due to the contribution of the gaps probably depending on where the read actually started. However, I found that if I wrote a track using my full-track write routine and then read it using my full-track read routine, that the checksum was ALWAYS THE SAME! So I modified my executable so that way-down in the code, I did a check for a “special” track that I wrote on the disk using my full-track write routine. I did a full-track read on the “special” track twice and compared the checksums. If they matched, I knew it was the copy-protected disk that I had provided. If they didn?t match then I knew it must be an illegal copy. Normal copy routines, as noted before, introduced variability in the gap areas so any normal method of copying would make my track check fail when the executable was run from an illegal copy. The beauty of this scheme was that all copy routines worked without reporting any errors but the copies would not run! The track did not have ANY errors. In fact it was BETTER than the standard, i.e., it was a perfect track! As agreed, I sent the disks containing the most recent version of the executable to my partner. I never heard from him again. He had moved to the MIT area by then and I have always envisioned him going from super-hacker to super-hacker at MIT begging them to crack the copy-protection scheme. I am quite sure no one ever was able to beat it. It was a perfect, unbeatable copy-protection scheme. For the record, here is the full-track write routine: .MACRO POP PLA STA %1 PLA STA %1+1 .ENDM .MACRO PUSH LDA %1+1 PHA LDA %1 .ENDM ; NOTE!! „JUMP? USES LOCATION 0 FOR ; RETURN VECTOR. RETURN .EQU 2 PTR .EQU 4 DRIVE .EQU 6 ENGAG1 .EQU 0C0EA ENGAG2 .EQU 0C08B DRVON .EQU 0C0E9 LATCHN .EQU 0C0EE LDLAT .EQU 0C0ED LATOUT .EQU 0C0EF STROBE .EQU 0C0EC DRVOFF .EQU 0C0E8 NUTTIN .EQU 0AAAA .ABSOLUTE .PROC SYNCHWRITE, 1; .ORG 0E00; SET PAGE BOUNDARY START POP RETURN; POP DRIVE; LDA #00 STA PTR LDA #1A STA PTR+1 LDA DRVOFF; LDY #00; LDA @DRIVE, Y; CMP #05; BEQ DRIV2; DRIV1 LDA ENGAG1; ENGAGE SLOT 6, DRIVE 1 JMP OKON2; DRIV2 LDA ENGAG2; ENGAGE SLOT2, DRIVE 2 OKON2 LDA DRVON; SLOT6, DRIVE 1 MOTOR ON ; READ A BYTE TO MAKE SURE ; DISK IS UP TO SPEED LDA LATCHN; DELAY LDA STROBE; BPL DELAY; CMP #0D5; BNE DELAY; LDY #00 CLC LDA LDLAT; CHECK FOR WRITE PROTECT LDA LATCHN; BMI ERROR; LDX #00 LDA #0FF JMP CONTIN; ERROR JMP FINISH; ERROR EXIT (WRITE PROTECTED) CONTIN STA LATOUT, X ORA STROBE, X PHA PLA NOP LDY #7F; ENTRY0 PHA PLA JSR WRTBT2 DEY BNE ENTRY0 JMP ENTER ENTER CMP 00 NOP JMP LOOP TABF6 INC PTR+1 JMP LOOP LOOP LDA @PTR, Y BEQ QUIT STA LDLAT ORA STROBE CMP #0FF CMP #00 BACK INY BEQ TABF6 NOP NOP NOP JMP LOOP FWRITE CMP NUTTIN JMP BACK WRTBT2 PHA PLA STA LDLAT, X ORA STROBE, X RTS QUIT LDA LATCHN LDA STROBE FINISH LDA DRVOFF; YES, TURN OFF DRIVE MOTOR PUSH RETURN; RTS; TRASH . word word文档格式规范word作业纸小票打印word模板word简历模板免费word简历 .END