Games that were tough to crack...

[sparhawk]

On C64 there was some like this:

label: jmp label

Which just could be nop-ed.

I was so baffled when I saw that, that I couldn't believe it. Like they invested probably a good sum in copy protection and then it can be defeated so easily.

[Gardhul]

On Amiga Dungeon Master used a special "fuzzy bit" which were recorder purposely in an instable state (I can't remember in which way, but was possible only through a special hardware, not a regular drive). Different reads were guaranteed to return at least a different value from others, and the game did a check by reading many times in a single burst during the game: if the read were all the same, then the copy were recognized as illegal.
Tech details here: http://dmweb.free.fr/?q=node/210

[jotd]

Dungeon Master wasn't hard to crack because of the fuzzy bit (those routines are easy to spot because they're accessing the drive in a weird way) but because of all the code checksums protecting the protection routines.

[Gardhul]

Originally Posted by jotd

Dungeon Master wasn't hard to crack because of the fuzzy bit (those routines are easy to spot because they're accessing the drive in a weird way) but because of all the code checksums protecting the protection routines.

True, but also because the checks would result in game glitches, instead of some more evident clues, so it was hard to know if a crack was fully working.

[sparhawk]

Originally Posted by Gardhul

True, but also because the checks would result in game glitches, instead of some more evident clues, so it was hard to know if a crack was fully working.

I always wondered about that. I thought, that, if I wold write a protected game, I would also trigger the copy protection such that an important item is missing. Like a key to open the door to the next level or such. This is much harder to spot, than some "If copy protected, reboot" or or other easily recognizable action.


On the other hand, this might look like a bug to the (illegal) users and wouldn't this create a negative media, if suddenly a lot of users start to report that the game is not working, while this is only exhibiting that they are using a pirated copy?

[Galahad/FLT]

Originally Posted by sparhawk

I always wondered about that. I thought, that, if I wold write a protected game, I would also trigger the copy protection such that an important item is missing. Like a key to open the door to the next level or such. This is much harder to spot, than some "If copy protected, reboot" or or other easily recognizable action.


On the other hand, this might look like a bug to the (illegal) users and wouldn't this create a negative media, if suddenly a lot of users start to report that the game is not working, while this is only exhibiting that they are using a pirated copy?

Nothing new to that idea, it was done lots of times, most times unsuccessfully I might add.

[Galahad/FLT]

Originally Posted by Gardhul

True, but also because the checks would result in game glitches, instead of some more evident clues, so it was hard to know if a crack was fully working.

Not quite.

Due to the nature of the game, you couldn't just do a level skipper or infinite lives like you would a shooter or a platform game, you physically had to play it, and the nature of the game meant that could be days to complete it, which is what made the protection effective.

[roondar]

Isn't it basically impossible to prevent cracking on a system like the Amiga where you can more or less read out everything in memory at 'all times'?

I'd say your best bet to prevent cracking would be to try and somehow create code that will always hang/crash/fail any debugging attempts (i.e. block Action Replay and similar hard/software solutions, make it so a reset is either impossible or will wipe memory, etc).

And even if this would be possible to do with a 100% success rate (which it may not be), I'm still fully unconvinced you can actually stop cracking that way.

[sparhawk]

As long as you have full control over the machine, you can't prevent cracking. For example, if you take games like Diablo 3, it's quite different, because part of the code is not even on your machine, so if done right, this can prevent cracking, because you don't have the whole code available for analyzing.
On any machine, where you get the full code physically (discs, cd, etc.) you can not prevent this. I'm not sure if a dongle could prevent this. It probably depends. Theorethically you could send it all kind of inputs and look at the output, so I think this wouldn't be safe either.

[Hewitson]

Originally Posted by Galahad/FLT

Nothing new to that idea, it was done lots of times, most times unsuccessfully I might add.

Not only was this type of protection ineffective, it also caused people to think the games were either bugged or way too difficult (eg Gods).

[A10001986]

Originally Posted by Gardhul

True, but also because the checks would result in game glitches, instead of some more evident clues, so it was hard to know if a crack was fully working.

