• Please review our updated Terms and Rules here

Modifying Machine Language Games

J

jeff48356

New Member
Joined
Dec 24, 2007
Messages
7
On a particular game, how do I find the code that controls the number of lives a player gets? I would like to change it to 99 lives, so I can keep playing and explore all the levels.

The games in question are "Shamus" and "Jumpman Junior"


Thanks
 
Hi
This depends on the environment you are running in.
If you can run the code under a debugger, break the
code at the point that it ask for the number of players.
Usually this will be within a subroutine and the return
address will be on the stack. Try to disassemble some
code around the area where one stopped. Look for the
likely entry point to see if the routine saved any other
registers.
This will help in finding the return address on the stack.
The code will most likely be 2 or three levels back on
the stack that cares about the numbers entered.
Work back on the stack and disassemble code until
you find the location that evaluates the returned
string.
The other method is a lot harder. You disassemble
all the code and try to follow the flow of the code.
If it is on a PC, it will most likely use standard BIOS
calls. Look for those that get keyboard input.
Expect to spend several days figuring out the code.
If just begining, this can take weeks but a lot will
be learned.
Dwight
 
Dwight wrote:

...run the code under a debugger, break the code at the point that it ask for
the number of players. Usually this will be within a subroutine and the return
address will be on the stack.

Great technique Dwight!! Please feel free to enlighten us about various methods
one can use to figure out the purpose of these assembly programs (any)...

ziloo
 
Shamus:
Code: 
Unlimited Lives

Load or reset the game, then execute the following BASIC commands before running or restarting the program.

POKE 18486,169
POKE 23558,169

Jumpman Junior:
Code: 
Cheats

Code	Effect
Before running the game, type POKE 9450,173	Infinite lives
 
In general, you can use a tool such as Action Replay which will tag certain memory locations and check if they changed the contents once you lost a life. Generally, it is instructions such as DEC, STA and so on that need to be replaced by "safe" LDA, LDX, sometimes NOP NOP NOP.

What Dwight wrote about stack values unfortunately is mostly bogus when we are discussing Commodore (64) games.
 
carlsson said:
In general, you can use a tool such as Action Replay which will tag certain memory locations and check if they changed the contents once you lost a life. Generally, it is instructions such as DEC, STA and so on that need to be replaced by "safe" LDA, LDX, sometimes NOP NOP NOP.

What Dwight wrote about stack values unfortunately is mostly bogus when we are discussing Commodore (64) games.
Click to expand...

Hi
Could you educate me in how this is bogus?
Dwight
 
All right gentlemen, let's keep it nice and clean, no rabbit punches, hitting below the belt and especially, no ear-biting! Follow my instructions, break clean, and protect yourselves at all times. Now go to your corners, etc, etc...:lightsaber:

--T
 
Sorry, I misread your message as there would be a subroutine that decreases a value and leaves it as a return value on the stack for the main program to pick up. The C64 stack is exactly 256 bytes, large enough to hold return addresses and register contents.

In any case, if you know the expected initial value, it may be a better idea to look for code fragments that hold that value:

LDA #$04 (LDX, LDY) where the game starts with four lives
LDA $NNNN (LDA $NNNN,X etc) where $NNNN holds the number of lives
LDA ($NN),Y etc - not so likely in this case

However as I wrote, automated tools like AR instead look at locations that decrease counters. Generally, if it finds one, you would work backwards from there to change the cheat to increase the number of lives instead of having unlimited ones.
 
Hi
I'll admitt that looking for the locatin that has changed
value will surely find the right variable but little would have
been learned. I was disapointed that someone just posted
the values. It meant that he has not learned anything
other than that he can now play longer without the hastle.
On the other hand, maybe that was all he was looking
for.
I have used similar methods to the one you point to, looking
for the right code. On my Olivetti M20, I was connecting up
a hard drive but needed to change the step rate. I just looked
for code that talked to that port. I took less than a day
to patch it.
I've also found that looking at the previous values on the
stack can be quite informative. On my Poly88, I'd break
into the monitor code, right in the middle of the queary.
Looking at the values there, it is relatively easy to find
the code that cares about the value returned.
I have a C64 but not played enough with it to know
what tools are available for it.
Dwight
 
While I agree, learning would be better; I think it's a bit much for this forum expecting to teach someone how to crack a game within several posts.

Everyone who's posted has the right technique though, you need to run the game under a debugger or on a system that has a built-in monitor (memory editor/disassembler) application. From there you're needing to search memory for the value of interest (converted to hex) so if you had 5 lives you'd search for memory addresses with the value 05. When you die, you'd search for memory addresses with 04 and see which of those used to have 05. Once you find some matches you can goof around and change them to a value you know like 0F for 15 or something (note: choosing a number too high (if the game doesn't support more than 99 lives and you choose FF) it may not work and throw you off).

The other technique is finding the code that runs each time you die and modifying those commands which they mentioned you could remove the assembly decrement command with NOP commands, etc. This of course will depend what architecture you're on to know what assembly command is valid (DEC on x86, 6502 would be DEC, DEX, etc).. then if you're working in a monitor app you'd probably need to instead know the machine language (compiled) opcode instead of the english word.

Anyway, quite a lot to try and teach someone in a small amount of time and I too am not sure what is out there for each architecture.

- John
 
Fortunately, almost every monitor program on the C64 works with mnemonics as well as hexadecimal opcodes.

Another problem arises when it comes to entering those POKEs. For an original game, it probably autostarts after loading. You'd need a reset button and knowing which SYS address to restart it (if possible). For a copied game, it probably is crunched as well and the POKEs only work on uncrunched data. Here does the freezer cartridge come handy again, as you can press a button to freeze the program, enter the POKEs and resume execution with minimal damage to memory contents.
 
You must log in or register to reply here.
Back
Top