Hacking Sequential codes PSX

[Helder]

Like I said before it's either 16bit or 32bit and it can be decreasing or increasing when jumping so you have to try both. I start a search right as I leave the ground then again once I move up slightly, I don't do any searches while coming down from a jump as that's usually different. Once you find the ASM for it you will notice that it affects all characters including enemies, you need to trace back to find the Player's data by looking at the registers but that's up to you to do.

[jin299]

Helder what is the purpose for using the instruction la (Load Address) in asm when trying to find a code with the debugger and what is the difference between loading a value and storing one in mips, because it can be quite difficult to understand the difference between the two?

Also when hacking a code with the debugger, why is it that most of the time all the information you want is usually located near where the first breakpoint occured, but sometimes you have to trace up or down in the the debugger to find where abouts exactly the address for the code you are looking for is?

[Helder]

I have no idea what function or usefulness the LA command does as I've never used it. I have no idea why you keep going back to the simple basics of the ASM which you should know by now, maybe take notes or re-read some pages in this thread seriously.

What's hard about a load instruction? it just read the contents of an address or loads aka inserts the value we chose in a register. A store saves the value or writes it to an address, this seems like a brain buster doesn't it? <--Sarcasm

The info is usually located near a write breakpoint when looking for certain codes, once you're looking for complex codes which like WTW or Hit Anywhere then you will likely have to backtrack alot since these codes require alot of calculations and therefore have subroutines many times.

I don't mind helping you but this is shit we have gone over so many times and if you ask simple questions that at this point in time you should know I won't even bother responding.

[jin299]

The reason why I'm going back to the basics of asm coding man is because when tracing up in the debugger i've finally come to realize that I'm still unsure as to exactly where the correct instruction is located in the debugger, I'm looking for? because the code address location is different in asm from code to code.

I'll give you a quick example of a code i'm trying to find at the moment in asm, you see i have finally figured out whats the point in me learning to hack more advanced asm codes man, if I haven't mastered the simple basic concepts in asm hacking yet, there just no point in moving beyond this point at the moment because of my lack of understanding in certain aspects in the the asm language so I was hoping that someone could put me straight on the issues i'm currently having?

I'm trying to find the character modifier address values for normal Bison in the game Street Fighter Alpha 3 for the Psx through asm hacking by tracing backwards in the debugger, so here's the problem, having already found an instruction that loads the correct values for a character which was a addu instruction, I want to find the same values I have found in asm but by tracing backwards further back in asm.

So first I put a write breakpoint on the character modifier ram address for player 1, then went to the character selection screen in the game, and highlighted Bison which cause the game break on the character modifier address, now here's where the confusion comes in man regarding finding what I want in the debugger. I also tried scrolling up the debugger and testing some load instructions.

The game broke on an branch instruction in the debugger, so I scrolled up to the next instruction just above the branch instruction, which was an store byte instruction, now looking at the memory viewer it said the following [801943E6]=0A, I thought this means that I found the correct address because the viewer pointed to the right address and value, but soon found after some testing that it wasn't the right address I was looking for in the debugger

I thought helder you told me before that when ever you hit a store instruction the debugger to trace up in the debugger a bit until you have found an load instruction that is loading the same value and as the previous store instruction?

[Helder]

Sometimes there are multiple writes to the same address which you sometimes see a break occur 2 times but at different locations. Monster Rancher 2 I did some codes for was like this and after following the various breaks or after the first break just go line by line (F7 I think) to let the game run through the code and you might see it change somewhere else or not.

For me to explain things exactly to your situation I would have to hack the code for the game you're trying to hack and then explain why this or that is occurring but what I told you is just the guidelines of what USUALLY happens it doesn't mean it will always happen. Like I have said before but you ignore it is to hack simpler codes and dissect it and learn how the ASM is doing what it does, then once you're familiar with it go ahead and tackle more complex codes like this character mod. Here is the thing I know you won't do that and will pester me with the same questions we have gone over a ton of times instead of learning the ASM with simpler hacks to familiarize yourself with the instructions.

[jin299]

Yeah Helder I know that what you mean man and I know that there are actual rules that I must abide by when hacking in asm. I get that now also I'm slowly beginning to learn that most if not all of asm hacking is based on mathematical calculations, so finding the correct address in the debugger might involve a lot of tracing which can be quite quite time consuming.

But there is something I need to really need to ask you about and hopefully you could give me an honest answer on the issue im having.

I figured out that it would be best to start of learning on how to understand read breakpoints before moving on to learning to read write breaks points, first so I started of my learning by placing a read Breakpoint ? on the character modifier ram address for player 1 in Arcade mode of the game Street Fighter Alpha 3, I then picked Bison at the character modifier selection screen, and the game broke on the read breakpoint i had set on that address, I then scrolled up above the load instruction and came across the load instruction lbu v0, $136 (A1}.

