Checksum routines in games

11 January 2007, 15:38

Hey there.

I'am a new guy around here.

I've been browsing the net and read some info's on Amiga protections. Especially site called Flashtro got some interesting stuff.

A question i cant get and answer to, is how to locate checksums in games. I know Whdload can be used for the purpose, but how is it done "old fashion" way ?
With an Action Replay or.. ?

Thanks on advance

Joe

girv · 11 January 2007, 16:22

Maybe one of the more experienced old sk00l crackers can jump in here - Galahad, I'm looking at YOU, boy! - but I always found checksums by tracing back from where the game "protection has failed" crash / lockup / whatever happened. Find the lockup code, find the conditions where the game jumps to it, find what creates those conditions. This would have been with an AR3 cartridge on an A500 - the breakpoint and memwatchpoint features come in handy for this.

Still, easier said than done, I guess

11 January 2007, 16:33

[quote=Still, easier said than done, I guess

[/quote]

Hehe, yeah.

I was thinking of a game called Darkman. If the CL protection is changed, the game crashes, but not just into a lock up. I tried looing at the stack, to try tracing back, but no luck.
The mem watch point in AR3 only works for changed memory, would be nice with a feature that halted the miggy, when the checksum read the CL code for changes

Galahad/FLT · 11 January 2007, 16:38

Checksums that crash the game are generally easier to find. When the Amiga crashes, the last address that it was executing or the memory address of the routine it was in can normally be found in the stack memory area (a7).

checksums that remove features of a game are harder, but that all depends on how they are implemented.

For instance, many checksums in Anco games are stupidly coded and are glaringly obvious when you are scanning through the game code.

Checksums are there to protect certain routines, so that also makes it easier to search. If the game has a Copylock routine, then more than likely if a checksum is going to be used, its going to be checking the integrity of that routine to detect for changes.

Sometimes the way a checksum routine is written just looks out of place compared to the rest of the game code. Anco games uses lots of movem.l instructions for the checksums, despite the game code itself hardly using any.

In the abscence of an MMU, sometimes you simply have to scroll through game code to spot the checksums.

girv · 11 January 2007, 17:45

@joejoe:

Have you examined the code in the areas around the copylock or the call to the copylock to see if there is anything like a checksum? Lazy programmers are a cracker's best weapon

Have you searched for instructions referencing the start (even +- some amounts) of the copylock code? That address has got to get loaded somehow! (aside: was the blitter ever used for a checksum routine? ISTR one or two...)

You could maybe narrow down the search area if you can determine when in the run path the copylock is checksummed. eg: leave the copylock unchanged, set a breakpoint at some point after the copylock return and run the game. When that fires, modify the copylock code (randomly!) and continue. If the game works you know either (a) you don't have a checksum or (b) it's calculated before your breakpoint.

Are you sure its a checksum you're looking for anyway? How are you cracking the copylock? Have you disassembled it to make sure its not doing anything tricky in the encrypted part, or are you just bypassing it and setting the magic number afterwards? Might not be a checksum after all

Sometimes a quick disassembly scroll-by will do the trick ... checksum routines can stand out a mile!

11 January 2007, 18:30

Hey Girv.

I've checked the copylock (actually there are 3) & only thing its doing, is to return a key in reg. D0 & at address 60.

I've tried the breakpoint thing, without luck & also looking for "odd" code, but the game seems to be full of it

The main file is fully encrypted (which is real easy to pacth, though) and then lots of the game data is also encrypted.
I've got a crack by Fairlight, done by Gaston, I wonder how he did it..

girv · 12 January 2007, 10:09

It certainly sounds like an "interesting" one

Given that the programmer has gone to the trouble of encrypting the code and data, I'd guess that there will be multiple checksum routines and they will be well hidden in other (probably vital) routines.

Did you try leaving the copylocks themselves untouched but patching the actual bsr/jsr/whatever to the copylock routines?

You could look for slightly odd instructions that might be used to calculate a checksum - eors or shifts for example - but there will be many innocent instances of these too. I'd also check the interrupt and disk loading routines as possible hidey-holes.

At what point in the run does the game crash? You basically need to trace all the calls from the copylock call to around that point and see WTF the code is doing. It will take time, patience, dedication and lots of coffee.

How was it originally cracked? I'd say: time, patience, dedication and lots of coffee

You'll probably kick yourself when you do find the checksum routines, but it should make a good tutorial!

I notice there is a WHD patch for it made by Mr. Larmer and updated by Dark Angel. Wepl will have the source code for this...

12 January 2007, 15:01

Sneaky thing is, that the copylocks are part of the vital code, that has to be run, for the game to work. If the calls to the copylocks are skipped, the game does not work.
According to the tutorial on Flashtro, there should be 14 checksum routines in the game.
A "read watch point " would be a nice feature in a cartridge/monitor program.

musashi5150 · 12 January 2007, 16:09

Quote:

Originally Posted by Joejoe

A "read watch point " would be a nice feature in a cartridge/monitor program.

WinUAE has this... but I guess that's cheating

And it won't help you of course on real HW

girv · 17 January 2007, 21:42

So did you get anywhere with this Joejoe?

dlfrsilver · 14 February 2007, 18:48

Quote:

Originally Posted by girv

It certainly sounds like an "interesting" one

Given that the programmer has gone to the trouble of encrypting the code and data, I'd guess that there will be multiple checksum routines and they will be well hidden in other (probably vital) routines.

Did you try leaving the copylocks themselves untouched but patching the actual bsr/jsr/whatever to the copylock routines?

You could look for slightly odd instructions that might be used to calculate a checksum - eors or shifts for example - but there will be many innocent instances of these too. I'd also check the interrupt and disk loading routines as possible hidey-holes.

At what point in the run does the game crash? You basically need to trace all the calls from the copylock call to around that point and see WTF the code is doing. It will take time, patience, dedication and lots of coffee.

How was it originally cracked? I'd say: time, patience, dedication and lots of coffee

You'll probably kick yourself when you do find the checksum routines, but it should make a good tutorial!

I notice there is a WHD patch for it made by Mr. Larmer and updated by Dark Angel. Wepl will have the source code for this...

Well our dear Darkman programmer is also the parasol stars programmer,
and actually tony hawk pro skater programmer.

He has put encryption everywhere with checksum all along !

26 December 2009, 20:24

I find a good way of finding these is to disassemble the game, and searching for things like

add.l (ax)+,dx
add.w (ax)+,dx
eor.w (ax)+,dx
.....

etc it's usually in some kind of loop, using some kind of loop construct like dbra or something, and they usually do a straight cmp # after the loop calculation ( you'de be suprised )

