Hacking Wii U Homebrew Situation and FAQ

[TheChield]

Thank you for your answers

This means that only the Cafe OS kernel gets direct access to the IPC memory region.

I thought the web browser exploit can make a stack attack ? (what core ?)
It it the "user space" limitation that disallow the "well" defined jump to corrumpt ARM stack ?
Do all core have the same right access ?
Do all core have the same stack ? (well stupid question...)
Corrupt "stack3" then corrupt "stack2" then corrupt "stack1" then corrupt "stack0" (ARM) then "profits" ?

 

[Marionumber1]

I thought the web browser exploit can make a stack attack ? (what core ?)

The WebKit exploit is not a buffer overflow, it's based on a use-after-free vulnerability. The use-after-free allows us to create a virtual method table in Javascript, which the WebKit code uses to make a virtual method call. The virtual method call goes to an address that we control from Javascript, beginning execution of the ROP chain. All of this happens on core 1 (the second core).

It it the "user space" limitation that disallow the "well" defined jump to corrumpt ARM stack ?

Being unable to access the IPC memory region doesn't prevent us from exploiting vulnerabilities in ARM code, but it may make it more difficult.

Do all core have the same right access ?

Yes, unless one of them performs a kernel syscall or loader call. These will temporarily elevate its privileges, but this privilege elevation is designed to make sure that the cores only go to addresses controlled by the kernel. A kernel or loader exploit would allow us to elevate the privileges of our code.

Do all core have the same stack ? (well stupid question...)

Each thread has its own stack, and no two cores can run the same thread at the same time.

Corrupt "stack3" then corrupt "stack2" then corrupt "stack1" then corrupt "stack0" (ARM) then "profits" ?

More like this:

1. Use a WebKit exploit to get code execution in PPC userspace.
2. Elevate privileges to PPC kernel-mode through a kernel-mode vulnerability.
3. Exploit a vulnerability in an IOS module to get code running in ARM userspace.
4. Exploit a vulnerability in the IOS kernel to get code running in ARM kernel-mode.
5. ???
6. PROFIT!!!

 

[TheChield]

Each thread has its own stack, and no two cores can run the same thread at the same time.

I know that 2 cores can't share the same threads but threads can attack each other
So the OS Manages stacks for threads ?
Isn't stacks some OSI low level use used by the OS ? (on processor level ?)

More like this:
1. Use a WebKit exploit to get code execution in PPC userspace.
2. Elevate privileges to PPC kernel-mode through a kernel-mode vulnerability.
3. Exploit a vulnerability in an IOS module to get code running in ARM userspace.
4. Exploit a vulnerability in the IOS kernel to get code running in ARM kernel-mode.
5. ???
6. PROFIT!!!

Yes, my dream of finding an hypothetical direct breakthrough to bare metal execution can't be done...
I was thinking to attack a thread that can have been called by some more elevated thread on an other core down to the ARM...

And I never spoke of an overflow, this can't be done...
I spoke about a stack attack (but no "buffer" overflow which is stupid...)

 

[Marionumber1]

I know that 2 cores can't share the same threads but threads can attack each other

I'm pretty sure that threads can overwrite the stacks of other threads in the same process, so yes.

So the OS Manages stacks for threads ?

Yes, when you create a thread a stack is allocated for it.

Isn't stacks some OSI low level use used by the OS ? (on processor level ?)

The stack holds the program execution state and function local variables for each thread.

I was thinking to attack a thread that can have been called by some more elevated thread on an other core down to the ARM...

When a thread performs a kernel syscall or loader call, it switches to a different stack which is inaccessible from normal userspace code. Stacks of ARM threads are also not accessible from userspace code.

 

[TheChield]

When a thread performs a kernel syscall or loader call, it switches to a different stack which is inaccessible from normal userspace code. Stacks of ARM threads are also not accessible from userspace code.

But you said that each thread as it's own stack ? A stack Stacks all returns a dresses (by definition) ? If you manage to corrupt the current stack, their must be some point of "double" return that could corrupt the ARM stack ?

Sorry to ask but you seem to have access to the CAFE OS dump...

 

[Marionumber1]

But you said that each thread as it's own stack ? A stack Stacks all returns a dresses (by definition) ? If you manage to corrupt the current stack, their must be some point of "double" return that could corrupt the ARM stack ?

Yes, you're right about how a stack is used. What I'm saying is that kernel, loader, and ARM thread stacks are located in regions of memory that normal userspace code can't access.

Sorry to ask but you seem to have access to the CAFE OS dump...

No, I don't.

 

[Coto]

