The thing about certain copylocks

[MethodGit]

I thought it'd be as simple as "take a handful of encrypted opcodes you wish to replace and run them through an XOR calculator", but according to some of the Flashtro guides (yes, I still check them occasionally, though not as often as before!) you're supposed to pick the opcodes prior to the ones you wish to replace.

Doesn't sound too difficult in itself, unless you're trying to do what I'm trying to do atm.

Namely, see if I can somehow add encrypted opcodes into Doodlebug's copylock that does the following:

MOVE.L #35B23068,100.S
BRA (end of first part of copylock)

(End of first part being the BRA instruction below MOVEM.L (A7)+,D2-D7/A0-A3 of course.)

...seeing as doing the common bogstandard way of wiring a key into D0 during that precise moment doesn't work, since it obviously expects the key to be in a specific address, not one of the Dx slots. Of course, it worked brilliantly with Cyberpunks, but then that doesn't use specific addresses.

ARIV - while helpful at times - can also be bleeding useless. The way its ROBD function works means it somehow refuses to accept any target value (for a MOVE instruction) other than D0, which it automatically converts anything else to. Hence me trying to work things out the manual, hard-labour way.

Seeing as a copylock hardly compresses all that well in an RNC chunk, I feel chucking some encrypted code into the middle of it would be a quicker job done than either a boot patch (of which I already previously did for Doodlebug) or a rip-unpack-edit-pack-inject method (which won't work with this game anyway due to its fussy decoding routine).

All the Flashtro guides I've seen which carry specific parts on XOR calculating seem geared only towards those patches where you simply plonk numbers into a Dx value. Which isn't what I'm after.

So is it absolutely vital to go sort of backwards when doing XOR converting? ARIV didn't seem to give the impression that it had to do anything of the sort. Maybe it's just an alternative method coined by Flashtro...

[MethodGit]

I'm thinking mainly of the copylocks in games like Steg, Spellfire the Sorcerer, SAS Combat Simulator and Alien³ here.

Namely..... I still can't work out how to find the right spot in all of them. The spot in question beginning with "MOVEM.L D2-D7/A0-A3,-(A7)".

I've even tried using Copylock Decoder, but usually for that to work effectively you need to be able to find the end of a copylock so you know how much of it to copy into a new file, right? And I think one problem here is that games which use entirely copylock-encrypted loaders (like the three Codies examples above) don't have an obvious end-of-copylock to track down. I did look at the copylock in memory in ARIII before, as well as reading the file/track manually in ARIV. But what usually happens is it either keeps churning out more junk code, or the code gradually fades out without giving me an obvious JMP/BRA/RTS command. Can someone confirm that you're only supposed to include the copylock code in your new file before loading it in Decoder, or can you in fact get away with loading a whole program into it and it'll be smart enough to decode only what it needs to decode?

In the case of Alien³, its copylock is pretty alien (pardon the pun). As well as not being able to find "MOVEM.L D2-D7/A0-A3,-(A7)" anywhere inside of it, Copylock Decoder can't even successfully decode it, spitting out a 0-byte file each time (while seemingly acting like everything went just fine). Both the Flashtro and Prodigy cracks hack it via non-encrypted methods, so I'm led to believe that it is in fact not possible to do an encrypted hardwire in this game, right?

(Additional note: Spellfire has a copylock at $2C00 on the disk just like The Sword and The Rose, but at least with the latter I was able to track down the target spot in ARIV. So I'm curious as to what Spellfire has done which means I can't hardwire it in the same manner.)

[Galahad/FLT]

Why would you want to hardwire the key into the encrypted copylock of Alien 3 when theres no need to?

Going back on my hazy memory, its a simple Copylock that stores the serial key in register D5 if I recall correctly, in fact if my memory serves me right, it has a particularly stupid fail routine should the serial key not be correct.

As for the Codemasters ones, if they are of the type where they are Copylocked big files (i.e. the Copylock runs and then decrypts the main file, you would need to include ALL the encrypted data. I personally don't use anyone elses decoder, but the entire encrypted game data would be part of the Copylock as well, as typically the Copylock will decrypt a separate decrypt routine for the rest of the data, but might usea checksum across all the data so it can correctly decrypt the decrypter for the game.

Thats certainly how Stunt Car Racer and Xenon II do it anyway.

[MethodGit]

Originally Posted by Galahad/FLT

Why would you want to hardwire the key into the encrypted copylock of Alien 3 when theres no need to?

Going back on my hazy memory, its a simple Copylock that stores the serial key in register D5 if I recall correctly, in fact if my memory serves me right, it has a particularly stupid fail routine should the serial key not be correct.

As for the Codemasters ones, if they are of the type where they are Copylocked big files (i.e. the Copylock runs and then decrypts the main file, you would need to include ALL the encrypted data. I personally don't use anyone elses decoder, but the entire encrypted game data would be part of the Copylock as well, as typically the Copylock will decrypt a separate decrypt routine for the rest of the data, but might usea checksum across all the data so it can correctly decrypt the decrypter for the game.

Thats certainly how Stunt Car Racer and Xenon II do it anyway.

In the case of NDOS disks like SCR, X2, Spellfire and SAS, would I have to choose carefully how many tracks to rip to a file? Depending on how big the encrypted data in a game is and where it officially ends on the disk, of course.

[Galahad/FLT]

Originally Posted by MethodGit

In the case of NDOS disks like SCR, X2, Spellfire and SAS, would I have to choose carefully how many tracks to rip to a file? Depending on how big the encrypted data in a game is and where it officially ends on the disk, of course.

I would have to look at the games in question, but I do know on a few Codemasters games, they had Copylock 'wrappers' where the game would have one big file which was encrypted and had the Copylock attached to it, you wouldn't see any useful JMP's or anything like that as its all encrypted.

So the main file would be loaded up (generally quite large), the Copylock was at the start of the file, that would be executed, once the read routines had finished, it would then use the serial key it was given to decrypt a small piece of code, which was then executed to decrypt the rest of the game file.

To be honest, i've NEVER seen anyone hardwire a key into this type of Copylock, the file has always been cracked so the Copylock is completely removed and readily decrypted and written back to the disk decrypted.

SAS Combat Simulator is a wrapper type Copylock, but it doesn't even encrypt the entire game.

Only the first 61K of the header of the file is encrypted (includes Copylock), the rest of the file is exposed, probably done that way because the Copylock routine would take too long over a big file to decrypt and would be easier to break.

As its a single loader game, its actually incredibly easy to crack without ever touching the Copylock.

Game data is located from address $10000 in memory, and simply patching the reset routine to copy the bottom half of 512k chip ram to fast ram would be the quickest way to crack it without even the need for an Action Replay cartridge.

[Codetapper]

@MethodGit: If you continue this obsession with hard-wiring a key, you will *never* be able to write a WHDLoad install for any of the games as you cannot (easily) run illegal code in WHDLoad. So why don't you learn to patch the games cleanly?

And yes, you have been told this many times in other threads but you don't read them, don't listen, or don't reply.

As for Alien 3, there's nothing much about it, my decoder outputs the following:

Copylock Decrypter v0.01
(c) 2004 Codetapper of Action (codetapper@hotmail.com)

Copylock header found at $0
Copylock stack 1 found at $7a
Encryption routine adds on $b5862f3c to previous longword before eor'ing!
Copylock stack 2 found at $3c4
Copylock key wiring skip to position found at $42c
Post copylock branch to address starts at $7e4
Copylock new magic number ($a573632c) compare at $450

======[ Key calculation routine found at $4b2: ]======
_4b2    move.w  #$b,d1
_4b6    add.l   d6,d6
_4b8    sub.l   (a0)+,d6
_4ba    dbra    d1,_4b6
_4be    move.l  d6,($80).w      ;Serial number stored at $80
_4c2    not.l   ($80).w         ;Modify memory at $80
_4c6    addq.l  #4,sp
_4c8    rts

======[ Post copylock code starts at $7e4: ]======
_7e4    lea     $78(sp),a6      ;Set a6 to real copylock registers
_7e8    move.l  d0,$14(a6)      ;Store serial number in real d5 register
_7ec    rol.l   #1,d0
_7ee    move.l  d0,(a6)+
_7f0    move.l  d1,(a6)+
_7f2    rol.l   #1,d0
_7f4    move.l  d0,(a6)+
_7f6    rol.l   #1,d0
_7f8    move.l  d0,(a6)+
_7fa    rol.l   #1,d0
_7fc    rol.l   #1,d0
_7fe    move.l  d0,(a6)+
_800    addq.w  #4,a6
_802    rol.l   #1,d0
_804    move.l  d0,(a6)+
_806    rol.l   #1,d0
_808    move.l  d0,(a6)+
_80a    moveq   #$0,d0
_80c    moveq   #$1,d0
_80e    lea     _820(pc),a6
_812    move.l  -$4(a6),d6
_816    add.l   $8,d6
_81c    or.w    #$a71f,sr
_820    addi.l  #$44,($24).l
Copylock stack 2 ends at $820

It's one of the games that you need to add on $b5862f3c to the previous longword before eor'ing.

The key in d5 is displayed in the game too, so this is a very simple one to crack. The file in question is located at $4400 on the disk, you just need to unpack it and for the process above, I grabbed the copylock chunk from offset $9c.

Note that if you do your lame hard-wiring trick, you might miss the $80 check

I just had a look at the WHDLoad install and nowhere does it seem to be writing the correct key (not'd) to $80 so it may not be correctly cracked. Jeff, Keith or Phil may have missed that!

Of course, the game may not be checking $80 at all but it would seem daft not to after the d5 check is so obvious in the code.

[MethodGit]

For the record, I have cracked Alien³ already in at least a couple of different ways..... I was just looking to see if a hardwire was possible as it would obviously be a significantly smaller patch to write (and I'm all about finding the smallest working patches possible) than, say, a boot patch.

I'm not sure why you're telling me that I'll never be able to write a WHDLoad install in future as I've not exactly expressed any interest in doing such a thing. Surely I would need more than just an Amiga-emulating PC and a couple of Action Replays to make slaves how you guys make them. I imagine many of you have multiple Amiga models at home to test on!

Originally Posted by Codetapper

It's one of the games that you need to add on $b5862f3c to the previous longword before eor'ing.

You might have to educate me a bit on the whole EOR process. Is it related to XOR, or even the opposite of it? I've been practicing a bit of XOR calculating for wiring purposes lately and trying to master the pretty confusing process of picking the correct previous longwords/shortwords to chuck into an XOR calculator. Had no real clue on how it worked until I looked at Crystal's Archer Maclean Pool crack and noticed their extensive hardwire patch, and learned from there onwards.

[Codetapper]

I'm telling you that you cannot write a WHDLoad install by hard-wiring a key in the copylock as WHDLoad will exit when it hits $10 (illegal). So you have to emulate the code in the copylock and bypass it. All your recent posts have been about hard-wiring and you have ignored replies about doing "clean" patches and cracks so I'm not sure how we are supposed to guess that!

In your couple of cracks of Alien 3, did you actually write the modified key to $80?

At the heart of a copylock, it is simply exclusive-or-ing (eor) the instruction (in trace mode) that it is about to execute with the previous longword. 1st Division Manager, Krusty's Super Fun House, Alien 3 etc eor it with the key $b5862f3c in addition to the normal trick.

I don't think any other automated cracking tool (ARIV, Copylock Decoder) etc detects and handles this except mine!

[Minuous]

@MethodGit:

EOR is just another name for XOR, they both mean "exclusive or", ie. invert bits...

[Galahad/FLT]

As Codetapper has said, hardwiring the key is one thing, but its more important that you KNOW what the Copylock is doing.

I think back in the day I only ever bothered to hardwire one key for a Copylock, the rest I went through them and ripped out the routines that were important and ran them outside of the Copylock to ensure 100% results.

Hardwiring the key on Hook for instance would not crack the game 100%, because hardwiring the key means it misses out a crucial routine that sets a bit in memory which is important for the game to continue, and i'm pretty sure Hook is not an exclusive game to do this either

Your goal should not be to produce the smallest and most elegant code, your goal should be to crack the game 100%.

Several of the older Bitmap Brothers Copylocks can be hardwired, but then don't work on faster processors, and its imperitive that you emulate what the Copylock does, without the need for the Copylock to remain.

And what Codetapper says about WHDLoad is sound advice. You were in no position to crack anything a year ago, who knows, you might well decide in the future to do a WHDLoad install, if you do find yourself in that position, would it not be a good idea to avoid the pitfalls before they arise?

[MethodGit]

Originally Posted by Galahad/FLT

As Codetapper has said, hardwiring the key is one thing, but its more important that you KNOW what the Copylock is doing.

I am perfectly aware that some/certain games need to copy a key to a specific (usually short) address, or correct certain instructions that were deliberately corrupted pre-copylock. I have made efforts to implement these extra fixes also if absolutely needed by the game in question (i.e. to ensure it doesn't crash at a certain point or do anything else intended to hinder gameplay).

Hardwiring the key on Hook for instance would not crack the game 100%, because hardwiring the key means it misses out a crucial routine that sets a bit in memory which is important for the game to continue, and i'm pretty sure Hook is not an exclusive game to do this either

I'm also aware of the extra trickery Hook implements, and indeed I looked at your modified code on your Hook Disk 2 to get a good understanding of it. Not really looking to try and better that for now.

Your goal should not be to produce the smallest and most elegant code, your goal should be to crack the game 100%.

Depends on what you define as 100%. My personal 100% would be to basically ensure that a game is fully completable - without any major (or even minor at that) hiccups - while changing the least amount of code, be it in memory or permanently. Your 100% most likely involves adding extras such as AGA compatibility, something I'm intentionally staying the heck away from for the time being as it's a whole new game as far as I'm concerned and my only interest atm is finding my own ways (and occasionally learn multiple ways) of cracking a game to ensure that nothing crashes it at random, and additionally skip novella protection altogether rather than force the user to input something still.

And what Codetapper says about WHDLoad is sound advice. You were in no position to crack anything a year ago, who knows, you might well decide in the future to do a WHDLoad install, if you do find yourself in that position, would it not be a good idea to avoid the pitfalls before they arise?

That sounds reasonable and all, but again, wouldn't I need to get myself a real Amiga first rather than make and test a slave entirely through emulation, release it and then potentially receive tons of error reports from people with more specific setups?

[Galahad/FLT]

No, 100% crack as in fully deprotect the game, thats all 100% means.

If you then opt to take it further with other fixes that are nothing to do with copy protection, then thats fine, but there is no expectation that it must be done.

You also have a hangup about changing the 'least amount of code', whilst that sounds vaguely admirable, that is never the initial goal. The goal is to crack the game 100% however way you deem necessary to achieve it, whether that be a lot of code or a little amount of code is utterly irrelevant.

Take a typical Anco crack, generally lots of code is needed to crack 100%, I have never felt the need nor urge to shave off bytes to make it smaller, making it a flawless crack is far more important.

As for entirely skipping novella protections, generally not a good idea as there may well be a check later in the game to check if anything was entered

[Codetapper]

@MethodGit: For gods sake please STOP creating a new thread for all your copylock questions! Why on earth don't you listen to the people that tell you the same things over and over?

[TCD]

No idea what just happened, but I moved two posts, but only Codetapper's showed up here
Anyway, here's MethodGit's post :

Originally Posted by MethodGit

Correct XOR calculation can be so confusing

I thought it'd be as simple as "take a handful of encrypted opcodes you wish to replace and run them through an XOR calculator", but according to some of the Flashtro guides (yes, I still check them occasionally, though not as often as before!) you're supposed to pick the opcodes prior to the ones you wish to replace.

Doesn't sound too difficult in itself, unless you're trying to do what I'm trying to do atm.

Namely, see if I can somehow add encrypted opcodes into Doodlebug's copylock that does the following:

MOVE.L #35B23068,100.S
BRA (end of first part of copylock)

(End of first part being the BRA instruction below MOVEM.L (A7)+,D2-D7/A0-A3 of course.)

...seeing as doing the common bogstandard way of wiring a key into D0 during that precise moment doesn't work, since it obviously expects the key to be in a specific address, not one of the Dx slots. Of course, it worked brilliantly with Cyberpunks, but then that doesn't use specific addresses.

ARIV - while helpful at times - can also be bleeding useless. The way its ROBD function works means it somehow refuses to accept any target value (for a MOVE instruction) other than D0, which it automatically converts anything else to. Hence me trying to work things out the manual, hard-labour way.

Seeing as a copylock hardly compresses all that well in an RNC chunk, I feel chucking some encrypted code into the middle of it would be a quicker job done than either a boot patch (of which I already previously did for Doodlebug) or a rip-unpack-edit-pack-inject method (which won't work with this game anyway due to its fussy decoding routine).

All the Flashtro guides I've seen which carry specific parts on XOR calculating seem geared only towards those patches where you simply plonk numbers into a Dx value. Which isn't what I'm after.

So is it absolutely vital to go sort of backwards when doing XOR converting? ARIV didn't seem to give the impression that it had to do anything of the sort. Maybe it's just an alternative method coined by Flashtro...

[MethodGit]

Originally Posted by Galahad/FLT

Take a typical Anco crack, generally lots of code is needed to crack 100%, I have never felt the need nor urge to shave off bytes to make it smaller, making it a flawless crack is far more important.

Granted, I've not bothered to look at any Anco titles to date as they're not really my 'thing'.

As for entirely skipping novella protections, generally not a good idea as there may well be a check later in the game to check if anything was entered

It'd be interesting to see a list of games which use such trickery. I only know of Soccer Kid (according to what Flashtro says about it) to date, and I'm pretty sure that check can be patched out also.

[Galahad/FLT]

Originally Posted by MethodGit

Granted, I've not bothered to look at any Anco titles to date as they're not really my 'thing'.

It'd be interesting to see a list of games which use such trickery. I only know of Soccer Kid (according to what Flashtro says about it) to date, and I'm pretty sure that check can be patched out also.

Any check can be cracked and patched, but whether or not you'll play test the game for a long time to find out?

Carrier Command has such a check, if you just press RETURN to skip the protection, you get killed 10 minutes into the game.

The point about the Anco games wasn't an invite to crack them, but a small amount of code isn't possible to crack them, lots of checksums and disk read routines that need to be removed.

Whilst elegant and nice code is part of your goal in cracking something, the main point is always to crack it 100% no matter how much code is needed to do it.

That should be your only consideration.

[WayneK]

Another thing to consider about novella's - the password screen can also be used to enter cheatcodes in some games... another good reason not to skip it entirely! (see the game "WHIZZ" for an example).
As for the cracking/copylock-patching... I wouldn't get hung-up on doing everything with the most optimised code possible. The golden rule is if it works 100%, it's a perfect crack... noone (except you) cares how it works, as long as it works. Yes you can take pride in doing a job well, or coming up with a unique way to bypass some protection check, but if you miss another check later and some butcher who splatters memory with NOPS everywhere and JMP's to his long-winded patch code elsewhere doesn't... he's perfect, you suck

[marty]

Originally Posted by MethodGit

Granted, I've not bothered to look at any Anco titles to date as they're not really my 'thing'.

It'd be interesting to see a list of games which use such trickery. I only know of Soccer Kid (according to what Flashtro says about it) to date, and I'm pretty sure that check can be patched out also.

Only remember Paramax, Shadow Fighter. But there are for sure many many more

[StingRay]

Originally Posted by MethodGit

Granted, I've not bothered to look at any Anco titles to date as they're not really my 'thing'.

You should try to crack such Anco title, you will have to deal with encryption, checksums and track checks. Try to at least beat the encryption, it is much more interesting than always trying to crack copylock protected games.

[MethodGit]

Originally Posted by marty

Only remember Paramax, Shadow Fighter.

Both of which I've cracked to skip the protection, funnily enough.