I then took a quick glance at the register tab in the debugger on the the top right hand corner and found that this instruction was loading the character modifier address and the value of Bison's player data, register v0, was loading 0A which is ten in hex and is bison character vlaue in the game, and register a1 was loading the address 801942B0 at the time.

So reading the load instruction above which I know understand that basically all it means in mips is to take the the hex pointer value that's in register a1 which is $136 and load it into the register in v0, which in turn should add up to my character modifier because 801942B0+$136 =801943E6 which was right according to my maths and indeed should have been the correct address for the character modifier in the game so I edited this load instruction by using the command ori v0, zero, $A like you told me to do so many times in the past, ,but found that it was not the correct address, that's was loading the character modifier.

So if that load instruction wasn't the right one, what instruction do I need to look for in the debugger, I'm thinking possibly I should try and find a store instruction of some sort by tracing back further in asm. but I'm not at all sure man?

[Helder]

Well now your mixing things that I've said in the past. You generally trace up or go up some lines when you have a break on write and seldom on read. When you get a break on read there usually isn't anything else affecting the load of the value unless it's some math a few lines up to help determine the value for the pointer used to add to the address that loads your character.

Basically when you do a break on read you don't go up unless it's to alter the pointer values (not always a good idea since many functions could use the pointer) so you kind of do the opposite and that is go line by line to see what is happening AFTER the load/read occurs since it's not writing anything yet. Like I said a few posts above use the F7 key I believe to go line by line and see the changes occurring and try to figure out where things start to write/save and then theorize what changes you plan to make so the code effect is what you want.

I often put a break on instructions that I think are worth observing like conditionals or branches or loads since you will see if the routine with pointer is used by something else or not, generally you just double click an instruction in the Assembly window to do this. All this info and little tricks that I use I learned on my own on what methods work for me so it's time for you to do the same, and again stop messing with this Bison code and mess around with simpler stuff them move on to it later once you have the knowledge to do so.

[jin299]

I don't know man I pretty sure I'm doing everything correctly I just don't know?

[Abystus]

I don't know man I pretty sure I'm doing everything correctly I just don't know?

You need to stop trying to hack the more advanced code types when you have no clue about the code your looking at (telling you this has become redundant). I've watched Helder go round and round with you for 37 pages now, and you're still in the same rut as you were initially. You need to work with simpler code types like infinite types (health, lives, ammo, etc...), reversing object counters (lives, timers, etc..), or anything else of that nature in which you can start to learn from. You're attempting to jump into things that are out of your league, and unless you take time of your own to learn (using the simpler code types), you'll soon find yourself with no one willing to help you out (Helder has been patient with you, but we typically don't enjoy wasting our time teaching when someone doesn't attempt to try and learn things on their own).

If you have a question about something you see in the game code, then walk over it with the debugger and see how registers, flags, and RAM locations are affected or how the code executes. A Google search can give you all the information you need on a particular instruction's operation, and this should become part of your learning routine. If for some reason you cannot seem to find any information on that particular instruction, or have a valid question relating to creating simpler code types (you should be doing these), then please feel free to post here asking for information or guidance.

The best advice for you right now is just to keep messing around in the debugger (breakpoints, stepping through code, watching registers, etc...), and try altering the ASM (proper edits, not random values) to get a feel for what your doing, and how the code actually executes (continually throwing yourself into it will help you grasp the concepts we preach). Once you get to where you understand what is happening (what instructions are doing, how the game is doing what it does), then it will be the time to move up the ladder and tackle more advanced code types (could take a while depending on how fast you learn).

[Helder]

And there you have it in a nutshell! I won't bother with this thread until you have the basics down and are in need of help like Abystus has mentioned above. Put effort into it and learn, it's like you're trying to run when you're still crawling (baby steps first).

[jin299]

Maybe there is something wrong with my debugger then? because here me out.

I put a read breakpoint on the character modifier address in the game Street Fighter Ex2 Plus, picked a character in the game which cause the game to break on that address, went to the load instruction above the first instruction the game broke on in the debugger, it was an load byte unsigned instruction ibu a1, $2 (s2). now give me some credit guys I know what the instruction does it's simply putting the hex value of $2 into the address in s2 which is 801E7FD0 and then loading that hex value into register a1, which makes sense because 801E7FD0 + $2 (Hex} equals to our address 801E7FD2.

