Random Information

USB Gecko Setup tutorial-

Congratulations on now owning your own USB Gecko. :)

Now I'm sure you have some questions on what to do now and how to set it up,

I will show you exactly how to setup your gecko in just a few simple steps below.

I hope this tutorial helps those people who are new to coding, now lets get started.

Resources:

-USB Gecko(It doesn't matter wether you have the SE or the older version)

-USB Gecko adapter chord(This should have come with your gecko)

-Driver software

-Laptop or computer that will reach your Wii

Step 1: Take your gecko out and check it out.(be careful they're very fragile)

Step 2: Plug the small end of the gecko adapter chord into the slot on the top

of your gecko.

Step 3: Plug the usb part into the usb slot of your computer.

Step 4: Plug the USB Gecko into the gamecube memory card slot on the top of

your Wii.

Once the chord is plugged into your computer Windows Update will search for

the driver software for you and install it automatically.(if it does'nt then

download the software from the link below)

Driver Software download link: Latest USB Gecko Drivers (FTDI Chip) (Dropbox, Mega, GDrive) (VirusTotal Scan)

Step 5: Download gecko.net(you could use WiiRD, but Gecko.net is better)

Gecko.net download link: Gecko dotNet (Dropbox, Mega, GDrive) (VirusTotal Scan)

Step 6: Load gecko OS on your wii and go to config settings and turn "Load Debuger" On

and click save config.

Step 7: Put in a game and click launch game in Gecko OS and open up gecko.net on your

computer and your gecko will connect.

Happy hacking! :)

ellijah!

Since it requires some knowledge about programming, this article might be too difficult to understand. If that is the case, just put the following at the beginning/end of your ASM code. This is all that you need...you don't need anything else from this article. But don't change the first two or last two lines.

stwu r1,-80(r1) # make space for 18 registers

stmw r14,8(r1) # push r14-r31 onto the stack

# put your ASM code here

# you can safely use r14-r31

lmw r14,8(r1) # pop r14-r31 off the stack

addi r1,r1,80 # release the space

---

In case you're thirsty for more...

The first part is a simple Function Prologue. When we run out of registers, we use the stack to store some of them. The stack is just a chunk of memory; you can look at it in Memory Viewer.

We can make room on the stack by "claiming" a chunk of it using stwu, which will also subtract from the stack pointer (in our case, we subtract 80). It is extremely important that you follow the conventions when using the stack; failure to do so will almost certainly lead to crashes.

stmw is "STore Multiple Words". It writes each register, starting with the source operand (r14 in our case), to subsequent addresses in memory, starting with the base-displacement operand, 8(r1) in our case.

At this point, it's safe to use any register from r14 up. They're all stored on the stack, so you won't destroy their values. Note that r14 is the first non-volatile register...there's very little reason to use any register below r14 with stmw.

The last part is a simple Function Epilogue. It restores the contents to the registers from the stack. lmw = Load Multiple Words, and it does pretty much the opposite of stmw. Then, the amount of space that we subtracted from the stack pointer (in our case, 80) is added back to it. This releases our claim on that chunk of the stack.

---

However, what if you don't want to add those four lines to all your ASM codes? No code should ever require a stack frame...the PowerPC is a register-rich RISC architecture with 9 volatile registers (r0, r5-r12) that are safe after any bl. If you learn to think like the compiler, you will see that there is always a bunch of free registers.

---

I also made a pretty picture that might help illustrate volatile/nonvolatile registers across function calls.

A function is a Black Box. Parameters go in, stuff gets processed, and outputs are returned.

There are two sides to a function; the call into it and the return from it. Functions are called with bl (on the left), and functions return with blr (on the right). All games follow a very specific convention when calling and returning from functions.

1) The caller (on the left side, outside the box) will not rely on volatile registers (the top half, r0-r12) to contain their previous values when execution returns from the function call (on the right side, outside the box). Therefore, the callee is not required to protect their values.

