If you use a USB Gecko to hack games, then you should use the two C2 codes below!
---
The ultimate result of this thread http://wiird.l0nk.org/forum/index.php/topic,7909.0.html revealed that there was a bug in how the code handler sends dumps to the USB Gecko. I shall call this the "tx bug". (tx = transmit) Ultimately, a workaround was employed in Gecko.NET to prevent corrupted dumps. To a certain extent, WiiRDGUI worked around it by dumping 1MB chunks.
There have also been isolated instances of an "rx bug". (rx = receive) A command would be sent to the Wii, like pause or run, and it would be ignored. Ultimately, a patchwork of isolated safeguards probably shielded most users of WiiRDGUI and Gecko.NET from experiencing the rx bug.
However, I wasn't happy with those solutions. I was eventually able to track down the rx bug and tx bug by comparing the code handler's sendbyte and recvbyte to the devkitppc and some C code I found on Nuke's web site. This was...an interesting adventure. The end result, however, is that I have two C2 codes that will fix the code handler bugs.
NOTE: These C2 codes patch the code handler directly, so they work for both WiiRDGUI and Gecko.NET. They should be the very first codes in the list and they should always be applied, both when starting a game and when sending new codes. However, WiiRDGUI users may notice a second bug where the code handler hangs after patching C2 codes a second time. To prevent this other bug, you'll have to set an execute BP on 800018A8 before applying codes. Gecko.NET will do all of this automatically with "Pause While Sending" checked.
EDIT:
The C2 bug was fixed by two more debugger patches using recent versions of Gecko.NET. Also, recent versions use "hard-coded C2's" that are smaller and tucked away at the end of the code list.
---
TX Bug Fix [dcx2]
C2001E08 00000009
6C637000 560537FF
40820038 7FA902A6
3CA08000 60A51D6C
7CA903A6 4E800421
560537FF 41A2FFEC
6C637000 3CA08000
60A51D6C 7CA903A6
4E800421 7FA903A6
560337FF 00000000
RX Bug Fix [dcx2]
C2001D54 00000007
3C60D000 7FA902A6
3CA08000 60A51D6C
7CA903A6 4E800421
7FA903A6 560337FF
7FC803A6 3BA00000
4D820020 3C60A000
60000000 00000000
BTW I should add that before using the RX bug fix and TX bug fix, make sure your code handler is the right version. Gecko OS 1.9.3.2 will not work with these bug fixes, because the addresses moved. It was designed for 1.9.3.1, which is the code handler used in most places I think.
Your code handler should be IDENTICAL. If it is not, DO NOT use the code with that code handler! You will have to port the bug fix to your code handler. If you port the bug fix, please leave a reply to help others! If you can't port the bug fix yourself, send me a dump of MEM1 from your code handler and I can port it for you.
---
The RX Bug Fix patches this part of the code handler.
80001D50: 7FC802A6 mflr r30
80001D54: 3C60A000 lis r3,-24576
80001D58: 48000015 bl 0x80001d6c
80001D5C: 76030800 andis. r3,r16,2048
80001D60: 561D863E rlwinm r29,r16,16,24,31
80001D64: 7FC803A6 mtlr r30
80001D68: 4E800020 blr
---
TX Bug Fix patches this part
80001DE8: 386000AA li r3,170
80001DEC: 7FC802A6 mflr r30
80001DF0: 5463A016 rlwinm r3,r3,20,0,11
80001DF4: 6463B000 oris r3,r3,45056
80001DF8: 3AC00019 li r22,25
80001DFC: 3AE000D0 li r23,208
80001E00: 3F00CD00 lis r24,-13056
80001E04: 4BFFFF69 bl 0x80001d6c
80001E08: 560337FF rlwinm. r3,r16,6,31,31
80001E0C: 7FC803A6 mtlr r30
80001E10: 4E800020 blr
Wouldn't it be better to patch the code handler binaries directly? Or the source code of the code handler? Adding extra codes eats up available memory for other codes.
Also if this really only patches the code handler once, you may want to look into the patches Gecko OS can apply via gameconfig.txt. I don't remember at which point these patches are applied, but it's after loading the main.dol, so there's a chance the code handler is in memory at that time.
This depends on how you define "better".
C2 advantages:
1) brkirch doesn't need to release a new Gecko OS. He's been MIA for a while now; I even tried to contact him for help finding these bugs, but I got no reply. As far as I know, he is the only one with the Gecko OS source. The code handler in 1.9.3.1 is not public, I needed to reverse engineer it using an old source, and 1.9.3.2 is even more different. the code handler is public, actually...
2) Hackers can keep using the same apps they're using.
3) The layout of the code handler addresses is unchanged by a C2 hook. This means much less work in developing and testing the patch.
4) These bug fixes only affect the debugger, so only hackers would experience them. Joe Cheater doesn't need these bug fixes.
C2 disadvantages:
1) Must be applied every time. I'll release a new Gecko.NET that will have the option of patching the code handler behind-the-scenes to solve this problem, but WiiRDGUI users will still have to make sure they patch every time.
2) It takes up a little bit of extra space. However, even if the patch was applied to the binaries directly, it would still consume code list memory. In practice, we only lose like four or five code lines, because an in-line patch would push the code handler farther into the code list, reducing the maximum code list possible.
Patching with gameconfig.txt might be an option, but then you're micromanaging a file that's sitting on the Wii, so you need to constantly swap out the SD card, or use FTPii to transfer new files to the Wii every time you play a new game. And the gameconfig patch would probably need to be an in-line patch, so it would move code handler addresses around as well. We wouldn't be able to patch *just* exireceivebyte and exisendbyte, we'd have to recompile EVERYTHING to account for relative addresses that moved, so we'd basically be patching the whole code handler instead of just two subroutines, which seems like a very error-prone process, especially without source that has the branch labels.
As far as available code space...you can turn the patches off. And for Joe Cheater, who doesn't even use the debugger, there is no loss of code space.
That said, maybe you can help me find malloc(). I could then add a new code handler command that will allocate a new code list of 8k on the heap. This will practically remove the code list limitation.
Sorry, i didn't think this through, if it's only debugging related, then the less code lines do not matter. I can't help you with the malloc, but for gamecube i'm reducing the available memory for games by 16KB and it seems to work stable. If that works for Wii games, it would need to be implemented in the loader, so i guess it won't help you much. But if you would start using either, wouldn't that have a good chance to move some memory locations used in codes? While a malloc on a button press or such would be disastrous.
Something else i thought about:
Does the code handler currently flush the data cache? Or invalidate the instruction cache? I could imagine that if one or both is not done, it could explain some crashes(if there are) that occur randomly/eventually if the game runs long enough. Well, maybe i'm too naive and i'm overlooking something important.
No, WiiPower, you are not naive. You are in fact quite intelligent. As well as correct. ^_^
The old code handler source looks like it does all of the necessary syncing. As far as I can tell, 1.9.3.1 is mostly the same, except that the actual code type processing was extended. See this snippet from poke (aka "writedword") (disclaimer: I have not comprehensively analyzed the code handler top-to-bottom, but I've seen the sync code in a few places)
[spoiler]dcbf r0, r5 # data cache block flush
sync
icbi r0, r5
isync
[/spoiler]
We compare this to the PowerPC Microprocessor Family Programming Environments (https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525699600719DF2), Section 5.1.5.2 "Instruction Cache Instructions" It's pretty much the same template; in fact, the "initial template" uses dcbst, and then says "oh yeah you might want to use dcbf instead for multicore". So everything checks out. (a-side: would Wii be considered multicore? Starlet is an ARM processor, right?)
* (uh oh, you saw this coming, right?) However, there's an ominous note in this section...
NOTE: [snip] Since instruction fetching may bypass the data cache, changes made to items in the data cache may not otherwise be reï¬,ected in memory until after the instruction fetch completes.
hmm...what exactly does this mean?
Also, what areas should be protected with isync? How would we identify a place that should be protected, but isn't?
Regarding malloc, what I wanted to do was patch the code handler to allow a new command. This new command would malloc, then copy the existing code list over to the malloc'd area, and then adjust then re-patch the code handler to point at the new code list. However, it would require the debugger to be running, so only USB Gecko users would benefit.
So I wouldn't need these codes if I only work on making RAM codes and porting ASM codes right? I hardly use the Debugger/Disassembler.
If you use the USB Gecko *at all*, then you're using the debugger, and you should use these codes to prevent errors in communication.
EDIT:
Here's an example of why you need these codes. You use the Search tab, right? Use a version of Gecko.NET that doesn't have search dump verification, or you can even use WiiRDGUI.
Pause the game, do an unknown search on MEM1, then an equal search. All memory should remain the same because the game is paused. You should get 24MB = 25,165,824 bytes, and if you do 32-bit searches that means you get 6,291,456 results. Keep the game paused, and keep doing equal searches. Eventually, you will lose results. Probably by the fifth dump. This is the tx bug corrupting your search.
Ah I see. But is using these codes absolutely necessary then? I haven't had any issues like the ones strakn and the other guy did in the other thread.
I'm still running with an original usbgecko and using the latest geckodot.net and wiirdgui if that helps.
edit: Hmm, I haven't used the 'equals' search repeatedly very often to be honest.
I'll have to play with a code and its RAM and see if that'll do anything then.
That's just the easiest way to definitively prove the presence of the tx bug. It will always hit you, no matter what type of searches you do. Older Gecko.NET is very susceptible to this bug, and you'll lose a lot of search that way. WiiRDGUI still loses data, just not as much. Newer Gecko.NET verifies searches as a workaround.
They aren't "absolutely necessary". But I bet you have had issues, it's just that WiiRDGUI and Gecko.NET have workarounds implemented in them that you're unaware of. For instance, you send cmd_readmem to the Wii, and you don't get a reply because of the RX Bug, the app will just send the cmd_readmem again.
If you don't believe me, go to the Logs folder and look at the GDNDebug.log files. You'll see EUSBGeckoExceptions. Those are examples of the RX and TX bug being worked around.
All right. So the idea then is to send these codes first before I do any search dumps then. I'll have to try it out then.
Yeah, they should be the first in the list of codes to apply, and you should apply them to every game. WiiRDGUI might bug out if you apply C2 codes more than once.
The next rev of Gecko.NET will automatically patch the code handler for you behind-the-scenes.
Do you have an ETA for when that'll come out?
http://wiird.l0nk.org/forum/index.php/topic,4886.msg68243.html#msg68243
Quote from: WiiPower on April 17, 2011, 01:55:33 PM
Sorry, i didn't think this through, if it's only debugging related, then the less code lines do not matter. I can't help you with the malloc, but for gamecube i'm reducing the available memory for games by 16KB and it seems to work stable. If that works for Wii games, it would need to be implemented in the loader, so i guess it won't help you much. But if you would start using either, wouldn't that have a good chance to move some memory locations used in codes? While a malloc on a button press or such would be disastrous.
Something else i thought about:
Does the code handler currently flush the data cache? Or invalidate the instruction cache? I could imagine that if one or both is not done, it could explain some crashes(if there are) that occur randomly/eventually if the game runs long enough. Well, maybe i'm too naive and i'm overlooking something important.
Hey WiiPower, that reminds me, was meaning to ask you if you could add a feature to GeckoOS Mod (and the associated loader that I can't name on this forum) that reserves 16KiB or 32KiB and redirects the code list there. According to Fuzziqer, doing so doesn't screw up codes (at least, it works fine on GameCube), except for the FST codes (which can be easily recalculated). That would be a nice way to get extra code space. (Also, any idea when you might be able to integrate the new code handler for GameCube that I sent you?)