* Recently => September 2020
Recently*, a famous, mysterious cracker (who I dub a "KraXpert"TM), in the Apple II community posted his findings about additional latent copy protection on an Apple II title called Crossword Magic. The version he mentioned was 4.0.
I remembered that while in high school, years 1988 - 1992, my primary school had a software title by the same name. For reasons I cannot explain, I felt no guilt about having made my own copy of the program and keeping it in my library.
When this came on topic, I located the disk and booted. It was in fact version 4.0.
This KraXpert had identified that Crossword Magic 4.0 had three recurrences of an E7 bitslip protection, each with a slight variation.
Back in the day, I discovered my own method to slip around the E7 protection scheme. The method allowed for easy bit copying in most cases. I never had any motivation to make these backups normalized 16-sectors.
In fact, it employed some minor changes to a standard 16-sector format, and my knowledge of sectors was limited back then, so the slightly modified backup served my purpose. This particular backup showed evidence of my resync technique characterized by invalid sector checksums.
This KraXpert gave some examples of how an incomplete recreation of the E7 fields fails in interesting ways. One type of failure results in clearing the all memory and stopping at ] cursor prompt.
Using some powerful disk imaging (Applesauce), the KraXpert revealed where the extra zeroes appeared in the E7 stream. Only the correct pattern would pass muster. I questioned whether my copy worked in the same circumstances this KraXpert would be using - an emulator. But first I would test on actual equipment.
TL;DR? Jump to the end of this blog post.
I booted my backup on a real //e, absent a printer interface, and although it began to print, it failed quickly to a prompt.
I imaged the disk with Applesauce and tried a WOZ in Virtual II. It printed perfectly.
Although this worked perfectly, it was in WOZ format, which preserves a remarkable amount of bit integrity necessary for sophisticated copy protection to survive inside emulation.
I anticipated the the KraXpert would be using a tool of their own design that completely normalizes DOS-based RWTS. I have used this tool to verify disks; it's an amazing piece of software that helps with validation of different title releases by normalizing to a standard 16-sector format.
The most recent release scans through an original disk of Crossword Magic and finds unformatted tracks $12 through $22. It uses the disk's own DOS to read sectors, and succeeds on tracks $F through $11. Upon reaching track $E it gets an error. On my backup copy it failed at track $F due to an error I had made long ago. I located the WOZ-A-DAY version and started with it, fancying I could always re-establish my E7 sequences.
Unable to use this tool to normalize Crossword Magic, I attempted to track down a tool I used in my youth. I did not find that old tool, but I discovered that Applewin, in combination with Copy II Plus 8.3, was able to write an unprotected version of it in a DSK format. All sectors, with DOS 3.3 PATCHED set from the sector editor, ended up reporting an error 5 with SECTOR COPY, but the contents in most cases were correct. The exception surfaced when Copy II Plus 8.3 was used to perform a sector copy of either bad sectors (like my WOZ) or empty tracks $12 through $22, where Copy II Plus appeared to fill in already established sector data across all those tracks. Realistically, those tracks should have all blank sectors (either all zeros or all FF's).
Now that I had the disk contents unprotected, I could begin testing if my E7 sequence worked universally or if only in special cases. This is where the fun began.
The first hold up began in the boot loader in track $00 sector $00. The boot sector uses the disk II ROM to pull in sectors, but on its own terms. Once it is through with track $00, it calls a disk arm routine to advance to track $01. It continues to use the disk II ROM routine, but it now fails to read any sectors from an unprotected disk's track $01. This is because the disk II ROM loader expects to only load from track $00 unless the caller has set zero page $41 to $01. This constitutes the first bit of code patching.
After it gets to track $02, it now has its own early sector header locator in text page 1. The routine in this page specifically requires that the header epilogues end with $FF and the sector loader in page $5A00 end with a sector epilogue of $FF. Patching as follows in Applewin gets through the boot process
$44D => DE
$457 => AA
$5ACE => DE
The secondary protection is E7 field based. The main program will fail if the DOS sector at track $02 sector $08 lacks pattern
EE E7 FC EE E7 FC EE EE FC
If that sequence exists in the E7 field, the main menu will allow for selection of various operations; however, as the KraXpert reported in a Apple II workspace, symptoms will appear; such as the inability to play a puzzle and successfully print. I do not know this KraXpert personally, so I do not know if the symptoms are caused only by an invalid E7 sequence or related to other alterations. For instance, I propose alterations below that may have a latent effect.
Moving on, there are two more E7 fields on track $11. If either one of those is absent, the protection check before printing will fail and it will ask again for the program disk. The KraXpert; however, noted that an incorrect pattern may result in endless printing of garbage.
Because this disk is no longer in a protected sector structure, another likely protective measure, that allows for successful reading of the original disk's protected tracks, will now fail because it adjusts the epilogues back to the $FF's before the check and restores them to $DE AA / $ DE following the check.
AppleWin provides a convenient means to inject code through the debugger (F7 - debugger). After lifting the 16-sector protection for tracks $2 through $E, the boot sequence should be disrupted through a breakpoint at $802 by using the following debugger command prior to booting (F2 - reset).
BP 802
Resume execution with F7. When AppleWin breaks at $802, supply the following commands in the debugger.
MEB 863 20 E0 08
MEB 8E0 E6 41 4C 82 08
MEB 879 20 E5 08
MEB 8E5 A9 DE 8D 4D 04 8D CE 5A A9 AA 8D 57 04 A9 02 4C 82 08
Resume execution with F7.
When reaching the CROSSWORD MAGIC splash screen, enter the debugger (F7 - debugger) and enter the following command at the debugger.
MEB 9FE7 8C
This final change will cause the code to $DE AA epilogues instead.
I am repeating the sequence from above - track $2, so it is closer to the latent E7 sequences on track $11, for the sake of easy comparison.
Track $02, DOS sector $08 can work with this E7 field sequence.
EE E7 FC EE E7 FC EE EE FC
Raw sector AB AF can work with this E7 field sequence.
EE E7 FC E7 EE FC EE FC
Raw sector AE AB can work with this E7 field sequence.
EE E7 FC EE E7 EE FC EE FC
All of the above E7 sequences must be inserted at the correct position in the respective E7 field. A nibble editor can be used to insert the sequence, followed by a sector editor to regenerate a proper checksum.**
At the start of any E7 field, the first three E7's are left as is; this is the accepted approach used by the KraXpert. The next three signature bytes are EF F3 FC, followed by the desired E7 sequence from above.
E7 E7 E7 EF F3 FC pp aa tt tt ee rr nn aa bb oo vv ee
TL;DR From limited testing in AppleWin, MAME, and Virtual II, it behaves identically to a WOZ version. MAME shows an interesting video artifact with both //e and //c after selecting some of the menu options, and this artifact is present with the WOZ.
Another interesting discovery, Crossword Magic detects a //c and prevents changes to the printer interface and slot. Larry did an incredible job on this title.
// that's all folks. thanks for reading.
** One caveat I found is that if the sector on track $02 is corrected in a nibble editor and written back to a DSK type image in Applewin, sector $00 will be written as a blank sector, which yields a very interesting effect in Crossword Magic. The effect is that the blank sector is all CPU BRK instructions, for which Crossword Magic has a BRK handler. It cleanly exits to a ] prompt for showing the title screen.