something like

moveq #0,d0 ; checksum
move.w #$1234,d1 ; length of the code block
lea $2000.w,a0
.loop add.l (a0)+,d0 ; << ==== search for this add.w/add.l
dbra d1,.loop ; << ==== search for this ( or subq.l #, cmpa.l #??,ax )

cmp.l #$ab343444,d0 ; << ===== search for cmp.l # / cmp.w #
; you'de be suprised how often coders do this kind of thing
beq.s .ok

; duff up code
...
...

.ok rts

i've found quite a few using these techniques. It might involve a bit more work if the game has encrypted code blocks, or uses code overlays or some such thing, but you get the idea.

If you don't have much joy with this method, then another method I have employed is to use the trace vector to bounds check memory reads from address pointers, something like this.

pea findchecksumtrace(pc)
move.l (sp)+,$24.w
or.w #$8000,sr
rts

anaddressinthegamesloader equ $4524 ; sensative part of the loader
; checksum code has to read it, usually
; via an address register

findchecksumtrace
move.w d0,$dff180.l ; so we know we haven't been kicked out for some reason
cmp.l #anaddressinthegamesloader,a0 ; a0 maybe reading from this loc ? ( why else would a0 be pointing here ? )
beq.s .checksumcodefoundmaybe
cmp.l #anaddressinthegamesloader,a1 ; ditto for a1
beq.s .checksumcodefoundmaybe
rte
.checksumcodefoundmaybe
jsr startsim ; Simbug.
; into the debugger, so you can have a look what's going on
rte

or maybe

findchecksumtrace
cmp.l #anaddressinthegamesloader-100,a0 ; range check on a0
blt.s .x
cmp.l #anaddressinthegamesloader+100,a0
bge.s .x
jsr startsim
.x rte

obviously there are more addressing modes to cope with than this simple case, so to make a completely robust version would take more work, but you get the idea ( this method will work in the majority of cases IMO ). It's also good to skip things that change the trace vector / sr ( even better patch them out ). A jump table on the opcode would be nice and fast, and it's good to make it fast, because ...

A problem with this method is it can slow the game down alot if the CPU is loaded ( also, interrupts cause the trace bit to be cleared, so checksums in an
interrupt handler wouldn't be caught ). I typically employed it on start-ups of the game/intros/level loads and key-points through the game, by trapping the games VBL, and kicking of the trace on a right mouse button or something. It's also a good way to find where counters get decremented/etc ( if you can't find them by hand ), if that's they way you want to train it.

I found the Turrican checksums like this ( at the start of level 1-3, and the end of level 5-2 ). These checksum fails don't crash the game, but make it sure you can't progress past these 2 parts ( this is far superior to an out-and-out crash, as Galahad has remarked ). There where a few duff cracks of Turrican back in the day, due to this, and crackers not checking their cracks, but that's easy to say

MMU is certainly the best catch all, but I certainly didn't know anyone with one of these at the time.

Hope this helps.

11 January 2007, 15:38	#1
Joejoe Posts: n/a	Checksum routines in games Hey there. I'am a new guy around here. I've been browsing the net and read some info's on Amiga protections. Especially site called Flashtro got some interesting stuff. A question i cant get and answer to, is how to locate checksums in games. I know Whdload can be used for the purpose, but how is it done "old fashion" way ? With an Action Replay or.. ? Thanks on advance Joe

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
decompression routines	Toni Wilen	Coders. General	12	17 May 2017 00:30
OSTER's assembler routines & tricks	Shoonay	Coders. Tutorials	8	17 November 2016 15:41
Checksum error	Vikingex	support.Apps	3	26 June 2008 10:36
Tilemap + Scrolling routines source code	Ultron	Coders. General	0	02 April 2007 01:00
Bootblock checksum	-Rob-	Coders. General	5	17 April 2006 15:49

11 January 2007, 16:22	#2
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	Maybe one of the more experienced old sk00l crackers can jump in here - Galahad, I'm looking at YOU, boy! - but I always found checksums by tracing back from where the game "protection has failed" crash / lockup / whatever happened. Find the lockup code, find the conditions where the game jumps to it, find what creates those conditions. This would have been with an AR3 cartridge on an A500 - the breakpoint and memwatchpoint features come in handy for this. Still, easier said than done, I guess

11 January 2007, 16:33	#3
Joejoe Posts: n/a	[quote=Still, easier said than done, I guess [/quote] Hehe, yeah. I was thinking of a game called Darkman. If the CL protection is changed, the game crashes, but not just into a lock up. I tried looing at the stack, to try tracing back, but no luck. The mem watch point in AR3 only works for changed memory, would be nice with a feature that halted the miggy, when the checksum read the CL code for changes

11 January 2007, 16:38	#4
Galahad/FLT Going nowhere Join Date: Oct 2001 Location: United Kingdom Age: 50 Posts: 8,986	Checksums that crash the game are generally easier to find. When the Amiga crashes, the last address that it was executing or the memory address of the routine it was in can normally be found in the stack memory area (a7). checksums that remove features of a game are harder, but that all depends on how they are implemented. For instance, many checksums in Anco games are stupidly coded and are glaringly obvious when you are scanning through the game code. Checksums are there to protect certain routines, so that also makes it easier to search. If the game has a Copylock routine, then more than likely if a checksum is going to be used, its going to be checking the integrity of that routine to detect for changes. Sometimes the way a checksum routine is written just looks out of place compared to the rest of the game code. Anco games uses lots of movem.l instructions for the checksums, despite the game code itself hardly using any. In the abscence of an MMU, sometimes you simply have to scroll through game code to spot the checksums.

11 January 2007, 17:45	#5
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	@joejoe: Have you examined the code in the areas around the copylock or the call to the copylock to see if there is anything like a checksum? Lazy programmers are a cracker's best weapon Have you searched for instructions referencing the start (even +- some amounts) of the copylock code? That address has got to get loaded somehow! (aside: was the blitter ever used for a checksum routine? ISTR one or two...) You could maybe narrow down the search area if you can determine when in the run path the copylock is checksummed. eg: leave the copylock unchanged, set a breakpoint at some point after the copylock return and run the game. When that fires, modify the copylock code (randomly!) and continue. If the game works you know either (a) you don't have a checksum or (b) it's calculated before your breakpoint. Are you sure its a checksum you're looking for anyway? How are you cracking the copylock? Have you disassembled it to make sure its not doing anything tricky in the encrypted part, or are you just bypassing it and setting the magic number afterwards? Might not be a checksum after all Sometimes a quick disassembly scroll-by will do the trick ... checksum routines can stand out a mile!

11 January 2007, 18:30	#6
Joejoe Posts: n/a	Hey Girv. I've checked the copylock (actually there are 3) & only thing its doing, is to return a key in reg. D0 & at address 60. I've tried the breakpoint thing, without luck & also looking for "odd" code, but the game seems to be full of it The main file is fully encrypted (which is real easy to pacth, though) and then lots of the game data is also encrypted. I've got a crack by Fairlight, done by Gaston, I wonder how he did it..

12 January 2007, 10:09	#7
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	It certainly sounds like an "interesting" one Given that the programmer has gone to the trouble of encrypting the code and data, I'd guess that there will be multiple checksum routines and they will be well hidden in other (probably vital) routines. Did you try leaving the copylocks themselves untouched but patching the actual bsr/jsr/whatever to the copylock routines? You could look for slightly odd instructions that might be used to calculate a checksum - eors or shifts for example - but there will be many innocent instances of these too. I'd also check the interrupt and disk loading routines as possible hidey-holes. At what point in the run does the game crash? You basically need to trace all the calls from the copylock call to around that point and see WTF the code is doing. It will take time, patience, dedication and lots of coffee. How was it originally cracked? I'd say: time, patience, dedication and lots of coffee You'll probably kick yourself when you do find the checksum routines, but it should make a good tutorial! I notice there is a WHD patch for it made by Mr. Larmer and updated by Dark Angel. Wepl will have the source code for this...

12 January 2007, 15:01	#8
Joejoe Posts: n/a	Sneaky thing is, that the copylocks are part of the vital code, that has to be run, for the game to work. If the calls to the copylocks are skipped, the game does not work. According to the tutorial on Flashtro, there should be 14 checksum routines in the game. A "read watch point " would be a nice feature in a cartridge/monitor program.

17 January 2007, 21:42	#10
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	So did you get anywhere with this Joejoe?

26 December 2009, 20:24	#12
rubberunderpant Posts: n/a	I find a good way of finding these is to disassemble the game, and searching for things like add.l (ax)+,dx add.w (ax)+,dx eor.w (ax)+,dx ..... etc it's usually in some kind of loop, using some kind of loop construct like dbra or something, and they usually do a straight cmp # after the loop calculation ( you'de be suprised ) something like moveq #0,d0 ; checksum move.w #$1234,d1 ; length of the code block lea $2000.w,a0 .loop add.l (a0)+,d0 ; << ==== search for this add.w/add.l dbra d1,.loop ; << ==== search for this ( or subq.l #, cmpa.l #??,ax ) cmp.l #$ab343444,d0 ; << ===== search for cmp.l # / cmp.w # ; you'de be suprised how often coders do this kind of thing beq.s .ok ; duff up code ... ... .ok rts i've found quite a few using these techniques. It might involve a bit more work if the game has encrypted code blocks, or uses code overlays or some such thing, but you get the idea. If you don't have much joy with this method, then another method I have employed is to use the trace vector to bounds check memory reads from address pointers, something like this. pea findchecksumtrace(pc) move.l (sp)+,$24.w or.w #$8000,sr rts anaddressinthegamesloader equ $4524 ; sensative part of the loader ; checksum code has to read it, usually ; via an address register findchecksumtrace move.w d0,$dff180.l ; so we know we haven't been kicked out for some reason cmp.l #anaddressinthegamesloader,a0 ; a0 maybe reading from this loc ? ( why else would a0 be pointing here ? ) beq.s .checksumcodefoundmaybe cmp.l #anaddressinthegamesloader,a1 ; ditto for a1 beq.s .checksumcodefoundmaybe rte .checksumcodefoundmaybe jsr startsim ; Simbug. ; into the debugger, so you can have a look what's going on rte or maybe findchecksumtrace cmp.l #anaddressinthegamesloader-100,a0 ; range check on a0 blt.s .x cmp.l #anaddressinthegamesloader+100,a0 bge.s .x jsr startsim .x rte obviously there are more addressing modes to cope with than this simple case, so to make a completely robust version would take more work, but you get the idea ( this method will work in the majority of cases IMO ). It's also good to skip things that change the trace vector / sr ( even better patch them out ). A jump table on the opcode would be nice and fast, and it's good to make it fast, because ... A problem with this method is it can slow the game down alot if the CPU is loaded ( also, interrupts cause the trace bit to be cleared, so checksums in an interrupt handler wouldn't be caught ). I typically employed it on start-ups of the game/intros/level loads and key-points through the game, by trapping the games VBL, and kicking of the trace on a right mouse button or something. It's also a good way to find where counters get decremented/etc ( if you can't find them by hand ), if that's they way you want to train it. I found the Turrican checksums like this ( at the start of level 1-3, and the end of level 5-2 ). These checksum fails don't crash the game, but make it sure you can't progress past these 2 parts ( this is far superior to an out-and-out crash, as Galahad has remarked ). There where a few duff cracks of Turrican back in the day, due to this, and crackers not checking their cracks, but that's easy to say MMU is certainly the best catch all, but I certainly didn't know anyone with one of these at the time. Hope this helps.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)