dlevere's GameShark and Action Replay codes

[dlevere]

Check this post out, I put up 3 tutorials on how to hack Moon Jump codes.

[47iscool]

Check this post out, I put up 3 tutorials on how to hack Moon Jump codes.

I did, best I could make was that same code.

Gabe standing still on ground: FFFF
Gabe jumping up to grab onto object: 0001
Freeze the 0001 and he keeps going up, problem is it changes the address once you exit the level or die. The moon jump code that was made for SF2 has a problem, well at least on emulators. You must hold the button combo while you get into the level and after all the objects start to go up even if you release the combo they keep going up. I was able to follow that pattern for SF1 and port the code from 2. Problem is it has the same problem on both games. My code only makes Gabe levitate and not the others.

[dlevere]

That would be an extremely difficult code to hack. I haven't talked to Szalay in years. Maybe I can track him down and ask him about this...It may take a few days, though.

[Abystus]

I'm not THAT advanced like some of you are.

No better time to learn than the present (since things are slow lately around here). BTW, ASM would fix your current problem ("Freeze the 0001 and he keeps going up, problem is it changes the address once you exit the level or die. ").

Summary:

Once you have a grasp on MIPS (ASM), you will want to find the character structure. Within that structure there will be an identifying characteristic that makes it unique to all other characters. Using this in combination with an assembly hack in the area that your value is read (the memory address changes, but the ASM that reads that memory location does not since it is a pointer to the value no matter where it moves to) will allow you to make your code work on any level in the game as long as the same routine is used in ASM. Most of the time routines are shared between all players or objects that use it, thus finding the unique identifier in the player/object structure will be the key to fixing your issues.

Example:

Character Base Addresses (Not Static):

Jim:   80015000
John:  80016000
Mary:  80017000

Character Structure Offsets (Static):

Offset   Jim    John    Mary

0x00     [COLOR="#0000FF"][B]0x00   0x01    0x02[/B][/COLOR]     <- Character Index
0x02     0x64   0x52    0x64     <- Character Health
0x04     0x35   0x64    0x10     <- Character Mana
0x06     0x02   0x04    0x04     <- Character Status
...      ...    ...     ...      <- (Etc)
...      ...    ...     ...      <- (Etc)
...      ...    ...     ...      <- (Etc)