Yeah and those were well hidden in odd places as well, such as a routine that buffered mouse clicks (eg when "running", ie clicking on the forward arrow repeatedly and quickly so that the gfx couldn't keep up), after the fifth or so click the check kicked in...

[StingRay]

Originally Posted by roondar

I'd say your best bet to prevent cracking would be to try and somehow create code that will always hang/crash/fail any debugging attempts (i.e. block Action Replay and similar hard/software solutions, make it so a reset is either impossible or will wipe memory, etc).

Also these checks can be removed. Besides, not everyone used cartridges for cracking, how do you want to detect if someone just looks at the code using a plain old disassembler for example?

[girv]

Originally Posted by Pfloyd

I remember digging the game code of "Tower of Babel". It looked like spaghetti code to me - perhaps it used some kind of framework, interpreter etc. And lots of checksums.

The loader was encrypted with a trace vector decoder. That's the only place I saw one of those outside of CopyLock, but it was a simpler variant that used fixed instruction lengths instead of a table. It also had quite a few checksums, as you say, and manual protection. Tricky enough

[StingRay]

Originally Posted by girv

That's the only place I saw one of those outside of CopyLock

Treasure Trap's protection also used the Trace Vector idea just like Copylock. It was a much simpler TVD than late Copylocks though and, even worse, nothing was hidden in the encrypted code which made the protection quite weak.

[CFou!]

Originally Posted by Codetapper

All the ReadySoft games were difficulty because they crammed so much on each disk. Every disk held more data than a standard disk could hold, so you had two problems. Firstly you had to work out what bits from each disk to move onto the extra disk, then you had to alter the loaders to take into account extra disks. The loader change required finding spare memory to put your code in, then you often had to hack up a screen to request the extra disk. Often the crackers just made the screen flash to indicate putting in the extra disk since that can be done without much code.

As for tough games to crack, any written with interpreters are tough (all those horrid old Infocom text adventures), any compiled AmigaBasic games (as the code is not visible), and games with hidden checksums were tough to crack compared to "normal" games.

Some hard (but not impossible) games to crack in addition to the Readysoft ones:

Archer Maclean's Pool, Cruise for a Corpse, Double Dragon 2, Exile, Future Wars, Hook, Magic Pockets, Operation Stealth...

i agree Ready soft games are not simple to crack.

but often crackers used dump of memory after main code decryption... however there was still as you indicated the problem of very long tracks ($19e0 with control data)

more complicate for whdload's patch because we must decrypt data and not just copy on disk decrypted data (in my memory Dragons lair 1 need many works to decrypt properly main code and recently Vortex but more simple)

some protections seem complicate to crack but often only skip first encrypted loader to crack it (recently Chinease Karate or Albedo encypted boot)

recently, i found the more stupid protection with Wrangler (http://www.whdload.de/games/Wrangler.html)

it's an external file named 'T'

file 'T' is really simple, it test a long track and crash the OS if no success.
In my memory by:
move.l 4 ,a0
jmp (a0)

you have just to launch main code directly to crack game... it'seems there no another protection test in main code...

[StingRay]

Originally Posted by CFOU!

recently, i found the more stupid protection with Wrangler (http://www.whdload.de/games/Wrangler.html)

it's an external file named 'T'

file 'T' is really simple, test long track and crash OS if no success, i my memory by:
move.l 4 ,a0
jump (a0)

you have just to launch main code directly to crack game... it'seems there no another protection test in main code...

Same as in Cougar Force, protection code is in an external file ("loader") which is executed in the startup-sequence. "Cracking" just requires removing the "loader" line from the startup-sequence.

[Galahad/FLT]

Originally Posted by StingRay

Same as in Cougar Force, protection code is in an external file ("loader") which is executed in the startup-sequence. "Cracking" just requires removing the "loader" line from the startup-sequence.

I think 3 Stooges was exactly the same, you could just bypass the protected loader and let AmigaDOS load the main executable.

I wonder how many early Amiga games were this badly protected?

[jotd]

every time the main development team isn't involved with the protection and it's added afterwards.

[Phantasm]

Originally Posted by jotd

every time the main development team isn't involved with the protection and it's added afterwards.

every time?

[kamelito]

Originally Posted by CFOU!

i agree Ready soft games are not simple to crack.

but often crackers used dump of memory after main code decryption... however there was still as you indicated the problem of very long tracks ($19e0 with control data)

more complicate for whdload's patch because we must decrypt data and not just copy on disk decrypted data (in my memory Dragons lair 1 need many works to decrypt properly main code and recently Vortex but more simple)

some protections seem complicate to crack but often only skip first encrypted loader to crack it (recently Chinease Karate or Albedo encypted boot)

recently, i found the more stupid protection with Wrangler (http://www.whdload.de/games/Wrangler.html)

it's an external file named 'T'

file 'T' is really simple, it test a long track and crash the OS if no success.
In my memory by:
move.l 4 ,a0
jmp (a0)

you have just to launch main code directly to crack game... it'seems there no another protection test in main code...

As I know Albedo developers I’d love to see a detailed explanation how you defeated it. IIRC on the ST they made a special copier to avoid the game protection. (Might have been cracked too)