What to alter/add for Rodland patch?

[MethodGit]

Hello once more. Been so busy cracking games left, right and centre, hence the quietness! Been trying to compile a semi-large collection with the intention to share very soon. But in the meantime...

Rodland. A game I often thought would cause me to tear my hair out trying to crack. And yet I have managed to come up with some patch code:

(for version 1.3)

702B0 = MOVE.L #60000932,9718
702BA = MOVE.B #60,A056
702C2 = MOVE.W #6004,15124
702CA = MOVE.W #6004,AF84
702D2 = MOVE.W #8F,DFF180
702DA = JMP -20(A2)

My ideal destination for this on the disk would be 702B0 (which appears to have junk in that address on the v1.3 disk, and blankness on v1.32). This way I could take over the end of this code:

7006C = BSR     000700EE
70070 = MOVEA.L A5,A1
70072 = MOVE.W  #9,1C(A1)
70078 = CLR.L   24(A1)
7007C = MOVE.L  A6,-(A7)
7007E = MOVEA.L (A6),A6
70080 = JSR     -1C8(A6)
70084 = MOVEA.L (A7)+,A6
70086 = MOVE.L  A4,-(A7)
70088 = MOVEA.L A4,A0
7008A = BSR     00070142
7008E = MOVEA.L (A7)+,A4
70090 = MOVE.L  #32000,D0
70096 = MOVEA.L A4,A0
70098 = MOVE.W  #7FFF,00DFF096
700A0 = MOVE.W  #7FFF,00DFF09A
700A8 = LEA     700B2(PC),A1
700AC = MOVE.L  A1,00000084.S
700B0 = TRAP    #1
700B2 = MOVE.W  #2700,SR
700B6 = LEA     700DE(PC),A1
700BA = LEA     0007FF00,A2
700C0 = MOVEA.L A2,A7
700C2 = MOVE.L  (A1)+,(A2)+
700C4 = MOVE.L  (A1)+,(A2)+
700C6 = MOVE.L  (A1)+,(A2)+
700C8 = MOVE.L  (A1)+,(A2)+
700CA = MOVE.L  (A1)+,(A2)+
700CC = MOVE.L  (A1)+,(A2)+
700CE = MOVE.L  (A1)+,(A2)+
700D0 = MOVE.L  (A1)+,(A2)+
700D2 = MOVE.W  #8F,00DFF180   <--- insert "BRA 702B0" here
700DA = JMP     -20(A2)

Alas, this currently does not work, as the address where the patch code should be (after the game has finished loading the data and coming to the end of the routine) instead contains entirely different stuff, so branching there will cause the game to guru. I have a hunch that this is simply a similar issue I had with Fantasy World Dizzy, where the disk initially did not copy enough data to include my patch at the end. I took a gander at that thread again to see if I could adapt any trickery, but to be honest I'm not any wiser from reading it. Rodland appears to load its data quite differently. I'm convinced it's either 700A8 or 700B6 - or even both - that need altering.

However, I feel I should ask an expert on the matter first. Am I on the right track here?

On another Rodland note, could anyone confirm if it uses some kind of checksum/size check on the RNC chunk at $2C00 on the ADF? Seems the game doesn't like it if you repack it and replace the original chunk with it, as it causes a guru. Is this part of another routine that can be altered? Thanks.

[StingRay]