Now the key is to use the register that is referencing the non static address to your advantage in a custom routine. Your custom routine will be located elsewhere in memory, and will use the register + or - an amount to get to the "Character Index" of each character using the routine, and then compare that to a static value. So the idea would be as follows (using c# as an example for clarity):

Custom Routine:

if (ReadByte(register+0x00) == 0x01)  //Test to see if this is John (01)
{
    //If so, do your code here.
    return; //Return to hook location
}
else
{
    //Otherwise, do the original code here.
    return; //Return to hook location
}

Then in the location where the original code is executed that your wanting to modify, you will change that code to jump to your new custom routine. Where the "Otherwise, do the original code here." section is you will recreate the original code you replaced with the jump so that characters outside the one you define to be different will function correctly. To trigger the call to your custom routine, you can use a joker to toggle the original code to be either the jump to your custom routine, or back to original code on button release. This should cause your character (John in this example) to rise when holding the button, and then to fall when you release the button.

The whole point of all of this is to get around non static memory like the kind your dealing with, along with creating a custom routine to handle just your character instead of all of them in-case of a shared routine (90% of the time it will be). There may be an easier way with all these newfangled cheat devices, but this would be my initial strategy without any prior knowledge of what these newer cheat devices can achieve on their own. I know it may be confusing to you at first, but once you understand how the code works, it will be the only type of modification (ASM) you will want to use going forward. If you have questions let me know.

[47iscool]

Well I'm not a programmer, I look for patterns and I know very little about the PSX. I know what ASM is but like I said I'm not a programmer and I'm not an advanced hacker. Basically I look at values as to what they do in other games, I'll explain: One night I was searching through codes in the GameShark V5 and I looked for codes that do similar things such as stop timer, inf ammo and health doesn't decrease when hit. Even though the codes are for different game the one thing they all have in common is the value 2400. So after playing with Fceux's debugger I decided to see what a "breakpoint" was. And I soon found out that in this case the address 0736 in SMB3 is Mario's lives address. With that I copy and pasted that code into the debugger and selected "write" then the emulators pauses and I quickly figured out that the address that came in the debugger is what was subtracting Mario's lives and I decided to try different values until Mario dies but the lives counter doesn't decrease.

When it comes to Syphon Filter I tried setting a write breakpoint on that code but the debugger never snapped, I think this this address is in the r5900 CPU and every time I try to bring up the debugger for the r5900 or the vu's the emulator freezes. Maybe r5900 debugging was disabled in the version and when it comes to MESS, well I never could get it to work/load a game.

I'm using PSX 1.13's debugger.

[Abystus]

I've personally never used the emulator your using, so I'm unsure on why your breakpoint for write didn't break. I'm using MESS (a bit complicated initially to setup, but very hacker friendly once you do), so I may download this game to see if I can get it to break properly, and possibly help you along (if I get some free time that is, my time is usually devoted to watching my kid). In the meantime, I would look up the MIPs instruction set, and get familiar with the registers, and basic instructions like (LUI, MOV, CMP, Branch Types, Jump types, etc... Seems you are already familiar with a short NOP (2400 - addiu zero, zero), but just so you know the actual NOP instruction is 00000000 (2400 is a trick to cancel all 32 bits with a 16 bit opcode that nullifies the next 16 bits after it, thus allowing you to use one code instead of two to cancel an entire instruction). Programming knowledge would definitely help you out, though It's not required if you can grasp the concept of code logic/flow.

[47iscool]

I've personally never used the emulator your using, so I'm unsure on why your breakpoint for write didn't break. I'm using MESS (a bit complicated initially to setup, but very hacker friendly once you do), so I may download this game to see if I can get it to break properly, and possibly help you along (if I get some free time that is, my time is usually devoted to watching my kid). In the meantime, I would look up the MIPs instruction set, and get familiar with the registers, and basic instructions like (LUI, MOV, CMP, Branch Types, Jump types, etc... Seems you are already familiar with a short NOP (2400 - addiu zero, zero), but just so you know the actual NOP instruction is 00000000 (2400 is a trick to cancel all 32 bits with a 16 bit opcode that nullifies the next 16 bits after it, thus allowing you to use one code instead of two to cancel an entire instruction). Programming knowledge would definitely help you out, though It's not required if you can grasp the concept of code logic/flow.

I'd really appreciate that if you could, thank you very much.

Another code, except this one's for SF2, same thing though it disables after death or level change.

Moon Jump Level One Up+Triangle (SF2)
D0122FF0 1010
8019775E 0001

[47iscool]

Found something for SF2, set a breakpoint on the address that raises Gabe into the air, take a look

[dlevere]

In the meantime, I would look up the MIPs instruction set, and get familiar with the registers, and basic instructions like (LUI, MOV, CMP, Branch Types, Jump types, etc...

Full MIPS Assembly Commands by Blueman

[47iscool]

Full MIPS Assembly Commands by Blueman

That's pretty complicated, not sure what they all mean, I only know a few values. Really wish I'd have studied programming now...

[Abystus]

That's pretty complicated, not sure what they all mean, I only know a few values. Really wish I'd have studied programming now...

Well try using the short NOP to make some ASM based codes. You need to make yourself familiar with your tools (the debugger, memory editor, and trace feature if present) to make this as easy as possible, along with being able to understand what is happening as code is executed. By no means do you have to understand everything that is happening, only the section you care about. Everyone starts somewhere, and when moving to a new ASM type, I like to start with NOP (No Operation) as it is a pretty common instruction across many different types of ASM (though in this case 2400 is a better NOP than the actual NOP instruction).

Infinite Time Example:

1. Find the address controlling the timer value in the game.
2. Set a breakpoint for write on the timer address.
3. Your debugger should snap the next time the timer changes, and may be sitting on the code writing to the timer value or just below it.
4. Use a short NOP (2400) to cancel the line writing to the timer (or the line with the SUB opcode if you see it).
5. Disable your breakpoint, and test (in multiple areas the timer exists) to make sure it stopped the timer.

A neat trick you can do to test your newly found skill would be to make the timer run in reverse. This is usually very easy to accomplish in ASM, and probably only requires you change the SUB, to and ADD (you can usually see the values for these opcodes within the debugger by looking around while the game is halted) in most cases. Try the above on a few different games, learn the debugger functions for Step, Step Into, Step Over, Run, Run Till Return (some of these may not exist in yours), and just get an overall feel for what your doing while the game is halted by a breakpoint. After playing with it for a bit, you will understand what the code is doing (by watching the registers) as it executes (Step Into after initializing a break).

[47iscool]

Well try using the short NOP to make some ASM based codes. You need to make yourself familiar with your tools (the debugger, memory editor, and trace feature if present) to make this as easy as possible, along with being able to understand what is happening as code is executed. By no means do you have to understand everything that is happening, only the section you care about. Everyone starts somewhere, and when moving to a new ASM type, I like to start with NOP (No Operation) as it is a pretty common instruction across many different types of ASM (though in this case 2400 is a better NOP than the actual NOP instruction).

Infinite Time Example:

1. Find the address controlling the timer value in the game.
2. Set a breakpoint for write on the timer address.
3. Your debugger should snap the next time the timer changes, and may be sitting on the code writing to the timer value or just below it.
4. Use a short NOP (2400) to cancel the line writing to the timer (or the line with the SUB opcode if you see it).
5. Disable your breakpoint, and test (in multiple areas the timer exists) to make sure it stopped the timer.

A neat trick you can do to test your newly found skill would be to make the timer run in reverse. This is usually very easy to accomplish in ASM, and probably only requires you change the SUB, to and ADD (you can usually see the values for these opcodes within the debugger by looking around while the game is halted) in most cases. Try the above on a few different games, learn the debugger functions for Step, Step Into, Step Over, Run, Run Till Return (some of these may not exist in yours), and just get an overall feel for what your doing while the game is halted by a breakpoint. After playing with it for a bit, you will understand what the code is doing (by watching the registers) as it executes (Step Into after initializing a break).

I'll give it another go and see what happens.

[Hybrid]

oohhh.... stuff i'll never be able to do :P with using just a gspro
abystus can you post some code showing examples of these opcodes like with the timer stuff
so us lacking emulators will be able to see.

[47iscool]

Finally got a write BP for SF1, seems the code is a 32 bit code. Not sure what those lines mean but it looks like a pattern. What do you make of it?

[Abystus]

oohhh.... stuff i'll never be able to do :P with using just a gspro
abystus can you post some code showing examples of these opcodes like with the timer stuff
so us lacking emulators will be able to see.

Example: Mortal Kombat 3 (World) PSX - Disable/Reverse Timer

Timer Address (Second Digit):
801EECD0

We set a breakpoint for write on this address.

Timer Normal:

addiu v0,v0,-$1      <- Add -1 to register v0 (subtraction)
lui   at, $801F      <- Load register at with $801F0000 (LUI = Load upper 16 bits of the 32 bit register)
sh    v0, -1330(at)  <- Store v0 to register at - 1330 address (801F0000 - 1330 = Timer Address: 801EECD0)

The game adds a negative number (-1) to register v0 that is holding the current value, and then stores the register v0 value to the timer address.

Timer Disabled:

GS Code: 80021AD2 2400

addiu zero,zero,-$1  <- Use short NOP to cancel instruction, and prevent the value from being decreased.
lui   at, $801F      <- Load register at with $801F0000 (LUI = Load upper 16 bits of the 32 bit register)
sh    v0, -1330(at)  <- Store v0 to register at - 1330 address (801F0000 - 1330 = Timer Address: 801EECD0)

Our modification stops the value from being decreased by cancelling the instruction with a short NOP.  The last used value will be stored forever since it cannot be decreased.  You could have alternatively done the same thing to the Store address (80021ADA 2400) to achieve the same effect (though the debugger no longer breaks on that modification due to the address no longer being written to).

Timer Reversed:

GS Code: 80021AD0 0001

addiu v0,v0, $1      <- Add 1 to register v0 (addition)
lui   at, $801F      <- Load register at with $801F0000 (LUI = Load upper 16 bits of the 32 bit register)
sh    v0, -1330(at)  <- Store v0 to register at - 1330 address (801F0000 - 1330 = Timer Address: 801EECD0)

Our modification changes the -1 (FFFF) to a 1 (0001).  This in turn makes the timer count up instead of down.

Most games that split the digits into 2 bytes are not designed to handle reversed timers (like this game), so unless you make other modifications it won't correctly increment the first digit (they are designed to decrease the first digit when the second digit reaches 0, but will eventually round robin once it passes 255). Games that store the value all in 1 byte will work perfectly with this method. The concepts covered in this tutorial can apply to anything else that follows a similar pattern like lives, health, money, etc... This is just practice material to get you (47iscool) familiar with instructions, modifications, and how the debugger works.

Dlevere, sorry about taking over your thread with this tutorial. If you need me to move it let me know, and I'll create some sort of tutorial page or just include it into my own thread.