Yeah really. We've got ethernet (via adapter), wifi, USB, Bluetooth, and SD card, and we need to buy some other device to connect to it?
| Kodewerx https://www.kodewerx.org/forum/ |
|
| I'm going to assume you all have looked into it before... https://www.kodewerx.org/forum/viewtopic.php?f=11&t=5577 |
Page 1 of 1 |
| Author: | Andydark [ Mon May 05, 2008 11:15 am ] |
| Post subject: | I'm going to assume you all have looked into it before... |
But out of curiosity, what's the word on Gecko? It apparently is a USB add in that does funtastical things with the Wii games, I haven't been able to find much on it though. Probably ancient news, but just figured I'd ask if you all thought it was an adequately intelligent investment. Quote: 1.0 Beta Five (Change log) 1. Wii Mode hooks (can hook Wii Games as well as Gamecube Games) 2. Gamecube and Wii Cheat engine with own custom code types (upload cheat code patches Gamecube and Wii!) 3. Cheat Engine running with debugging engine to allow realtime code edits (Run list) 3. Upload code added to Remote debugger (can now upload binary files to running memory) 4. Hex Mode added to debugger (Switch from Asm to HEX etc, can scroll up and down hex windows also in memory!) 5. Wii Screen shots working Cheat code system, code types and information can be found on the forums, tutorials for these will be added to the site download section very soon. It SOUNDS promising to a n00b like me... |
|
| Author: | dexter0 [ Mon May 05, 2008 12:38 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
I have been using it to create some will codes for Brawl and Galaxy. It's a very nice device but the remote debugger needs some work. |
|
| Author: | Andydark [ Mon May 05, 2008 2:49 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
So would you say it has a future? I've been intrigued myself, I've heard that they're looking into eliminating tripping from Brawl... But eh. I managed to pick this up that posted a link to an article about it, could you by chance provide me with some more information? |
|
| Author: | dexter0 [ Mon May 05, 2008 4:36 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
I am writing a tutorial on how to hack games with it which will be similar to my DS Hacking Guide. I would say that what Nuke needs to do is work out a way to make the SD Gecko able to run a cheat engine on its own or build a cheat engine into his region free that does not require the Gecko. Right now it is more of a hobbyist/programmer tool. It's not marketable to your average user in the way that say an Action Replay Wii would be. It would be like Datel selling only the Trainer Toolkit and no standalone Action Replay. If you want more info join us at the forums. http://www.usbgecko.com/forums/ |
|
| Author: | Hextator [ Tue May 06, 2008 8:09 am ] |
| Post subject: | |
dexter0 wrote: ...or build a cheat engine into his region free that does not require the Gecko. That's what I want to do. I don't want to spend $40 on that thing if I can avoid it. I wish he'd make more of his stuff open source. At least share the IOS calls you used to restart discs and patch their executables! D: |
|
| Author: | HyperHacker [ Tue May 06, 2008 8:49 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
Yeah really. We've got ethernet (via adapter), wifi, USB, Bluetooth, and SD card, and we need to buy some other device to connect to it?
|
|
| Author: | Hextator [ Wed May 07, 2008 9:43 am ] |
| Post subject: | |
I've got IDA Pro working on the boot.elf. The function tree functionality of IDA Pro is truly a sight to behold.  I haven't identified any of the IOS function calls yet, but I have a few educated guesses of what's going on. It certainly helps that I can just click on an immediate labeled "Insert Wii game" to jump to the location in memory the immediate is stored at, and then click on the reference label IDA Pro puts next to it to see where the message is loaded and printed in the executable. 
|
|
| Author: | Parasyte [ Wed May 07, 2008 5:26 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
I hear Kenobi has been participating in its development, or at least keeping a watchful eye on it. |
|
| Author: | kenobi [ Thu May 08, 2008 9:35 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
Indeed. I personally really like it even if it has many flaws righ now. The possibilities it offers reminds me the blessed, old good gcnrd days... So I'm trying to help Nuke and Y.S. (which created the code handler used by the gecko) as much as I can. |
|
| Author: | HyperHacker [ Fri May 09, 2008 12:50 am ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
So help the rest of us out and at least describe how one goes about loading discs? |
|
| Author: | Hextator [ Fri May 09, 2008 8:51 am ] |
| Post subject: | |
Yeah. I didn't even know /dev/es had to be accessed before /dev/di (I'm assuming it does, since Nuke called the ES_GetTicketViews function and the like). There's some IOS_Ioctl call in there with arguments I don't recognize even with the reference on Wii Brew, too. Also, code handler? It has a code handler now? ;_; |
|
| Author: | kenobi [ Fri May 09, 2008 9:27 am ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
If I knew I would tell you, but I really don't know. I'm actually only helping on the "debugger" part, ie. the one that runs along the game. Not the part that loads the disc... And yes, it has a code handler since 1.5 (afaik). |
|
| Author: | kenobi [ Wed May 14, 2008 10:47 am ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
Well as the news is kinda out know, I think it would be nice I would let you know what it is about (even if I know some of you might not be interessed in buying the gecko). I'm posting in this thread as I just said in the above post I am working on something, and I don't see the point of making a thread about it right now. Link and I are working on WiiRd/WiiRd GUI. For the story, Link contacted me 2 weeks ago, and told me he ported to Delphi (he's a Delphi programmer too) the communication protocol to dialog with the USB Gecko. No need to say that when I heard that I though of WiiRdGUI. As he"only" had to focus on the command line tool (WiiRd) and I "only" had to port gcnrdgui to make it workd with WiiRd, the first results were fast. In 3/4 days,we had most of the thing working. We asked meanwhile Nuke and Parasyte what theythough of the project, and they had no problem with it. However the easy part was behind. Now we're working on the bugs correction, the new features... And it takes a lot of time (especially with my poor programming skills - it seems I love to put some crashing bug in any new thing I add). The basics are working (code searching, memory viewer, disassembler, screenshots...) but now I'm spending some time on breakpoints support and it's another matter. So we're working hard to go as fast as possible, but there is no real ETA. It should be out before the end of the month (be it a semi stable beta, or a realfirst release). |
|
| Author: | HyperHacker [ Thu May 15, 2008 2:02 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
So Delphi and Gecko? Ew. Look at the TCP loader, there's a LAN port and information on how to use it. |
|
| Author: | Link [ Sat May 17, 2008 5:53 am ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
HyperHacker wrote: So Delphi and Gecko? Ew. Look at the TCP loader, there's a LAN port and information on how to use it. Ew? Well, I chose Delphi simply because I know that programming language best. And the Gecko data is written mostly in PPC ASM anyway, Delphi is doing the connection on PC side. I personally like the way via Gecko because: if you'd choose games using the network interface code might become itchy to work on - the Gecko is dedicated and independent of all other things (might be however blocked though) - and I technically only ported the Gecko Memory Dumper source and then kenobi and me hacked the other Gecko commands and slowly but progressively developed a program around it - some information can be read at http://www.usbgecko.com/forums/showthread.php?t=347 |
|
| Author: | IAMASOMBODY [ Sat May 17, 2008 8:56 am ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
I am wondering Does the WiiRd requires USB GECKO in the future? I would really like to use my Wi-Fi connection without the wires dangling all over the place. As mentioned earlier in the post "even if I know some of you might not be interested in buying the gecko" that is true, I have the Twilight Hack in place with the Homebrew channel and want to use that instead. I am also wondering if the GCN Datel Memory Card will work, I ordered one way back when and never used it. It has a port on the card for connection for USB. |
|
| Author: | kenobi [ Sun May 18, 2008 1:37 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
I guess wiird only supports the gecko because it's the only public way of communicating with the Wii at that time. Also, unlike Parasyte's gcnrd, wiird is only a PC-side software. The Wii software is basicaly the gecko software. And of course the gecko software uses the gecko hardware. Which means right now no gecko hardware, no wiird/wiirdgui. In order to communicate with the Wii using wifi for exemple, someone would have to write a program for the wii that can send/receive data and run in the background. Once it's done, I believe wiird would just have to send the good commands to the wii using the network (and wiirdgui would just need some tweakings to accomodate). So yeah, in the future everything might be possible. And I've no clue if the gcn datel memorycard could replace the gecko (but I honestly doubt it). |
|
| Author: | IAMASOMBODY [ Sun May 18, 2008 9:59 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
Thanks for the reply, I ordered USBGekko, just because I have the $$$ to burn.  And so that I can use wiird when it is ready. |
|
| Author: | lemmayoshi [ Mon May 19, 2008 12:41 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
Amazing. I can't wait. Just a note: It'd be great to see a "Not for GSCentral" tag somewhere in the program 
|
|
| Author: | kenobi [ Mon May 19, 2008 3:01 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
I'm not fond of the "not for..." message. I usually prefer to put something like "kodewerx rulez" somewhere. The more you talk about someone/thing, even in a bad way, the more publicity he/it gets. Look at Paris Hilton and Britney ^_^ Anyway, things are going slowly but surely... Most of the problems have been solved, but the task is still huge. Hopefuly I've taken some vacation to speed up the progress on the GUI/Gecko ! I guess we're still aiming for a "before the end of the month" release, but as we keep on adding/changing things each time we got a new idea, I can't make any promise. |
|
| Author: | lemmayoshi [ Tue May 20, 2008 8:22 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
Great. I'm looking forward to it  *buys USB Gecko* |
|
| Author: | Hextator [ Wed May 21, 2008 1:25 pm ] |
| Post subject: | |
HH says he did ask for the source and that Nuke didn't respond. Dodgy, are we? |
|
| Author: | HyperHacker [ Wed May 21, 2008 5:36 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
Is it GPL or LGPL? One would require source to be released, the other wouldn't. I've seen a few Wii apps without source. Does the app work without the Gecko plugged in? |
|
| Author: | Hextator [ Wed May 21, 2008 6:43 pm ] |
| Post subject: | |
The Region Free ELF? Yes, it does work on its own. Also, I'm pretty sure libogc is just plain GPL. Isn't LGPL the one that doesn't require the source? But either way, I admitted to not understanding the license business. It just appears to me there may be a catch here. Edit: http://pastebin.com/f5e1db9ee Edit: I've pretty much confirmed that Nuke used that snippet from Dolwin (or something that mimicks Dolwin exactly) for his apploader loader (yes, he loads the apploader from the disc and uses that to load the Wii DOL instead of writing his own apploader like he said he did...or maybe he thought "apploader loader" sounded funny (I do) and just called it an apploader anyway). The function he "copied" is in /SRC/HighLevel/Bootrom.cpp of Dolwin and is called "BootApploader". Edit: If those of you working on wiird/GUI know of a way to implement break points (well, watch points, from what I've seen in a USB Gecko video) without the USB Gecko hardware, please let me know >.> |
|
| Author: | Parasyte [ Fri May 30, 2008 4:57 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
Look at PowerPC registers IABR and DABR. |
|
| Author: | Hextator [ Fri May 30, 2008 9:04 pm ] |
| Post subject: | |
HH suggested I paste this info in case someone is able to do something with it. The source I linked to in my previous post implements most of what is labeled here: http://pastebin.com/f1d54a6f2 Edit: You wouldn't happen to know the names of any mnemonics that can access the registers you're talking about, would you? |
|
| Author: | Parasyte [ Sat May 31, 2008 11:28 am ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
Sounds like you are missing the IBM Gekko User Manual as well as some other very important PowerPC documentation, including "PowerPC Microprocessor Family - The Programming Environments". Who do you think I am, any way? Of course I know. Code: void PPCmtdabr(u32); void PPCmtiabr(u32); Code: PPCmtdabr: mtspr 1013, r3 blr PPCmtiabr: mtspr 1010, r3 isync blr The gist of it is, you call PPCmtdabr(), passing a word as the only argument, which is the address you want the PPC to watch for reads/writes to. Bit 0 enables breakpoints on read accesses, bit 1 on write accesses, and bit 2 enables breakpoint address translation, which is very handy if you also handle virtual memory address translation. Any way, the granularity on watchpoints with DABR is 8-bytes, as you should be able to guess from those bit settings. To prevent a lot of false positives (from memory accesses occurring withing that 8-byte block that you do not care about) just check the value of the DAR register in your DSI exception handler. You can also check the DSISR to verify the condition which caused the DSI exception. Using PPCmtiabr() for instruction execution breakpoints is similarly easy, but slightly different; Bit 0 enables translation, bit 1 enables the breakpoint. The granularity is 4 bytes, which is OK considering that every instruction is already 4 bytes long. The exception to handle is the special IABR exception. And continuing execution from any of these breakpoints is only possible with the breakpoint disabled. If you want to continue execution while leaving the breakpoint enabled, you must fake it by disabling it any way and enable trace-mode to step the instruction. Once back in your exception handler, disable trace mode, re-enable the breakpoint, and finally let it continue on its way. |
|
| Author: | Hextator [ Sat May 31, 2008 1:06 pm ] |
| Post subject: | |
Argh, I feel dumb. I was messing with devkitPPC trying to compile mtspr1013 %r0 thinking that it was similar to the opcode and operand set up for the mtctr %register opcode (yes, I realize no mnemonic would deign to be that ugly, but I wanted to make sure...). I suck at using sprs. I did find documentation on what registers will hold what information in the event of a DABR related DSI, but now I have to learn how to catch DSI exceptions and possibly do that trace mode business. Or at least I would, if it mattered. At the moment I can't execute DOLs I've loaded, so patching them to add break points or even a simple trainer is pointless. I wouldn't mind being able to catch a program exception though. Executing the prolog portion of the apploader throws a program exception the first time, for me. |
|
| Author: | Parasyte [ Mon Jun 02, 2008 7:36 pm ] |
| Post subject: | Re: I'm going to assume you all have looked into it before... |
You have to patch the exception vector(s) to intercept any exceptions. |
|
| Page 1 of 1 | All times are UTC - 8 hours [ DST ] |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|