But you said that each thread as it's own stack ? A stack Stacks all returns a dresses (by definition) ? If you manage to corrupt the current stack, their must be some point of "double" return that could corrupt the ARM stack ?

Sorry to ask but you seem to have access to the CAFE OS dump...

Still stacks vary (physically) from different ARM cpu status modes. FIQ , IRQ, USER stacks can't access SYS stack (depending on the NX or other protection method running through the SYS thread). There are ways todo stack management through SRS opcode. IF the SYS processor mode allows it

 

[Marionumber1]

Still stacks vary (physically) from different ARM cpu status modes. FIQ , IRQ, USER stacks can't access SYS stack (depending on the NX or other protection method running through the SYS thread). There are ways todo stack management through SRS opcode. IF the SYS processor mode allows it

At this point, we haven't even gotten code running on the ARM yet. We're running in PPC userspace, which can't access ARM memory due to two reasons: MEMPROT and virtual addressing.

 

[TheChield]

No, I don't.

Thank you for all your answers, it's a very interesting thread

 

[Skeet1983]

My System updated to 5.0, even when standby was disabled and the IPs at beginning of FAQ blocked through my Router. What can I do in future to keep system from updating?

 

[Goku Junior]

My System updated to 5.0, even when standby was disabled and the IPs at beginning of FAQ blocked through my Router. What can I do in future to keep system from updating?

I think with blocking IP servers and disable the auto downloading feature is enough.

 

[TheChield]

I think with blocking IP servers and disable the auto downloading feature is enough.

Why not just delete wifi configuration from Wii U ?

 

[GorTesK]

Why not just delete wifi configuration from Wii U ?

because that would disable all online functionalities lol
and some people, like me, use their wiiu to play online and its browser to watch videos, post in forums n stuff ;p

 

[TheChield]

because that would disable all online functionalities lol
and some people, like me, use their wiiu to play online and its browser to watch videos, post in forums n stuff ;p

Ok, I thought the Wii U have to be updated to connect to internet.
I only use mine to play games...

 

[GorTesK]

Ok, I thought the Wii U have to be updated to connect to internet.
I only use mine to play games...

you only need to be up to date in order to use the eshop... you can block updates, if you dont need the eshop and then still use the browser, youtube app, game online functions and other online apps

 

[Skeet1983]

My system updated to 5.0... Am I still safe to use possible Wii U homebrew in the future? Also, I have the following IPs blocked:

96.17.161.145
184.50.229.158
184.50.229.137
nus.c.shop.nintendowifi.net
nus.cdn.c.shop.nintendowifi.net
nus.cdn.shop.wii.com
nus.cdn.wup.shop.nintendo.net
nus.wup.shop.nintendo.net

Are those IPs all I need, or do I need to block more? Thoughts appreciated

 

[Goku Junior]

My system updated to 5.0... Am I still safe to use possible Wii U homebrew in the future? Also, I have the following IPs blocked:

96.17.161.145
184.50.229.158
184.50.229.137
nus.c.shop.nintendowifi.net
nus.cdn.c.shop.nintendowifi.net
nus.cdn.shop.wii.com
nus.cdn.wup.shop.nintendo.net
nus.wup.shop.nintendo.net

Are those IPs all I need, or do I need to block more? Thoughts appreciated

Yeah, you will be fine!, check the thread hacking discussion, it says what is the latest safe firmware , for 5.0.0 there's not exploit yet, but it will get worked!.

 

[Skeet1983]

Yeah, you will be fine!, check the thread hacking discussion, it says what is the latest safe firmware , for 5.0.0 there's not exploit yet, but it will get worked!.

I had some of those blocked previously, but system update still happened... Should I be worried about system trying to update itself in the future, even though I had standby turned off?

 

[Goku Junior]

I had some of those blocked previously, but system update still happened... Should I be worried about system trying to update itself in the future, even though I had standby turned off?

It doesn't show something like "The server it's full" and it fails to update? that's happening to me.

 

[Mackman]

Sorry to bother.I can`t seem to get the answers I`m looking for and you seemed to know a lot about what to do around here.I recently got a Wii U and installed the homebrew channel and backup my enand,but I have questions about Wii U mode.My Wii U came with Mario Kart 8 and I updated my system to 4.1 firmware via Mario Kart 8 and I want to be able to use Netflix and Youtube app,but when I try to open up those apps it asking for a system update and I will do it if I have to,but I want to know what will work and what want work with the hack in vWii mode and what URLs to block and system settings to disable and still have access to the important things to me like Netflix,Youtube,and the internet browser which works on 4.1.