I just had a quick look, what I would do here (if I'd want to patch on the fly that is) is that I'd just use the protection track for my patch code since there is no space in the bootblock for any patches. Thus I would use the copylock track and place my patches there. Obviously, for that to work you will have to adapt the game loader so that it'll start to load from offset $1600 and it has to load $1600 bytes more. Then once the game has been loaded and decrunched you can easily jump into your patch code.

Originally Posted by MethodGit

On another Rodland note, could anyone confirm if it uses some kind of checksum/size check on the RNC chunk at $2C00 on the ADF? Seems the game doesn't like it if you repack it and replace the original chunk with it, as it causes a guru. Is this part of another routine that can be altered? Thanks.

There is no checksum/size check, my guess is that the game decruncher is not compatible with the ProPack version you used to (re)pack the game code. If you'd patch the decruncher I'm sure it will work.

[marty]

Yes, MethodGit there are checksum routines in the game, protecting the copylock code.

[MethodGit]

Originally Posted by StingRay

I just had a quick look, what I would do here (if I'd want to patch on the fly that is) is that I'd just use the protection track for my patch code since there is no space in the bootblock for any patches. Thus I would use the copylock track and place my patches there. Obviously, for that to work you will have to adapt the game loader so that it'll start to load from offset $1600 and it has to load $1600 bytes more. Then once the game has been loaded and decrunched you can easily jump into your patch code.

I did dread the prospect of shifting a whole bunch of code onto the next block as it seems to be quite a lot of work (and I thought it was only necessary at times if you were making a cracktro). There's actually plenty of blank space from $2B0 onwards on the v1.32 ADF at least so I was hoping to try and use that to my advantage and confine all changes to the bootblock for that particular version. And even with v1.3, I'm convinced that not *all* of that data towards the end of the bootblock (or up to $400 in other words) is necessary to keep - I discovered that for myself when messing about with Dizzy Collection Disk 2, overwriting what looked like garbage with my patch code, trying it out and lo and behold, it actually worked wonderfully!

There is no checksum/size check, my guess is that the game decruncher is not compatible with the ProPack version you used to (re)pack the game code. If you'd patch the decruncher I'm sure it will work.

I did wonder if it was a version disagreement. Alas, it looks like 2.08 is the only publically available version of the cruncher. Do you happen to know how the decruncher may be patched, and if it involves little or lots of code changing?

This issue also affects Doodlebug and Cyberpunks, so maybe they can be patched similarly.

Originally Posted by marty

Yes, MethodGit there are checksum routines in the game, protecting the copylock code.

Which I'm aware of. However, I was inquiring about the way it loads the first RNC chunk containing all the program code (and copylock) as it did appear to be insensitive to even basic repacking (without modification).

[marty]

No, there are none else

[StingRay]

Originally Posted by marty

Yes, MethodGit there are checksum routines in the game, protecting the copylock code.

This is totally irrelevant since he said he just repacked the data, i.e. no modifications whatsoever. And it shouldn't crash right away anyway!

Originally Posted by MethodGit

I did dread the prospect of shifting a whole bunch of code onto the next block as it seems to be quite a lot of work

There is no need to shift anything. Patch code will be located on the (now unused) protection track, that is all.

Originally Posted by MethodGit

There's actually plenty of blank space from $2B0 onwards on the v1.32 ADF at least so I was hoping to try and use that to my advantage and confine all changes to the bootblock for that particular version.

Both versions I checked (SPS1509 and SPS572) have no space in the bootblock for any patches. I have no idea what "version 1.32" is, upload please!

Originally Posted by MethodGit

I did wonder if it was a version disagreement. Alas, it looks like 2.08 is the only publically available version of the cruncher. Do you happen to know how the decruncher may be patched, and if it involves little or lots of code changing?

Just overwrite the decruncher in the game with the one found in the ProPack package.

[marty]

Please tell me why you keep on trying to repack things ?
You done it again, and the result is as it use to be; something goes wrong.
Patch the fucking decruncher or take over jumps to decrunched code, you been told this a million times

[StingRay]

While I totally agree on that I won't tell him that anymore, he has to learn it the hard way.

[MethodGit]

Originally Posted by StingRay

There is no need to shift anything. Patch code will be located on the (now unused) protection track, that is all.

Well I wonder where I can insert the track loader code to have the ADF load the patch from $1600? Something would have to be overwritten.

Both versions I checked (SPS1509 and SPS572) have no space in the bootblock for any patches. I have no idea what "version 1.32" is, upload please!

Just zoned. Both ADFs created via WWarp from the IPFs in my No-Intro collection. SPS572 is v1.3 and SPS1509 v1.32, btw.

Just overwrite the decruncher in the game with the one found in the ProPack package.

Not sure what you mean exactly - the Aminet package includes just the one Amiga program for both packing and unpacking. Though it also contains some sources for various platforms, I'm not sure if they'd be of immediate use!

Originally Posted by marty

Please tell me why you keep on trying to repack things ?
You done it again, and the result is as it use to be; something goes wrong.
Patch the fucking decruncher or take over jumps to decrunched code, you been told this a million times

Keep your hair on, I've been looking at both bootpatch and hardpatch methods. The latter is plausible but quite difficult when the game has a problem with the cruncher I'm using. I've almost done it with a boot patch but the problem is working out what values to alter exactly.

[StingRay]

Originally Posted by MethodGit

Well I wonder where I can insert the track loader code to have the ADF load the patch from $1600? Something would have to be overwritten.

You don't have to insert any trackloader code. You just modify the game loader to load from offset $1600 instead of $2c00 and let it load $1600 bytes more and load it to original loadaddress-$1600. No need to add any code.

Originally Posted by MethodGit

Not sure what you mean exactly - the Aminet package includes just the one Amiga program for both packing and unpacking. Though it also contains some sources for various platforms, I'm not sure if they'd be of immediate use!

There is a source to unpack ProPacked data files in the ProPack package. You would assemble it and replace the decruncher in the game with that one. However, read what Marty wrote!

[marty]

Originally Posted by MethodGit

Keep your hair on, I've been looking at both bootpatch and hardpatch methods. The latter is plausible but quite difficult when the game has a problem with the cruncher I'm using. I've almost done it with a boot patch but the problem is working out what values to alter exactly.

You know, I'am soon turning 32, and there ain't much hair left

[MethodGit]

Originally Posted by StingRay

You don't have to insert any trackloader code. You just modify the game loader to load from offset $1600 instead of $2c00 and let it load $1600 bytes more and load it to original loadaddress-$1600. No need to add any code.

Is this the routine I'm looking for?

700EE = LEA 702A0(PC),A4
700F2 = MOVEA.L A4,A2
700F4 = MOVE.L 7013A(PC),D0
700F8 = LEA 0(A2,D0.L),A3
700FC = MOVE.L #2C00,D2
70102 = MOVEA.L A5,A1
70104 = MOVE.L A2,28(A1)
70108 = MOVE.L #1600,24(A1)
70110 = MOVE.L D2,2C(A1)
70114 = MOVE.W #2,1C(A1)
7011A = MOVE.L A6,-(A7)
7011C = MOVEA.L (A6),A6
7011E = JSR -1C8(A6)
70122 = MOVEA.L (A7)+,A6
70124 = TST.L D0
70126 = BNE 70064
7012A = ADDI.L #1600,D2
70130 = ADDA.W #1600,A2
70134 = CMPA.L A3,A2
70136 = BCS 70102
70138 = RTS

BTW, did you look at the ADFs I uploaded? Like I said, the v1.32 ADF has lots of blank space so I should still be able to fit a patch there without the need to use the copylock track.

There is a source to unpack ProPacked data files in the ProPack package. You would assemble it and replace the decruncher in the game with that one. However, read what Marty wrote!

You mean the MC68000 sources?

[StingRay]

Originally Posted by MethodGit

Is this the routine I'm looking for?

Yes, that's the routine which loads the game code. If you don't feel like modifying the loader you could also do this (which is even easier):
- still use the copylock track for your patch code
- modify the original bootblock so that it will only load your patch code and then execute the original bootblock, i.e. you'd load the protection track with your patches and then load the original bootblock, that way you won't have to patch the game loader

Originally Posted by MethodGit

BTW, did you look at the ADFs I uploaded? Like I said, the v1.32 ADF has lots of blank space so I should still be able to fit a patch there without the need to use the copylock track.

I had a look yesterday already (since you also used the IPF's) and if you understand how the game loader works you'll also see that blank space won't help you. There was a reason why I said there is no space in the bootblock for any patches.

Originally Posted by MethodGit

You mean the MC68000 sources?

Yes.

[MethodGit]

Originally Posted by StingRay

Yes, that's the routine which loads the game code. If you don't feel like modifying the loader you could also do this (which is even easier):
- still use the copylock track for your patch code
- modify the original bootblock so that it will only load your patch code and then execute the original bootblock, i.e. you'd load the protection track with your patches and then load the original bootblock, that way you won't have to patch the game loader

I'll admit, I've never really had to mess with this precise sort of thing before. I'm so used to LEA/copy methods and track copy loaders (both learnt from Flashtro) that I'm left dumbfounded. When you say the other method is even easier, do you mean "less code to modify"? You able to show me an example by any chance?

I had a look yesterday already (since you also used the IPF's) and if you understand how the game loader works you'll also see that blank space won't help you. There was a reason why I said there is no space in the bootblock for any patches.

So it's definitely not a case of just changing how much initial data the bootblock loads like what I was shown with Fantasy World Dizzy?

Yes.

Fingers crossed ASM-One is friendly with it then!

[StingRay]

Originally Posted by MethodGit

When you say the other method is even easier, do you mean "less code to modify"? You able to show me an example by any chance?

Yes, the advantage is that you don't have to patch the loader if you use this method since you're executing the original bootblock after you installed your patches. Code for this could like like this:

; load patches to $50000 (code size is 28 bytes)
	pea	$50000
	move.l	#$1600,d0
	move.l	d0,$2c(a1)		; start
	move.l	d0,$24(a1)		; length
	move.l	(a7),$28(a1)		; address
	jmp	-456(a6)		: DoIO + jmp $50000

That's the code you'd execute in the original bootblock after the move.l a1,a5 instruction (offset $E in the bootlock). I think you should be able to figure out what happens here.

; patch code
	bsr	InstallPatches		; do whatever here

; load bootblock
	move.l	a5,a1			; restore IO request
	pea	$60000			; just an example, you could/should
	clr.l	$2c(a1)			; allocate memory here!
	move.l	#512*2,$24(a1)
	move.l	(a7),$28(a1)
	move.l	$4.w,a6
	jsr	-456(a6)		; DoIO


; original bootblock loaded to $60000, restore the 28 bytes we
; killed with our patch code
	lea	code(pc),a0
	move.l	(a7),a1
	add.w	#$e,a1			; destination
	moveq	#codesize/2-1,d7
.loop	move.w	(a0)+,(a1)+
	dbf	d7,.loop

	move.l	(a7)+,a0
	move.l	a5,a1			; restore IO request
	jmp	$3*4(a0)		; execute original bootblock





code	move.w	#0,$dff180
	move.l	#$32000,d0
	moveq	#3,d1
	move.l	$4.w,a6
	jsr	-198(a6)	
	tst.l	d0
	dc.w	$673a			; beq *+$3a+2

codesize = *-code


InstallPatches
	rts

And that's the code that will install the patches and then load the original bootblock. It shouldn't be too hard to understand either. Basically, it will load the original bootblock, restore the instruction which were overwritten by our patch code and then execute the bootblock.
Note that I did not test this code, it's just to give you an idea how ONE possible solution could look like. I used absolute addresses here to keep the code simple, I normally would either allocate memory or just remember the address the original bootblock has been loaded to. It could be a good exercise for you to add these things yourself.

Originally Posted by MethodGit

So it's definitely not a case of just changing how much initial data the bootblock loads like what I was shown with Fantasy World Dizzy?

No. I can just repeat myself, you need to understand what happens in the code, trial and error might help sometimes but it's not really the way to go. Look at the code, try to understand what it does and then decide what to do.

Originally Posted by MethodGit

Fingers crossed ASM-One is friendly with it then!

If memory serves me right, the source can be assembled without major changes with Asm1.

[Codetapper]

@MethodGit: You would probably be better off using WHDLoad to try and HD install some of these titles for various reasons:

1. You don't have to locate any spare space on the disk, risk overwriting game data etc.

2. You won't need to worry about your code being overwritten as it resides in a safe block of memory.

3. All modifications are simple patches in memory where you load the original game data and patch around it.

4. It will teach/force you to crack cleanly as your obsession with recompressing data seems quite mad to me and some other crackers on here.

5. The Amiga community might end up with some new games that run from HD rather than disk cracks (of dubious quality) that have already been cracked 20 years earlier.