Wii U Plugin System TCP Gecko

A lot of people were looking forward to the TCP Gecko plugin for the Wii U Plugin System.

So far I didn't start working on it (neither did anyone else) but I'm going to write down a few of my plans below:

• Implement a multi-threaded server for handling multiple TCP connections at once (for instance like described here). This will allow you to connect multiple cheat tools at once and it would make the server more stable and won't force you to restart your Wii U or the TCP Gecko if it corrupts or gets stuck as before.
• Implement the code handler in C/C++ instead of assembly to make it more maintainable for improvements and changes (I already made a functional Windows C code handler here).
• Since allocating memory on the heap in the homebrew app code shifts most cheat code addresses, this problem has to be addressed: We need to read the segment information to find the base address of each segment and then create cheats using the start address plus an offset to be shift resistant (Read more about the memory layout of C programs). Here is a write-up by Maschell about this "cheat codes problem". Making the change would mean that all of most codes have to be re-created or ported over to relative addressing. Code creators need to learn how to make cheats using relative addressing then but it's pretty simple once a respective utility is implemented (in e.g. JGecko U) so it's just a matter of a few clicks from the absolute address.
• By default when making the TCP Gecko a plugin, this will enable you to use multiple homebrew apps at once such as the other already created plugins which is really nice to have available at the same time. This is one of the main things people wanted.
• Reading memory has been slow (about 15 minutes to dump the entire MEM2 range) so with the plugin we might be able to use zlib for compression and 3 threads to accomplish a speedup (3 threads because the Wii U has 3 cores without hyperthreading I believe). Sending data cannot be parallelized but compression.

If anyone wants to contribute something or start this project, you're welcome to do so. I will not have time before August 1st but then I can spend some time working on it. Again, without any contributions this might take a while to finish and go public since it's pointless to release a semi-functional version which does not fully support all existing JGecko U features and such so you would trip into a minefield.

What about JGecko U and other existing TCP Gecko tools?
JGecko U will continue to work almost exactly the same since the server commands should be kept (minus a couple redundant ones which may get deleted). Other tools may need to be modified if they are using commands which got removed. This is to clean up the plugin from unnecessary junk such as writing memory using byte, short, int or other special sized data types. Just writing a byte array is all what is necessary to support. The client code can then decide to implement those data type wrappers or not. Also, the addresses would all be shifted anyway so existing tools once more wouldn't even work without being fixed for that particular purpose.

A video showcasing the progress


That's all for now. Any questions, ideas or planned contributions?