2) However, the callee (inside the box) must preserve the values in the non-volatile registers (r13-r31) at the edges of the box. This provides the illusion to the caller of stable, reliable values that persist after calling another function. Note that callee may back up some of these registers and use them for its own function calls, but it must restore the original values before execution returns; this is denoted by the ... connecting left side of the box to the right side.

3) r31-r14 can be thought of as local variables. If you see any of these registers being used, search only within the scope of the current function (from beginning to end, over bl if necessary) to see where the value comes from.

4) Note the black arrow pointing from r31 toward r14; games prefer larger registers. This is also reflected in the architecture of the CPU, with the lmw and stmw instructions that load/store all the registers from r31 to the operand.

5) When calling a function with bl, the values in the blue registers on the left will be considered lost. That is, at the very start of a function, in the new frame, r0/r11/r12 are safe to use.

6) When returning from a function with blr, the values in the blue registers on the right will be considered lost. That is, after execution returns from a function to the caller's frame, the caller can safely use r0/r5-r12 (!!!). This means that any hook which runs right below a bl can use nine registers safely.

7) Dark green registers on the left side are inputs. You will see them loaded with values before a bl happens. Games prefer small registers, so they'll start with r3 and work their way up. If you know it only uses r3-r5, then you know that r6-r12 are safe at the start of the new function. You also know that r6-r12 are also safe in the previous function, up to the previous bl (because they're volatile)

8 ) If you see these input registers being used, you only have to search as far back as the previous bl (because they are volatile)

9) However, because they are inputs, there may not be a "previous bl" before you walk past the very beginning of the function. In this case, the value was passed in by the caller, so you must go back to the caller's frame to see where it got the values that it put into the parameters.

10) Bright green registers are outputs. You will see them loaded before the blr. There are only two, and the game prefers smaller registers again. If you see these registers used, you may have to go into the called function to see where the values came from.

11) Don't use the bright red registers. Ever. Period. Don't even try to back them up. I warned you.

---

"Safe" is a colloquial phrase used to refer to a register whose contents can be over-written without ever affecting the game's execution. Many people confuse 0 for safe, but that is not the case. Safety cannot be determined from the value of a register; it could be 0 when you're looking at it and a different value later.

Safe means that you can load a value into a register, and the original game code will over-write that value before reading from that register. "Safety" changes over the course of execution; a register will be unsafe for a while, then it will become safe, and then unsafe again, over and over.

---

the Spectrum of Safety

safest --- safer --- safe --- ?? --- unsafe --- unsafer --- unsafest

r12 r11 r10-r5 r4-r3 r0 r31-r? r14-r31 r1 r2,r13

---

There are two absolute ends to the Spectrum of Safety: "safest"/"unsafest". There are a few special registers that are always/never safe to write to.

The safest register is r12. r12 is used exclusively (at least to my knowledge) to load the ctr preceding a bctr[l]; this means there's only a one-instruction long "unsafe" window and it's very rare to encounter. Unusual, but quite fortunate for us. You pretty much never have to worry about the contents of r12.

Conversely, there are the unsafest registers r2 and r13. NEVER EVER write to an unsafest register (you CAN still read). There are no exceptions, period. These registers are used by the CPU to access specific areas of memory related to constants, global variables, etc. They will be read during interrupts which you will not see or know about.

---

Somewhat more nebulous to define are the safer/unsafer registers. These have special conditions that affect their safety.

r1 is the most "unsafer" register. Generally, you should consider it an unsafest register, but there are a few exceptions, but you have to follow a certain convention when writing to it. It's possible that we can use "negative stack frames" for storing registers, but I don't know how to prove that negative stack frames are safe...

The regular unsafer registers are the non-volatile registers, r14-r31. These registers must have their contents preserved if you write to them, with the exception of "temporal safety" where they may be safe for a brief period of execution. In general, push/pop them on the stack or leave them alone.

---

