Protection format names

[kaffer]

I have a project (Amiga-Disk-Utilities on github) analysing disk dumps and converting to image formats such as IPF. Part of this of course involves implementing various track formats, and also naming them Generally for data-track formats these end up being game or publisher specific. A few protection-track formats are used more widely, and it would be nice to know if they have proper names, or were given names by the cracker community.

RNC Copylock is of course well known and easy, and I can at least pick out an RNC protection from its always cunning use of TVD and checksums. I'm not sure if the RNC protection that hides at the end of an AmigaDOS track has a particular name? I'm guessing not.

Another common one is a very long (~110000 bits) track with sync 4454, and a check routine which does an unsynced disk DMA read and then bit-by-bit scan for successive instances of the sync word. I only discovered this is PROTEC because some game included a fragment of PROTEC source in its track data.

Now, the one that started me off on this post is another common one, but apparently mostly specific to Gremlin releases. It lives on tracks 158 and 159, has sync 41244124, and is usually around 105000 bitcells. Again contains no data or key. Check routine does a synced disk DMA read and then a straightforward word-by-word scan for successive instances of the sync word. Apart from Gremlin releases, I have also found a variant on Strider II (Tiertex/US Gold) where the in-game check tests for a normal-length track! Does this track format or protection have a recognised name? It crops up so often that I think it must?

That is all, for now.

[Galahad/FLT]

Originally Posted by kaffer

I have a project (Amiga-Disk-Utilities on github) analysing disk dumps and converting to image formats such as IPF. Part of this of course involves implementing various track formats, and also naming them Generally for data-track formats these end up being game or publisher specific. A few protection-track formats are used more widely, and it would be nice to know if they have proper names, or were given names by the cracker community.

RNC Copylock is of course well known and easy, and I can at least pick out an RNC protection from its always cunning use of TVD and checksums. I'm not sure if the RNC protection that hides at the end of an AmigaDOS track has a particular name? I'm guessing not.

Another common one is a very long (~110000 bits) track with sync 4454, and a check routine which does an unsynced disk DMA read and then bit-by-bit scan for successive instances of the sync word. I only discovered this is PROTEC because some game included a fragment of PROTEC source in its track data.

Now, the one that started me off on this post is another common one, but apparently mostly specific to Gremlin releases. It lives on tracks 158 and 159, has sync 41244124, and is usually around 105000 bitcells. Again contains no data or key. Check routine does a synced disk DMA read and then a straightforward word-by-word scan for successive instances of the sync word. Apart from Gremlin releases, I have also found a variant on Strider II (Tiertex/US Gold) where the in-game check tests for a normal-length track! Does this track format or protection have a recognised name? It crops up so often that I think it must?

That is all, for now.

Theres lots of names, most of them are actually official names, only a couple are named by crackers because they originate from one person.

RNC is the obvious one, there is also RNC PDOS which is Rob Northens Longtrack MFM system as used on later Virgin games like both Mortal Kombats and a lot of Team 17 games.

The commonly used MFM at Gremlin is SSMFM which is Shaun Southern MFM, and was on lots of Gremlin games like Lotus 1, 2 and 3, plus virtually most MFM games you can think of.

There is Speedlock which is on Dragon Breath and a few other games.

Protec I think went through a couple of iterations before being abandoned, and that might well be the other variant you describe above.

Ben Herndon HLS protection on one version of Sim City and lots of US games in the late 1980's.

Lots of programmers put the protection name in the bootblock, but where crackers didn't know, it was generically named for normally sensible reasons. Also sometimes the protection name was used as a checksum string to check integrity of the MFM that had been read.

Psygnosis' crappy MFM system was by Ian Hetherington if memory serves me right, used for its capacity not necessarily for its reliability!

Factor 5 had their own MFM system, which was used on a couple of non Factor 5 games, but sort of done by mates of theirs.

CyberDOS by Richard Aplin for Double Dragon 2.

RLDOS by Randy Linden for the MFM protected Dragons Lair games and a couple of others by the same software company.

Plus many more.

[kaffer]

Very useful, thanks!

Okay, so my 'Gremlin' format is in fact SS-MFM. The tracks 158-159 longtrack protection with sync 4124 was often coupled with that.

