wiiudev / libwiiu Goto Github PK

I have a Wii U with firmware 4.0.2 and the OSDriver kernel exploit doesn't seem to be implemented on it yet. I got hinted at https://github.com/wiiudev/libwiiu/blob/master/kernel/osdriver/src/loader.h which defines variables and their kernel version specific values however the VER == 400 branch has all definitions set to 0. This made me realize why all of my attempts in running the kernel exploit failed with either a freeze or with a race attack failed message. Note that I'm willing to help finding the correct addresses if someone guides me in the right direction. This feature request obviously is of low priority but I prefer not to update to a higher firmware at all though and still get the kernel exploit to work.

hi, so I played around with GX and found a bunch of functions just not working on 5.3.2, they work fine on my 3.1.0 wiiu though, heres the whole source code for the stuff I tested today:
http://pastie.org/private/fea59vdoavqdb6m7ymmkg
in the last while loop line 141 I commented it. all of these functions have something to do with time, let it be OSSleepTicks or OSSleepThread or just OSGetTime.

There is a solved issue regarding this but it wasn't really solved, a comment from @MarioNumber1 #9 (comment) explains why the issue is occurring.

I can't get osdriver to work on my 5.3.2 wiiu after having it working every time previously and there's quite a bit of advice floating around surrounding this so I'm just going to list what I've tried and some questions that I have.

wiiu history is a Lego City Undercover bundle upgraded to 5.3.2 using Splatoon.

Originally it took me 20~ attempts to run the exploit successfully the first time, every attempt up until the time that it worked froze the browser bar half way and then put some artefacts on the screen and locked up the console, requiring a hard reset. Every time after the first successful attempt it would succeed or fail the race attack with the correct error message.

Then I compiled loadiine myself to skip some of the screens and changed over to self hosted exploits rather than using the wiibrew address I had used previously. I thought that I should probably clear out all the wiiu browser settings in the process of switching over to use my own .elfs - and now I can't get the (unchanged) osdriver exploit to run reliably.

Some questions I have -
Does server speed matter for the exploit?

Are we aiming to have more memory used or less when the exploit runs?
(I would say that less is better as I have seen reports of the exploit working when the quick start menu is used on the Wii controller, I have also experienced this however it doesn't seem to 'cache' the exploit like it did the first time I succeeded in running it.)

How can I debug this further? I know little about how this works at the moment but if I can help at all I will.

When I load any example, my Wii U crashes without loading anything on screen.

I'm on 5.3.2U.

libwiiu/src/coreinit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libwiiu/src/coreinit.h b/libwiiu/src/coreinit.h
index 5753a21..a6bde0c 100755
--- a/libwiiu/src/coreinit.h
+++ b/libwiiu/src/coreinit.h
@@ -24,7 +24,7 @@
#define OSFatal ((void ()(char msg))0x0102D01C)
#define __os_snprintf ((int()(char s, int n, const char * format, ... ))0x0102b9ac)
#elif VER==500
-#define OSDynLoad_Acquire ((void ()(char rpl, unsigned int handle))0x01029CD8)
+#define OSDynLoad_Acquire ((void ()(char* rpl, unsigned int handle))0x01029F70)
#define OSDynLoad_FindExport ((void ()(unsigned int handle, int isdata, char symbol, void *address))0x0102B3E4)
#define OSFatal ((void ()(char* msg))0x01030ECC)
#define __os_snprintf ((int()(char s, int n, const char * format, ... ))0x0102ECE0)

When there are spaces in the file path of the project libwiiu-master, build.py doesn't function properly e.g. it aborts creating any html files in the www directory. This kinda is a pointless bug report but it would be great if it gets fixed nevertheless.

...would be very nice. Not good enough at programming and reverse engineering to port it myself. Counting on you guys! (needed for loading binaries >16-20kB with yellows8's exploit)

Many user (me too) are having a black screen all time they run it.

A lot of poeple are on 5.4.0 and waiting for official kernel support and other app....

When I compile most recent kernel exploit,I receive error like:

IOError: [Errno 2] No such file or directory: '/libwiiu-master/kernel/osdriver/bin/code200.bin'

Makefile:18: recipe for target 'libwiiu532' failed

make: *** [libwiiu532] Error 127

Its also doesn't work when replacing makefile...

Edit: Forgot to say that I am on ubuntu 15.10.Also,here is the log when I do "python build.py kernel/osdriver" :

http://pastebin.com/7NDE9k6U

Hi,

first of all, thank you for putting this up on GitHub!
I just tried to cross-compile the example project ("helloworld"), but received the following error:

root@do3:/tmp/libwiiu# python build.py examples/helloworld/
Building for your linux platform...
mkdir -p /tmp/libwiiu/framework/bin
# Build findcode
powerpc-eabi-gcc -nostdinc -fno-builtin -c -DVER=500+ /tmp/libwiiu/framework/src/findcode500.c
powerpc-eabi-gcc: error trying to exec 'cc1': execvp: No such file or directory

I downloaded the devkitPPC, which worked fine. There seems to be a problem with my environment. Can you help me out here? I couldnt find any documentation on how to compile the samples.

Thank you in advance!

Regards,

Timo

After adding 5.3.2 support, I tested various example projects, including the multithreading one. Trying it, I noticed a crash, which I traced to the OSAllocFromSystem(6,1) call that creates a string buffer. Removing this call makes everything else in the demo work fine. There appears, rarely, to be some crashing rather than _Exit() being called, but this is most likely due to the unreliability of the underlying exploit. It is worth going through OSAllocFromSystem() and evaluating why it would crash.

@MarioNumber1 Thank you for adding the OSDriver exploit 😊
I'm having issues compiling kernel/osdriver on my PC because the Makefile depends on cygpath.
Line 6:

override CURDIR:=$(shell cygpath -m $(CURDIR))

When I build the project, I get:

make: cygpath: command not found

I'm very sorry, but I don't know how to fix this without breaking Cygwin...

I tried out the OSDriver exploit but after about 10 tries it never worked. It either froze or displayed weird dashes on the screen instead of a proper message so I figured hey, maybe the OSFatal() function is somehow broken so I tried running the hello world example and it confirmed the assumption. It displayed weird dashes. Take a look at the following picture:
http://fs2.directupload.net/images/150828/7gfb4hzh.jpg
This is captured from the TV screen. Note that the dash patterns are different every time the example is ran.

Also note that I tried http://wj44.bplaced.net/ and my own local files that I just compiled with the newest repository versions. Same result.

On firmware 4.0.2 E the hello world example worked perfectly and the OSDriver exploit was pretty reliable but not fully working, see this issue for details: #22

A possible explanation of the oddity might be that I updated using the Splatoon disk and not the online updater. Maybe it is different from the regular 5.3.2 E?