To discuss the "safer" (aka volatile) registers, you will need to understand the concepts of a function call, parameter passing, and return registers. You will need to know how bl/blr work, too.

r11 is the most safer register. I think I have only ever seen r11 used to cache the stack pointer. It is never used to pass parameters into a function, so it is safe after a bl (i.e. at the entry point of a function). The function called does not have to preserve its contents, so it is guaranteed to be safe after a blr.

The other safer registers are r5-r10. These are used to pass parameters into a function, so they are not safe after a bl. In fact, if you see r5-r10 being written to, the game is probably getting ready to bl to a function. However, these registers are NOT used to return values, so they are safe after a blr.

---

The unsafe registers start with r31 and extend backwards from there. The compiler prefers larger registers, so you will usually see it start with r31, then r30/r29/etc. EDIT: You can also see this preference reflected in the instructions lmw and stmw.

At the beginning of function calls (just after the bl), you will see the game push unsafe registers onto the stack. This is the function preserving non-volatile registers, so that those registers can be used as local variables. At the end of the function they will be popped off the stack. EDIT: It is important to use non-volatile registers for storing the local variables, because the value in a non-volatile register persists across function calls. Any value stored in a volatile register can/will be lost when a function is called.

The safe registers are r3 and r4. Like r5-r10, these registers are used to pass parameters in. The compiler prefers smaller registers, so you usually see r3, then r4, before r5/etc. Unlike r5-r10, these registers are also used to pass return values back to the caller after a blr, again preferring smaller registers. So they are NOT safe after a blr.

r0 is a special kind of safe. It's almost safer; it is volatile, thus does not need preserved. It is not used to pass parameters or return values, so it is safe after bl and blr like r11 and r12. However, you cannot use r0 for rA in certain instructions (e.g. addi rD,rA,1). These instructions will have "(rA|0)" in their datasheet describing their operation. Other instructions that show only "rA" can use r0. You can also use r0 for any other register operand (e.g. rD, rB, etc).

---

Unsafe registers, safe registers, and safer registers (when used) all have tempory windows of safety. These are periods where the contents of the register do not matter; the game will not be reading from that register until after it has written a new value to it.

The top edge of a safe window is defined by the last instruction that read the contents of the register. The bottom edge of the safe window is defined by the first instruction to write to the contents of the register. During the safe window, a register is safe to use in your hook.

---

EXAMPLES

Here is an example from Super Mario Galaxy 2. I was trying to find 1ups, so I found Mario's life count and set a write breakpoint on it, then got a 1up and backtracked in search of a 1up pointer. Here's a small function I found while walking the stack.

804DE030: 9421FFF0 stwu r1,-16(r1) allocate room on the stack

804DE034: 7C0802A6 mflr r0 preserve LR in r0

804DE038: 38A00063 li r5,99 prepare r5 for the bl

804DE03C: 90010014 stw r0,20(r1) push LR onto the stack so we can bl

804DE040: 93E1000C stw r31,12(r1) push r31 on the stack...

804DE044: 7C7F1B78 mr r31,r3 ...so we can cache the pointer (parameter in r3) in r31

804DE048: 88030008 lbz r0,8(r3) read Mario's life count

804DE04C: 7C602214 add r3,r0,r4 add the number of lives from parameter r4 to prepare r3 for the bl

804DE050: 38800000 li r4,0 prepare r4 for the bl

804DE054: 4BB3BDAD bl 0x80019e00 calls the function I breakpointed inside; makes sure r4 <= r3 <= r5; returns result in r3

804DE058: 987F0008 stb r3,8(r31) store the result returned from the function

804DE05C: 83E1000C lwz r31,12(r1) pop the local variable's contents back into r31

804DE060: 80010014 lwz r0,20(r1) pop the LR back into r0

804DE064: 7C0803A6 mtlr r0 restore LR so we can go back to our caller

804DE068: 38210010 addi r1,r1,16 free the memory we allocated on the stack

