Wii Asm hacking Mips help

[jin299]

Hello there, I'm currently trying to learn MIPS Assembly language so that I can hack Wii Asm codes.

The problem I'm having is I don't understand how some instructions work in Asm hacking, Like what's the difference between these instructions in Asm, add, ori,stw, lwz and li?

I understand what lwz does but what I don't understand is what's the difference between storing a value stw and loading a value lwz?

Take the instruction lwz. As an example r4,896(r3
I know that what were doing with the instruction is adding 896 hex to register r3 and storing it r4, but what effect does that have on the game?

And what effect would it have on the game if I changed this instruction to Stw instead in the debugger?

Also is r4 the main memory destination in this instruction, like is r4 a register in the memory of a game?

[Pyriel]

The Wii uses a PowerPC CPU doesn't it? I know it's not a MIPS CPU. There is a difference, which you seem to vaguely appreciate, since you're apparently not using PS2Dis, but a proper disassembler.

Registers aren't "memory". They store a value, but not in RAM, etc. Registers are on the CPU (or some processor), and are used to perform almost every operation. If you have 15 stored at location 1 in memory, and 13 at location 5, you typically have to load those values to registers for the CPU to operate on them. Then you perform an add, and then store the value back in memory. Complex instruction set CPUs can let you bypass steps on some instructions, but work is being done for you to allow that to happen.

When you're dealing with assembly, it's extremely low-level. When people you tell you computers just do math, they're really not lying. Computers just do simple things, like adding, multiplying, and so on, very quickly. Millions upon millions of very simple things being done very quickly makes the game happen. So what the operation in your example does could be something very important to you (e.g., loading "Health" to be operated on), or it's just something like loading values that will be used to configure the disc hardware. It's impossible to say based on that operation alone.

[Demonic722]

The Wii uses a PowerPC CPU doesn't it?

Yes.

[Hacc]

The best place to look: http://wiird.l0nk.org/forum/index.ph...dc0&board=24.0

[jin299]

Thanks Hacc That was very helpful, now I should probably clarify that I understand the difference between add and subtract instructions and NOP in asm but what instruction would I use to make an money code in asm for a game say I wanted to give my character an certain amount of money, or say I wanted to load a character from From a character modifier code, I could use the li instruction but I could also use the add instruction as well right to load a character in a game right?

Do li and the add instruction do the same thing in asm, like they both load a value, would that be right to say?

[jin299]

Sorry for double posting.

[Pyriel]

Just like with any toolbox, some tools are useful for exactly one thing, and some tools are Swiss Army knives.

The ADD operation is very often used to load a value, to move a value from one register to another, and even to clear a register, in addition to adding two values together. In some cases, "LI" (load immediate) isn't an actual op code the processor understands, but an assembler macro that is translated into an ADD operation with zero as one of the operands. Even if there is an actual "LI" op code or something similar, there's often nothing to stop you from using an ADD, an OR, or whatever else to accomplish the same thing, if it suits your purpose.

Deciding what to do with a game is situational. If you want to give yourself a fixed amount of money, it's usually best to just use a cheat device to do that, and overwrite the value. If you want to earn double money, you can use a multiply or a left-shift (more likely). You can also force the game to give max money by altering branches or conditional checks, usually changing them so the game executes logic that should only be used if your latest prize gives you more than the maximum amount.

In the case of a character modifier, that's likely to be some sort of immediate load. I can't think of a case where you'd do much of anything with that, except load an explicit value.

[jin299]

Right so say I wanted to load a character in a game could I use the add instruction or the ori instruction to load a character instead of having to use li all the time?

[Pyriel]

What difference does it make? If the situation is right, yes, you could, but I don't see how it matters. And the PowerPC reference I have says that LI is an extended mnemonic for ADDI or ADDIS anyway. That will likely vary according to the assembler/disassembler too. IDA for MIPS will interpret ADDI, ADDIU, ORI, DADDI, DADDIU, as LI if appropriate, and several of those paired with LUI as a single LI instruction. Most of the assemblers I've used will typically translate LI to either ORI or a LUI/ORI pair.

Edit: Actually, one way it could matter is if the instructions are different widths, assuming the PowerPC instruction set is complex and different op codes take up varying amounts of space. I didn't check on that. I've never encountered an instruction set like that where OR and ADD variants didn't match each other, though. That is, if there are immediate ADDs that take 8-, 16-, and 32-bit operands, there's usually a matching set of ORs.

[jin299]

Your knowledge in Assembly is highly impressive Pyriel, I hope one day be half as knowledgeable as you, in the subject thanks for clearing up any confusion I was having regarding asm instructions.

Now I have a question to ask you Pyriel, once you have found the correct instruction in the debugger to make your asm code, you can basically edit that instruction to your liking right, but how do game hackers create new asm codes in the debugger from ram hacks, like how does the hacker know what address he is looking for in the debugger, when they are making new asm codes for a game from existing ram codes?

[Pyriel]

It can be done any number of ways. I'm used to working without a debugger, so I use searches in the disassembly based on something like maximum value, a computed offset from what I believe is the start of a struct—e.g., the character data is 80 bytes in size, and bytes 24-27 are the experience, so I go looking for 32-bit load operations with that index value—something like that. It varies a lot from game to game. It's a cumulative process too. Every little thing that can be established about the game may give you one more way to look for other routines or data.

If there's a good debugger for the system you're working on, it's a lot simpler. You can just use breakpoints. If you know the address of a character's health, throw an on-write breakpoint on the address, go out and get hit or drink a potion or whatever it takes to change the value, and it should halt right on the instruction that tries to store the new value. You could also just do a break on read/access, and it should halt after an attempt to read it whenever you go into the status menu.

Some emulators can be rather flaky about it, though. Sometimes they don't switch cleanly between execution modes. For example, the game recently executed your routine, so it's still in a recompiled state somewhere in memory. After you switch on the debugger, the game should cease using the recompiled code, and switch to a slower, purely interpreted mode, but it doesn't. So your breakpoint fails because the emulator isn't working properly. Or, in some cases, the target CPU has an instruction cache that's emulated, and switching to the debugger doesn't invalidate it. The emulator is running in the proper mode, but the emulated CPU is getting instructions from a cache that the debugger won't let you access, and it's not designed to break on operations within it. Those situations should be fairly rare in general, but, as a couple of the PSX emulators hit one or the other of them (pretty sure it's the latter) more frequently than I'd like, I feel I should issue a warning.

[Abystus]

Once you have found the correct instruction in the debugger to make your asm code, you can basically edit that instruction to your liking right, but how do game hackers create new asm codes in the debugger from ram hacks, like how does the hacker know what address he is looking for in the debugger, when they are making new asm codes for a game from existing ram codes?

Depending on what your intentions are, you need to modify the ASM in that way, all the while making safe alterations to the existing game code to prevent any problems that may occur from your modification. Think of RAM as a scratchpad for the ROM to load and store values from/to. When something occurs in-game, the game code may write new values to RAM, and on occasion loads values from RAM depending on what the game code is doing. So to find what game code is modifying a RAM address, you need to set breakpoints accordingly on the RAM address in question for read or write (depending on the operation your looking for). The debugger will snap at the location that is performing the operation, and will give you a glimpse of what you need to modify in order to produce your code.

Example:

Code: Infinite Lives
Lives Address: 12345

Losing a life subtracts 1 from 12345, so we want to find the operation that writes the new value into that address (breakpoint for "Write" on 12345), and make alterations to prevent the value at the address from changing. There are several ways you could alter the routine (really depends on how the game code was written), but the most obvious and common alteration would be to replace either the subtract or store of the new value with a NOP (no operation). You cannot get away with randomly replacing the instruction with anything made up on your own, and whatever you replace it with has to be part of the instruction set related with the processor in question. My advice would be to start small (Infinite Types), and then work your way up to more complex hacks once you get the hang of how things work.

[jin299]

Makes sense I suppose, so what about making more advanced asm codes, like helder made a no charge asm code for a street fighter game, so that it works for all fighters the question is how did he know what address and instruction to find in the debugger, in order to make the code?

Also say I wanted to explore where more data relating to a code is in the debugger take a character modifier code as an example, is all the addresses surrounding the actual character modifier instruction in the debugger, useless or could I still find new addresses in the debugger relating to an aspect of the character modifier, can I find new codes in asm by backtracking existing ram codes in the debugger?

[Pyriel]

People can explain how they made specific codes to some extent. It'll make sense to you if you already have some familiarity with what they're talking about, or it'll sound like Greek and won't make a lick of sense until later.

All the data in the game serves some purpose. Whether or not its potentially useful to you isn't necessarily a question we can answer in general terms. What's in proximity to that selected character value might be useless strings and menu positions, or it could be the selected stage and music, or who knows what else.

At this point, you know what the basic tools and techniques are. Now it's just a matter of throwing a thousand punches until you get used to it, and letting people help you when you make mistakes or get lost.

[Hacc]

Heh; we basically said the same thing. I just saw your post.