Smallest possible replacement loader for Twiddy games?

[MethodGit]

I was recently looking at those titles which use John Twiddy's loader system - First Samurai, Global Gladiators, Cool Spot and Aladdin - and got to understand it a *little* bit better.

I mean first off, Prodigy obviously found a simple way to get around the booting issue by patching a single value, but with mixed results. F.S. (not cracked by Prodigy) and G.G. seem to benefit from a tiny patch like this, or at least there've been no reported issues of this affecting disk-loading routines to the point of making the game uncompleteable. However, as was already mentioned on here before, attempting this with Cool Spot will make everything seem okay at first, but then once you insert Disk 3, you come a cropper as it bombs back out to Kickstart. I'm willing to bet that the game was expected to ask you to swap disks again, but couldn't work out when to stop loading, so kept on going until it keeled over. They also cracked Aladdin, but it appears (from combing over the disk in a hex-editor) that they actually replaced the loader in that one (so maybe a different member of Prodigy worked on this one ), and certainly I attempted to try and crack it at first with the one byte change only for it to fail.

I've been browsing through the loader code in ARIII but have been having a hard time making head nor tail of it - I remember what Galahad said in a previous thread that it was possible to patch Aladdin (or at least the beta)'s loader correctly by branching off into new code to have it search for an exclusive longword existing only on a specific disk (mind you, I'm not quite sure if he did exactly this or replaced the entire loader, or both :S). If it's possible, I'd quite like to do it this way, as one of my personal aims in Amiga cracking is to try and come up with the smallest amount of code possible that results in a 100% cracked game. Since late last year I've been keeping documents of my own findings and compiling a list of hex-replacement notes for easy reminders in future, and have now and again revised my previous crack notes if I came up with anything smaller that didn't drastically affect gameplay. I've looked at some scene cracks in the past and thought how silly it was that they used up excessive amounts of bytes by (for instance) not using shortwords (or whatever values applied with .S are called) in LEA/JMP/MOVE sequences, or replaced a CMP instruction with a MOVE (even though patching the BEQ/BNE alone will affect the outcome anyways), just to give some examples. But I digress.

On a similar note, I've been trying to get my head around the disk-checking system for Street Fighter II as that seems to use a unique way of utilising the copylock (I know that the keys for each disk are stored on a specific part of Disk 1, for one thing, but have found no real way to both satisfy the copylock and ensure the game doesn't load the wrong data. Again, it would really benefit me if it was somehow possible to go by any disk-exclusive longwords and do a CMP on that). I'm hoping (probably against hope, mind you) that one won't absolutely, positively be required at minimum to replace an entire chunk of data just to satisfy what must be a simple disk-check. Am I on cloud cuckooland, or might there be a chance of a nice Diet Patch?

[Hewitson]

I'd be more inclined to think the game was bombing out due to an incorrect checksum or some other anti-cracking measure..

.S = short branch. Can not see any reason why this would use less memory, but I believe it is faster.

[StingRay]

Originally Posted by MethodGit

If it's possible, I'd quite like to do it this way, as one of my personal aims in Amiga cracking is to try and come up with the smallest amount of code possible that results in a 100% cracked game.

With your current knowlegde you won't be able to come up with the shortest possible crack! Why you are so obsessed with that is beyond me anyway.

Originally Posted by MethodGit

I've looked at some scene cracks in the past and thought how silly it was that they used up excessive amounts of bytes by (for instance) not using shortwords (or whatever values applied with .S are called) in LEA/JMP/MOVE sequences, or replaced a CMP instruction with a MOVE (even though patching the BEQ/BNE alone will affect the outcome anyways), just to give some examples. But I digress.

Yes you digress. And as someone who can't even crack the simple loading system of games like Aladdin you shouldn't judge other cracks like you do here.

Originally Posted by Hewitson

I'd be more inclined to think the game was bombing out due to an incorrect checksum or some other anti-cracking measure..

No, it bombs out because the loader wasn't patched correctly. I explained it here.

Originally Posted by Hewitson

.S = short branch. Can not see any reason why this would use less memory, but I believe it is faster.

It uses less memory because the instruction is shorter.

[Hewitson]

How much is saved by using a bne.s rather than a bne.b? I've never bothered looking into it.

[StingRay]

Originally Posted by Hewitson

How much is saved by using a bne.s rather than a bne.b?

Nothing because bne.s is the same as bne.b. I just consider .s the wrong form which is accepted by most assemblers.

When it comes to bne.w vs. bne.b 2 bytes are saved.

[Hewitson]

That's what I thought. Cheers and sorry for derailing the thread

[Codetapper]

Originally Posted by MethodGit

Since late last year I've been keeping documents of my own findings and compiling a list of hex-replacement notes for easy reminders in future, and have now and again revised my previous crack notes if I came up with anything smaller that didn't drastically affect gameplay.

I'm sure many of us would LOVE to see these documents you have been keeping. Is there anything useful in them or are they basically hexadecimal byte changes that one random disk image has to another random crack such as:

Change $6104 to $6004 at location $2468 on the disk

ie. You are not cracking at all but merely duplicating some byte differences that you have noticed from the actual person that cracked the game?

I've looked at some scene cracks in the past and thought how silly it was that they used up excessive amounts of bytes by (for instance) not using shortwords (or whatever values applied with .S are called) in LEA/JMP/MOVE sequences, or replaced a CMP instruction with a MOVE (even though patching the BEQ/BNE alone will affect the outcome anyways), just to give some examples. But I digress.

Well for one thing, let's take an example where a game is asking for a particular page number from the manual. Let's say the answer is 5, and you by luck happen to type in 5.

Those "silly" crackers that changed the compare to a move mean anything typed in will work.

