FLAK by Funsoft, physical copy protection

[ijor]

FLAK, by Funsoft, disk has an almost unique copy protection based on physical alteration of the disk surface.

 

Physical copy protection, as opposed to magnetic ones, are almost impossible to copy. Even modern flux transition level devices, that at least in theory, can copy just about any magnetic based protection, can't copy this type of protection because, obviously, it requires altering the disk surface. The special characteristic of this protection is that survives a write or even a format of the whole track. That means that can't be copied by pure magnetic methods because any magnetic pattern would be overwritten by a write. If the software that checks the copy protection doesn’t write to the disk at runtime, then it can't distinguish a physical from a magnetic protection. It would typically read just as a sector with weak bits.

 

The most common method to perform a reliable physical alteration to the disk surface is with a laser burnt hole. But laser holes require sophisticated equipment and were very expensive to produce. This process was rather expensive and then it was used only for applications usually costing much more than a game. However, a couple of publishers developed affordable inhouse methods. I contacted Yves Lempereur, the original FLAK developer, and asked him how they actually applied the protection. This was his answer that includes a small anecdote:

 

 

Quote

We used a drill ?

 

Basically, my idea was to cause a random defect on the disk by damaging/removing the magnetic material on the surface (a very thin layer) somehow. I then wrote a scanner that would format and scan the disk to discover which sector(s) were affected. At the end of the scan, it would write the game data on the disk, skipping over the affected area(s), then write the address of the center of the affected area in a specific spot on the disk (near the edge, away from the damage). At boot time, the loader would read the address and attempt to read/write in that area. If successful, the load would abort. If it failed, the load would continue and launch the game.

I tried a few different ways of causing a spot damage on the disk, and settled on a small Dremel drill attached to a stand with an arm to lower the drill. The idea was to put the floppy “window” under the drill and carefully lower the drill to just remove the surface material, making a little damaged dot the size of the drill bit (which was very small).

During production, I later discovered that the job had been handed to an intern who was doing serious damage to the disks. It didn’t prevent the copy protection from working, but I had concerns that the damage to the surface could itself damage the head of the drives used to load the game. We had … a talk.

 

This is the only game we know with this type of protection for the Atari 8-bit. The only other case I am aware for any platform is a British game release for the Atari ST.

 

A couple of pictures of the actual physical modification from two different copies of FLAK, courtesy of two members of the a8preservation team:

 

Edited March 6, 2022 by ijor

[Zarxx]

Technicolor Dream

 

[ijor]

5 minutes ago, Zarxx said:

Technicolor Dream

 

Thanks Zarxx.

 

I didn't analyze this title, but AFAIK it doesn't write to the disk and then it doesn't verify the actual presence of a physical alteration to the disk surface. If so it seems just a rudimentary way to producing a sector with weak bits, and it should be possible to copy with any tool that can produce weak bits.

 

It does run write protected, right?

 

Edited March 6, 2022 by ijor

[Rybags]

Re Flak, is it known...

 

- what sector is affected or is it just placed where a particular track is, with the game expecting an error on one of the sectors.

- what test is performed?  Does it attempt to write to the sector.

 

Given a stock drive only really gives fairly high level access with errors and status bits giving generic descriptions that could have dozens of causes, is this protection actually that hard to replicate?  Wouldn't a missing sector ID be just as useful?

[+DjayBee]

35 minutes ago, Rybags said:

- what sector is affected or is it just placed where a particular track is, with the game expecting an error on one of the sectors.

They drilled into the magnetic layer (and obviously sometimes even deeper as can be seen in the first picture above). Afterwards they scanned the disk to find out which sectors exactly are affected and adapted the protection check to this sector. They even check how many bytes from the beginning of this sector are still OK and adapt to this too.

As a result of that, every single disk is unique.

 

38 minutes ago, Rybags said:

- what test is performed?  Does it attempt to write to the sector.

Exactly, it writes to the sector. If there is no physical damage to the magnetic layer, the writing will create a good sector, even if the disk was copied with a copy utility that is able to create weak sectors.

The real check is then done by reading the sector back and compare it to what was written. The data must differ due to the fact that the damaged part cannot be changed.

 

