Introduction to Ghidra: Commodore 64 Copy Protection Analysis

TOC:
0:00 Introduction
3:11 Basics of Ghidra and 6502 assembly
11:12 Introducing floppy disk copy protection schemes
----
16:39 Start of Robots of Dawn copy protection analysis
25:52 Using python window to perform deobfuscation
30:13 Introducing custom scripts
34:57 Crash course in CBM DOS calls
39:45 Code relocation using the python window
42:35 Searching binary for strings
54:11 Protection revealed
----
58:15 Start of Bride of Frankenstein copy protection analysis
59:12 Custom Ghidra loader and Ghidra/Eclipse integration
1:14:46 Using a script for deobfuscation
1:17:54 Yet another deobfuscation loop
1:20:20 And yet another deobfuscation loop
1:26:12 Code relocation using the GUI
1:27:08 Analysis of code sent to floppy drive
1:32:28 Protection revealed
1:37:38 Jumping into the middle of an instruction
----
1:39:55 Custom Ghidra Analyzer (used on Bride of Frankenstein)
1:43:17 Emulating assembly code (used on Robots of Dawn)
1:48:34 Extending CPU instructions by changing the Sleigh
1:58:04 Close

Errata:

Links:

Code in the talk (some updates since recording):

Ghidra:

Ghidra forums:

C64 protection schemes:

C64 floppy disk image file formats:

[andrewdunbar]

I'm not a C64 guy but I am an 8-bit era guy and a reverse engineering guy and a Ghidra guy and this video hits all of those spots! I'm now working on my own bunch of stuff for using Ghidra with Retro systems just for fun.

[stephenwhite]

Cool and interesting stuff, nice work!
These days, VICE's monitor makes it very easy to watch how copy protections work. You can view code on both the 64's CPU and the drive's CPU. When developing the emulator Pi1541 it was an invaluable asset.
The thing I discovered, when developing Pi1541, was a long run of zeros on a floppy is problematic for two reasons. One, maintaining bit cell timing (the one everyone says is the reason for encoding) but also a second reason. The second reason is that drive coils can only detect changing magnetic fields. With long runs of zeros, the magnetic field change is slowed down, the more ones the slower the change. The slope of the signal gets flatter and flatter. This flatness is problematic.
The flux reversals are detected by finding the derivative of the signal by feeding it through an op-amp configured as a differentiator. This converts the parts of the signal where the slope changes (ie becomes flat) into zero crossings. If an almost flat signal slope has the slightest amount of random noise on it then a false zero crossing could occur and hence an incorrect one read. Some copy protections exploited this by deliberately inserting a very slow changing magnetic field or simply a section of the disk with no magnetic field. The code would read the section of the disk multiple times and expect different results each time (as the noise was random). If it ever read back the same values then it would know it was a copy. For Pi1541 I had to simulate this by randomly inserting ones between long stretches of real flux reversals.
When testing Pi1541 I saw some crazy stuff all in the name of copy protection. One case, that I don't even think Ghidra would help, was code in the drive would begin executing the data at the drive's ROM as code. This would cause BRK instructions to execute but the code keeps going executing everything including the interrupt vectors (at the end of the ROM) as code and eventually loops back around into zero page RAM where it keeps executing over the variables it put there and finally into code it put there.

[ScottyBrockway]

Interesting, I would want to change a lot of the pc definitions to standard 6502 syntax. I'm not sure how difficult that would be. 0x is very offputting for 6502 and $ is more natural. VICE is incredibly useful for reverse engineering as others have mentioned as you can step both the 64 and drive code an the emulation is the most accurate available at this time. The flow charting is quite useful, but can get complex to the point of being unmanagable with 6502 stuff pretty quickly due to optimizations. Would need to add everything from No More Secrets as well for all the undocumented opcodes and becoming familair with the all the "features" of the 6502 that not everyone knows which are often exploited in copy protections. Would be fun to work on something that is a lot more complex like a Datasoft protection or Rapidlok or V-Max, or even Timex.

[aethermass]

"If you are genX, this is what Christmas looked like in 1983." That's my Youd =)

[johnmarks]

You should do a youtube interview with the developer of this copy protection.

[markusfritze]

This is the best video I've seen on how to use Ghidra with a C64 – not just in the context of copy protection. Thank you very much!

[johnmarks]

Thanks for making this video. I do have 6502 experience with the Apple ][ and none with the C64. Hope I can follow this video.

[jcl]

In the case of Robots of Dawn, if you boot the game up in C64 Debugger you could step through the program and see the decoding happening and the code appearing in that loader. Might have been a faster way to demonstrate this decoding happening right of the bat. Although interesting tool this Ghidra and nice to get a demonstration of how you could use it for this kind of case. Btw, maybe I missed it but what makes the program read each of the two differently labelled Track 21 Sector 3 for each time that call is made to fetch that? Is it a feature of the ROM code that it would deliver one and then the next one?

[IanLee]

In case you're like me and missed it, there are links to files used in this talk (such as the source code) in the description.

[JoEbY-X]

I'm on a Zoom meeting so I haven't watched this yet, but some of the copy protection methods I remember discovering in the 1980's were:

1. Data on an unallocated sector that the program would look for at start-up. If you just copied files from the original disk to a copy, it wouldn't run. Easily cracked by copying a full disk image instead of just the files, or by finding the branch command after the comparison and changing the bytes to NOP (which allowed copying just the files).

2. A little more sophisticated was an unreadable final track (track 15, I think?) on the floppy disk. The program would check for an ERROR in reading a sector on track 15 and run ONLY if there WAS an error. I formatted a new disk and listened carefully to the tracks stepping, and when it got to track 15 I opened the drive, the 1541 would freak out and buzz and blink, and the C64 would report it didn't finish formatting the disk, but then I copied the original program to the new disk and it ran! (Quicker and easier than finding the check in the code like #1.)

3. And then there was Electronic Arts. I never figured them out. You could get the raw code that first loads up and try to read what it does and it would disassemble to gibberish. I always suspected that it was either (a) encrypted (although I could never find how or where any decryption code would run) or (b) used an undocumented feature of 6502 where alternate bytes could execute the same command as the normal byte, such that it could run on the 6502 but confuse disassemblers (although I couldn't find any pattern to the alternate code that resembled real code).

I'm looking forward to watching this to find out what Ghidra is! Something like #3?

[yet_another_ne]

If you got both c64 & 1541 all in same year your dad must have won the pools. Makes it look so easy, back in the day all you had was a paper clip and later a action replay/expert cartridge.