Game appears to use weird JSR instructions

MethodGit · 08 March 2011, 15:04

In the executable anyway. In memory they resemble more 'normal' instructions.

Basically, I've found a way to skip the protection screen in Valhalla: Before The War and know which JSR to edit in the "BeforeTheWar" exe. Only problem is that it looks something like this:

Code:

4E B9 80 00 45 7A

When the game is loaded in memory, this instruction becomes something more coherent like, say, JSR C11F12. Usually I just subtract the difference in order to get the right address to put in hex so that it ultimately redirects to the routine I want, but if my calculations are correct, my alternative number for this particular one would be in the minus figures! I've tried to alter my calculation many a time but I can't find an ideal number that will actually go to my target address. I'm just wondering what the purpose of that 80 above is. Is it an AMOS thing? (I notice AMOS references in the executable after all).

Lonewolf10 · 08 March 2011, 18:11

Yes, AMOS was used to make the game, or the level data. I can't tell you what the 80 is for without looking at the file itself.
I know that all the extensions used within an AMOS program have to pass the extension number to AMOS (to say everything in this extension is working ok), but valid extension numbers are 1-25(-1).

Regards,
Lonewolf10

MethodGit · 08 March 2011, 18:27

Quote:

Originally Posted by Lonewolf10

Yes, AMOS was used to make the game, or the level data. I can't tell you what the 80 is for without looking at the file itself.

You can grab the exe from the pre-installed archive available at WHDownload.

pmc · 08 March 2011, 21:48

As a total stab in the dark, it isn't a jsr to a minus offset is it...?

The $8000 would make the most significant bit a 1 meaning this could be interpreted as a minus number...

and you often see jsr's to minus offsets, for library calls for example.

Only thing sticking in my mind telling me this guess is wrong is that -$ba86.l should be $ffff457a and not $8000457a

But, errr... well, it's just a punt.

BippyM · 08 March 2011, 23:44

You do know that the amospro compiler can compress the executable when it compiles it, and who knows what the developers did when they wrote it. Is the came encrypted and then decoded into memory??

MethodGit · 09 March 2011, 01:42

Encrypted? Looking at the executable, I highly doubt it. Otherwise things as simple as an "accept any answer" patch wouldn't be so easy to implement.

musashi5150 · 09 March 2011, 08:54

Quote:

Originally Posted by pmc

As a total stab in the dark, it isn't a jsr to a minus offset is it...?

Tut tut...

Think about the differences between bsr & jsr and then go stand in a corner

pmc · 09 March 2011, 09:02

Quote:

Originally Posted by musashi5150

Tut tut...

Think about the differences between bsr & jsr and then go stand in a corner

LOL. In my defence, I literally skim read it and posted a reply.

Like I said - it was a punt!

phx · 09 March 2011, 11:44

Quote:

Originally Posted by MethodGit

Code:

4E B9 80 00 45 7A

When you intend to patch a 32-bit address later, you want to make sure it isn't optimized by the assembler to a 16-bit addressing mode. This could be a reason to set bit 31.

But I would try to find the code, which patches this address, for a better understanding. Or is there even a relocation entry for it?

Lonewolf10 · 12 March 2011, 17:59

Quote:

Originally Posted by MethodGit

4E B9 80 00 45 7A

Well I compiled one of my AMOS programs (MMR) using various options - AMOS compiled, Cli version, no AMOS.Lib squashed & unsquashed, no error messages squashed and unsquashed, long Option on & off.

I searched for the above string and got no hits. I then searched (using Directory Opus) for "4E B9 80 00" and only got hits in the unsquashed versions with no AMOS.library built in to the compiled file.

X - MMR_AMOScompiled
X - MMR_cli
X - MMR_Cli_squashed
/ - MMR_nolib_ERRmsgs
/ - MMR_no_lib_longOpt
/ - MMR_no_lib_noERRmsgs
X - MMR_no_lib_squashed

Which makes sense with what phx said about patching addresses later on, for example after the AMOS.library file has been loaded into memory.

Regards,
Lonewolf10

MethodGit · 15 March 2011, 11:12

Would this mean I'd have to load an external patch file, or find space within the game exe to take over an instruction and redirect it to some patch code (like is possible with some games)?

BippyM · 16 March 2011, 09:40

External patch would be clean. Oh wait whdload.

MethodGit · 17 March 2011, 15:33

Quote:

Originally Posted by bippym

