How was Alien Breed '92 cracked again?

MethodGit · 14 October 2010, 21:26

Having been fascinated by the Amiga Patch List and learning how relatively easy it is to disable the copylock in some games (mostly by changing a few bytes through a hex-editor) I proceeded to search for hex differences between originals and cracks, both with ADFs and with the files inside them.

One thing that puzzled me though was Alien Breed '92. After using uaeunp to extract both the ADF I made out of the Disk 1 IPF and the FLT version's Disk 1 ADF, I noticed only one file - CFUS - had changed between the two, so I proceeded to test my discovery out. First I tried to run the file through HexEd in Workbench, but as it happens CFUS is the one file on the disk burdened with a (intentional?) checksum error, leaving me puzzled as to how uaeunp could extract it without a problem. Then I thought about trying to find the same set of bytes in the ADF itself through a hex-editor and changing it that way, but that just caused the disk to guru when booting it in WinUAE.

Please don't tell me this game requires a more overly-complicated method of defeating a copylock?

StingRay · 14 October 2010, 21:58

Crackpatch in the bootblock, copied to $300.w, game code modified to call this patch. That's all.

MethodGit · 14 October 2010, 22:05

So, bootblock replaced with new one and a modification or two to the game code? While I can easily notice the bootblock difference, finding the crack-calling reference through hex code may be very difficult, as I have a hunch that the order of the files was shuffled around on the disk somehow. I'm spotting a few sections where code is present in the crack but just blankness in the original, or the other way around.

jotd · 14 October 2010, 22:13

I have cracked this game back in 1993 or 1994, and I remember having to install several traps to patch each loader after decrunch, to finally be able to patch the one with the (lame) copylock check. At least 3 or 4 patches were needed to do that (because of RNC compression)
Was not tough, just tedious.

StingRay · 14 October 2010, 22:16

Quote:

Originally Posted by MethodGit

So, bootblock replaced with new one and a modification or two to the game code? While I can easily notice the bootblock difference, finding the crack-calling reference through hex code may be very difficult, as I have a hunch that the order of the files was shuffled around on the disk somehow. I'm spotting a few sections where code is present in the crack but just blankness in the original, or the other way around.

No files have been shuffled around. The call to the patch is at offset $6e6f2 in the disk image ($4ef900000300 = jmp $300).

MethodGit · 15 October 2010, 02:22

Quote:

Originally Posted by StingRay

No files have been shuffled around. The call to the patch is at offset $6e6f2 in the disk image ($4ef900000300 = jmp $300).

Cheers for providing the offset.

As it turns out, it's just a few bytes early from where I found the first byte difference between the two CFUSes. Changing just that byte and the next two caused the guru I mentioned, so I looked a bit further. As I discovered, it's all pretty intricately linked together - the bootblock can't be changed by a single byte or it fails. It's coded to call for an integrated cracktro executable situated at offset $001600 and lasting until $001C97. And I guess then it calls for the original loader. Looking closely at the bootblock, I notice it's almost identical at the very top, adding just an extra 52 bytes of data close at the top, from $C to $5D - I'm going to assume this is what calls for the cracktro exe. The data from $150 to $197 I assume is some more caller code or other. Now if only I knew some more about how bootblocks are structured, how they're built and/or modified correctly etc...

What puzzles me is that whereas there is data in the original ADF from $05F803 to $06E000, that section is entirely blank in the FLT ADF. Wonder why?

MethodGit · 15 October 2010, 17:54

Well, I did have a 'smart moment' and thought about extracting CFUS with uaeunp, editing it through an Amiga hex editor and then copying it over the existing CFUS on disk 1 (which seems to work without a problem), but when I boot it up, guess what?

It still gurus. >.<

I can only conclude that the game is somehow programmed to expect that specific checksum error to exist or it will refuse to boot. Amirite?

Codetapper · 15 October 2010, 21:00

MethodGit: I think you need to learn a bit more about assembler and the bootblock structure before you try patching bytes in disk images. There is a longword checksum in the bootblock that must be correct or the disk won't boot. So if you change a single byte, the checksum will change rendering the disk non-bootable.

Games on the whole do not have checksum errors on the disks, only a few old protections such as Herndon appear to have an intentional checksum error when viewed at the AmigaDOS level.

14 October 2010, 21:26	#1
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 40 Posts: 2,731	How was Alien Breed '92 cracked again? Having been fascinated by the Amiga Patch List and learning how relatively easy it is to disable the copylock in some games (mostly by changing a few bytes through a hex-editor) I proceeded to search for hex differences between originals and cracks, both with ADFs and with the files inside them. One thing that puzzled me though was Alien Breed '92. After using uaeunp to extract both the ADF I made out of the Disk 1 IPF and the FLT version's Disk 1 ADF, I noticed only one file - CFUS - had changed between the two, so I proceeded to test my discovery out. First I tried to run the file through HexEd in Workbench, but as it happens CFUS is the one file on the disk burdened with a (intentional?) checksum error, leaving me puzzled as to how uaeunp could extract it without a problem. Then I thought about trying to find the same set of bytes in the ADF itself through a hex-editor and changing it that way, but that just caused the disk to guru when booting it in WinUAE. Please don't tell me this game requires a more overly-complicated method of defeating a copylock?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Working WinUAE config for Alien Breed and Alien Breed II	takeobass	support.WinUAE	2	22 July 2008 14:48
Cracked Alien Storm	BippyM	Coders. Tutorials	28	05 June 2008 12:49
alien breed 3d 2	c0d334t3r	project.Sprites	1	22 May 2005 12:40
Which alien breed was the best?	Mangar	Retrogaming General Discussion	39	27 August 2004 20:26
Alien Breed 2	Sir Kidd	request.Modules	2	19 December 2003 13:41

14 October 2010, 21:58	#2
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Crackpatch in the bootblock, copied to $300.w, game code modified to call this patch. That's all.

14 October 2010, 22:05	#3
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 40 Posts: 2,731	So, bootblock replaced with new one and a modification or two to the game code? While I can easily notice the bootblock difference, finding the crack-calling reference through hex code may be very difficult, as I have a hunch that the order of the files was shuffled around on the disk somehow. I'm spotting a few sections where code is present in the crack but just blankness in the original, or the other way around.

14 October 2010, 22:13	#4
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,325	I have cracked this game back in 1993 or 1994, and I remember having to install several traps to patch each loader after decrunch, to finally be able to patch the one with the (lame) copylock check. At least 3 or 4 patches were needed to do that (because of RNC compression) Was not tough, just tedious.

15 October 2010, 17:54	#7
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 40 Posts: 2,731	Well, I did have a 'smart moment' and thought about extracting CFUS with uaeunp, editing it through an Amiga hex editor and then copying it over the existing CFUS on disk 1 (which seems to work without a problem), but when I boot it up, guess what? It still gurus. >.< I can only conclude that the game is somehow programmed to expect that specific checksum error to exist or it will refuse to boot. Amirite?

15 October 2010, 21:00	#8
Codetapper 2 contact me: email only! Join Date: May 2001 Location: Auckland / New Zealand Posts: 3,187	MethodGit: I think you need to learn a bit more about assembler and the bootblock structure before you try patching bytes in disk images. There is a longword checksum in the bootblock that must be correct or the disk won't boot. So if you change a single byte, the checksum will change rendering the disk non-bootable. Games on the whole do not have checksum errors on the disks, only a few old protections such as Herndon appear to have an intentional checksum error when viewed at the AmigaDOS level.

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