wiird.exe is the command line application which is controlled by WiiRd GUI - 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 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.
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 (<patches>)
This command does not require parameters! It hooks to a Wii game and applies some startup
patches! The patches may be:
> hook Resetting USB Gecko device driver! Starting game! > _
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 > _
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 > _
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 a 4 byte value from a given memory address.
poke - Write a 4 byte 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, dumpmmu 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 and mmu.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. - MMU stored to mmu.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 and mmu.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. - MMU stored to mmu.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 and mmu.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. - MMU stored to mmu.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 and mmu.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. - MMU stored to mmu.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 "dumpmmu" and "getregs" to read registers and MMU data. 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 and mmu.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 "dumpmmu" and "getregs" to read registers and MMU data. 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 and mmu.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 "dumpmmu" and "getregs" to read registers and MMU data. 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 and mmu.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 "dumpmmu" and "getregs" to read registers and MMU data. 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 and mmu.bin will be explained later.
> bpnx 80315548 Setting execute breakpoint on 80315548 The game will pause once it hits! > _
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. > _
dumpmmu
This command has no parameters. It will store the MMU data to a file called mmu.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!
> dumpmmu Stored MMU data to mmu.bin. > _
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.
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.
| 0x00: | LR | 0x04: | XER | 0x08: | CTR | 0x0C: | DISR |
| 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 |
Open mmu.bin with a hex editor, the structure is the following: TBA
See wiird.qc Documentation in the "User commands" section!