42 minutes ago, Rybags said:

Wouldn't a missing sector ID be just as useful?

Probably if only the failed writing would be checked, BUT because the protection also verifies that the remaining good bytes at the beginning of the sector actually have been overwritten, this will not work.

[Rybags]

I think they went right through (note the pics showing index hole on either side of where the head goes in each pic)

 

I'm not sure what happens with a write in such a situation - I'd assume so long as the sector header is there the write would take place and if it was "P" instead of "W" there'd be no verify (as most of us use)

 

The read back, I'm not sure either - I'm fairly sure it populates the buffer and ensures the CRC is good before sending the data frame to the user, otherwise it still returns some data but would it be (part of) the sector we just partly wrote?

 

I'd heard of this protection technique in the day but didn't know of any examples for our machine - and like just about everyone else had a file version of Flak that likely had any evidence of a protection check stripped out.

 

 

Additional - in theory if the disk was created by a drive or duplicator that used the index hole, they should be fairly precisely be able to put the hole at a known place in the middle of a sector (maybe a dozen bytes either side but that'd be well sufficient)

Edited March 7, 2022 by Rybags

[+DjayBee]

44 minutes ago, Rybags said:

The read back, I'm not sure either - I'm fairly sure it populates the buffer and ensures the CRC is good before sending the data frame to the user, otherwise it still returns some data but would it be (part of) the sector we just partly wrote?

The sector is returned with bad CRC and you are right that some data will/must be valid. Exactly this is being checked.

 

44 minutes ago, Rybags said:

Additional - in theory if the disk was created by a drive or duplicator that used the index hole, they should be fairly precisely be able to put the hole at a known place in the middle of a sector (maybe a dozen bytes either side but that'd be well sufficient)

This is theoretically true but they wrote the disks without index hole alignment.

They not even hit the same tracks on different disks. The disk in the first picture above has the "bad spot" on tracks 25-30, the one in the second picture on tracks 21-23.

They even managed to create very edgy sectors which sometimes work and sometimes not. Each of our dumps has one sector "collatorally" bad which needs to be good, but at least the disk in the second works fine in a 1050 drive.

Edited March 7, 2022 by DjayBee

[Rybags]

OK, fair enough - it would be a fairly effective method though knowing how they implemented it you could probably recreate it if you had a few originals.

Compare each one then work out which is the bad sector.  Likely they just stored it without altering the value so it might have been easy to find.

 

[Zarxx]

19 hours ago, ijor said:

 

Thanks Zarxx.

 

I didn't analyze this title, but AFAIK it doesn't write to the disk and then it doesn't verify the actual presence of a physical alteration to the disk surface. If so it seems just a rudimentary way to producing a sector with weak bits, and it should be possible to copy with any tool that can produce weak bits.

 

It does run write protected, right?

 

Yes, the B side has sample images.

[+DjayBee]

Not only we had problems with the reliability of the protection:

 

While I was analyzing the image nearly a year ago, I searched the web for information on FLAK and its protection but could find only one mentioning of "SYNCROLOK", the name Funsoft gave its protection, on page 65 of Personal Software Magazine Sep 1984:

 

Quote

We tested AppleFlak on several II Plus, Ile and Ile machines. All worked well, except for one Ile which wouldn’t boot the game despite considerable fiddling and it required a fair number of attempts before it would run on the Ile. CommodoreFlak worked fine. But the first dozen times we tried to boot AtariFlak the program decided we were trying to copy it (not true!) and gave us a smirking “happy face” instead of the game at the end of the boot, proudly announcing the brand of protection (Syncrolok). We changed drives and tried many more times and it finally loaded. Heavily protected programs like this are often fussy about disk drive speed and alignment. Loading the program takes about 90 seconds on all versions.

 

Snokie, which was published by Funsoft as well, used - not explicitly checked - the returned status codes from some bad sectors. This made it impossible to crack without access to a working copy.

Now the "Syncro" in Syncrolok put me on the wrong track that it used some advanced track alignment protection.

So I put it in my backlog after some time to eventually revisit it. Partially because its code is really convoluted and partially because I expected to need testing on a real physical drive to get all neded status and timing information.

 

Btw.: This is the "happy face":

 

Some two weeks ago I was cleaning my work-folder, stumbled over the image and gave it a second try.

After two days I had only found out that the loading and protection is completely obfuscated. It consists of an infinite loop built from a JSR to "weird code" and a JMP back to the JSR. Every piece of "weird code" ends in a BRK command.

At some point one of the subroutines tries to write to one of the weak sectors.

B6C1: 20 D1 B5          JSR $B5D1	; wait for ???
B6C4: 4C C1 B6          JMP $B6C1	; loop until ???

--
B5C6: A5 D4             LDA FR0
B5C8: 48                PHA
B5C9: 40                RTI		; go somewhere and return by BRK

B5CA: 08                PHP
B5CB: 68                PLA
B5CC: 29 C7             AND #$C7
B5CE: 85 D4             STA FR0
B5D0: 60                RTS

B5D1: 20 BF B5          JSR $B5BF
B5D4: A0 00             LDY #$00
B5D6: B1 D5             LDA ($D5),Y
B5D8: 85 DF             STA $DF
B5DA: 30 46             BMI $B622
B5DC: C9 30             CMP #$30
B5DE: B0 11             BCS $B5F1
B5E0: C9 0C             CMP #$0C
B5E2: B0 0A             BCS $B5EE
B5E4: 0A                ASL
B5E5: AA                TAX
B5E6: BD 78 B4          LDA $B478,X	; fetch subroutine's address
B5E9: 48                PHA
B5EA: BD 77 B4          LDA $B477,X
B5ED: 48                PHA
B5EE: 4C C6 B5          JMP $B5C6


Routine in sector $eb (235) at offset $7510:
----------------------------------------------------------

B703: A9 00             LDA #$00	; disable VVBLKD
B705: 8D 03 B4          STA $B403
B708: 20 06 A2          JSR $A206	; =>$a6d3, $a227/8=$d0 $c1 => 649 to $a000, write damaged sector
B70B: A9 80             LDA #$80	; enable VVBLKD
B70D: 8D 03 B4          STA $B403

B710: 98                TYA
B711: 00                BRK		; protection fails if code does not return from here

Since the bad sector every time was overwritten and became a good sector in Altirra, I suspected an emulation error in Altirra's disk code.

I mentioned this in the a8preservation forum and @ijor asked for the flux dump for analysis. He then came up with the solution that the disk must have been physically modified.

 

=====

 

FLAK has some checksum protection in the first phase of its loader, but fortunately not in the crucial second phase.

This allowed me to patch the above shown code at $B70B and insert some more code into the end of a disk sector which gets loaded before the above routine is called.

DONE.

Routine in sector $eb (235) at offset $7510:
----------------------------------------------------------

B703: A9 00             LDA #$00	; disable VVBLKD
B705: 8D 03 B4          STA $B403
B708: 20 06 A2          JSR $A206	; =>$a6d3, $a227/8=$d0 $c1 => 649 to $a000, write damaged sector

B70B: 4C E0 BF          JMP $BFE0	; fake expected sector data and status
B70E: 03 B4

B710: 98                TYA
B711: 00                BRK		; protection fails if code does not return from here


Added code to end of sector $29b (667) at offset $14d10:
----------------------------------------------------------

BFE0: AE FF 9F          LDX $9FFF	; number of stable bytes (minus 2)
BFE3: E8                INX
BFE4: E8                INX
BFE5: AD 0A D2          LDA RANDOM	; fill damaged area with random data
BFE8: 9D 00 A0          STA $A000,X
BFEB: E8                INX
BFEC: 10 F7             BPL $BFE5

BFEE: A2 08             LDX #$08	; fake expected status codes
BFF0: A0 90             LDY #$90
BFF2: A9 80             LDA #$80	; run the commands overwritten ...
BFF4: 8D 03 B4          STA $B403	; ... by the crack (enable VVBLKD)
BFF7: 4C 10 B7          JMP $B710   	; go back (BRK may not be here) 

 

Flak (1984)(Funsoft)(US)[cr CSS].atr (The disk may not be write-protected.)

 

Second dump (in case somebody wants to do an exhaustive comparison): Flak-Attempt2-SideA[cr CSS].atr

 

My documentation: Flak - Documentation.txt

Edited March 7, 2022 by DjayBee

[Rybags]

All that said, is the protection easy to remove?  Generally once a checksum routine is defeated and you fudge the expected return values from the disk operations you're probably just about there.

(though I did try to crack AR:  Dungeon and got maybe to the second round of code decryption, was working without the benefit of an original copy though)

[+DjayBee]

1 hour ago, Rybags said:

All that said, is the protection easy to remove?  Generally once a checksum routine is defeated and you fudge the expected return values from the disk operations you're probably just about there.

The crack itself was quite easy. As you can see in my code snippet above it's an inserted JMP and a few lines of added code.

The big deal was to find it. On real hardware without Altirra's help, it probably would have been a deal-of-a-lifetime with all this obfuscated code.

[+DjayBee]

If you want to create your own physical disk:
(The example numbers below are the ones matching the attached ATR)

• format a disk as single density
• drill into a small area of the disk
• hope that all damaged tracks have only sectors 10-18 damaged, because sectors 1-9 of every track are needed for FLAK
• map your disk and find out which sectors have become bad
• read each of the bad sectors a few times until you find one which
  1. creates a CRC-error
  2. starts with a certain number of stable bytes, followed by bytes varying at each read
• write down the track number and relative sector number on the track, both counting from 00 (i.e. sector 408 => t22, s11)
• find out how many bytes from the beginning of this sector always read the same value (i.e. 57) and subtract 1
• convert your numbers to hex (i.e. $16, $0B, $38)
• EOR each number with $FF (i.e. $E9, $F4, $C7)
• EOR all numbers with each other for a checksum (i.e. $16 EOR $0B EOR $38 = $25)
• copy the attached ATR over this disk using a sector copier
• run a sector editor, open sector 649 of your disk and change these bytes (bytes count from $00 to $7F):
  byte $25: EORed track-number (i.e. $E9)
  byte $45: EORed sector-number (i.e. $F4)
  byte $65: EORed stable bytes (i.e. $C7)
  byte $7F: checksum (i.e. $25)

Keep your fingers crossed and boot your personal copy protected disk of FLAK.

 

ATR with still active protection for sector 408:

Flak (1984)(Funsoft)(US)[write-protect off][f].atr

[cwilbar]

A step to help id where to damage the disk.....

 

I had a similar issue years ago with Super Bunny.  My 810 drive with The Chip could not copy it ('weak' sector). 

 

What I did was determined the track and sector.  I then put in a blank disk with the index hole in the media aligned with the index hole in the floppy's jacket.  I then put it in the 810 and wrote the track.  I then drew the right number of lines to 'map' the sectors to the physical disk (realigning the index hole), then with this paper overlayed, ran a small alnico magnet from the hub to the outside.  I then used The Chip/Archiver to read back the track and see what was damaged.  With a number of attempts I could figure out where to swipe the magnet in order to damage the correct sector.  I then copied all other tracks (and can't recall if I needed to copy the non damaged sectors of the track with the 'weak' sector).

 

Voila... a working copy of Super Bunny.

 

Something similar could be done here.  Target a sector, identify where to use a magnet to locate the right angle and beyond there, you could come up with a measurement based on drive specs if you wanted to target a specific track, and then use a dremel, drill, etc to permanently damage the magnetic coating where you want to, and then pick up on the instructions above.... less disks hopefully will go to landfills in this manner ?

 

Though I'd recommend just using a cracked copy and save all the effort ? .....

 

[+DjayBee]

11 hours ago, cwilbar said:

Though I'd recommend just using a cracked copy and save all the effort ? .....

This is my personal preference too - see post #10.

But I thought that documenting the original process, Funsoft must have applied back then, is a good thing.

 

Although I guess that they had a tool to redistribute the needed sectors, in case the bad ones where in the range of 1-9 per track.

Sectors 685 and 667 contain pointers to sectors needed for six load processes.