Enigma at 22:00, 24 August 2026

2026-08-24T22:00:01Z

Enigma: Created page with "= Eagles (C64) — GMA87 copy protection, full technical write-up = This article documents, in full technical detail, the copy protection scheme used by the Commodore 64 rele..."

2026-08-24T21:44:12Z

Created page with "= Eagles (C64) — GMA87 copy protection, full technical write-up = This article documents, in full technical detail, the copy protection scheme used by the Commodore 64 rele..."

New page

= Eagles (C64) — GMA87 copy protection, full technical write-up =

This article documents, in full technical detail, the copy protection scheme
used by the Commodore 64 release of '''Eagles''' (Hewson/Graeme Ashton,
1987), as distributed on the ''Beau Jolly Big Box 2'' compilation disk
(<code>BeauJolly_BigBox2_Disk6_s0.g64</code>). Eagles carries a
<code>GMA87</code> disk label — the same protection family used by
[[Cholo]], [[Triaxos]], and roughly twenty other titles linking to the
[https://preservation64.de/index.php?title=GMA87 GMA87] wiki page — but,
uniquely among all of them, moves the actual decryption step off the C64 and
onto the '''1541 disk drive's own 6502 CPU'''. This makes Eagles a title where the C64 never sees ciphertext for the protected
game data at all.

== Summary ==

* The disk directory is deliberately hidden from naive tools by a non-standard
(<code>$00</code> instead of <code>$A0</code>) filename padding.
* The only loadable file, <code>BOOT</code>, is deliberately loaded at
<code>$02A7</code> so that it overlaps and hijacks the C64's own KERNAL
page-2/3 RAM vector table — a standard auto-start trick.
* From there, a self-decrypting bootstrap streams in a much larger program
live from the drive, byte by byte, XORing each byte against its own
destination address (a descramble, not a secret key).
* That program contains a hardware-handshake primitive
(<code>$05EB</code>) that talks to the drive over CIA2's <code>$DD00</code>
port with cycle-accurate raster-line synchronization. It is used for
''every'' byte of a further custom byte-transfer protocol.
* The drive, on command, seeks to track 39 containing a
deliberately malformed sync region, and measures a **physically
unclonable, disk-specific signature byte** from sync length variation —
structurally the same measurement Cholo/Triaxos perform on track 38.
Measured value for this disk capture: <code>$95</code> (149 decimal).
* Unlike Cholo/Triaxos (which send this byte to the C64 and decrypt a large
static block there in one pass), Eagles uploads a '''fresh drive-side
program''' to drive RAM (<code>$0300</code>–<code>$03DF</code>) via
standard 1541 <code>M-W</code> (memory-write) commands, and bakes the
measured signature byte directly into that program's own machine code —
as the literal operand of an <code>EOR #$95</code> instruction at drive
address <code>$035D</code>.
* From that point on, the '''drive's own 6502''' decrypts every byte of
every subsequent game-data sector, one block at a time, and streams
already-plaintext bytes to the C64 over the bit-banged serial link. The
C64 never receives, stores, or applies the key itself.
* Both halves of the scheme fail ''silently'' on a bad copy — a hang, not an
error message or a crash on load. A disk that reproduces the sync-mark
layout but not the exact sync length pattern sails through every check on
both sides and decrypts to garbage far downstream

== Disk structure and directory obfuscation ==

=== Non-standard filename padding ===

The <code>BOOT</code> directory entry (logical track 18, sector 1, slot 0)
is the four bytes <code>42 4F 4F 54</code> (<code>"BOOT"</code>) followed by
'''twelve <code>$00</code> bytes''', not the standard CBM DOS
<code>$A0</code> (shifted-space) padding. Two confirmed consequences:

* <code>LIST</code>ing the directory truncates right after <code>BOOT</code>
with no closing quote or <code>PRG</code> shown — BASIC's line printer
reads the <code>$00</code> mid-string as a premature line terminator.
* <code>LOAD"BOOT",8,1</code> (exact name) returns <code>FILE NOT FOUND</code>
— the real KERNAL's name-matching does not tolerate the non-standard
padding either. Only <code>LOAD"*",8,1</code> (wildcard match on the
first directory entry) works.

1306 bytes, load address <code>$02A7</code>.

== Boot mechanism: overlapping the KERNAL's own RAM vector table ==

<code>$02A7</code> deliberately overlaps <code>$0300</code>–<code>$0333</code>,
the C64's page-2/3 KERNAL RAM vector table (<code>IERROR</code>,
<code>IMAIN</code>, ..., <code>CINV</code>, ..., <code>IGETIN</code>, ...).
Simply ''loading'' the file overwrites these vectors with whatever bytes
land at those file offsets — no explicit install instruction is needed.