External patch would be clean. Oh wait whdload.

WHDLoad won't help with general hardpatching for floppy *and* hard disk users.

Seriously, if I want to patch a game my way, I'll patch it my way!

BippyM · 17 March 2011, 19:43

I totally understand that but I don't understand why you are re-inventing the wheel?

Hasn't this game already been cracked/hacked??

pmc · 17 March 2011, 20:07

Quote:

Originally Posted by bippym

I totally understand that but I don't understand why you are re-inventing the wheel?

Hasn't this game already been cracked/hacked??

I do see what you're saying bippym but if someone wants to learn how to do something, a good way is to do it from scratch. All the things I've coded have been done by others before but I still learned loads from doing all those routines again for myself.

MethodGit · 18 March 2011, 16:26

Quote:

Originally Posted by bippym

I totally understand that but I don't understand why you are re-inventing the wheel?

Hasn't this game already been cracked/hacked??

As far as I can tell nobody has skipped the protection check entirely, only disabled the "check for correct answer" flag.

08 March 2011, 15:04	#1
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 40 Posts: 2,731	Game appears to use weird JSR instructions In the executable anyway. In memory they resemble more 'normal' instructions. Basically, I've found a way to skip the protection screen in Valhalla: Before The War and know which JSR to edit in the "BeforeTheWar" exe. Only problem is that it looks something like this: Code: 4E B9 80 00 45 7A When the game is loaded in memory, this instruction becomes something more coherent like, say, JSR C11F12. Usually I just subtract the difference in order to get the right address to put in hex so that it ultimately redirects to the routine I want, but if my calculations are correct, my alternative number for this particular one would be in the minus figures! I've tried to alter my calculation many a time but I can't find an ideal number that will actually go to my target address. I'm just wondering what the purpose of that 80 above is. Is it an AMOS thing? (I notice AMOS references in the executable after all).

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
68040 MMU jsr/bsr	Toni Wilen	Coders. General	5	28 April 2010 20:57
Weird instructions	absence	Coders. General	4	12 October 2009 16:54
Weird physics game thing	FromWithin	Looking for a game name ?	30	25 November 2008 23:58
Amiga game instructions?	HonoredShadow	support.Games	6	22 October 2005 04:48
Game Instructions	Ricky55	Retrogaming General Discussion	2	06 July 2002 20:10

08 March 2011, 18:11	#2
Lonewolf10 AMOS Extensions Developer Join Date: Jun 2007 Location: near Cambridge, UK Age: 44 Posts: 1,924	Yes, AMOS was used to make the game, or the level data. I can't tell you what the 80 is for without looking at the file itself. I know that all the extensions used within an AMOS program have to pass the extension number to AMOS (to say everything in this extension is working ok), but valid extension numbers are 1-25(-1). Regards, Lonewolf10

08 March 2011, 21:48	#4
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	As a total stab in the dark, it isn't a jsr to a minus offset is it...? The $8000 would make the most significant bit a 1 meaning this could be interpreted as a minus number... and you often see jsr's to minus offsets, for library calls for example. Only thing sticking in my mind telling me this guess is wrong is that -$ba86.l should be $ffff457a and not $8000457a But, errr... well, it's just a punt.

08 March 2011, 23:44	#5
BippyM Global Moderator Join Date: Nov 2001 Location: Derby, UK Age: 48 Posts: 9,355	You do know that the amospro compiler can compress the executable when it compiles it, and who knows what the developers did when they wrote it. Is the came encrypted and then decoded into memory??

09 March 2011, 01:42	#6
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 40 Posts: 2,731	Encrypted? Looking at the executable, I highly doubt it. Otherwise things as simple as an "accept any answer" patch wouldn't be so easy to implement.

15 March 2011, 11:12	#11
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 40 Posts: 2,731	Would this mean I'd have to load an external patch file, or find space within the game exe to take over an instruction and redirect it to some patch code (like is possible with some games)?

16 March 2011, 09:40	#12
BippyM Global Moderator Join Date: Nov 2001 Location: Derby, UK Age: 48 Posts: 9,355	External patch would be clean. Oh wait whdload.

17 March 2011, 19:43	#14
BippyM Global Moderator Join Date: Nov 2001 Location: Derby, UK Age: 48 Posts: 9,355	I totally understand that but I don't understand why you are re-inventing the wheel? Hasn't this game already been cracked/hacked??

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