Applesauce – Make exact images of copy-protected Apple II floppy disks | Hacker News Reader

Applesauce – Make exact images of copy-protected Apple II floppy disks

wiki.reactivemicro.com

109 pointstimmytokyo35 comments

Applesauce will be an amazing boon to the preservation of Apple II software. If you have any original Apple II software that you would like to preserve publically for posterity, please consider contacting Jason Scott from the Internet Archive (twitter handle: @textfiles).

The reactivemicro wiki page seems to be buckling under the load. To learn more about applesauce, watch this video from KansasFest 2017: https://www.youtube.com/watch?v=RMrOiYCEuxc

And don't just assume that software has been archived because it's a commercial release of some kind. New software gets discovered all the time from personal collections.

Kind of an ironic end to @a2_4am’s project to reverse engineer the copy protections on all this software (https://archive.org/details/apple_ii_library_4am). Rather than his DRM-free versions, Archive.org will probably prefer to use these .WOZ flux-track files that keep the copy-protection intact.

Still, I suppose 4am’s work exposed quite a bit of the history of copy protection, even if we won’t be using his rips. The docs he wrote outlining his process of cracking the DRM (and his gradual automation of such) are valuable historical artifacts all by themselves, and I hope they persist in the Archive even alongside the .WOZ rips.

4am seems very excited about the project. https://twitter.com/a2_4am/status/993247470414127104

And there will still be work to do. https://twitter.com/yesterbits/status/993345477805559809

The Internet Archive will have both copies around, and I can't think of any particular reason they wouldn't let you boot both of them in their emulator.

I don't really think that this is the end of cracking. It is more of just the start of a new era of preservation. There is still a good amount of hardware out there like the CFFA3000 that doesn't support .WOZ images. Those will still require the cracked DSK files.

As a young one, I had a apple //e copy disk with a wide variety of copy programs (copied of course...)

My favorite could copy 2 disks only 4 disk swaps (If you had a single drive). And "Locksmith" which had profiles for certain originals that would allow copying by knowing the original's secret. It was a back and forth battle between the copy programs and copy protection..

https://en.wikipedia.org/wiki/Bit_nibbler#Apple_II_-_Locksmi...

Of course we got a bought copy of electronic arts "seven cities of gold" and it didn't work because of the copy protection. Got a second copy and it too didn't work...

My friend had a card that could at a push of a button dump the entire apple ][+ Ram to a bootable disk (64K!). Great for those single load games.

We recently implemented read and write .woz support into our Apple IIe emulator: https://paleotronic.com/2018/06/05/microm8-now-supports-woz/

We changed our internal reference format from NIB to WOZ so we convert other formats to WOZ upon loading... we <3 WOZ!

was always mesmerized by the copy protection on some of these disks.. which begs the chicken-and-egg question of how these disks were written in the first place, since it sounds like these copy protection schemes are above the threshold of what is 'addressable' by the system..

The devices used to fabricate the floppy disks were not the same as the devices used by consumers. They had many more capabilities, infamously including the ability to adjust the write head to follow a spiral pattern (instead of concentric circular tracks).

Spiral writing didn't mean a thing unless the consumer's drive could read it back.

The more important part about spiral writing was that it defeated the track-by-track copy of most Apple ][ copy programs, since there was no disk position synchronization available on the consumer drives. Note that the Applesauce device modifies the drive to allow for this.

The only modification of the drive is the installation of a sync sensor that Woz removed (among all the other smarts in the drive to begin with).

IIRC, they were all defeated, except for the burn a hole in the disk and try to write to it copy protection mechanism.

It was more a matter of which bit copy software had the right profile to be able to copy the tracks.

Back when I was doing a lot of copying disks, I remember it was really important to get the drive speeds right for a given profile. That way the you could dead reconing style copy for a partial track once the drive sync'ed to some known pattern that was fully on the starting track. These copies obviously didn't work 100% of the time, but generally a few tries would yield a working copy.

I personally used Copy][ Plus as my primary utility and vaguely remember writing little "scripts" (more a few bytes of hex codes IIRC that described which tracks to read, and how to do quarter stepping/etc) to describe how to copy spiral track disks. Although frequently, I remember it being easier to try one of a number of other bit copy utilities first.

> the burn a hole in the disk and try to write to it copy protection mechanism

Uhh, mind elaborating on this?

I remember this was a protection scheme, but I don't remember who used it. They would use a laser to burn a small hole in the disk. At load time, the program would attempt to write to the sector with the hole and then read it back. If it succeeded, they knew it was a copy.

Basically, they created a disk that could accept writes everywhere except a certain sector, something you could not replicate with even a perfect copy.

Yes and that was VERY easily defeated too -- you just had to take the floppy, very carefully align the synchronization hole with your copy, and take a pinhead and make your own little scratch in the same place.

It was a bit silly to be honest -- this was the easiest copy protection to bypass!

That won't work, because the actual disk inside the sleeve will never be aligned the same way your copy is.

The protection is not the hole in the sleeve, it's the hole in the disk. For example, the garbage reads would happen on track 12, $230 bytes after the $D5 $AA $96 marker. Good luck physically reproducing this.

These protections are trivial to remove in code, though.

You clearly have never looked at a floppy before making "that won't work" comments, but floppies have a sync hole that is aligned.

And having made multiple copies like that, I know very well it worked pretty well as a method -- it's very likely why that method never became the 'uncopiable' it was claimed to be when it came out.

The apple ][ didn't have the hardware to read the sync hole (much less a sensor to detect where the head was, hence the clatter on reset as the head bangs into the endstop). That was part of the magic, each sector had a sync field and then a few bytes and a track/sector number.

That is of course why its not just a simple case of locating where the burned hole was relative to the sync hole because the "physical" location of a sector offset on the disk would normally vary from disk to disk (or for that matter from track to track) or format to reformat.

I have seen many floppies, but you don't seem to know how the Apple ][ encodes bytes on the floppy because of the Disk 2 limitations. See my remark about the $D5 $AA $96 marker, and if you want to learn more, look up "6 and 2 encoding".

The Apple II drives have this capability, which is why they can follow the data. The track-to-track motion is carried out by a stepper motor which is controlled with some memory mapped registers. To move from one track to another, the motor is stepped through four phases corresponding to "quarter track" increments. Some copy-protected software was written on using partial tracks, with quarter track increments. The software's loading routines knew how to follow that.

Hence the spiral tracks which were basically, a partial track written and then the head was stepped a quarter track and another partial track written, repeat. The copy protection was easy broken once you knew how much data needed to be read/written before stepping to the next track. Of course the sync sequence, or timing requirements to find the track once you stepped was helpful too.

Let me see if I understand this. The disk authoring machine would lay down a true spiral, right? And the software controlling the read head would know this, and follow/emulate that spiral by stepping the head in a 1/4 track every 90°? So while the continuous spiral moved underneath the read head, the read head would mostly follow it but with some "quantization" error? (Not large enough to cause issue with reading, but impossible for an OS-level utility to replicate when copying the disk)

The thing is, if the OS-level utility replicated that with quarter-track increments so that the same data is read back, it would be fooled. The consumer Apple II Drive (Disk II) has only quarter track increments; it cannot follow a smooth spiral. If a copy protection is based on a smooth spiral, it has to somehow depend on detecting the quantization errors due to the track skew, the absence of which reveals that there is a quantized, piece-wise spiral. If the skew didn't cause any issues with reading, then the software couldn't tell the difference between the smooth spiral and the fake staircased one.

I'm thinking that the OS-level diskcopy tool doesn't expect to see such a wacky layout, and would just fail to track along what it expects to be concentric circles. Only the software that's aware of the custom layout would be able to read the disk, by taking direct low level control of it. And if the data is laid out in a true spiral, mimicking that with 1/4 shifts every 90 deg. might be close enough to never lose track of the, erm, track.

The most popular and most devious ways to protect floppies on the Apple ][ were more or less all based on timing bits (including the most famous protection of all, the E7 slipstream).

These timing bits were necessary on the disks for the reading head to be able to tell 1's from 0's, but copiers did not have the ability to maintain them, so copies were often desynchronized.

AppleSauce is the only device that can successfully preserve timing bits, hence allowing protected disks to be copied.

Source: I crack Apple ][ programs for fun.

Here's one where Track 6 is a bit-for-bit copy of Track 5 - including the header that says "This is Track 5"! https://archive.org/download/PinballConstructionSet4amCrack/...

That is a pretty standard EA protection. Pretty amazing stuff. 2 normal tracks typically have a crosstalk area between them (typically on the half track). But the EA tracks are perfect from 4.75-6.50. And the protection scheme actually sweeps the head back and forth across the range WHILE reading the data.

They are actually just writing data to the concentric tracks, but just timing the steps between the tracks very carefully. When making a copy, you couldn't get the steps to sync up and so the timing for the steps would all be broken.

High end commercial copiers really didn't come into play until 1984-5.

At the end of life of Oric, a friend has published a game. The editor has asked him to add a copy protection on the disk. A little latter, the editor asked him to provide a copy program because the copy protection was defeating his physical disk copier ;-)

This is great, I just packed a box of ~200 old Apple ][ 5.25" floppies, and was wondering if there was ever going to be a way to see what was on them again.

Let's chat.

Please do :-)

Makes me wonder at what point it will become impossible to root an iPhone.

> All flux transitions read for the disk are saved in this file. The size of a file is about 20Megs.

Incredible!

"360kb" capacity, with 20Megs of information.

shout out to the diskjockey if he's still out there somewhere for making this: http://www.a2heaven.com/webshop/index.php?rt=product/product...

i learned computers (6502 assembly) by reverse engineering and cracking copy protection on games.

changed my life

Reply on news.ycombinator.com