So anyway I put a breakpoint on that load instruction I then edited the instruction to ori a1, zero, $1B, which should of load the entire player data of Bison II in the game, but all it did was load the image of bison II at the versus selection screen along with the announcer of the game saying bison II at the character selection screen, but in the actual fight I'm not playing as Bison II instead im playing as the normal character I had chosen before the fight?

This isn't rocket science by any means, what I'm trying to do here but I do know that learning asm isn't an easy task for anyone. regardless of how determined and willing your are to learn it, so can someone please set me straight on what exactly I'm doing wrong here thanks.

[Helder]

Maybe there is something wrong with my debugger then? because here me out.

I put a read breakpoint on the character modifier address in the game Street Fighter Ex2 Plus, picked a character in the game which cause the game to break on that address, went to the load instruction above the first instruction the game broke on in the debugger, it was an load byte unsigned instruction ibu a1, $2 (s2). now give me some credit guys I know what the instruction does it's simply putting the hex value of $2 into the address in s2 which is 801E7FD0 and then loading that hex value into register a1, which makes sense because 801E7FD0 + $2 (Hex} equals to our address 801E7FD2.

So anyway I put a breakpoint on that load instruction I then edited the instruction to ori a1, zero, $1B, which should of load the entire player data of Bison II in the game, but all it did was load the image of bison II at the versus selection screen along with the announcer of the game saying bison II at the character selection screen, but in the actual fight I'm not playing as Bison II instead im playing as the normal character I had chosen before the fight?

This isn't rocket science by any means, what I'm trying to do here but I do know that learning asm isn't an easy task for anyone. regardless of how determined and willing your are to learn it, so can someone please set me straight on what exactly I'm doing wrong here thanks.

You know you're doing it right but this is where experience and know how come into play. I tried repeating your steps and the damn this is pointless with a Read since you're not trying to find out where something is getting loaded from all you want to do is alter the value at the end so a WRITE is the way to go like I have said.

