Soccer Kid

Soccer Kid
c Krisalis

 
image
What you need:

 

Original game or SPS release #1129 
AR 3 cart. 
Little asm knowledge 
blank disks 
pencil and paper 
 

In this tut, I have used slow memory at $ C00000, yours might differ. It would be a good idea, to take note

of some addresses on a piece of paper, during the tutorial. You’ll know which ones. 

Start by making a copy of the original disks. None of them have errors, so most likely a off-disk protected game.

From now on, only use copy of game disks.

Boot game, and this appears:


 

If you type a number and press return, Amiga crashes. 

Let game re-load, enter 2 digit at protection screen and enter AR. Lets keep in mind, Amiga crashes when 

Return is pressed. Check out the keyboard routine. Look at the KB int:


 

KB routine starts at $ c389a6. At c389ea + c389ec the key value is calculated. At $ c389ee key is moved

To memory address $ c002a3. Stick a memory watchpoint to address $ c002a3, exit AR and press 

Retrun. When $ c002a3 is changed, AR pops up. Address c002a3 now holds value for return.

Its #44. Exit AR again, then address gets cleared by the gamecode, and AR pops up again.

We don’t need the memory watchpoint anymore, so delete it; MDA. 



 

Disassemble memory and hit enter a few times.

The key for enter (44) is checked at $ c3706a, if its pressed, game branches to $ c3709c.




Disassemble this address:


 

At $ C370F0 something interesting appears. Two things compared against each other. Stick a breakpoint to

$ c370f0, and exit AR; BS c370f0. When AR pops up, check regs; R. And address $ c37692. They differ.

(unless you put in the correct page number)

Address $ c37692 holds the correct value, which is 10. Insert this value in reg. d0; r d0 10, see above.

Exit AR. This appears;


 

Pretty nice. To crack the protection, we move $ c37692 into reg d0. and the compare will be successful.

Go back into AR and disassemble compare routine;




You’ll see lots of branches and then at $ c375b0, address $ c002d1 is set to zero. Take note, it gets a 

Little interesting later on.

I started making a crackpatch and everything was happy happy joy joy. Until I finished the first world.

After disk loading, this appeared;


 

After buying another 8MB of extra fast memory and the fault still appeared, I thought something was wrong…

Yes, its checksums causing the problems.

Reboot game and enter AR at the novella screen. From earlier experiences with Topgear 2, Tip Off,

Kick Off 2 and Xenon, I started looking for checksums. A common thing, seems to be they do a 

CMPI.L #xxx,D0 or D1 and so on. I started searching for this and bingo.

To find opcodes to search for, assemble ex. $ 300 and insert a “ cmpi.l #12345678,d1 “ and see

Opcodes with “ m 300 “. Search for these: F 0C 81,c00000.

AR returns a bunch of addresses, as you can see below, most of them is false alarm. 

$ c55c7a looks interesting.


 

It checks D1 for a value, if its ok, it branches past $ c55c82, which sets an address to $ FF.

Look at bit further up, at $ c55c60, that loads value $ bfdfa4 into a2, looks very odd. 

But the “crash code” at $ c55c82, helps to make sense. It adds $ 2338 to a2 = bfdfa4+2338= $ c002dc, which

Is a valid memory address. To crack this, simply change the BEQ at $ c55c80 to a BRA, by putting

The value # 60.

There might be further checksums. And probably similar, yet different. This is to make them more difficult

To find. Lets use the instruction at $ c55c60 as a guideline. Assuming it could be anything from a0-a6.

Start by searching for similar instructions, for A0;

See below picture.

 


 

AR returns 3 addresses, where 2 of them is “legal” values. Third one, $ c388e2 loads in a strange value.

This value +da1 is then checks if its # 0. bff530+da1 = c002d1, remember this address ?

Yes, this address was set to #0, after the novella was run. Apparently, game checks if novella actually

Has been run. Our way of cracking game, including running novella and not skipping it, so we don’t

Have to worry about this.

Do next search, this time for a1. See below.


 

Disassemble the hits. Most of them contains valid addresses. Except these two;


 

 $ C3c9a2 loads a1 with strange value and $ c3c9ae makes a compare. If it fails, a series of jumps are 

skipped. To crack this, move two nops (4e714e71) into $ c3c9b0. Again, at $c56166 we have a check, if

this fails, $ bfa06d+6237 =c002a4 is set to #ff, causing game to crash at some point. To crack this one,

nop out the BNE at $ c56164 and change BEQ at $ c5616a to a BRA, by putting #60.

Next victim A2. Follow the usual steps below;


 

$ c37e5c & c38452 contains valid addresses. $ C55c60 have we already cracked. Two left:


 

Pretty much the same routine ? haha

$ c3bfdc is pretty easy to spot. Again, crack with putting #60 at $ c3bfe2. Same with next one at 

$ c561e0, also put #60 here.

Well, that’s it. Could not find any more checksums. Checked all LEA’s.

Next is actually cracking the game. We can not just insert changes to the main file, as it is crunched.

They used a ByteKiller like algo., so we need to patch mainfile. The idea, is to take over the decruncher,

And call our code, each time decruncher has been called. In our code, we check if mainfile has been decrunched.

If it has, our code will insert new opcodes, cracking the game, if not, it just returns to the decruncher.

