Feature Request: Kernel Version 400 Support

[BullyWiiPlaza]

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.

[georgeklees]

First, I'd suggest pointing line 186 of loader.c to a two-element uint32_t array that you can check. Then after line 217, print that array to make sure that you control DRVHAX. If we verify that the race attack works, I'll find the 4.0.0 addresses.

[BullyWiiPlaza]

Line 186 assigns the value of KERN_SYSCALL_TBL + 0xD0 which will be 0xD0 since KERN_SYSCALL_TBL is 0 when not implemented. Why two elements in the array if that value can fit into one? Also printing it out must be done in a single OSFatal call which requires some sort of String concatenation to cover both elements. Here's some standard C code that kind of does what you're suggesting (I wrote it, even though it might be useless after all): http://pastebin.com/kYUU00K1

[TiniVi]

@MarioNumber1 so you're saying something like this should be done?

uint32_t test[2];
copy_payload[0xff8/4] = test; //Line 186

char str[16]; //right after line 217
__os_snprintf (str, 16, "%d %d", test[0], test[1]);
OSFatal(str);

If so, it printed: "0 0" on the first test, and on the second and third test I got: "32768 304".

[georgeklees]

TiniVi: Well, do the first two lines when setting up copy_payload, and the last three after the CopyToSaveArea() of the syscalls.

BullyWiiPlaza: What is 186, stuff has moved around.

[TiniVi]

@MarioNumber1 That's exactly what I did, I purposely used a previous version based on the date and time of your comment. The results are still up there, but I can quote them:
"If so, it printed: '0 0' on the first test, and on the second and third test I got: '32768 304'."

[georgeklees]

I would suggest initializing test to contain two distinctive values (like 0xDEADBEEF) at the start, so you can see if it was modified.

[TiniVi]

uint32_t test[2] = {0xDEADBEEF, 0xFEEDC0DE};

With this change I got: "-559038737 -179" three times.

[georgeklees]

Keep trying, and see if it's ever zeroes.

[TiniVi]

I still get the same value, I'll try updating to the newer loader.c and see if that does me any good.

[TiniVi]

Alright, on the second try with the updated loader it printed 0s.

[georgeklees]

Change KERN_CODE_READ and KERN_CODE_WRITE to something like 0xC0DE, and see if those ever get written in the buffer. If so, it's a pretty good indication of race success.

[TiniVi]

#define KERN_CODE_READ 1234
#define KERN_CODE_WRITE 4321

It printed: "1234 4321" on the first try

[TiniVi]

I decided to take a look at the kernel image myself and, unless I'm mistaken, the addresses should be:

#define KERN_SYSCALL_TBL 0xFFE85890
#define KERN_CODE_READ 0xFFF02214
#define KERN_CODE_WRITE 0xFFF02234
#define KERN_ADDRESS_TBL 0xFFEB7E5C
#define KERN_HEAP 0xFF200000

EDIT: It didn't take that long, so If the above is accurate, here's some for more versions: http://pastebin.com/5j2VazVU

[BullyWiiPlaza]

I was going to update using the Splatoon disk but if these are accurate I probably won't. Thanks for posting mate :)

[TiniVi]

Just tested, it worked fine for me.

EDIT: Launching an app afterwards seems to crash the system... I can't see any issues with the addresses... @BullyWiiPlaza does it work for you?

[BullyWiiPlaza]

Yes, it worked the 2nd try (redirected me to the home menu) but then it froze when I tried to launch the Internet Browser again. Something must be wrong :(

[georgeklees]

The Internet Browser froze on load?

On Thu, Aug 27, 2015 at 2:10 AM, BullyWiiPlaza notifications@github.com
wrote:

Yes, it worked the 2nd try (redirected me to the home menu) but then it
froze when I tried to launch the Internet Browser again. Something must be
wrong :(

—
Reply to this email directly or view it on GitHub
#22 (comment).

[BullyWiiPlaza]

Yes indeed. Still stuck on the Wii U typical app loading screen.
http://fs1.directupload.net/images/150827/3v6gju2t.jpg

[georgeklees]

Try commenting out the two kern_write() calls that edit the kernel address table. I suspect something wrong with the address table is causing this.

[georgeklees]

TiniVi: Could you paste the 4.0.0 address table here? It may be different from other versions (though this seems unlikely).

[TiniVi]

Yeah, that stops the crashing.

[georgeklees]

Yeah, but we need that address table modification for TCPGecko and Cafiine installation, as well as other useful things.

[TiniVi]

Like the raw table? http://pastebin.com/rGLziS34

[TiniVi]

I figured it was important. Cafiine would be fun to have.

[georgeklees]

The 0xA0000000 mapping is located where it is in current versions, so setting the addresses in the table should work just fine. I'm not sure why it would cause the app to fail to start, unless the table has more entries and we run out of BAT registers. I'll investigate this more later.

[TiniVi]

Alright, keep me posted.

[TiniVi]

So I disabled:
kern_write(KERN_ADDRESS_TBL + (0x12 * 4), 0x31000000);
and it let me run apps. I'm going to try disabling the other but re-enabling this one to see if I get the same effect.

EDIT: Yeah they don't crash apps alone, but they do together.

[BullyWiiPlaza]

Are there any news on the correct KERN_ADDRESS_TBL address? Sorry for the bump but I'm literally waiting for this to be resolved because otherwise I personally would just use the Splatoon disk update. Thanks guys :)

[TiniVi]

@BullyWiiPlaza As I understand it, the address is fine, the issue has something to do with writing two addresses to the kernel. I don't know how to fix this (I do have some ideas on how it might work, but that's irrelevant), so you'll have to wait on @MarioNumber1

[TiniVi]

@MarioNumber1 I see the kernel addresses are defined for 3.0.0, is it operational with it? I just wanna know if this is a 4.0.0 issue or a general <4.1.0 issue.

[FIX94]

I assume that the memory mapping depending on the firmware is just different, for my 3.1.0 it looks like this to get it to not crash:
#if (VER == 310)
kern_write((void_)(KERN_ADDRESS_TBL + (0x12 * 4)), 0x30000000);
#else
kern_write((void_)(KERN_ADDRESS_TBL + (0x12 * 4)), 0x31000000);
#endif

[TiniVi]

Well, that seemed to have fixed it. I can boot into other applications now. This is great ^^, I can finally take a LONG needed break from 3DS stuff.

[Relys]

Looks like this was fixed so I'm closing it: https://github.com/wiiudev/libwiiu/blob/master/kernel/osdriver/src/loader.c#L299