804DE06C: 4E800020 blr return to caller

Notice how r3 and r4 were used to pass parameters into this function. r3, r4, and r5 are used to pass parameters to the bl. That bl used r3 to return a value. r31 was used for a local variable, so it was pushed onto the stack.

---

I have bolded the window edges in this example. r5 is ambiguous at the start of the function; it could be passing a parameter in. However, it is written to before being read, so we can conclude that there is no important value in it.

804DE030: 9421FFF0 stwu r1,-16(r1)

804DE034: 7C0802A6 mflr r0

804DE038: 38A00063 li r5,99

804DE03C: 90010014 stw r0,20(r1)

As it turns out, 804DE038 is still safe. This is because when you write a C2 hook, you always make sure to add the instruction you will replace to the end of your hook. Your hook is effectively inside the window's bottom edge even if you are hooking the bottom edge.

r5 is now in an unsafe window from 804DE03C on. The bottom edge of the window is defined by the bl at 804DE054; we CANNOT hook the bottom edge of unsafe windows.

804DE038: 38A00063 li r5,99

804DE03C: 90010014 stw r0,20(r1)

804DE040: 93E1000C stw r31,12(r1)

804DE044: 7C7F1B78 mr r31,r3

804DE048: 88030008 lbz r0,8(r3)

804DE04C: 7C602214 add r3,r0,r4

804DE050: 38800000 li r4,0

804DE054: 4BB3BDAD bl 0x80019e00

804DE058: 987F0008 stb r3,8(r31)

After the bl, r5 is safe again, through the blr.

804DE054: 4BB3BDAD bl 0x80019e00

804DE058: 987F0008 stb r3,8(r31)

804DE05C: 83E1000C lwz r31,12(r1)

804DE060: 80010014 lwz r0,20(r1)

804DE064: 7C0803A6 mtlr r0

804DE068: 38210010 addi r1,r1,16

804DE06C: 4E800020 blr

---

The final product would look like this without the overlapping window edges

804DE030: 9421FFF0 stwu r1,-16(r1)

804DE034: 7C0802A6 mflr r0

804DE038: 38A00063 li r5,99

804DE03C: 90010014 stw r0,20(r1)

804DE040: 93E1000C stw r31,12(r1)

804DE044: 7C7F1B78 mr r31,r3

804DE048: 88030008 lbz r0,8(r3)

804DE04C: 7C602214 add r3,r0,r4

804DE050: 38800000 li r4,0

804DE054: 4BB3BDAD bl 0x80019e00

804DE058: 987F0008 stb r3,8(r31)

804DE05C: 83E1000C lwz r31,12(r1)

804DE060: 80010014 lwz r0,20(r1)

804DE064: 7C0803A6 mtlr r0

804DE068: 38210010 addi r1,r1,16

804DE06C: 4E800020 blr

---

Let's look at r4. r4 is passing a parameter in, so it is in an unsafe window from the start of the function until the last read before the first subsequent write.

804DE030: 9421FFF0 stwu r1,-16(r1)

804DE034: 7C0802A6 mflr r0

804DE038: 38A00063 li r5,99

804DE03C: 90010014 stw r0,20(r1)

804DE040: 93E1000C stw r31,12(r1)

804DE044: 7C7F1B78 mr r31,r3

804DE048: 88030008 lbz r0,8(r3)

804DE04C: 7C602214 add r3,r0,r4 last read

804DE050: 38800000 li r4,0 first subsequent write

804DE054: 4BB3BDAD bl 0x80019e00 r4 used as parameter

804DE058: 987F0008 stb r3,8(r31)

804DE05C: 83E1000C lwz r31,12(r1)

804DE060: 80010014 lwz r0,20(r1)

804DE064: 7C0803A6 mtlr r0

804DE068: 38210010 addi r1,r1,16

804DE06C: 4E800020 blr

