Can you fix the Makefile as well, please?I pushed Matt's kexploit fix, it should now work within like 3 times, usually first try.
https://github.com/wiiudev/libwiiu
You should be using cygwin anyways, I don't see an issue.Can you fix the Makefile as well, please?
Just pick a Makefile from any example and use it instead of the osdriver exploit's. This is needed in order to build the exploit on *NIX, because the current Makefile relies on "cygpath"...
Cygwin is for Windows only. Why put a UNIX-like environment in a UNIX-like OS?You should be using cygwin anyways, I don't see an issue.
its just my browser shutdown code added isnt it lol, or is there anything I missI pushed Matt's kexploit fix, it should now work within like 3 times, usually first try.
https://github.com/wiiudev/libwiiu
Pretty much. Dunno why that plus changing CPU2 to 92 makes it work so well but it does o,oits just my browser shutdown code added isnt it lol, or is there anything I miss
That function doesn't work with TCPgecko and 5.3.2. It's perfectly normal for it to crash.When I attempt to use the "Read FSA" button in TCPGeckoDotNet, It disconnects from the WII U. I can't reconnect to the WII U no matter what I do. Its almost as if it crashed the CodeHandler on the WII U or something. Anyone know why this happens?
You need the unmodified codehandler, I'll throw up some hosted stuff in a bit.When I attempt to use the "Read FSA" button in TCPGeckoDotNet, It disconnects from the WII U. I can't reconnect to the WII U no matter what I do. Its almost as if it crashed the CodeHandler on the WII U or something. Anyone know why this happens?
Thank you for clearing that up. So for now Owners of 5.1.0 Wii U is SOL for now, unless the Wii U it get updated 5.3.2.You need a 5.0.0 installer. You should ask Marionumber1.
E:\>ping 192.168.1.60
Pinging 192.168.1.60 with 32 bytes of data:
Reply from 192.168.1.60: bytes=32 time=1ms TTL=64
Reply from 192.168.1.60: bytes=32 time=2ms TTL=64
Reply from 192.168.1.60: bytes=32 time=2ms TTL=64
Reply from 192.168.1.60: bytes=32 time=2ms TTL=64
Ping statistics for 192.168.1.60:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms
E:\paping_1.5.5_x86_windows>paping -p 7331 192.168.1.60
paping v1.5.5 - Copyright (c) 2011 Mike Lovell
Connecting to 192.168.1.60 on TCP 7331:
Connection timed out
Connection timed out
Connection timed out
Connection timed out
Connection statistics:
Attempted = 4, Connected = 0, Failed = 4 (100.00%)
Approximate connection times:
Minimum = 0.00ms, Maximum = 0.00ms, Average = 0.00ms
Terminate batch job (Y/N)?
You guys have to wait for Cafiine's app to go public. There's no releases for 5.3.2's app.
My guess is that you are in the same boat as me, except in need of 4.0.0 installer. So you need the installer for 4.1.0 Wii U, and that is probably why TCPGecko cannot communicate. You might have to update to 5.3.2 in order to use TCPGecko or PyGecko. But then again, I could be wrong, very wrong XD.Speaking of codehandler, my Wii U is version 4.1.0U and I could run the kernel exploit, however, I cannot connect using TCPGeckoDotNet (various versions including from dantarion, NWPlayer123) as well as using tcpgecko.py library to Wii U after running the PyGecko4. I have tried multiple times and followed the guidelines (i.e. reopening the browser after running PyGecko4). I even have recompiled PyGecko using codehandler410.h (instead of using codehandler532.h).
Does anyone have Wii U with version 4.1.0U and successfully able to connect using TCPGeckoDotNet? If you could share your PyGecko (not the kernel exploit) payload410.html as well as your version of TCPGeckoDotNet that would be great help.
Thanks in advance.
I check with ping, PC could see Wii U:
Code:E:\>ping 192.168.1.60 Pinging 192.168.1.60 with 32 bytes of data: Reply from 192.168.1.60: bytes=32 time=1ms TTL=64 Reply from 192.168.1.60: bytes=32 time=2ms TTL=64 Reply from 192.168.1.60: bytes=32 time=2ms TTL=64 Reply from 192.168.1.60: bytes=32 time=2ms TTL=64 Ping statistics for 192.168.1.60: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 2ms, Average = 1ms
And with paping (to check the port 7331 and PC could NOT see that Wii U port open):
Code:E:\paping_1.5.5_x86_windows>paping -p 7331 192.168.1.60 paping v1.5.5 - Copyright (c) 2011 Mike Lovell Connecting to 192.168.1.60 on TCP 7331: Connection timed out Connection timed out Connection timed out Connection timed out Connection statistics: Attempted = 4, Connected = 0, Failed = 4 (100.00%) Approximate connection times: Minimum = 0.00ms, Maximum = 0.00ms, Average = 0.00ms Terminate batch job (Y/N)?
There's already a userland and kernel exploit for 5.5, they are just not released yet. The userland exploit is the same as the one for 5.4, and there's at least one more kernel exploit that wasn't patched.Hopefully 5.5fw exploit found one day. Have a 5.5fw nand backup but didn't know about nandmod until stupid wiiu updated. Will test downgrade once a new firmware is out.. if works like 3ds those with soldering experience will be able to easily keep exploit nand and latest nand and flash between