English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 12 July 2011, 05:52   #1
MethodGit
Junior Member
MethodGit's Avatar
 
Join Date: Dec 2002
Location: The Streets
Age: 34
Posts: 2,729
Smallest possible replacement loader for Twiddy games?

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?
MethodGit is offline  
Old 12 July 2011, 09:48   #2
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 36
Posts: 2,618
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.
Hewitson is offline  
Old 12 July 2011, 10:33   #3
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,146
Quote:
Originally Posted by MethodGit View Post
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.

Quote:
Originally Posted by MethodGit View Post
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.


Quote:
Originally Posted by Hewitson View Post
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.

Quote:
Originally Posted by Hewitson View Post
.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.
StingRay is offline  
Old 12 July 2011, 11:38   #4
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 36
Posts: 2,618
How much is saved by using a bne.s rather than a bne.b? I've never bothered looking into it.
Hewitson is offline  
Old 12 July 2011, 11:43   #5
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,146
Quote:
Originally Posted by Hewitson View Post
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.
StingRay is offline  
Old 12 July 2011, 12:26   #6
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 36
Posts: 2,618
That's what I thought. Cheers and sorry for derailing the thread
Hewitson is offline  
Old 12 July 2011, 13:08   #7
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,147
Floppy disk

Quote:
Originally Posted by MethodGit View Post
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?

Quote:
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?

Quote:
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...
Codetapper is offline  
Old 12 July 2011, 14:21   #8
MethodGit
Junior Member
MethodGit's Avatar
 
Join Date: Dec 2002
Location: The Streets
Age: 34
Posts: 2,729
Quote:
Originally Posted by Codetapper View Post
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.


Quote:
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.

Quote:
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.
MethodGit is offline  
Old 12 July 2011, 22:03   #9
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,147
Quote:
Originally Posted by MethodGit View Post
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.
Codetapper is offline  
Old 15 July 2011, 04:32   #10
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Posts: 1,283
Quote:
Originally Posted by MethodGit View Post
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?

Last edited by 8bitbubsy; 15 July 2011 at 04:38.
8bitbubsy is offline  
Old 15 July 2011, 09:20   #11
h0ffman
Registered User
 
Join Date: Aug 2008
Location: Salisbury
Posts: 469
Yawn
h0ffman is offline  
Old 16 July 2011, 02:55   #12
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Posts: 1,283
Quote:
Originally Posted by h0ffman View Post
Yawn
Sorry, I didn't talk to you.
8bitbubsy is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
HD loader example st! Coders. General 4 16 October 2012 22:56
Hardware File Loader h0ffman Coders. General 9 02 December 2010 17:40
HELP........with getting winuae loader to work. mrbailey1890 support.WinUAE 3 09 July 2009 00:47
Smallest hendheld N64 in the world? Shoonay Retrogaming General Discussion 2 29 December 2008 23:13
IFF Loader v1.0.0 is released... :) Steve News 11 17 September 2004 20:10

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:45.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08249 seconds with 15 queries