It's possible the bl is returning something in r4, and that value is returned by us without modification. So I would declare the region after the bl to be an unsafe window for r4. If you knew the bl didn't load anything into r4, then you could probably use it here. This is why r5-r10 are safer than r3 and r4.

---

r3 is even more fun! It starts off as a parameter, then it is used as a different parameter, then it has a return value, and then it's ambiguous!

804DE030: 9421FFF0 stwu r1,-16(r1)

804DE034: 7C0802A6 mflr r0

804DE038: 38A00063 li r5,99

804DE03C: 90010014 stw r0,20(r1)

804DE040: 93E1000C stw r31,12(r1)

804DE044: 7C7F1B78 mr r31,r3

804DE048: 88030008 lbz r0,8(r3)

804DE04C: 7C602214 add r3,r0,r4

804DE050: 38800000 li r4,0

804DE054: 4BB3BDAD bl 0x80019e00

804DE058: 987F0008 stb r3,8(r31)

804DE05C: 83E1000C lwz r31,12(r1)

804DE060: 80010014 lwz r0,20(r1)

804DE064: 7C0803A6 mtlr r0

804DE068: 38210010 addi r1,r1,16

804DE06C: 4E800020 blr

---

r31 is safe once it is pushed onto the stack, until it is loaded with the copy of the pointer. It's then safe after the pointer is used, until the original contents are popped off the stack.

804DE030: 9421FFF0 stwu r1,-16(r1)

804DE034: 7C0802A6 mflr r0

804DE038: 38A00063 li r5,99

804DE03C: 90010014 stw r0,20(r1)

804DE040: 93E1000C stw r31,12(r1)

804DE044: 7C7F1B78 mr r31,r3

804DE048: 88030008 lbz r0,8(r3)

804DE04C: 7C602214 add r3,r0,r4

804DE050: 38800000 li r4,0

804DE054: 4BB3BDAD bl 0x80019e00

804DE058: 987F0008 stb r3,8(r31)

804DE05C: 83E1000C lwz r31,12(r1)

804DE060: 80010014 lwz r0,20(r1)

804DE064: 7C0803A6 mtlr r0

804DE068: 38210010 addi r1,r1,16

804DE06C: 4E800020 blr

---

r0's safety is awkward. Don't forget that it can't be used as rA for many instructions, too.

804DE030: 9421FFF0 stwu r1,-16(r1)

804DE034: 7C0802A6 mflr r0

804DE038: 38A00063 li r5,99

804DE03C: 90010014 stw r0,20(r1)

804DE040: 93E1000C stw r31,12(r1)

804DE044: 7C7F1B78 mr r31,r3

804DE048: 88030008 lbz r0,8(r3)

804DE04C: 7C602214 add r3,r0,r4

804DE050: 38800000 li r4,0

804DE054: 4BB3BDAD bl 0x80019e00

804DE058: 987F0008 stb r3,8(r31)

804DE05C: 83E1000C lwz r31,12(r1)

804DE060: 80010014 lwz r0,20(r1)

804DE064: 7C0803A6 mtlr r0

804DE068: 38210010 addi r1,r1,16

804DE06C: 4E800020 blr

---

The remaining safer registers (r6-r10 + r11) are safe from start to finish. As you can see, they are never used.

The remaining unsafer registers (r14-r30) are never safe. If you wish to use any of these registers, you MUST preserve the contents in a stack frame.

As always, r12 is always safe, and r2/r13 are never safe even if you try to preserve the contents.

When writing codes, if you need a lot of registers, try to hook an address that has as many overlapping windows of safety as possible.

Ever been disconnected because you tried to search too big of an address range in a game? Yeah, its a pain. Ever wonder why? Read on.

The big difference between offline hacking and online hacking is one thing:

The internet connection.

If you are coding an offline game, you can search the whole mem1 and mem2 range in one search. This makes it easier, and much faster.