I used your address and using my method of the break on write I got a break and it uses the pointer like your results but I decided to use the somewhat functional tracer in no$psx (I'll explain the settings below and how to do it). Looking at the results I scrolled up in that log and say a few load instructions with one being before a branch conditional and one after it. I decided to try the one before the branch and it had constant breaks with me doing nothing so I decided to go line by line and the branch always followed where as in the trace log it didn't (follow me so far?). So I decided to put a break on the next load and no constant breaks UNLESS I chose a character so bingo we have something to work off of.

Here is the log with my annotations:


80105B78 94620000 lhu v0,$0(v1) ;[801F5220] Load I had constant breaks
80105B7C 00000000 nop
80105B80 304200FA andi v0,$FA ;v0=00000040
80105B84 1040006E beq v0,0,$80105D40 ;v0=00000040 Branch that always occurred unless player chosen
80105B88 3C02801E lui v0,$801E Next Load I set a Break on
80105B8C 24426670 addiu v0,$6670 ;v0=801E0000
80105B90 02221021 addu v0,s1,v0 ;s1=00000000, v0=801E6670
80105B94 90440010 lbu a0,$10(v0) ;[801E6680] This is the actual address that has the character value
80105B98 2402001D addiu v0,0,$1D
80105B9C 14820013 bne a0,v0,$80105BEC ;a0=00000009, v0=0000001D
80105BE8 A0430002 sb v1,$2(v0)
80105BEC 24637FD0 addiu v1,$7FD0 ;v1=801E0000
80105BF0 00111040 sll v0,s1,$1 ;s1=00000000
80105BF4 00511021 addu v0,s1 ;v0=00000000, s1=00000000
80105BF8 00021100 sll v0,$4 ;v0=00000000
80105BFC 00511021 addu v0,s1 ;v0=00000000, s1=00000000
80105C00 00021140 sll v0,$5 ;v0=00000000
80105C04 00511023 subu v0,s1 ;v0=00000000, s1=00000000
80105C08 00021080 sll v0,$2 ;v0=00000000
80105C0C 00431021 addu v0,v1 ;v0=00000000, v1=801E7FD0
80105C10 A0440002 sb a0,$2(v0) ;[801E7FD2], a0=00000009 The Store with the character value



So looking at this snippet we see the 2 ASM instructions in BOLD load the address 801E6670 into register V0 the next line adds a $10 to is so we get 801E6680 and I decided to go have a look there since I believed it to also hold the character value and it did. As a method of using observation you will notice that the Store is using Register a0 and that address above 801E6680 is loading it's value into a0 you can pretty much guess this is the place to look.

So now since you haven't listen to me through a shit load of pages and decided to go into complicated territory on your own I will let you decide on how to proceed with my findings, just remember this routine is used for player 2 so forcing values will edit both characters (VS mode/Practice).

What would I do you might be thinking is to put a break on the address 801E6680 and alter what changes that, but you can do what you like.

[jin299]

Thanks man, this is complex territory I have entered isn't it and being completely honest i had no real idea what i was looking for in the debugger those damn branches are so confusing to get an understanding of where an instruction starts and where it ends in asm so thanks for the breaking down the asm for me into more simple understandable steps i can understand i greatly appreciate it I will study this explanation you have given me, and try and work on easier hacks so that i can dissect what each instruction in asm, is exactly doing in realtime, because it's so easy to get lost when tracing further through the instruction in asm, when you have very little experience with asm.

I have reached the conclusion and fully acknowledge that everyone learns things differently, and learning asm is no exception to this rule, example what method works for you in hacking might not work for me, and that's perfectly okay.

Also I have a quick question to ask you about the trace log, I never knew the no cash debugger had a trace log on it, can i enable this feature on my version of the debugger or did martin only implement this feature on the newer version of the his no cash debuggers.

Now regarding where I currently am in learning asm hacking Im pretty sure man I have already hack basic asm codes already for the game, because I was able to find a timer already for the game using asm hacking to do so, and I also i hacked an infinite health for both players in the game. you see basic asm codes are not really much a problem for me because I have learned that when a value is decreasing in asm you look for a sub instruction of some sort and nop it, or when your looking for infinite codes of any type for a game you aways nop the instruction usually the subu instruction to give you an infinite amount, so knowing this helps a lot when it comes to hacking infinite codes in asm

I learned this and was able to apply this knowledge I learned, from previously reading asm breakpoint tutorials on the Gba and for the Wii console which are available on the internet to read, but what i would love to learn is to how to apply these skills to hacking more advanced codes in asm, like super jump, Hypermode, codes like that, which usually most of the time are a lot more complexed to understand in asm, basically what I'm trying to say Is I would love to learn how to apply these skills to learning new hacks in asm for a game.

[Helder]

I forgot to mention how to use the tracer in the emulator (you need version 1.9), you simply go to the option of the emulator and choose the "Other" Tab and go to the "TTY Debug Message Limit" and choose Overwrite log after 1MB. Then while in game set your breakpoints like normal but before you cause the game to break go to the debugger screen and go to the "Window" tab and look for the TTY Debugger and once it pops up go to File and disable everything except the Log MIPS CPU and keep the window open.

Go back to the game and you will notice it's slow as shit because of the logging going on and once you get a break the log window should show all the ASM up till that point, now go to File in the TTY Debugger window and disable the MIPS logging so it doesn't get overwritten. Now you can see all instructions that occurred till that break and things become easier to find.


Going back to your questions about how to find jump codes and what not all you do is trace back and observe the registers for clues as to where data is being called from and edit it with ram codes. For example this code I found I traced where that value was coming from and actually found the table of the characters and editing that table I can organize and add any character in any order I want. I mentioned tracing back to where games usually store a table with various values and it's often used in RPGs but many games use it and this one did too.

A jump code you trace the value in the register and find out where it's being loaded from and you alter the value at the address with a RAM code, this is how I did the Megaman 8 jump codes.

[jin299]

I think that at the moment all I'm mostly worried about is being able to find and correclty locate ram address values in the debugger but hopefully someday I'll tackle the Megaman 8 super jump asm code when I have gained enough knowledge about what i'm trying to do in asm.

But anyways I was trying to locate the character modifier address for the game Crash Team Racing, I found the code but i had to trace back in the debugger quite a bit till I found it the right instruction I was looking for. The instruction was an load instruction ih v0,$0 V0

Now the tricky thing I've found about trying to find the right instruction is where to find the correct address that's loading the proper value in the debugger to modify in asm.

Helder when trying to pin down exactly where the instruction is in the debugger do you always try and find an load or add or subtract instruction in the debugger example

Example I was trying to load a character called Cortex in the game, so using a write breakpoint to so, so first I placed a write breakpoint on the the character modifier address [80086E84] ! then i went into the a picked my character, and which caused the game to break on that ram address, But I quickly noticed that above the first instruction there was a lw instruction instead of the typical store byte instruction.

So I took a quick glance at the registers and noticed that register v0, and a0, where responsible and loading the the correct values for the character modifier, however the confusing thing about this is register a1, and t0, are both loading the address 80086E84, which is the correct address ram address.

So my question is if register a0, and v0, have the values for the character modifier i'm looking for, should I be looking for an any instruction that's loading a value into register a0, or v0, or should I be looking for an load instruction, that is loading a pointer into the ram address a1 or t0, and then loading that into register a0, or v0?