Ian Hetherington's MFM format -- is that the not-really-MFM encoding we've been talking about in the SPS forum, used on Obitus et al? Psygnosis have a bunch of MFM formats and mix-and-match heavily on some titles, making a right mess.

I have a dump of Dragons Breath so Speedlock will be on my plate soon

[WayneK]

There is also "Game Exec OS" which can be found on quite a few Starbyte-published titles (look for "CHW!" everywhere!) and the various Jochen Hippel formats used on Thalion titles - these are 2 used on multiple titles that spring to mind!

On the Atari ST, the Gremlin track 79 protection was called "Protoscan" - I have vague memories that this name came from similar circumstances as your "PROTEC" find (fragments of the programmers mem on the disk, or similar mistake).

[StingRay]

Originally Posted by WayneK

There is also "Game Exec OS" which can be found on quite a few Starbyte-published titles (look for "CHW!" everywhere!)

CHW = Christian A. Weber, once member of SCA and responsible that "something wonderful has happened". He also coded and protected the Linel games Dugger and Crack (heh ).

[kaffer]

Great stuff. This is what I'm looking for!

[kaffer]

Originally Posted by kaffer

I have a dump of Dragons Breath so Speedlock will be on my plate soon

Just onto this. Yay, a TVD that isn't by Rob Northen!

And a skanky decrypter that relies on the 68000 prefetch behaviour... Was preparing to spend some tedious time dealing with that when someone pointed out that UAE has a cycle-accurate CPU emulation option, *disabled* by default. I'm saved!

[StingRay]

Originally Posted by kaffer

Just onto this. Yay, a TVD that isn't by Rob Northen!

In the game Treasure Trap you'll also find TVD's not by Rob Northen (4 if memory serves me right). They are much more basic than late Rob Northen versions and rather easy to defeat.

Decrypters that relied on the 68000 prefetch behavior weren't uncommon either, Herndon HLS by Ben Herndon is one protection which used stuff like this.

[kaffer]

Originally Posted by StingRay

In the game Treasure Trap you'll also find TVD's not by Rob Northen (4 if memory serves me right). They are much more basic than late Rob Northen versions and rather easy to defeat.

Decrypters that relied on the 68000 prefetch behavior weren't uncommon either, Herndon HLS by Ben Herndon is one protection which used stuff like this.

Did any of them work reliably on 68020+? I'm happy now I have UAE emulating them correctly. I only use my own emulator for disassembling TVD-protected routines, which can't really be doing prefetch tricks.

I will take a look at Treasure Trap, thanks!

[StingRay]

Originally Posted by kaffer

Did any of them work reliably on 68020+?

Of course not. Quite often the protections were the reason that the game would only work on 68000 machines. Once the protection layer was removed lots of games worked without any problems on 68020+ machines.

Even some demos were protected ("Voyage" by Razor 1911 springs to mind) in such a way that they would only run on 68000. If you want to have some fun try to understand Voyage's bootloader, I totally love the code there.

[Galahad/FLT]

Originally Posted by StingRay

Of course not. Quite often the protections were the reason that the game would only work on 68000 machines. Once the protection layer was removed lots of games worked without any problems on 68020+ machines.

Even some demos were protected ("Voyage" by Razor 1911 springs to mind) in such a way that they would only run on 68000. If you want to have some fun try to understand Voyage's bootloader, I totally love the code there.

The last of the Ben Herndon HLS protections included a NOP table to try and knock out prefetch, but it wasn't always successful.

As for Voyage, I didn't totally love the code at all there

[StingRay]

Originally Posted by Galahad/FLT

The last of the Ben Herndon HLS protections included a NOP table to try and knock out prefetch, but it wasn't always successful.

I know, didn't really help anyway as the caches weren't flushed after decrypting the code. Thus it was pretty useless to have these nop tables (he even enlarged them in the last versions of his protection).

Originally Posted by Galahad/FLT

As for Voyage, I didn't totally love the code at all there

I do. It's very cute code. If you have an 68000 A500 at your disposal it's quite easy to defeat the encrypted boot loader. If you don't, well, then the real fun starts but it's not impossible either.

[kaffer]

Lol, well the actual Speedlock routine does decryption with prefetch tricks before getting to the TVD bit. So I had to implement prefetch anyway. And a totally bone-headed implementation of prefetch doesn't suffice since the decrypter relies on the interleaving of prefetch with execution of specific instructions. Two cases: ADD into the immediately following instruction, which is prefetched *before* ADD writes back; and MOVE into the second word of the next instruction, which is prefetched *after* MOVE writes its result. But now I have the guts of the Speedlock opened out.