Now… a looong journey starts….

Our goal is to locate the decruncher and find out, when protection sits decrunched in memory, but not

Yet run.

Reboot and enter AR when loading starts. Disassemble memory. You should be somewhere in the 

$ 78000 area of memory. Lets assume the code actually starts at this address. Start disassemble and look out

for any jumps;


 

At $ 78190 we have a jump $1000, stick a breakpoint here and exit AR, see above pic. When AR pops up,

Disassemble $ C370F0. No, protection is yet not appearing in memory. $ 78190 is the first jump we 

Have to take over. Disassemble $1000 and look for other jumps;


 

At $ 1594 we have a jump to $ 78000, second one we have to take over. Stick a breakpoint here and 

exit AR. See above. Intro now starts, game loads a little and then AR pops up. So, this smells like we had

one loader at 78000 for the intro and a new one has now appeared. Lets have a little looksie at memory;


 

Look at that nice txt marked above, “ BTB6 “. This is a sure sign, a ByteKiller decruncher is sitting in 

Memory. Lets have yet another look;


 

BKDC starts at $ 783cc, and routine at $ 783c0 calls it. Stick a breakpoint to $ 783c6, this is right after

The decruncher has been called. Exit AR and wait. When AR returns, disassemble $ c370f0, see above.

And yes, we now have the novella (and checksums) in memory. $ 783c6 is the last address to take over.

As the game uses expansion memory, we have to workout some offsets, to where we shall put our

crack code. Have a look at the regs., so we can find a base;

A0 points to $c360a0, this will be our base. Now we need some opcodes to check for, to see

if protection has been decrunched in memory. Lets take the SF c002ad instruction at $ c375b0.



 

 

C375b0-c368a0=d10. So, to check if file is decrunched, we do a “cmpi.w #51f9,d10(a0)”, see opcodes 

above.

Then we need a hook at the novella protection, to call our crackpatch/code. This was at $ c370f0.

C370f0-c38a0=850. Here we’ll move a “jsr patch”, ex. Move.l #4eb80284,850(a0).

Then there is all the checksums. Start by subtract locataion of first one, from our baseaddress:

C3bfe2-c368a0=5742. Next one, subtract second checksum location from first one; 

c3c9b0-c3bfe2=9ce. Do this with all of them, and you should get these values;

5742 
9ce 
192d0 
4e4 
6 
76 
 

Last checksum was at c561e0, so to restore a0 to original value, c561e0-c368a0=1f940, end by subtract

#1f940 from a0.

Reboot game and enter AR when protection screen appears. Enter AR and stick a breakpoint to $ c370f0,

Exit AR, type something at protection screen and press enter. AR should now pop up.

Here comes the explanation. Protection check is done at $ c370f0, we would overwrite this with a

“JSR crackpatch “. Original protection check is PC relative and we can not do that at our patch at

$ 200 area of memory. So, to emulate this and force correct key in reg. d0, we need some infos.

Correct key is at $ c37692, when instruction at $ c370f0 is executed, a0 points to $ c00e3a. 


 

C37692-c00e3a=36858. In our patach, we now know to add #36858, to make a0 point to address

Holding correct key. Then we can do a “ move.b (a0),d0 and emulate code at  $ c370f0 

with “ cmp.b (a0),d0.

 

Where in memory to locate patch ? Have a look at low mem, for any free space;




$ 200 looks very useful. Next question, is there left over space on boot block for patch ?

Read bootblock into memory and check it out; RT0,70000. N 70000.

Offset $300 and onward looks pretty unused.

Next step is having a little peek at the bootblock code. Around offset $ b0, something interesting appears. 

Part of the bootblock is being copied intro memory, at address 7d000. We could use this to let copy

our patch too. Problem is, its only copying the amount of data game needs. We need to increase amount

to copy. Then next problem occurs (its nothing but problems), size is set with “moveq “ instruction,

and it can not be used for the value we need. At $ 700b8 insert a “ BSR 703c0 “, at $ 703c0

a new copy routine can be written. Follow steps on below pic;   


 

Assemble $ 703c0 and insert below;


 

Instead of $1b now $400 data is copied (yes, more than enough). 

Check out code around $ 700c2. 

Remember the “xcopy” Text we had in memory at $ 200 and the “ FAT” at $ 100 ?


 

     Code at $ 700c2-700ce is responsible for this. Right after, it copy some code to $ 78000. Lets take over

     Here, and copy our patch to $ 200. Insert a “ bsr 70300 “ at $ 700d4, overwriting the “ move.w #8ff,d0 “

    Instruction. At $ 700da, we have a “ jmp 78000 “, calling copied data. Overwrite this with “jmp 200 “, making

    It call our patch, upon boot. Look at above picture.

   Assemble $ 70300, and insert copy routine, copying crackpatch to $ 200, and assemble actual crack;



 

Finally, correct bootblock checksum nad write back, see above.

Reboot and enjoy.




 

I guess you could just restore the novella protection opcodes after it has been run, then you would avoid

The checksum part. But.. this would cause it impossible to train the game….

A disk holding the above bootblock can be downloaded here. Just install it on a copy of program disk

And game is cracked.

 

Rob

Publication author

offline 2 weeks

mus@shi9

0

Comments: 1160Publics: 2780Registration: 06-03-2017