Methodgits Cracking Thread

[BippyM]

This thread is for Methodgit to put all his cracking queries, if you don't like him then please avoid..

[MethodGit]

Guess I finally found a use for this thread then.

Well, I'm not quite sure if it's something anyone could help out with, as it's not strictly 68000-related (I think).

I'm currently looking at Future Wars. I expressed in the past how great it could be if somebody came up with a fully cross-platform data-based crack for this game (and Operation Stealth) rather than rely on restricted executable hackarounds.

In this thread, JOTD mentioned how the PC CD version of the game used a different startup script file (AUTO00.PRC) that could bypass the protection screen completely, and that it could also be used with the PC floppy version of the game to achieve the same effect. So far, so good. However, he then added that he tried to see if it could work with the Amiga version as well, but neither ScummVM or WHDLoad liked that teamup at all.

Googling around, this thread at the ScummVM forums revealed some more information about the PC CD AUTO00.PRC file - importantly, the start of page 2 of the thread reveals one of the developers confirming that the file is 'crypted' by way of rotating all its bytes to the right by one (akin to ROL/ROR). This left me thinking: maybe if I tried decrypting this file back, other versions might be able to take it?

Well, just one problem: I'm not quite sure what 'rule' this game's engine follows in regards to byte-rotating, whether it's based more on x86 or 68000, etc. I've tried general byte-adjusting across the entirety of the small file (just 253 bytes, so at least it doesn't take all day), though I'm still not quite sure if I'm supposed to be seeing clear references to files inside the PART0x resource files - the floppy AUTO00.PRC mentions "PART01" and "TOTO.PRC" (the protection script) in comparison, but nothing I've tried so far has uncovered any hidden words. Maybe there aren't supposed to be any. Who knows?

Here's all that ScummVM's source code had to say on the matter (taken from 'engines\cine\part.cpp'):

/** Rotate byte value to the left by n bits */
byte rolByte(byte value, uint n) {
	n %= 8;
	return (byte) ((value << n) | (value >> (8 - n)));
}

byte *readFile(const char *filename, bool crypted) {
	Common::File in;

	in.open(filename);

	if (!in.isOpen())
		error("readFile(): Cannot open file %s", filename);

	uint32 size = in.size();

	byte *dataPtr = (byte *)malloc(size);
	in.read(dataPtr, size);

	// The Sony published CD version of Future Wars has its
	// AUTO00.PRC file's bytes rotated to the right by one.
	// So we decode the so called crypting by rotating all
	// the bytes to the left by one.
	if (crypted) {
		for (uint index = 0; index < size; index++) {
			dataPtr[index] = rolByte(dataPtr[index], 1);
		}
	}

	return dataPtr;
}

I've attached a zip containing three AUTO00.PRC files for examination purposes, from the Amiga, PC floppy and PC CD versions respectively.

(It's a shame btw that there appears to be little to no information on the Cine engine, so I have no clue as to its opcodes etc, unlike SCI or AGI.)

[Hewitson]

Here you go.

[MethodGit]

Well dang, I obviously wasn't doing it right then!

Perhaps I misunderstood the concept of byte-rotation? From reading up on it I was made to believe it went similar to "AABBCC00 to BBCC00AA" (move one byte from one end to another in a wraparound) but comparing the encrypted and decrypted files it appears none of the numbers had to physically move. Or does the game not follow the 68000 or x86 convention?

[Hewitson]

Originally Posted by MethodGit

Well dang, I obviously wasn't doing it right then!

Perhaps I misunderstood the concept of byte-rotation?

You did. Performing a rotation on a byte means rotating the bits within that byte. For example a ROL on 10001100 would be 00011001.

With a bit shift, the bit on the end drops off instead of wrapping around to the other side of the byte. An LSL on 10001100 would be 00011000.

[MethodGit]

Okay, something else now. I've been left stumped by an unsuccessful bootcrack attempt at Stunt Car Racer.

Having found a bootcracked Stunt Track Racer within the latest TOSEC, I felt inspired to try and defeat Stunt Car Racer the simpler way, with no complete data replacement involved. I disassembled the WHDLoad slave to get a good idea of the decryption process and proceeded to try and implement it onto the ADF.

Well, the decryption works and I can get as far as the title card before the screen suddenly glitches and the game dies after it finishes decrypting the last bit of data. Having debugged a lot, it appears to have decrypted it all just fine, but somehow part of the data much later on isn't 'right' somehow. I looked back at the slave over and over and can't see what I may have missed in the process. The bootcrack for Stunt Track Racer is a lot simpler and doesn't involve absolute Dx values, but I have no clue how they did it to begin with and can't think of how to convert it to make it work with Car.

Anyhow, it's in the Zone so anyone with the knowhow can bop me on the head and tell me what sort of silly mistake I've made this time.

[Codetapper]

Firstly, copying the disassembled slave source into your own version is hardly what I'd call cracking the game!

I've only had a 1 minute look but as a guess, I'd say you have forgotten that a DBF loop operates until the WORD in d0 becomes false, not the longword. The game will be copying $8ef8+1 longwords, not $18ef8+1 longwords. Therefore, most of the game is not decrypted and relocated into the correct place.

000000EC 203c 0001 8ef8           MOVE.L #$00018ef8,D0
000000F2 22d8                     MOVE.L (A0)+,(A1)+
000000F4 51c8 fffc                DBF .W D0,#$fffc == $000000F2

Change the DBF to a CMP.L #0,D0 instead and it'll probably help. I'm 100% sure the WHDLoad patch does not use a DBF loop as it wouldn't work!

But you have more issues to deal with, when the crack patch at $c0 is run, it's assuming A2 is pointing to something useful. When it gets here, the address is garbage:

00000114 4eea 025c                JMP.L (A2, $025c) == $000131b0
...
000131B0 5044                     ADD.W #$00000008,D4
000131B2 3539 4755 5a58           MOVE.W $47555a58,-(A2)
000131B8 5762                     SUB.W #$00000003,-(A2)
000131BA 737f                     ILLEGAL.L
000131BC 807a 7987                OR.W (PC,$7987) == $0001ab45,D0
000131C0 9398                     SUB.L D1,(A0)+
000131C2 9598                     SUB.L D2,(A0)+
000131C4 a3b0                     ILLEGAL.L

You've cocked this crack up pretty badly I'd say!

BTW there is no need to disassemble my WHDLoad slaves. You'd save yourself a tonne of time by asking for the source code - I'd happily send it if you asked first! And this way you'd get all the comments etc...

[MethodGit]

Originally Posted by Codetapper

Firstly, copying the disassembled slave source into your own version is hardly what I'd call cracking the game!

True, but I'm hoping in a way that it'll help me learn how the decrypting routine works so that I may implement similar code in any game that's similarly protected (though to date I can only think of this, STR and Rick Dangerous...).

I've only had a 1 minute look but as a guess, I'd say you have forgotten that a DBF loop operates until the WORD in d0 becomes false, not the longword. The game will be copying $8ef8+1 longwords, not $18ef8+1 longwords. Therefore, most of the game is not decrypted and relocated into the correct place.

000000EC 203c 0001 8ef8           MOVE.L #$00018ef8,D0
000000F2 22d8                     MOVE.L (A0)+,(A1)+
000000F4 51c8 fffc                DBF .W D0,#$fffc == $000000F2

Change the DBF to a CMP.L #0,D0 instead and it'll probably help. I'm 100% sure the WHDLoad patch does not use a DBF loop as it wouldn't work!

Well there's my problem! I was unaware that DBF came with a limitation and that it can't always be used as a substitute for a SUBQ/BNE or CMP/BNE pairing. I believe it's not in the slave either, just me trying to change it here and there in my personal quest to "optimize" crack code as much as possible (as well as make it a lot less like I just copy/pasted everything 1:1 and actually made the effort to watch the code in action to see how it handles every step). Sure enough, I just replaced it with a SUBQ.L/BNE and it decrypts marvellously now. The fix seemed to break the location setting for my crack for the third copylock however so that needed adjusting too.

(Out of interest: does a longword version of DBF exist?)

But you have more issues to deal with, when the crack patch at $c0 is run, it's assuming A2 is pointing to something useful. When it gets here, the address is garbage:

00000114 4eea 025c                JMP.L (A2, $025c) == $000131b0
...
000131B0 5044                     ADD.W #$00000008,D4
000131B2 3539 4755 5a58           MOVE.W $47555a58,-(A2)
000131B8 5762                     SUB.W #$00000003,-(A2)
000131BA 737f                     ILLEGAL.L
000131BC 807a 7987                OR.W (PC,$7987) == $0001ab45,D0
000131C0 9398                     SUB.L D1,(A0)+
000131C2 9598                     SUB.L D2,(A0)+
000131C4 a3b0                     ILLEGAL.L

You've cocked this crack up pretty badly I'd say!

Derp. Memo to self: when taking advantage of Ax values, make sure they remain consistent across every configuration possible (and don't be fooled by the lack of Cxxxxx memory usage)! What worked under a bog-standard A500 setting doesn't work so well under an A600 or anything else for that matter. If I want to keep using A2, I can just toss in a MOVEA.L A1,A2 after setting E700 as A1's location. But yeah, I'm ready to admit to a cock-up when I see one.

BTW there is no need to disassemble my WHDLoad slaves. You'd save yourself a tonne of time by asking for the source code - I'd happily send it if you asked first! And this way you'd get all the comments etc...

Really? I was always under the assumption that I had no real right to ask for the source to a slave if it wasn't made publically available to begin with. I'm sure you don't include sources in your installs for a reason after all.

Besides, it's not really that difficult for me to disassemble a slave - just copy it to a disk, fire up ARIII, load file to memory and gradually skim through the code looking for anything that looks like patching protection checks (or in this case manually decrypting protected data). Thank you for the offer however.

[Galahad/FLT]

Originally Posted by MethodGit

True, but I'm hoping in a way that it'll help me learn how the decrypting routine works so that I may implement similar code in any game that's similarly protected (though to date I can only think of this, STR and Rick Dangerous...).

Well there's my problem! I was unaware that DBF came with a limitation and that it can't always be used as a substitute for a SUBQ/BNE or CMP/BNE pairing. I believe it's not in the slave either, just me trying to change it here and there in my personal quest to "optimize" crack code as much as possible (as well as make it a lot less like I just copy/pasted everything 1:1 and actually made the effort to watch the code in action to see how it handles every step). Sure enough, I just replaced it with a SUBQ.L/BNE and it decrypts marvellously now. The fix seemed to break the location setting for my crack for the third copylock however so that needed adjusting too.

(Out of interest: does a longword version of DBF exist?)

Derp. Memo to self: when taking advantage of Ax values, make sure they remain consistent across every configuration possible (and don't be fooled by the lack of Cxxxxx memory usage)! What worked under a bog-standard A500 setting doesn't work so well under an A600 or anything else for that matter. If I want to keep using A2, I can just toss in a MOVEA.L A1,A2 after setting E700 as A1's location. But yeah, I'm ready to admit to a cock-up when I see one.

Really? I was always under the assumption that I had no real right to ask for the source to a slave if it wasn't made publically available to begin with. I'm sure you don't include sources in your installs for a reason after all.

Besides, it's not really that difficult for me to disassemble a slave - just copy it to a disk, fire up ARIII, load file to memory and gradually skim through the code looking for anything that looks like patching protection checks (or in this case manually decrypting protected data). Thank you for the offer however.

You say its not difficult to disassemble the slave, and yet you got it wrong.

Skimming through code is never a good idea lest you miss stuff out,

Stunt Car Racer is especially a simple to follow crack as well, I'm not sure you can bugger it up with the slave to help you.

Remind us about PM3 Deluxe again?

[StingRay]

Originally Posted by MethodGit

I believe it's not in the slave either, just me trying to change it here and there in my personal quest to "optimize" crack code as much as possible (as well as make it a lot less like I just copy/pasted everything 1:1 and actually made the effort to watch the code in action to see how it handles every step).

That one surely made my day. I checked your bootblock code and the core stuff looks pretty much carbon copied from the WHDLoad slave!
Also, before even attempting to size optimise code you REALLY should gain knowledge about the 68k instruction set as otherwise it doesn't make sense at all. Why you are obsessed with size optimising crack patches is something I don't really understand anyway, a crack has to work, no matter how large or small it is.

Originally Posted by MethodGit

(Out of interest: does a longword version of DBF exist?)

No.

Edit: Galahad posted at the same time.

[MethodGit]

Originally Posted by Galahad/FLT

You say its not difficult to disassemble the slave, and yet you got it wrong.

Only by one instruction. And the A2 stuff was my (botched) idea of trying something completely different.

Remind us about PM3 Deluxe again?

That reminds me, check out the PM3 Deluxe crack disk I just zoned and tell me in what way that crack violates any one of the checksums.

[Codetapper]

Originally Posted by MethodGit

Well there's my problem! I was unaware that DBF came with a limitation and that it can't always be used as a substitute for a SUBQ/BNE or CMP/BNE pairing. I believe it's not in the slave either, just me trying to change it here and there in my personal quest to "optimize" crack code as much as possible (as well as make it a lot less like I just copy/pasted everything 1:1 and actually made the effort to watch the code in action to see how it handles every step).

Sounds more like you're trying to hide the fact you've directly copied the code from someone else...

Sure enough, I just replaced it with a SUBQ.L/BNE and it decrypts marvellously now. The fix seemed to break the location setting for my crack for the third copylock however so that needed adjusting too.

I don't believe that for a second. Altering a DBF d0,xxx into a SUBQ #1,d0 and CMP.L would not alter the "location setting for my crack for the 3rd copylock" is simply jibberish.

Derp. Memo to self: when taking advantage of Ax values, make sure they remain consistent across every configuration possible (and don't be fooled by the lack of Cxxxxx memory usage)! What worked under a bog-standard A500 setting doesn't work so well under an A600 or anything else for that matter. If I want to keep using A2, I can just toss in a MOVEA.L A1,A2 after setting E700 as A1's location. But yeah, I'm ready to admit to a cock-up when I see one.

This is more nonsense. If you had the original source, you'd have seen my routine does a few things for the trainer, patches the game, sets the stack to fast memory and does a jmp $e700 at the end of it.

In the slave, a2 always points to the WHDLoad base, and you have clearly copied the wrong bit of code, assuming that started the game. JMP ($25c,a2) is probably calling resload_Patch and you've thought that is how I started the game! The real code is jmp $e700. Clear as day!

There is no way your "standard A500 setting" would work yet not on "an A600 or anything else". It simply would not work on ANYTHING.

Besides, it's not really that difficult for me to disassemble a slave - just copy it to a disk, fire up ARIII, load file to memory and gradually skim through the code looking for anything that looks like patching protection checks (or in this case manually decrypting protected data). Thank you for the offer however.

That seems to be the most long winded, inefficient and error prone way to disassemble something. If you knew how to use Resource, you'd have all the code you need and in a saveable format. The slave is about 1300 bytes, and you are "skimming through memory looking for patching protection" - WTF?

[TCD]

[MethodGit]

Originally Posted by Codetapper

Sounds more like you're trying to hide the fact you've directly copied the code from someone else...

Except I never denied the fact. What I was trying to say is that there's a difference between lazily copying a crack from one source to another and calling it a day, and copying a crack from one source to another, testing it out, analyzing the instructions to understand them, and seeing for oneself if it can be optimized any further than that. This is only for my private learning interest anyway, I don't intend on hawking it around the scene and boasting it was all my work when it clearly wasn't.

I don't believe that for a second. Altering a DBF d0,xxx into a SUBQ #1,d0 and CMP.L would not alter the "location setting for my crack for the 3rd copylock" is simply jibberish.

Let me explain it better. This bit on the 'bad' disk...

000000F8 41f9 0005 d58c           LEA #$0005d58c,A0

...was meant to point A0 to the start of the third and final copylock that comes between decryption and the main menu. This worked when the DBF was involved. But upon replacing the DBF, the game code was relocated to a different spot and the above instruction was no longer pointing to the copylock. Hence I had to change it accordingly (to $5c8f0 to be precise). That make any sense?

In the slave, a2 always points to the WHDLoad base, and you have clearly copied the wrong bit of code, assuming that started the game. JMP ($25c,a2) is probably calling resload_Patch and you've thought that is how I started the game! The real code is jmp $e700. Clear as day!

There is no way your "standard A500 setting" would work yet not on "an A600 or anything else". It simply would not work on ANYTHING.

Again, I'm aware that JMP $E700 is the correct thing to do. I even did another version of my crack disk which doesn't touch A2 or any other Ax towards the end. All I was doing was seeing if I could be clever and try to reach the same locations through the Ax values and lop some bytes off. The attempt on the disk failed because I didn't take to heart that the values would differentiate on each setup. And again I must stress, this stuff was purely to entertain myself a bit with some experimenting.

[TCD]

Originally Posted by MethodGit

All I was doing was seeing if I could be clever...

This just made my day.

[BippyM]

What is your obsession with cracking??

[MethodGit]

Originally Posted by TCD

This just made my day.

And this is why I should learn to save my breath more and just not bother saying anything in future. I didn't register on here to "make people's days".

[StingRay]

Originally Posted by MethodGit

That reminds me, check out the PM3 Deluxe crack disk I just zoned and tell me in what way that crack violates any one of the checksums.

WTF! Really. I mean, what the freaking fuck?

[Galahad/FLT]

Originally Posted by StingRay

WTF! Really. I mean, what the freaking fuck?

^ what he said, eloquent as well

[TCD]

Originally Posted by MethodGit

And this is why I should learn to save my breath more and just not bother saying anything in future. I didn't register on here to "make people's days".

I think as long as you deliberately ignore the advise of people that know better you'll never stop doing that

Honestly, you show up here every 6 months to get your good amount of bashing and that's it. Maybe you can explain me why you do it one day.