Decoding Copylock

[mnemo70]

Hi!

I discovered this amazing treasure of Amiga disk formats and especially the Copylock decoder while researching tools to participate in a small Crack Challenge on Twitch for cracking "Archer MacLean presents Billiard Americain". This is the French (?) release of "Archer MacLean's Pool" and the protections look the same.

I managed to crack the game using WinUAE's debugger, but when trying to run the Copylock code through your "copylock" tool, a specific part of customized, game-specific protection code inside the Copylock does not decode and I wonder why.

IPF is here.

If I'm not mistaken, "copylock" will not read IPF images so I first converted the IPF to DSK:

./disk-analyse -v -f amigados_copylock -e 79 ../m68k/billard.ipf ../m68k/billard.dsk
Found format "amigados_copylock"
PLL Parameters: period_adj=5% phase_adj=60%
T0.0: AmigaDOS
T0.1: Copylock
T1.0-79.1: AmigaDOS

The Copylock code in Billard Americain is located at 32a8c:

00032a8c 487a 000a                pea.l (pc,$000a) == $00032a98
00032a90 23df 0000 0010           move.l (a7)+ [00000003],$00000010
00032a96 4afc                     illegal

In the game, the Copylock runs in Supervisor mode with the stack pointing to 3f0. I added a bit of startup to set this up for "copylock" and added $4afa at 33392 after the Copylock to make m68k exit.

00032a72 41fa 0008                lea.l (pc,$0008) == $00032a7c,a0
00032a76 21c8 0080                move.l a0,$0080.w [00032988]
00032a7a 4e40                     trap #$00
00032a7c 4ff8 03f0                lea.l $03f0.w,a7

Running copylock:

./copylock billard-copylock.bin 0 0 32a72 billard.dsk

There are two custom instructions in the Copylock.

One instruction is correctly decoded:

00033216  31fc a9d0 03e8  move.w  #a9d0,3e8

The other is at 32fee and is not decoded:

00032fd6  4e75            rts
00032fd8  3005            move.w  d5,d0
00032fda  6b14            bmi.b   32ff0
00032fdc  6100 01a4       bsr.w   33182
00032fe0  4a86            tst.l   d6
00032fe2  6722            beq.b   33006
*** MISSING CODE ***
00032fee 33fc 9290 0003 7994 move.w #9290,37994
    tst.b d3
    beq.s 33006
*** /MISSING CODE ***
-------------------------------
00032ff2  70ff            moveq   #-1,d0
00032ff4  13c0 00bf d100  move.b  d0,ciabprb

I don't know the reason why the custom code at 32fee is not executed.

Does this game have changes in the Copylock protection track that is not converted correctly in disk-analyse?

Thanks for taking a look. ;-)

Thomas

[keirf]

I will say that it's normal for copylock not to fully disassemble the encrypted parts of the Copylock routine. The principle of operation is that unencrypted opcodes are captured as they are executed. So sections of Copylock which are not executed are not correctly disassembled. And it is quite normal for some sections of a Copylock not to be executed on a normal execution.

If you are certain that the offending instruction must be executed on a normal correct execution then yes, there must be a problem.

[keirf]

An initial dig indicates that copylock tool is not working properly. I only see it logging that it "loaded track 0" however the Copylock is of course on track 1. So the Copylock never finds the first custom sync word, and bails early. Hence why the disassembly is especially short.

I will see if I can fix this as an academic exercise!

[keirf]

Yeah so the evaluation of CIAB_DSKSIDE is just out of whack. The initial value of CIABPRB is 0xFF, which selects side 0, but the initial logical track number is 1. Then the side-update code:

if ((old_ciabb ^ new_ciabb) & (1u << CIAB_DSKSIDE))
        s->disk.tracknr ^= 1;

Remains forever out of sync, always selecting precisely the wrong side of the disk.

How did this ever work for the very early Copylocks I decoded (eg. https://github.com/keirf/amiga-stuff/blob/master/cracking/protections/rnc_copylock_NZS)?

Well it seems that I did this back in 2012, and at that time the copylock tool was broken in a different way, treating CIABPRB macros as bit masks when they are defined as bit offsets. And that worked by luck. Then in 2014 I noticed this brokeness and fixed it (a280956) but won't have subsequently retested copylock, which was now visibly broken. And that's been the status quo for over a decade until you came along!

[mnemo70]

Wow, this is awesome! Sorry for not getting back earlier, but I only can make the time in the evenings. I guess you don't need the other decoded assembly anymore. Thank you so much for spending your time on this. I just tried the new code and lo and behold:

00032fea  4a86            tst.l   d6
00032fec  6722            beq.b   33010
00032fee  33fc 9290 0003  move.w  #9290,37994
00032ff4  7994
00032ff6  4a03            tst.b   d3
00032ff8  6716            beq.b   33010

The "secret" MOVE.W gets disassembled now.

[keirf]

Hopefully this will be useful for future cracking exploits now. Of course these sorts of poke instructions are quite easy to eyeball in a disassembled Copylock but you could also imagine adding extra logging to the emulator callbacks, eg mem_write(), to explicitly log unexpected writes. The code's readily hackable for investigating specific Copylock routines, that's quite a strength.

[mnemo70]

That's a great idea, I'll keep that in mind!

[keirf]

This is now fixed by 2b35477.

Incidentally, I found the copylock at 32a96. Some of my disassembled instructions are at your reported addresses, while others are +0xa. If I change my start address to 32a8c then I end up with all my addresses -0xa from where they were (unsurprisingly). So it seems you reported copylock decodes relative to two slightly different base addresses? Not that this matters, just interesting to report it. Or perhaps I decoded a different Copylock from the game (eg. a different payload based on memory size)?

[keirf]

I've also done some more cleanups meanwhile.

[mnemo70]

You are correct, of course. The Copylock sits at 32a96. Maybe I somehow introduced the $A offset while adding the setup code I described above to enter Supervisor mode and set the stack to run the code in copylock. I wrote my original post in the course of about 2 hours while gathering all the data and trying out various things, sorry.

There is no variation of addresses in the game. It is always unpacked and run at 5D82.

00032a90 41f9 0006 a11c           lea.l $0006a11c,a0
00032a96 487a 000a                pea.l (pc,$000a) == $00032aa2
00032a9a 23df 0000 0010           move.l (a7)+ [000c0000],$00000010 [00fc0000]
00032aa0 4afc                     illegal

[keirf]

Mysteries solved!