* <code>IMAIN</code> (<code>$0302</code>, the address BASIC jumps through
every time it returns to its input loop) → becomes <code>$0334</code>.
* <code>ISTOP</code> (<code>$0328</code>, checked periodically during
KERNAL I/O, including during <code>LOAD</code> itself) → becomes
<code>$02ED</code>.

It means the "program" starts running the
moment <code>LOAD</code> returns control to BASIC, with no <code>RUN</code>
needed. The execution entry is at <code>$02ED</code> (<code>ISTOP</code>), not
byte 0 of the file.

== Bootstrap: a self-decrypting live stream, not a static file ==

Tracing forward from <code>$02ED</code> '''live''' (the static file content
at these addresses is misleading — see why below):

* <code>$02ED</code>–<code>$0301</code>: <code>JSR $FFC3</code>
(<code>CLOSE</code>), set pointer <code>$AE</code>/<code>$AF</code> =
<code>$0334</code>, disable the display (<code>$D011</code>), then
<code>JSR $FFC6</code> (<code>CHKIN</code> — itself hijacked, see next),
then <code>JSR $0334</code>.
* The hijacked <code>ICHKIN</code> vector (<code>$031E</code> →
<code>$02CB</code>) actually points at a small relocator that copies 9
bytes from <code>$0304</code> to <code>$8000</code>, then
<code>JMP $02A7</code>.
* <code>$02A7</code>: a tight loop —

<pre>
$02A7 JSR $FFA5 ; ACPTR - read one byte from the IEC bus
$02AA EOR $AE ; XOR against the destination pointer's OWN low byte
; (a self-referential descramble, not a secret
; key - fully determined by address alone)
$02AC STA ($AE),Y
$02AE ... ; increment pointer, loop
</pre>

...continuing until the pointer reaches <code>$075D</code>. This is why a
''static'' disassembly of <code>$0334</code>–<code>$075D</code> looks like
noise: those bytes are overwritten live, streamed byte-by-byte from the
drive, before they are ever executed.

Once populated, <code>$0334</code> onward contains a real, coherent program

== The <code>$05EB</code> primitive: the real protection gate ==

Deep inside the newly-populated block sits <code>$05EB</code>, the key
routine used for every byte of the custom transfer protocol that follows —
including the destination address the payload gets written through.

<pre>
$05EB A9 0A LDA #$0A ; border/background = orange (visual cue)
$05ED 8D 20 D0 STA $D020
$05F0 8D 21 D0 STA $D021
$05F3 A5 17 LDA $17
$05F5 8D 00 DD STA $DD00 ; write to CIA2 port A (drive-facing)
$05F8 EE 18 D4 INC $D418 ; SID volume flicker, cosmetic
$05FB AD 00 DD LDA $DD00
$05FE 10 F8 BPL $05FB ; wait for bit 7 - a response from the drive
$0600 AD 12 D0 LDA $D012 ; raster line
$0603 C9 31 CMP #$31
$0605 90 06 BCC $060D
$0607 29 06 AND #$06
$0609 C9 02 CMP #$02
$060B F0 F3 BEQ $0600 ; cycle-accurate raster-synced wait
$060D A9 02 LDA #$02
$060F 8D 20 D0 STA $D020 ; border = red
$0612 8D 21 D0 STA $D021
$0615 A5 18 LDA $18
$0617 8D 00 DD STA $DD00
$061A EA (x9) NOP ; fixed-length timing pad
$0624 AE 00 DD LDX $DD00 ; read the port value...
$0627 BD 00 01 LDA $0100,X ; ...as an INDEX into a lookup table
$062A AE 00 DD LDX $DD00
$062D 1D 08 01 ORA $0108,X ; three more reads, three more tables, OR'd together
$0630 AE 00 DD LDX $DD00
$0633 1D 10 01 ORA $0110,X
$0636 AE 00 DD LDX $DD00
$0639 1D 18 01 ORA $0118,X
$063C 60 RTS
</pre>