If you are coding an online game, you can only search a certain amount of addresses before you trip your internet out and get disconnected. What is an appropriate address range to search? I wouldn't recommend more then 4 blocks at a time. As I was told once, its almost useless to search unless you have an idea of what your searching for is located online. A good tip for this is to dump the 81 region in a RAM dump, and search through that and see if you can find what your looking for. Even if you can't find exactly what your looking for, if you search the address of the dvar in the 81 region you will find addresses common to that dvar.

I would also recommend that you bookmark the Wii cheat type document, and keep it opened. This will help when trying to assemble the code.

Use your resources, id recommend looking at the address in memory viewer and see what it does, how it changes etc. Before going further with an adress. You are also given breakpoints, run it through a breakpoint if you find it need be, it'll make the quality of your codes a lot better.

Mute. Keep the remote by you, I dunno about everyone else but id imagine the "BEEEEEEEEEEEEEEEEEEEEEEPPPPPPPPPPP BUZZZZZZZZZZZZZZZZZZ WEIRD SOUNDSSSSSSS" get annoying while you search. Ooh well, nothing can change that xD

Explore. Don't make common codes like inf. Ammo, be adventurous and do some cool gfx stuff or something. This will get you recognized faster, if you are seeking attention, and will teach you more if your in it for the knowledge.

Complexity. The more advanced the code, the better. It will be longer, and will probably have a better effect.

Go outside. Sitting inside searching all day will get tiring, don't hesitate to pause it and go do something; your gecko won't grow legs and run off (lol)

Requests. If someone requests anything, think about doing it. This might help inspire you, as well as give you major brownie points (;

Test. Test the code before you post it anywhere, it takes a whole of what, 10 seconds? Just go to gct codes and apply it.

Memory Regions

Most commonly in games, mem2 *I believe* is where the gfx addresses are stored. The Wii has many different memory regions, but only 2 seems to be used most commonly. These are mem1 and mem2 regions; area's containing many addresses.

Mem1 goes from 0x80000000 to 0x81800000.

Mem2, however, goes from 0x90000000 to 0x94000000.

Be careful though, the top of mem2 is traditionally un-accessible. If you try and read from/write to it your Wii will crash. You can usually access up to 0x94000000 though.

Hope this helps a little, thought id start decrypting the Wii cheat type document to a more noob friendly readability.

The inner workings of the code handler and ram writes

Well, I'm not sure how many coders/leechers know this, and I found it interesting, so I thought id share it.

What is the code handler?

I can't give the best description on this, however it is pretty much what gecko OS + other loaders run in game to over write the original addresses, with what we call 'hacks.'

The code handler reads what codetype you are using, and does the following:

04/05 - direct ram write, writes the address every frame of the game.

F6 - searches for the stable values and ba first time the game is ran, if found they keep running it like a ram write. Only searches once.

C2 - Hooks the base address, and writes the instructions directly into the games ASM. Only changes instructions/reg. Info. I believe it runs every frame.

C0 - Loads the base address into registers, usually using ori/lis instructions, then allows you to write your own asm for that address. This, I believe, only runs when the game finds the address (I.e. C0ing player coords to change them to certain xyz, only runs when the xyz coords change, NOT EVERY FRAME)

So on and so forth.

So, game lag can be caused by having too many codes on that run every frame. (A frame is like a screen in the game, pretend you were flipping through a slideshow super fast, and let's say the slideshow is the game. Every slide of the slideshow is a frame ingame. The games run frames super fast, so that might have been a poor analogy.) So, be careful of how many frame writes you do in game, it could lag you more then everyone else.

The code handler is stored between, what I believe, is 80000000-80003000, however I may be wrong. It is somewhere there.

So, just in case you had issues of getting terrible lag/disconnection/had no problem but just felt the need to read this, I hope it was insightful. I found it interesting, I don't know about everyone else though.

Note: The code handler is open sourced, you can edit and make changes to it, you can write to it as the games loading, and you can make the edits you make into a codetype.