Protection systems

Hardware Hacking, Programming and Game Solutions/Cheats
User avatar
robcfg
Posts: 1303
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden

Protection systems

Post by robcfg »

Hi guys!

I was converting Rommel's Revenge and Tube Way Army to cas files, and noticed custom loading schemes and protection systems.

In the case of Tube Way Army, it has a standard loader followed by custom blocks, and in the case of Rommel's Revenge, the loading screen has custom 32 byte misaligned blocks (by inserting an extra 1 before the sync byte at block's beginning) and the code has 128 byte data blocks with custom block type.

The extra 1's in Rommel's revenge are recorded at a very low amplitude, so my guess is that if you tried to copy the tape, the 1's would probably be lost and the game would fail to load.

Both cas files load nicely on XRoar, but are not suitable for use on a real Dragon. I think that the loaders expect a bit of time at some point, which cas file don't store.

There's also the Buzzard Bait dongle. Quite ineffective as the code is easily cracked.

Are there any other copy protection schemes that you're aware of?
prime
Posts: 246
Joined: Fri Apr 10, 2009 1:40 am

Re: Protection systems

Post by prime »

I seem to remember Manic Miner Or Jet Set Willy (can't remember which), would check for a cartridge in the $C000 area and erase themselves from memory if they found one. Plus they had the colour blocks protection sheet. I think it was also them that the loader / protection code would pass a value I think in the U register that would not be set correctly if called from a straight EXEC so even if you managed to load and defeat the copy protection it was still would not run correctly.

Cheers.

Phill.
sixxie
Posts: 1129
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Protection systems

Post by sixxie »

I did a recreation of Tube Way Army, here:

http://www.6809.org.uk/tmp/da/dragon_originals/

(there's also a variant in there with a faster loader)
User avatar
robcfg
Posts: 1303
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden

Re: Protection systems

Post by robcfg »

Nice!

Did you add the extra sync bytes?

Mine has the exact amount of bytes actually present on the tape. It seems that some pauses are critical on the real Dragon.
sixxie
Posts: 1129
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Protection systems

Post by sixxie »

robcfg wrote:Nice!

Did you add the extra sync bytes?

Mine has the exact amount of bytes actually present on the tape. It seems that some pauses are critical on the real Dragon.
Nah it's just structurally the same with the waveform lengths targetted to fall in the middle of the timing window both during the ROM loaded parts and the custom bit (to try and make it as reliable as possible). It loads on a real machine - at least, I'm sure I must have tested that!

Interesting note about the "quiet" bits on Rommel's Revenge. Is that consistent? Wonder if it really did make much difference to tape-to-tapes...
User avatar
robcfg
Posts: 1303
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden

Re: Protection systems

Post by robcfg »

Hi Ciaran!

The pulses are consistent, every 32 byte block from the loading screen has the 'ghost bit'. It's recorded at a very low amplitude and slightly off-center.

I've attached an annotated picture of the ghost bit.
RommelsGhostOne.png
RommelsGhostOne.png (20.06 KiB) Viewed 3909 times
sorchard
Posts: 428
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Protection systems

Post by sorchard »

Hi Rob, that's a nice image you've created there. I'm thinking how great it would be if there was software that could automatically generate that kind of image and highlight the marginal bits for manual correction.

The ghost bit could just be a false waveform caused by a short gap between the two bits. The limited frequency response of the tape means that a bit cannot stop at the mid level and will overshoot before heading back. It looks like it's followed by a leader so it wouldn't have much effect.
Stew
User avatar
robcfg
Posts: 1303
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden

Re: Protection systems

Post by robcfg »

Hi!

The short gap is exactly the size of a full 1 waveform, maybe I could try to set it as a 0 waveform and see if it still loads. If not, it must be definitely a copy protection mechanism.
Hi Rob, that's a nice image you've created there. I'm thinking how great it would be if there was software that could automatically generate that kind of image and highlight the marginal bits for manual correction.
Today is your lucky day, then :D That is a screenshot of a tool I'm developing for fixing Dragon tapes, as I realized that no code could recognize the errors better than the human brain.

As soon as I have implemented a couple of features, I'd like to clean the code a bit and make it available to you guys. It uses the FLTK library and works flawlessly on Windows, OSX and Linux.
sorchard
Posts: 428
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Protection systems

Post by sorchard »

robcfg wrote:That is a screenshot of a tool I'm developing for fixing Dragon tapes
That's awesome! :D

Work has stopped me playing the last few months but hoping to get back into tape preservation soon. I've got lots of scans to add to the wiki and your new tool could prove very useful for dumping tapes.

I'm wondering what kind of bribe I need to send to Rolf to get wiki editing privileges ;-)

One thing I remember about Rommel's Revenge is the way the screen scrolls up while it is loading. I imagine it would require a long gap between blocks to give time for the scrolling (much longer than the 'ghost' bits). If a tape is recreated without the gaps it might not work.
Stew
admin
Site Admin
Posts: 391
Joined: Thu Jul 17, 2008 10:22 pm

Re: Protection systems

Post by admin »

I have seen this on some other tapes and am yet to be convinced its actual copy protection, it seems too advanced for the Dragon era in terms of tape duplication and detection within the loader code.

The extra low amplitude "bit" could just be an artifact of the duplication machine used to create the tape, or in some cases the machine being used to play the tape and actually has no meaning to the custom loader.

That would make sense as the game loads fine under XROAR and the only reason it doesn't work on a real dragon is due to the missing "gaps" that the CAS file format does not preserve.

The only copy protection I have seen to date is things like invalid CRCs or an EOF block in the middle of the code blocks - both these approaches would stop Tape to Tape and Tape to Disk programs (for a while) and indeed the did not convert to CAS with the original DC.EXE program unless you forced its RAW mode for the same reasons.
Simon Hardy
Post Reply