This reads CIA2's <code>$DD00</code> port with cycle-accurate raster-line
synchronization — structurally the same "cycle-accurate <code>$DD00</code>"
handshake mechanism the Cholo/Triaxos track-38 check uses — and decodes the
drive's response into a byte using four 256-entry lookup tables as a
nibble/bit decoder.

The four lookup tables at <code>$0100</code>/<code>$0108</code>/
<code>$0110</code>/<code>$0118</code> are '''fixed, not disk-derived''': a
store-watchpoint on that range caught the first write coming from a plain,
unconditional copy loop (<code>$0725</code>–<code>$073F</code>) that tiles a
'''fixed''' 28-byte source at <code>$0740</code>, eight repeats each, into
<code>$0100</code>–<code>$01FF</code>. They only gate ''whether''
<code>$05EB</code> can complete at all; they don't encode a disk-specific
value.

The transfer this primitive serves uses a <code>$01</code>-byte
escape/terminator framing: a lone <code>$01</code> signals end-of-data,
<code>$01 $01</code> is an escaped literal <code>$01</code>, anything else
is stored directly via <code>STA ($AE),Y</code> with '''no further
transformation'''.

=== Verification: a plain D64 hangs, it does not decrypt to garbage ===

Attaching a plain sector-image conversion of this disk (no raw GCR
track-39 signature present) and running the identical
<code>LOAD"*",8,1</code> sequence, execution reaches <code>$02A7</code>,
runs '''identically''' up to this exact point, and then '''hangs
permanently''' at <code>$05FB</code>/<code>$05FE</code>
(<code>LDA $DD00</code> / <code>BPL $05FB</code>).

== The signature track: track 39 ==

The signature region is '''not''' at logical track 38 the way it is for
Cholo/Triaxos. Converting the G64 to text and inspecting it shows physical
tracks 36–38 are entirely empty (no <code>track N</code> section at all —
a real gap), while '''track 39''' has a section with two
unmistakable markers: its first decoded bytes start with
<code>69 59 59 A7 A7...</code> (matching the <code>69 XX XX XX A9</code>-style
signature prefix used by every other GMA87 game), and its <code>sync N</code>
entries are wildly non-uniform (<code>41, 40, 40, 40, 87, 136, 40, 40</code>)
versus a normal track's uniform sync-mark length throughout.

=== Track-seek mechanism: entirely standard DOS ROM code ===

