wiirdw32.exe (or just wiird on Linux) is the command line application which is controlled by WiiRd GUI (Windows only)-
while most users will stick to WiiRd GUI as it's easier to use and offers much advanced code search functionality it might be
interesting for many users (especially Linux users) to also control the command line as this one is the actual interface
between WiiRd GUI and the Gecko - it is also possible to use both at the same time (press on "Show WiiRd" in the GUI) to
control the command line interface.
This documentation covers all commands which are usable using WiiRd including rare paremeters and extra commands you can
define yourself. Please note: all commands are case insensitive, it doesn't matter whether you type in dump, DUMP or DuMp.
Linux note: WiiRd is also case insensitive on filenames and will be only able to find/create lower case filenames - that's
an issue being worked on, the Linux version is kinda fresh!
This section covers all commands besides breakpoint commands - those were given an extra section as there are 10 commands just for properly handling breakpoints. Please note that most commands are only availible when you're connected to the USB Gecko - those commands are gonna be marked with a blue note while commands which are always availible are marked with a green note.
hook (<language>) (<videomode>) (<hookmode>) (pause) (vidtv)
This command has several optional parameters! It hooks to a Wii game!
For stability reasons, before this command is executed it will auto-reconnect to the USB Gecko!
Possible parameters are:
Languages:
Video modes
Hook modes
The two remaining parameters are "pause" and "vidtv". Both are unset by default. If you set "pause" the game won't be run after being hooked to. If you set "vidtv" the so-called VIDTV patches for video mode will be activated!
> hook pal60 vidtv Resetting USB Gecko device driver! Starting game - language won't be overridden! PAL 60 and VIDTV patches applied! Game is started using VI hook! > _
hooka <address1> <address2>
Basically this command generates a branch command (jump in some other assembly types) from address 1 to address 2. The main idea behind it was to quick generate hooks into the code handler which is at 800018A8 - if the standard hooks fail.
> hooka 81445338 800018A8 Hooked to address 0x81445338 > _
reconnect
This command has no availible parameters! It closes all current connections to the USB Gecko and attempts to reopen them, this command is recommended in case your USB Gecko was accidently not connected when you opened wiird.exe - during this status, besides hook, only help and exit/quit commands are availible!
> reconnect Reconnecting USB Gecko driver interface... connection established! > _
run
This command has no availible parameters! It simply resumes a paused game - if the game is already running it will show no visible effect!
> run > _
pause
This command has no availible parameters! It pauses a running game - if the game is already paused it will show no visible effect!
> pause > _
next
This command has no availible parameters! It will internally quickly execute "run", then "pause" and therefore allows to kinda skip one frame (maybe little less, maybe more, depending on your speed) forward. Useful if you you're modifying data in a time critical area (meaning you need to find an address within 5 game seconds)! A running game will be paused.
> next > _
dump <file> <start address> <end address>
This command reqires 3 parameters. It will dump the game memory beginning from <start address> (e.g. 80003100) until <end address> (e.g. 81800000) - please note that the command line does no memory range checks, the GUI does - be carful what memory area you dump!
> dump head.bin 80000000 800031000 Dumping 80000000 to 80003100 to file: head.bin Dumping... done! > _
peek <address> (<type>)
This command reqires 1 parameter, the second is optional. It will show you the memory value of a given address. If no <type> is specified it will standard to a 32 bit/4 bytes peek. Please note that in this mode addresses are exact up to 4 bytes (meaning 80000003 would be lowered to 80000000). The output is normally in hex. Other types are:
> peek 80150001 0x80150000: 0x3F800000 > peek 80150001 8 0x80150001: 0x80 > peek 80150001 16 0x80150000: 0x3F80 > peek 80150000 f 0x80150000: 1 > _
poke <address> <value> (<type>)
This command reqires 2 parameters, the third one is optional. It will write the given <value> to the given memory <address>. If no <type> is specified it will standard to a 32 bit/4 bytes poke. Please note that in this mode addresses are exact up to 4 bytes (meaning 80000003 would be lowered to 80000000). You will be given a confirmation message if the poke succeeded. Other types are:
> poke 80150001 00000000 Value 0x00000000 written to 0x80150000 > peek 80150000 0x80150000: 0x00000000 > poke 80150001 08 8 Value 0x00010000 written to 0x80150000 > peek 80150000 0x80150000: 0x00010000 > poke 80150000 1.5 f Floating point value 1.5 written to 0x80150000 > peek 80150000 0x80150000 3FC00000 > peek 80150000 f 0x80150000 1.5 > _
upload <file> <start address>
This command requires 2 parameters and does the opposite of dump - instead of dumping memory to file, it writes memory from a file. It uploads the complete content of a given <file> to the Wii memory beginning at <start address>.
> upload dangerous-ppc-virus.bin 80003100 Uploading file dangerous-ppc-virus.bin to address: 0x80003100 Upload................... done! > _
screen (<filename>)
This command requires no parameters but 1 is optional. It will grab a screenshot from your Wii hardware and save it as a bitmap file. <fiename> will be the output filename, if no filename is given it will store it in the screens folder using the following filename structure: [gamename]_xxx.bmp while xxx is simply counting up from 000 to whatever. Note: if you give a filename it will overwrite files without asking! Note, the command line will never do any resizing to the screenshots, it will just perform clean dumps from the XFB. EFB screenshots are not supported.
> screen Taking screenshot! Dumping data.......... done! Storing to screens\RZDP01_012.bmp... done! > screen zelda.bmp Dumping data.......... done! Storing to zelda.bmp... done! > _
Note: GCNrd compatibility
The structure screen xfb filename.bmp is supported for backwards compatibility
with GUIs using GCNrd commands - note that screen efb ____ will give a warning message and won't do anything!
gamename
This command requires no parameters. It will simply print out the internal game name. Useful if you want to add extra commands (see later!).
> gamename Name: RZDP01 > _
gamestatus
This command requires no parameters. It will show you whether the game is currently running, paused or in breakpoint mode. If you're still in Gecko OS, it will tell you that the game hasn't yet started!
> gamestatus Game is paused! > _
sendfail
This command requires no parameters. It will just send a fail command to the USB Gecko - in case the game is stalled but the USB Gecko is still reacting, sendfail might help - send it and then send a run command.
> send > run > _
sendcheats <file>
This command will send a GCT type cheat file - these files are usually created by the code manager. You can send them to the Wii in real time using this command.
> sendcheats RZDP01.GCT Sending cheat file RZDP01.GCT.. done! > _
sendcheatstxt <file>
This command will send a cheat file which only contains cheat code lines... like 04123458 60000000 - these lines will be internally converted to GCT and sent to the the handler!
> sendcheatstxt RZDP01.TXT Sending cheat text file RZDP01.TXT.. done! > _
sendcheatsgui (<file>)
This command will send a WGC file like the ones used in WiiRd GUI. If no file name is given it will try to search for a file called code\<gameid>.wgc as that's the format the GUI uses for saving them.
> sendcheatsgui Sending GUI cheat file codes\RZDP01.WGC.. done! > _
sendcheatsexec <file>
This command will send a GCT type cheat file - these files are usually created by the code manager. Unlike the regular files these codes are immediately executed then (useful to create hooks in pause mode).
> sendcheats RZDP01.GCT Sending cheat file RZDP01.GCT.. done! > _
execcheats
Cheat lists in the code handler will be immediately executed once.
> execcheats > _
disablecheats
All code lists will be completely deactivated.
> disablecheats Disabling cheats.. done! > _
multipoke <file>
This command is technically only of relevance for the GUI not for the enduser. It's only discussed here for the sake of completeness. Multipoke reads a given binary file which contains of the following data (attention: little-endian):
This command was included to allow WiiRd GUI to do fast multi pokes - everything's handled in the console, it doesn't need to send multiple commands to it.
> multipoke multipok.bin Starting a multi poke....... finished! > _
help (<command>)
This command requires no parameters. It will show you some basic help options - the documentation you're currently reading is more detailed however! To get details about a command type in help <command>!
> help dump - Dump a memory area into a file. upload - Send the file contents to a given memory area. peek - Read the value from a given memory address. poke - Write the value to a a given memory address. ... > help run # run Unfreezes the game after "pause". > _
exit quit
Um.. this should be self explanatory - closes the app.
> exit
The breakpoint commands can be used like normal commands, they just have common parameters which are listed here so that I do not need to repeat them during detail descriptions. But first of all: A breakpoint is a memory exception - you put a breakpoint on a specific memory address - and once the game does something with that address (like read) the breakpoint will break and the game will pause. The user will then be able to see how the game is behaving while it's doing its stuff with the given address. getregs and cancelbp are a little different, they are however only releavant for users who rely on the breakpoint feature and thus these commands are also listed in this category. The possible parameters for regular breakpoint commands can be:
There'll be a note which parameter is availible for which breakpoint command!
bpr <address> (<parameter1> <parameter2>)
Availible parameters:
This sets a read breakpoint on a given address. WiiRd will wait until the breakpoint hits (means once the game reads the given address). Press a key to cancel the breakpoint. The structure of regs.bin will be explained later.
> bpr 80150024 Setting read breakpoint on 80150024 Please wait - press a key to abort! Breakpoint hit! Registers stored to regs.bin. > _
bpw <address> (<parameter1> <parameter2>)
Availible parameters:
This sets a read breakpoint on a given address. WiiRd will wait until the breakpoint hits (means once the game writes the given address). Press a key to cancel the breakpoint. The structure of regs.bin will be explained later.
> bpw 80150028 Setting write breakpoint on 80150028 Please wait - press a key to abort! Breakpoint hit! Registers stored to regs.bin. > _
bprw <address> (<parameter1> <parameter2>)
Availible parameters:
This sets a read/write breakpoint on a given address. WiiRd will wait until the breakpoint hits (means once the game reads OR writes the given address). Press a key to cancel the breakpoint. The structure of regs.bin will be explained later.
> bpw 80150030 Setting read/write breakpoint on 80150030 Please wait - press a key to abort! Breakpoint hit! Registers stored to regs.bin. > _
bpx <address> (<parameter>)
Availible parameters:
This sets an execute breakpoint on a given address. WiiRd will wait until the breakpoint hits (means once the game executes the instruction at the given address). Press a key to cancel the breakpoint. The structure of regs.bin will be explained later.
> bpx 80215548 Setting read/write breakpoint on 80215548 Please wait - press a key to abort! Breakpoint hit! Registers stored to regs.bin. > _
bpnr <address> (<parameter>)
Availible parameters:
This sets a read breakpoint on a given address. The breakpoint will silently hits once the game reads the data at the given address - then the game will pause. You can use "getregs" to read registers. To cancel the breakpoint use the "cancelbp". This is a so-called silent breakpoint - you can set multiple of those. The structure of regs.bin will be explained later.
> bpnr 80215548 Setting read breakpoint on 80215548 The game will pause once it hits! > _
bpnw <address> (<parameter>)
Availible parameters:
This sets a write breakpoint on a given address. The breakpoint will silently hits once the game writes the data at the given address - then the game will pause. You can use "getregs" to read registers. To cancel the breakpoint use the "cancelbp". This is a so-called silent breakpoint - you can set multiple of those. The structure of regs.bin will be explained later.
> bpnw 80215544 Setting write breakpoint on 80215544 The game will pause once it hits! > _
bpnrw <address> (<parameter>)
Availible parameters:
This sets a read/write breakpoint on a given address. The breakpoint will silently hits once the game reads OR writes the data at the given address - then the game will pause. You can use "getregs" to read registers. To cancel the breakpoint use the "cancelbp". This is a so-called silent breakpoint - you can set multiple of those. The structure of regs.bin will be explained later.
> bpnrw 8021554C Setting read/write breakpoint on 8021554C The game will pause once it hits! > _
bpnx <address>
Availible parameters:
This sets an execute breakpoint on a given address. The breakpoint will silently hits once the game executes the instruction at the given address - then the game will pause. You can use "getregs" to read registers. To cancel the breakpoint use the "cancelbp". This is a so-called silent breakpoint - you can set multiple of those. The structure of regs.bin will be explained later.
> bpnx 80315548 Setting execute breakpoint on 80315548 The game will pause once it hits! > _
step
This command has no parameters. If you are currently in breakpoint mode the game is frozen at a CPU instruction. Use the "step" command to step to the next instruction.
> step > _
cancelbp
This command has no parameters. It will cancel all running silent breakpoints, they won't hit anymore!
> cancelbp All running silent breakpoints are cancelled! > _
getregs
This command has no parameters. It will store the registers to a file called regs.bin - the structure of this file will be explained later! This command should be run after a silent breakpoint has hit, it will be auto-run after a non-silent has hit!
> getregs Stored registers to regs.bin. > _
sendregs <file>
Once the game is halted for breakpoint mode you can read the registers from regs.bin - you can however even change them by uploading a new set of registers. Please however note that due to technical difficulties changing floating point register is not allowed as of now - therefore the file you send must have those striped out (remove the last 128/0x80 bytes of the file to upload), otherwise WiiRd will not accept the file!
> sendregs newregs.bin Sending registers... done! > _
WiiRd allows you to create your own custom commands - this is helpful if there are specific commands you often need or command chains you often need to execute (to add in new assembler routines or so). WiiRd allows you to do so two ways: either by creating batch files or by defining your own commands.
sleep <time>
Technically spoken this is a WiiRd command.. however it only makes sense in conjunction with user scripts so it will be discussed here. The command basically just freezes the console for <time> milliseconds. So if you use "sleep 200" the console is freezed and won't do anything for 200 milliseconds.:
> sleep 1000 > _
batch <file>
Simply reads the content of a given text file and executes it line by line. Please note that you can always add comments by simply adding # -everything after # is being ignored - if you need a # in a command (like if it is part of a filename) please write \# - if you need \#, write \\# - and so on! If you're file mybatch.txt looks like:
#gives me super much money in X poke 80605040 03E7 16 #999 coins rock!
Once you execute this with:
batch mybatch.txt
it will be striped down to
poke 80605040 03E7 16
A little bit more elegant than batch files is wiird.qc - it allows you to add completely new commmands to WiiRd and those commands might only function if a specific game is in the console. The commenting in the .qc file is identical to that of the batch files (#) ! The structure might look like:
:money [RABP00 poke 80605040 03E7 16 #999 coins rock :money [RABE00,RABJ00 poke 80605048 03E7 16 #999 coins rock #always dumps the game header :dumpheader dump head.bin 80000000 80003100
This wiird.qc now implements three commands to the WiiRd command list. To start out, commands start with ":" - so we, see
":money", ":money" and ":dumpheader" - this means we've just implemented the commands "money", "money" and "dumpheader". But
wait: money is implemented twice? Yes, kinda: the lines beginning with "]" tell WiiRd for which games the command is:
we see, the first money command contains the line "]RABP00" - this means this command is only availible if the game
name is RABP00 - the second money command however contains "[RABE00,RABJ00" which means that this command is availible
for the games with game name RABE00 and RABJ00 (You can even add more games, just seperate them with ",") - the
dumpheader command has no "]" line - it'll be availible on all games.
So if I now type in money - WiiRd will search for a command with that name. Once it finds the first instance it'll
check if the game name is RABP00 - if yes, it will execute poke 80605040 03E7 16 - if it's not it will go on searching
for that command.. it will find it again: this time it will check if the game name is RABE00 or RABJ00 - if yes, it will
execute poke 80605048 03E7 16, otherwise it will again continue searching - and won't find it anymore.
reparseqc
This command requires no paramets. Normally WiiRd will only read wiird.qc on start-up - changes while WiiRd runs will be ignored. To reload it, type in reparseqc and it will be read again!
> reparseqc Unloading old extra commands... done! Loading new command set... done! > _
This part contains some file descriptions of the files which are normally created by WiiRd.
Open regs.bin a hex editor, the structure is the following.
0x000: | CR | 0x004: | XER | 0x008: | CTR | 0x00C: | DSIS |
0x010: | DAR | 0x014: | SRR0 | 0x018: | SRR1 | 0x01C: | r00 |
0x020: | r01 | 0x024: | r02 | 0x028: | r03 | 0x02C: | r04 |
0x030: | r05 | 0x034: | r06 | 0x038: | r07 | 0x03C: | r08 |
0x040: | r09 | 0x044: | r10 | 0x048: | r11 | 0x04C: | r12 |
0x050: | r13 | 0x054: | r14 | 0x058: | r15 | 0x05C: | r16 |
0x060: | r17 | 0x064: | r18 | 0x068: | r19 | 0x06C: | r20 |
0x070: | r21 | 0x074: | r22 | 0x078: | r23 | 0x07C: | r24 |
0x080: | r25 | 0x084: | r26 | 0x088: | r27 | 0x08C: | r28 |
0x090: | r29 | 0x094: | r30 | 0x098: | r31 | 0x09C: | LR |
0x0A0: | f00 | 0x0A4: | f01 | 0x0A8: | f02 | 0x0AC: | f03 |
0x0B0: | f04 | 0x0B4: | f05 | 0x0B8: | f06 | 0x0BC: | f07 |
0x0C0: | f08 | 0x0C4: | f09 | 0x0C8: | f10 | 0x0CC: | f11 |
0x0D0: | f12 | 0x0D4: | f13 | 0x0D8: | f14 | 0x0DC: | f15 |
0x0E0: | f16 | 0x0E4: | f17 | 0x0E8: | f18 | 0x0EC: | f19 |
0x0F0: | f20 | 0x0F4: | f21 | 0x0F8: | f22 | 0x0FC: | f23 |
0x100: | f24 | 0x104: | f25 | 0x108: | f26 | 0x10C: | f27 |
0x110: | f28 | 0x114: | f29 | 0x118: | f30 | 0x11C: | f31 |
Open regs.bin a hex editor, the structure is the following. Floating point registers cannot be changed!
0x00: | CR | 0x04: | XER | 0x08: | CTR | 0x0C: | DSIS |
0x10: | DAR | 0x14: | SRR0 | 0x18: | SRR1 | 0x1C: | r00 |
0x20: | r01 | 0x24: | r02 | 0x28: | r03 | 0x2C: | r04 |
0x30: | r05 | 0x34: | r06 | 0x38: | r07 | 0x3C: | r08 |
0x40: | r09 | 0x44: | r10 | 0x48: | r11 | 0x4C: | r12 |
0x50: | r13 | 0x54: | r14 | 0x58: | r15 | 0x5C: | r16 |
0x60: | r17 | 0x64: | r18 | 0x68: | r19 | 0x6C: | r20 |
0x70: | r21 | 0x74: | r22 | 0x78: | r23 | 0x7C: | r24 |
0x80: | r25 | 0x84: | r26 | 0x88: | r27 | 0x8C: | r28 |
0x90: | r29 | 0x94: | r30 | 0x98: | r31 | 0x9C: | LR |
See wiird.qc Documentation in the "User commands" section!
First of all.. kenobi and me (Link) are mostly Windows nerds. Thus WiiRd and WiiRd GUI are mainly developed for Windows
operating systems. Due to major demand, I decided to port over the console to Linux - please note that a Linux version of the
GUI is highly unlikely. You can however use the interface provided with the sources (see where you downloaded this package)
to build your own GUI. The interface is developed to be 100% compatible with all operating systems and there is only one
function difference (Screenshot) between the Windows and the Linux compilation. For Mac support? I lack the hardware, provide
me a Mac, I'll port!
Unfortunately due to the nature of WiiRd being Windows optimized, some things do not yet completely work in Linux. These things
include but may not be limited to:
I am not aware of other limitations! Currently the Linux version has only been built on Kubuntu 8.04 amd64 - I am pretty sure it will compile without any problems on i386 platforms - endianness should be taken care of in all functions therefore I personally hope that compiles for every platform would work - all in-line assembly the Windows version has is removed and replaced by "proper" Object Pascal functions!