[Toni Wilen]

Prefetch and microcoded CPU = fun.

Only MOVEs have some annoying special cases. Most other instructions prefetch after writes.

But because prefetch is two stage, previous instruction will prefetch next word from address +4 (word after next instruction's opcode) which makes single word instructions (no extension words) to look like they prefetch before write when actually it was previous instruction that did the prefetch!

Most common MOVE exceptions are:

MOVE x,-(An) = prefetch before write
MOVE.L address,address = prefetch twice after writes.

(Probably getting a bit off topic)

btw, demo Purple by Warfalcons has also interesting boot block protection because it isn't too obvious what it actually does and how it works. (It probably is too easy to bypass without caring at all how it worked but thats not the point)

[StingRay]

Originally Posted by Toni Wilen

btw, demo Purple by Warfalcons has also interesting boot block protection because it isn't too obvious what it actually does and how it works. (It probably is too easy to bypass without caring at all how it worked but thats not the point)

The encryption was rather simple in that demo. From the readme of my WHDLoad patch for this very demo:

Master Ace tried to protect his code, the loader and all files were encrypted and all accesses to any hardware registers have been disguised. Not much of a challenge but interesting.

Voyage's boot code is the most interesting I've seen so far. Using CIA interrupts and changing registers there to calculate the key for the TVD and stuff. Quite nice.

[Toni Wilen]

Originally Posted by StingRay

The encryption was rather simple in that demo.

I didn't mean the encryption, I did mean explaining how that strange jump to invalid address is supposed to work.

Voyage's boot code is the most interesting I've seen so far. Using CIA interrupts and changing registers there to calculate the key for the TVD and stuff. Quite nice.

Yes but it was too obvious what it did

[kaffer]

Originally Posted by Toni Wilen

Prefetch and microcoded CPU = fun.

Only MOVEs have some annoying special cases. Most other instructions prefetch after writes.

But because prefetch is two stage, previous instruction will prefetch next word from address +4 (word after next instruction's opcode) which makes single word instructions (no extension words) to look like they prefetch before write when actually it was previous instruction that did the prefetch!

Hmm... all my knowledge comes from this document http://pasti.fxatari.com/68kdocs/68kPrefetch.html which reads very persuasively. It would indicate that most read-modify-writeback instructions will prefetch the first 2 words of the next instruction before writeback, regardless of the instruction length. Which I think contradicts what you say. However, you know more about Amiga and 68k than I've forgotten. And UAE's cycle-accurate emulation seems pretty exact to me. So I don't know who to believe.

EDIT: Here's an example from Dragon's Breath Speedlock routine:

# a1 = 261e6; d2 = ed8916fe
000261e4  d591        add.l   d2,(a1)
000261e6  2602        move.l  d2,d3
000261e8  b981        eor.l   d4,d1

Pretty straightforward single-word r-m-w instruction modifies following two instructions. The decrypter expects that *both* original opcodes should execute; both the move.l and eor.l, not just the move.l!

[Toni Wilen]

Originally Posted by kaffer

Hmm... all my knowledge comes from this document http://pasti.fxatari.com/68kdocs/68kPrefetch.html which reads very persuasively. It would indicate that most read-modify-writeback instructions will prefetch the first 2 words of the next instruction before writeback, regardless of the instruction length. Which I think contradicts what you say. However, you know more about Amiga and 68k than I've forgotten. And UAE's cycle-accurate emulation seems pretty exact to me. So I don't know who to believe.

Document is correct but you must have misunderstood some parts.

Single word instruction will always prefetch 1 word (move.l (ax),(ay) for example). Length of instruction (in words) always equals number of prefetches.

Instructions that do 2 cycle prefetch don't actually do any extra prefetch cycles, one prefetch cycle is simply done after write which normally would have been executed before write. (Made microcode more optimal that way)

"Position" of prefetch cycle(s) is the important part (before or after write), not number of prefetches.

[kaffer]

Originally Posted by Toni Wilen

"Position" of prefetch cycle(s) is the important part (before or after write), not number of prefetches.

Agreed, but the document claims that most instructions with extension words will still do all their prefetch cycles before their write. Most MOVE variants being the main exception.

In the above Speedlock example, if I changed the modifying instruction to the multi-word "addi.l #ed8916fe,(a1)" I would expect behaviour to not change (next two instruction execute non-modified opcodes). That is what the document suggests, but I think your argument would say that at least the second following instruction would execute the modified junk opcode?

EDIT: And I think you misunderstood my previous post, because I was unclear. What I meant was that "most r-m-w instructions will have the first 2 words of the next instruction(s) in the prefetch queue before writeback, regardless of the instruction length". Not necessarily that it is the r-m-w instruction that does both prefetches.

[Toni Wilen]

Originally Posted by kaffer

Agreed, but the document claims that most instructions with extension words will still do all their prefetch cycles before their write. Most MOVE variants being the main exception.

I only meant not all MOVEs have same prefetch behavior and can have unexpected addressing mode specific exceptions.

Other instructions (mostly) don't have these kinds of exceptions.

btw, reason for above can be seen in one Motorola patent's (slightly unreadable) microcode listing, big part of microcode is only used by different MOVE variants but most other instructions use common code for source and destination address calculation.

I guess we can agree after all

[kaffer]

Originally Posted by Toni Wilen

I only meant not all MOVEs have same prefetch behavior and can have unexpected addressing mode specific exceptions.

Other instructions (mostly) don't have these kinds of exceptions.

btw, reason for above can be seen in one Motorola patent's (slightly unreadable) microcode listing, big part of microcode is only used by different MOVE variants but most other instructions use common code for source and destination address calculation.

I guess we can agree after all

Yes, and I think I've had my fill of prefetch fun for one day.

And, for all the encryption fortification, the Speedlock disk routine is kind of lame.

[Galahad/FLT]

Originally Posted by kaffer

Yes, and I think I've had my fill of prefetch fun for one day.

And, for all the encryption fortification, the Speedlock disk routine is kind of lame.

Isn't it just? The actual end result of the Speedlock is less technical than Copylock, although the track format for Speedlock is actually stronger at being copy resistant than Copylock.

[kaffer]

Originally Posted by Galahad/FLT

Isn't it just? The actual end result of the Speedlock is less technical than Copylock, although the track format for Speedlock is actually stronger at being copy resistant than Copylock.

That's interesting. I mean, it seems logical that it might be more resistant, as the long/short bitcells are longer/shorter than in Copylock (+/-10% rather than ~5%) and the long/short sections are much smaller, and back-to-back. But I wonder are there really any copiers that could copy a Copylock but not a Speedlock? For example, X-Copy/Cyclone with dongle, I assume it just routes the data signal of the internal drive through to the write-data signal of the external drive, and will dumbly duplicate bitcells of any width, within reason (plus I assume pulse-modulation motor tricks to sync index signals, and some smarts to put the write splice in a safe place). That kind of scheme would probably duplicate any kind of non-uniform track pretty accurately, within reason (anything the Amiga disk controller would tolerate to read)?

[Galahad/FLT]

Originally Posted by kaffer

That's interesting. I mean, it seems logical that it might be more resistant, as the long/short bitcells are longer/shorter than in Copylock (+/-10% rather than ~5%) and the long/short sections are much smaller, and back-to-back. But I wonder are there really any copiers that could copy a Copylock but not a Speedlock? For example, X-Copy/Cyclone with dongle, I assume it just routes the data signal of the internal drive through to the write-data signal of the external drive, and will dumbly duplicate bitcells of any width, within reason (plus I assume pulse-modulation motor tricks to sync index signals, and some smarts to put the write splice in a safe place). That kind of scheme would probably duplicate any kind of non-uniform track pretty accurately, within reason (anything the Amiga disk controller would tolerate to read)?

Copylock could be done with a hardware copier, but not a software copier.

I'm not aware that Cyclone could successfully copy Speedlock though, but the end result is, Speedlock wasn't as well protected with code as Copylock was, and the actual results returned from the TVD part of Speedlock was pretty limited in comparison to Copylock, so Speedlock as a protection to crack was invariably easier than Copylock (not that Copylock was tricky, but was capable of having extra stuff hidden that Speedlock simply didn't ever try).

[kaffer]

Originally Posted by Galahad/FLT

Copylock could be done with a hardware copier, but not a software copier.

I'm not aware that Cyclone could successfully copy Speedlock though, but the end result is, Speedlock wasn't as well protected with code as Copylock was, and the actual results returned from the TVD part of Speedlock was pretty limited in comparison to Copylock, so Speedlock as a protection to crack was invariably easier than Copylock (not that Copylock was tricky, but was capable of having extra stuff hidden that Speedlock simply didn't ever try).

Well, I'm only speculating about the ease of copying. I don't actually know much about the old Amiga disk copiers.

And now I'm looking at Dungeon Master. Did all the protected versions of this title use weak/flaky bits? Cos I haven't found the clever bit of the protection routine yet, which actually checks something that would be uncopyable. But then the game seems to be written in C or somesuch, as the code is totally barking, so following the flow is no fun.

[Galahad/FLT]

Originally Posted by kaffer

Well, I'm only speculating about the ease of copying. I don't actually know much about the old Amiga disk copiers.

And now I'm looking at Dungeon Master. Did all the protected versions of this title use weak/flaky bits? Cos I haven't found the clever bit of the protection routine yet, which actually checks something that would be uncopyable. But then the game seems to be written in C or somesuch, as the code is totally barking, so following the flow is no fun.

From memory, (and its a loooonnnggg time), the protection read code isn't in the main code file, its hidden in one of the other files (possible 3x in other files), one of the graphics files if memory serves me right, but that really was a long time I checked.

The Psygnosis re-release didn't use that protection as far as i'm aware, but all the original early releases from FTL did.

[kaffer]

Originally Posted by Galahad/FLT

From memory, (and its a loooonnnggg time), the protection read code isn't in the main code file, its hidden in one of the other files (possible 3x in other files), one of the graphics files if memory serves me right, but that really was a long time I checked.

The Psygnosis re-release didn't use that protection as far as i'm aware, but all the original early releases from FTL did.

Looks like the protection track might be Atari ST (hence IBM MFM, like everything except C64/Amiga) format, so I might work on it from that angle and then observe how the track differs from regular IBM MFM.

[mr.vince]

You might want to check the graphs further down this page:

http://softpres.org/kryoflux:ui:stream-plot

[kaffer]

Originally Posted by mr.vince

You might want to check the graphs further down this page:

http://softpres.org/kryoflux:ui:stream-plot

Thanks, I remembered seeing that scatter plot before, and I was expecting to see some code that checked for the resulting flakey bits. It's in there somewhere I'm sure. Hence I'll start by producing a track that passes the minimal checks I can see, and find out what breaks next. I already had preliminary IBM format support so I'm just fleshing that out. It's a nice change and quite different from Amiga track formats. Interesting how the track format design is affected by the features of the FDC.

[StingRay]

Originally Posted by Toni Wilen

I didn't mean the encryption, I did mean explaining how that strange jump to invalid address is supposed to work.

Ah right, the boot code was indeed quite interesting. However, there was no need to understand what it does (as you already mentioned) because it was way too obvious what happened anyway (trackdisk loader and decryption routine weren't obfuscated).

Originally Posted by Toni Wilen

Yes but it was too obvious what it did

Yeah, but I like the idea behind the code. Must've taken ages to test/develop as it relied on exact instruction/interrupt timing. And it was a good way to defeat any debuggers/cartridges. The actual TVD was rather simple indeed (once you had the correct key that is).

Originally Posted by kaffer

And now I'm looking at Dungeon Master. Did all the protected versions of this title use weak/flaky bits? Cos I haven't found the clever bit of the protection routine yet, which actually checks something that would be uncopyable. But then the game seems to be written in C or somesuch, as the code is totally barking, so following the flow is no fun.

DM protection is described here.

[kaffer]

Originally Posted by StingRay

DM protection is described here.

Wow! Someone *really* liked the technical details of DM! Should come in handy though.

[kaffer]

Well, I had fun learning about Dungeon Master's particular flavour of weak bits, and updated my flux decoder to support more authentic emulation of an FDC's PLL, which the protection relies on. But I need to wait for an extension to the IPF format to be able to represent the weak bits. I suppose there had to be a good reason there's no official IPF with this long-understood protection.

Still it was worth it to find out a bit about the different kinds of weak data that can exist. It's pretty interesting.

[mr.vince]

Yes, like those 4 Psygnosis titles... needs different transport layer which can store the "sliding" timings.