The drive's own <code>DRVTRK</code> variable (<code>$0022</code>) was traced
live across a full load. '''The <code>DRVTRK=39</code> transition is
reached via completely standard, unmodified DOS-ROM job-dispatch code.

* The custom drive code's only involvement is submitting an ordinary job
(code <code>$E0</code>, EXECUTE) into the standard job queue with a
header-table track value of '''39''' — a value the ROM never validates
against the normal 1–35 range.
* The store into <code>DRVTRK</code> happens at <code>$F31B</code>
(<code>LDA ($32),Y</code> / <code>STA $22</code>), inside the stock job
dispatcher's buffer-scan/mismatch-handling loop — 100% ROM code, reading
the out-of-range track value straight out of the job's own header-table
entry.

== Stage 1: the track-39 signature-measurement program ==

It turns out to be '''structurally identical to the Cholo/Triaxos
track-38 algorithm''', just retargeted to Eagles' own signature track (39):

<pre>
; ---- sync-marker search, 90-attempt retry budget ----
$0300 AD 00 1C LDA $1C00
$0303 29 9F AND #$9F
$0305 8D 00 1C STA $1C00
$0308 A0 5A LDY #$5A ; Y = 90 - sync-retry budget
$030A 88 DEY ; <-- retry entry point
$030B D0 05 BNE $0312
$030D A9 02 LDA #$02 ; error $02 = HEADER NOT FOUND
$030F 4C 69 F9 JMP $F969 ; ERRR - retries exhausted, report failure
$0312 2C 00 1C BIT $1C00
$0315 30 FB BMI $0312 ; sync-wait poll
$0317 AD 01 1C LDA $1C01 ; discard first raw byte after sync
$031A B8 CLV
$031B A2 04 LDX #$04
$031D 50 FE BVC $031D ; CLV/BVC byte-ready wait (classic 1541 trick)
$031F B8 CLV
$0320 AD 01 1C LDA $1C01 ; read raw GCR byte
$0323 9D 00 05 STA $0500,X ; store into $0500-$0504 (5 bytes)
$0326 CA DEX
$0327 10 F4 BPL $031D
$0329 C9 A9 CMP #$A9 ; last byte read must be $A9
$032B D0 DD BNE $030A ; mismatch -> retry
$032D AD 04 05 LDA $0504 ; first byte read (2nd overall)
$0330 C9 69 CMP #$69 ; must be $69
$0332 D0 D6 BNE $030A ; mismatch -> retry
; signature "69 xx xx xx A9" confirmed

; ---- 10-sample raw pulse-width (flux-jitter) measurement ----
$0334 A0 00 LDY #$00
$0336 2C 00 1C BIT $1C00
$0339 30 FB BMI $0336 ; wait for next sync
$033B A2 00 LDX #$00
$033D E8 INX ; <-- pulse-width measurement loop
$033E 2C 00 1C BIT $1C00
$0341 10 FA BPL $033D ; count iterations (X) while bit7=0
$0343 8A TXA
$0344 99 00 05 STA $0500,Y ; store sample[Y]
$0347 C8 INY
$0348 C0 0A CPY #$0A ; 10 samples total
$034A D0 EA BNE $0336

; ---- fold 10 samples into an 8-bit result via CMP/ROL ----
$034C A2 02 LDX #$02 ; sample[0] discarded, sample[1] = reference
$034E BD 00 05 LDA $0500,X
$0351 CD 01 05 CMP $0501 ; compare sample[X] to reference
$0354 2E 0A 05 ROL $050A ; roll carry (>=ref->1, <ref->0) into result byte
$0357 E8 INX
$0358 E0 0A CPX #$0A ; samples[2..9], 8 comparisons -> 8-bit result
$035A D0 F2 BNE $034E
$035C AE 0A 05 LDX $050A ; X = computed 8-bit result: $95 for this disk

; ---- send the result byte to the C64 via VIA1 $1800, nibble-out ----
$035F 2C 00 18 BIT $1800
$0362 10 FB BPL $035F ; wait for IEC bus ready
$0364 A9 10 LDA #$10
$0366 8D 00 18 STA $1800
$0369 2C 00 18 BIT $1800
$036C 30 FB BMI $0369
$036E 8A TXA ; A = result byte
$036F 4A LSR A ; \ send high nibble
$0370 4A LSR A ; |
$0371 4A LSR A ; |
$0372 4A LSR A ; /
$0373 8D 00 18 STA $1800
$0376 0A ASL A
$0377 29 0F AND #$0F
$0379 8D 00 18 STA $1800
$037C 8A TXA
$037D 29 0F AND #$0F ; \ send low nibble
$037F 8D 00 18 STA $1800 ; |
$0382 0A ASL A ; |
$0383 29 0F AND #$0F ; |
$0385 8D 00 18 STA $1800 ; /
$0388 A9 0F LDA #$0F
$038A EA NOP
$038B 8D 00 18 STA $1800 ; final bus state
$038E A9 01 LDA #$01 ; status $01 = SUCCESS
$0390 4C 69 F9 JMP $F969 ; ERRR (used generically as "set status, return")

; ---- self-relocation/patch helper (install-time only, not per-visit) ----
$0393 38 SEC
$0394 AD 39 03 LDA $0339
$0397 E9 E1 SBC #$E1
$0399 85 FB STA $FB
$039B AD 3A 03 LDA $033A
$039E E9 10 SBC #$10
$03A0 85 FC STA $FC
$03A2 A9 8D LDA #$8D ; $8D = STA opcode - patches code in place
$03A4 A0 00 LDY #$00
$03A6 91 FB STA ($FB),Y
$03A8 C8 INY
$03A9 38 SEC
$03AA AD 35 03 LDA $0335
$03AD E9 D2 SBC #$D2
$03AF 91 FB STA ($FB),Y
$03B1 C8 INY
$03B2 AD 36 03 LDA $0336
$03B5 E9 04 SBC #$04
$03B7 91 FB STA ($FB),Y
$03B9 60 RTS

; ---- self-decrypt the $0300-$0392 block against 3 fixed ROM bytes (anti-static-disasm) ----
$03BA A2 00 LDX #$00
$03BC BD 00 03 LDA $0300,X
$03BF 4D 10 F5 EOR $F510
$03C2 4D 56 F5 EOR $F556
$03C5 4D 18 C1 EOR $C118
$03C8 9D 00 03 STA $0300,X
$03CB E8 INX
$03CC E0 93 CPX #$93 ; $93 = 147 bytes
$03CE D0 EC BNE $03BC

; ---- job setup: target track 39, submit EXECUTE job, check result ----
$03D0 A9 27 LDA #$27 ; $27 = 39 decimal - THE TARGET TRACK
$03D2 85 06 STA $06
$03D4 A9 01 LDA #$01
$03D6 85 07 STA $07
$03D8 20 18 C1 JSR $C118 ; (ROM call)
$03DB A9 E0 LDA #$E0
$03DD 85 00 STA $00 ; submit EXECUTE job (buffer 0)
$03DF A5 00 LDA $00
$03E1 30 FC BMI $03DF ; wait for job completion
$03E3 C9 02 CMP #$02
$03E5 90 06 BCC $03ED ; status < 2 (success) -> RTS normally
$03E7 4C E7 03 JMP $03E7 ; status >= 2 (FAILURE) -> INFINITE SELF-LOOP
$03EA 20 2C C1 JSR $C12C ; (unreached in the traced path)
$03ED 60 RTS
</pre>

'''Both failure modes are deliberate, permanent hangs, never wrong output:'''
if the 5-byte marker doesn't match, the routine retries the sync search up
to 90 times before giving up with error <code>$02</code> ("header not
found"). If the job's returned status is failure, execution at
<code>$03E7</code> falls into an infinite self-loop
(<code>JMP $03E7</code>) — the drive-side counterpart to the C64-side hangs
at <code>$05FB</code>/<code>$05FE</code>.

'''Measured result byte for this disk capture: <code>$95</code> (149
decimal).''' Raw sample buffer at <code>$0500</code>–<code>$0509</code>:
<code>12 27 3C 11 12 3D 12 3D 12 3D</code> (sample[0]=<code>$12</code>
discarded, sample[1]=<code>$27</code> the reference). Hand-verifying the
<code>CMP</code>/<code>ROL</code> algorithm against these samples
independently reproduces <code>$95</code> exactly.

== Stage 1 → C64: <code>$05EB</code> receives <code>$95</code> ==

The C64 receives the drive's track-39 result via the same
<code>$05EB</code> routine documented above (raster-synced <code>$DD00</code>
poll, then the 4-lookup-table decode, <code>RTS</code> at <code>$063C</code>).

The consumer is a separate, small wrapper elsewhere in the
same code block:

<pre>
$071F 78 SEI
$0720 20 EB 05 JSR $05EB
$0723 58 CLI
$0724 60 RTS ; A=$95, SP=$FB
</pre>

This returns to

<pre>
$03B9 8D 6E 05 STA $056E ; A=$95 (unchanged), SP=$FF
</pre>

== The <code>M-W</code> upload: staging a fresh drive-side program ==

<code>$056E</code> is not a destination in its own right — it is offset
<code>$5D</code> (93 decimal) inside a larger, 224-byte C64-RAM buffer
based at <code>$0511</code>. That buffer gets uploaded to the drive, 32
bytes at a time, via a sequence of standard 1541 DOS '''<code>M-W</code>
(memory-write)''' command-channel commands:

<pre>
; ---- open the drive's command channel (LFN=15, dev=8, SA=15) ----
$06D4 20 BD FF JSR $FFBD ; SETNAM
$06D7 A9 0F LDA #$0F ; A = 15
$06D9 A8 TAY ; Y = 15 (secondary address = command channel)
$06DA A2 08 LDX #$08 ; X = 8 (device 8)
$06DC 20 BA FF JSR $FFBA ; SETLFS(LFN=15, dev=8, SA=15)
$06DF 20 C0 FF JSR $FFC0 ; OPEN
$06E2 A2 0F LDX #$0F
$06E4 20 C9 FF JSR $FFC9 ; CHKOUT(15)
$06E7 A9 4D LDA #$4D / JSR $FFD2 ; CHROUT 'M'
$06EC A9 2D LDA #$2D / JSR $FFD2 ; CHROUT '-'
$06F1 60 RTS ; "M-" sent so far

; ---- complete the M-W command header and send one 32-byte chunk ----
$0644 20 D2 06 JSR $06D2 ; (the "M-" open routine above)
$0647 A9 57 LDA #$57 / JSR $EDDD ; 'W' -> command so far: "M-W"
$064C A5 17 LDA $17 / JSR $EDDD ; address LOW byte (running offset:
; $00,$20,$40,$60,$80,$A0,$C0)
$0651 A9 03 LDA #$03 / JSR $EDDD ; address HIGH byte (fixed: page $03)
$0656 A9 20 LDA #$20 / JSR $EDDD ; count = $20 (32 bytes), fixed
$065B A4 17 LDY $17
$065D 18 CLC
$065E A5 17 LDA $17
$0660 69 20 ADC #$20 ; running offset += $20 for next pass
$0662 85 17 STA $17
$0664 B9 11 05 LDA $0511,Y ; <-- payload byte Y of the upload buffer
$0667 20 DD ED JSR $EDDD ; send it
$066A C8 INY
$066B C4 17 CPY $17
$066D D0 F5 BNE $0664 ; loop for all 32 bytes of this chunk
$066F 20 CC FF JSR $FFCC ; CLRCHN
$0672 A5 17 LDA $17
$0674 C9 DA CMP #$DA ; $DA = 218 decimal
$0676 90 CC BCC $0644 ; more chunks needed -> loop
$0678 ... ; upload complete (7 chunks, 224 bytes)
</pre>

Each pass sends one complete <code>M-W $03xx $20 <32 bytes></code>
command. Seven passes, at running offsets
<code>$00,$20,$40,$60,$80,$A0,$C0</code>, upload <code>$E0</code> (224)
bytes total, covering drive RAM <code>$0300</code>–<code>$03DF</code>.
'''The <code>$0511</code> buffer is a full replacement copy of the next
drive-side job program, staged in C64 RAM and pushed to the drive one
<code>M-W</code> chunk at a time.'''

Since <code>$056E</code> sits at buffer offset <code>$5D</code>, inside the
'''third''' 32-byte chunk (offsets <code>$40</code>–<code>$5F</code>,
destined for drive addresses <code>$0340</code>–<code>$035F</code>), the
measured signature byte lands at drive address
<code>$0300 + $5D = $035D</code>.

== Stage 2: the uploaded drive-side program, with <code>$95</code> marked ==

Uploaded specifically to decrypt and stream the actual game
data:

<pre>
; ---- read a full GCR-encoded sector from the VIA into a 256-byte buffer ----
$0300 A9 06 LDA #$06
$0302 85 31 STA $31
$0304 20 0A F5 JSR $F50A ; seek/prep (1541 KERNAL DSTRT)
$0307 50 FE BVC $0307 ; wait for VIA SR byte-ready
$0309 B8 CLV
$030A AD 01 1C LDA $1C01 ; read GCR byte from VIA2
$030D 99 00 06 STA $0600,Y
$0310 C8 INY
$0311 D0 F4 BNE $0307 ; fill $0600-$06FF (256 bytes)

$0313 A0 BA LDY #$BA
$0315 50 FE BVC $0315
$0317 B8 CLV
$0318 AD 01 1C LDA $1C01
$031B 99 00 01 STA $0100,Y
$031E C8 INY
$031F D0 F4 BNE $0315 ; fill $01BA-$01FF (70 bytes, stack page)

; ---- decode GCR, verify header track and checksum (standard DOS ROM calls) ----
$0321 20 E0 F8 JSR $F8E0 ; GCRBIN
$0324 A5 38 LDA $38
$0326 C5 47 CMP $47 ; header track check
$0328 F0 04 BEQ $032E
$032A A9 04 LDA #$04
$032C D0 4E BNE $037C ; -> error, status $04

$032E 20 E9 F5 JSR $F5E9 ; CHKBLK
$0331 C5 3A CMP $3A ; checksum check
$0333 F0 04 BEQ $0339
$0335 A9 05 LDA #$05
$0337 D0 43 BNE $037C ; -> error, status $05

; ---- header fields decrypted with FIXED, disk-independent ROM constants ----
$0339 AD 01 06 LDA $0601
$033C 4D 77 F5 EOR $F577 ; byte-count field
$033F 8D 01 06 STA $0601
$0342 85 07 STA $07
$0344 A0 02 LDY #$02
$0346 A2 FF LDX #$FF
$0348 AD 00 06 LDA $0600
$034B 4D 76 F5 EOR $F576 ; status/type byte
$034E 8D 00 06 STA $0600
$0351 F0 03 BEQ $0356
$0353 8E 01 06 STX $0601
$0356 EE 01 06 INC $0601

; ---- ****** THE PER-BYTE DATA DECRYPTION LOOP ****** ----
$0359 B9 00 06 LDA $0600,Y
$035C 49 95 EOR #$95 ; <====== HERE. The measured
; flux-jitter signature byte, INJECTED
; by the M-W upload above, sits as the
; immediate operand of this EOR at
; drive address $035D. Every data byte
; of every subsequent sector is
; decrypted with THIS key, on the
; drive's own 6502, before ever being
; sent to the C64.
$035E AA TAX
$035F E0 01 CPX #$01
$0361 D0 03 BNE $0366
$0363 20 91 03 JSR $0391 ; send nibble (bit-bang $1800)
$0366 20 91 03 JSR $0391 ; send nibble
$0369 C8 INY
$036A CC 01 06 CPY $0601
$036D D0 EA BNE $0359 ; loop over the whole decrypted data block

; ---- end-of-block housekeeping / next-sector dispatch ----
$036F AD 00 06 LDA $0600
$0372 F0 0E BEQ $0382
$0374 C5 06 CMP $06
$0376 85 06 STA $06
$0378 F0 05 BEQ $037F
$037A A9 01 LDA #$01
$037C 4C 69 F9 JMP $F969 ; job dispatcher / error exit
$037F 4C 04 03 JMP $0304 ; loop back for next GCR block

$0382 A2 01 LDX #$01
$0384 20 91 03 JSR $0391
$0387 A2 02 LDX #$02
$0389 20 91 03 JSR $0391
$038C A9 7F LDA #$7F
$038E 4C 69 F9 JMP $F969 ; job status $7F = done/OK

; ---- $0391: the same $1800 bit-bang nibble-send routine used by Stage 1 ----
$0391 2C 00 18 BIT $1800
$0394 10 FB BPL $0391
$0396 A9 10 LDA #$10
$0398 8D 00 18 STA $1800
$039B 2C 00 18 BIT $1800
$039E 30 FB BMI $039B
$03A0 8A TXA
$03A1 4A LSR A
$03A2 4A LSR A
$03A3 4A LSR A
$03A4 4A LSR A
$03A5 8D 00 18 STA $1800
$03A8 0A ASL A
$03A9 29 0F AND #$0F
$03AB 8D 00 18 STA $1800
$03AE 8A TXA
$03AF 29 0F AND #$0F
$03B1 8D 00 18 STA $1800
$03B4 0A ASL A
$03B5 29 0F AND #$0F
$03B7 8D 00 18 STA $1800
$03BA A9 0F LDA #$0F
$03BD 8D 00 18 STA $1800
$03C0 60 RTS
</pre>

'''This is the actual decryption mechanism for the game's data payload.'''
The block's own header fields (byte count, status/type byte) are
"decrypted" with '''fixed, disk-independent''' constants pulled straight
from the drive's own ROM (<code>$F576</code>/<code>$F577</code>) — plain
obfuscation, not keyed to this disk at all. Every actual '''data''' byte,
by contrast, is decrypted with <code>$95</code> — the disk-specific,
sync length variation signature — inside the loop at
<code>$0359</code>–<code>$036D</code>, entirely on the drive, before the
byte is ever placed on the serial bus. The C64 receives only
already-decrypted plaintext through the same <code>$0391</code> nibble-out
routine documented for Stage 1.

== See also ==

* [[GMA87]]

@@ Line 2: / Line 2: @@
 This article documents, in full technical detail, the copy protection scheme
-used by the Commodore 64 release of '''Eagles''' (Hewson/Graeme Ashton,
+used by the Commodore 64 release of '''Eagles''', as distributed on the ''Beau Jolly Big Box 2'' compilation disk
 (<code>BeauJolly_BigBox2_Disk6_s0.g64</code>). Eagles carries a
 <code>GMA87</code> disk label — the same protection family used by

Eagles GMA87 - Revision history

Enigma at 22:00, 24 August 2026

Enigma: Created page with "= Eagles (C64) — GMA87 copy protection, full technical write-up = This article documents, in full technical detail, the copy protection scheme used by the Commodore 64 rele..."