These "elite" crackers such as yourself that change the branch from a beq to a bne mean that in the case where you have typed in the correct code, it will NOT take the branch and bring up a "sorry, wrong page number, try again". So who is the silly one now?

On a similar note, I've been trying to get my head around the disk-checking system for Street Fighter II as that seems to use a unique way of utilising the copylock (I know that the keys for each disk are stored on a specific part of Disk 1, for one thing, but have found no real way to both satisfy the copylock and ensure the game doesn't load the wrong data. Again, it would really benefit me if it was somehow possible to go by any disk-exclusive longwords and do a CMP on that). I'm hoping (probably against hope, mind you) that one won't absolutely, positively be required at minimum to replace an entire chunk of data just to satisfy what must be a simple disk-check. Am I on cloud cuckooland, or might there be a chance of a nice Diet Patch?

Yes you are in cuckooland. Altering a loader is way beyond your ability at the moment.

As I suggested several years ago, you'd be better off trying to write a WHDLoad install for a simple game where you don't have to worry about repacking files, fitting your loader into some unused bit of memory, and you can easily alter the loader to do extra things such as reading a few bytes from a disk image if you really need to check what disk the game is expecting.

But I'm sure you know best and will ignore the suggestion again...

[MethodGit]

Originally Posted by Codetapper

I'm sure many of us would LOVE to see these documents you have been keeping. Is there anything useful in them or are they basically hexadecimal byte changes that one random disk image has to another random crack such as:

Change $6104 to $6004 at location $2468 on the disk

ie. You are not cracking at all but merely duplicating some byte differences that you have noticed from the actual person that cracked the game?

Hardly like that! I may note down at first where the changes occur so that i can find the original routine in memory a lot quicker, but then I think of my own ways to patch a protection, such as skipping the manual check entirely if nobody else previously did it, or seeing if a game can actually get along fine without being fed an actual copylock key (and I do test games as far as I can). Say what you will, but I've been proud of certain personal achievements of mine regarding certain titles (I cracked Spellbound Dizzy myself when no-one else previously bothered with it!), even if with most of them you'd likely regard the protection as a joke anyway. Considering everyone cracked nearly all of the Amiga's library of games between 15-25 years ago, I was obviously never going to break any ground here, but it was from looking at existing cracks (and reading Flashtro's tutorials of course) that I learnt how it all basically worked, and ultimately inspired me to revisit certain games and play around with their values for interest purposes.

Well for one thing, let's take an example where a game is asking for a particular page number from the manual. Let's say the answer is 5, and you by luck happen to type in 5.

Those "silly" crackers that changed the compare to a move mean anything typed in will work.

These "elite" crackers such as yourself that change the branch from a beq to a bne mean that in the case where you have typed in the correct code, it will NOT take the branch and bring up a "sorry, wrong page number, try again". So who is the silly one now?

First off, I never called the crackers "silly", neither have I *ever* considered myself "elite" (versus you guys in a cracking competition? No contest!). Also, I didn't mean I'd change the BEQ to a BNE or vice versa. If it was a manual check deciding the outcome with a BNE, i'd NOP it out or clear it entirely.

Yes you are in cuckooland. Altering a loader is way beyond your ability at the moment.

As I suggested several years ago, you'd be better off trying to write a WHDLoad install for a simple game where you don't have to worry about repacking files, fitting your loader into some unused bit of memory, and you can easily alter the loader to do extra things such as reading a few bytes from a disk image if you really need to check what disk the game is expecting.

But I'm sure you know best and will ignore the suggestion again...

And I'm pretty sure I said that taking up WHDLoad programming would require me to spend years consulting actual programming books and understand a lot more of the Amiga's technicalities than I currently do. I've never imagined myself as a serious expert on these things and feel I wouldn't really be able to find the time nowadays. You guys have been doing this for years and certainly know untold amounts about many games and the architecture inside out. I only took up basic memory-editing and cracking late last year as a little hobby of mine. It was only in hindsight from learning about dynamic values and their long reach, and the aforementioned .S for addresses, that i personally considered a small amount of cracks (and I do mean *small*) to be a bit silly in terms of how much memory they consumed. If I've come across in the past as a tad snidey, then I never meant that and I do apologise.

[Codetapper]

Originally Posted by MethodGit

And I'm pretty sure I said that taking up WHDLoad programming would require me to spend years consulting actual programming books and understand a lot more of the Amiga's technicalities than I currently do.

I disagree entirely. I think it's far easier to get a game loading from hard drive using WHDLoad than you think. There's tonnes of example source code out there in the development package. The snoop bug-fixes and high score savers etc take longer to patch than the game in many cases.

At the heart of it, all you are doing is ripping a disk image of the game, and replacing a built in loader with the WHDLoad equivalent routine. You should try installing a very simple game rather than assuming it takes years of consulting books. You'd learn a lot more about cracking I guarantee as at the end of it you have a (usually tiny) file of the patches needed to crack and install the game.

[8bitbubsy]

Originally Posted by MethodGit

And I'm pretty sure I said that taking up WHDLoad programming would require me to spend years consulting actual programming books and understand a lot more of the Amiga's technicalities than I currently do.

You're implying that you don't know 68k asm fully, and that you need to know more about the Amiga hardware programming wise -- how come you try to crack games on the Amiga? You might end up cracking the easier ones and enjoy it, but where's the challenge and knowledge in that?
Besides, making WHDLoad slaves would actually be contributing to the existing Amiga society.
You don't really learn enough from experimenting with low-level cracking and reading no books/get no wider knowledge of the machine and its structure.




Hi StingRay, how are you?

[h0ffman]

Yawn

[8bitbubsy]

Originally Posted by h0ffman

Yawn

Sorry, I didn't talk to you.