Hacking Random USB Question

[bobdob123usa]

Here's the answer: You know how WUPInstaller allows USB Install?, same thing happens, the app knows which code string to "apply", for the lack of a better term, to access USB ports but it only checks for a specific key embedded within the code of the game, not widespread access, and because of its constant key checking, it won't work. The curiosity is apprecciated though

Interesting, thanks!

 

[FaTaL_ErRoR]

Let me tell you a story, kids:

We have a kernel exploit already, we cannot access USB because the medium Loadiine runs at is Mii Maker, which the System does not allow USB access to, because it doesn't need it, and the ARM Processor (the one that runs the IOSU), does NOT play loose with permissions. We will be able to use USB once we can allow Mii Maker (aka Loadiine), to access USB, which will require modifying the permissions given by the system. Disney Infiniy has USB access simply because the System allows it to.
You may be wondering: Why don't we use Disney Infinity as our base game? Because we cannot run Loadiine from a game, we do it from a System app. We could technically run a game with DI as base, but we couldn't run Loadiine because Loadiine is basically a giant SDCafiine.

And that kids, is How I Met Your Exploit

About 98.9% true.
Kernel access allows access to in game memory. Finding correct memory access from usb device would allow for poking at usb access points in game flaws. One might gain other accesses or simple corruption of things if coding flaws meet all the proper criteria.
Going about attempting this way could be very exhausting and require many different games with similar usb access to find a flaw that may or may not exist. One would also need to know an extensive amount of usb protocols and what flaws may exist in current programming to even take a stab at this that doesn't take 10 years to figure out. (and that 10 years could be spent for nothing if it turns out to not be exploitable)
The tools to poke at in game memory exist already. A little bit of work and knowledge and one could actually feed a copy of the already formatted usb drive with a game save to their wii u from their pc.
I love how everyone says usb access cannot be done via kernel but in reality it should read "we are unable to make it function without gaining further permissions."
The capability of running and accessing usb can be done in kernel only. It's just nobody is willing to put the time needed to execute into the project.
Only time anything is validated is when it is called upon from arm to read/write. If just validates the drive and the info stored for proper key sig and to make sure nothing corrupted. In order for the arm os to be accessed after boot it has to be called upon. The kernel does just that. Dump the kernel, mock up the kernel to never call for validation, load new kernel via some sort of loader, and run everything from there.
This ^^ can be done just requires a little knowledge. But, who am I?? Just a group of people showing the way but refusing to actually help.

 

[NexoCube]

Here's another story kids :

To access USB (That is called UHS) the Wii U Games/App use a function called ioctl (or ioctlv or ioctlv_async) what means "Input/Output Controller" that is a syscall for I/O (In/Out) Operations who can't be executed from a classic system devices.

But for UHS shit. We need IOSU.

Why can't we just call the function an grant uhs access ?

Because, while the ARM pocessor is processing the request it does check for the command sender, and it DOES, sadly, check for User Permission !
User Permission have multiple level :

- Higher : IOSU Permission
- Lower : A Non-Signed code permission (Like userspace)

But we got Kernel Permission but that's not enough.

Advanced Developers can told me that we have MCP Permission and that MCP communicate with UHS. That's true but when we call the function MCP_InstallTitleAsync, like WUPInstaller it does works but, who is ioctl'ing UHS Access to install a title update, the MCP Function (OS Function Perm) or us (Kernel Perm) ?

Until nobody find a IOSU Exploit, you'll not have any USB Support for Loadiine.

(Like @EstPC13 said)

Second Way :

User ask to nsysuhs.rpl (Dynamic Librairies containing Nintendo USB functions) if he can access to the librairie but same thing, Permission control :/

 

[FaTaL_ErRoR]

Here's another story kids :

To access USB (That is called UHS) the Wii U Games/App use a function called ioctl (or ioctlv or ioctlv_async) what means "Input/Output Controller" that is a syscall for I/O (In/Out) Operations who can't be executed from a classic system devices.

But for UHS shit. We need IOSU.

Why can't we just call the function an grant uhs access ?

Because, while the ARM pocessor is processing the request it does check for the command sender, and it DOES, sadly, check for User Permission !
User Permission have multiple level :

- Higher : IOSU Permission
- Lower : A Non-Signed code permission (Like userspace)

But we got Kernel Permission but that's not enough.

Advanced Developers can told me that we have MCP Permission and that MCP communicate with UHS. That's true but when we call the function MCP_InstallTitleAsync, like WUPInstaller it does works but, who is ioctl'ing UHS Access to install a title update, the MCP Function (OS Function Perm) or us (Kernel Perm) ?

Until nobody find a IOSU Exploit, you'll not have any USB Support for Loadiine.

(Like @EstPC13 said)

Second Way :

User ask to nsysuhs.rpl (Dynamic Librairies containing Nintendo USB functions) if he can access to the librairie but same thing, Permission control :/

This is why you guys cant access usb storage. You are looking at the sd card bus. UHS is ultra high speed. It's protocol for handling high speed sd cards. The emmc and the usb may share the same format but emmc is likely to be treated very much like an sd card is. Thus the need for UHS protocol. Oh well, happy hunting.

 

[GerbilSoft]

This is why you guys cant access usb storage. You are looking at the sd card bus. UHS is ultra high speed. It's protocol for handling high speed sd cards. The emmc and the usb may share the same format but emmc is likely to be treated very much like an sd card is. Thus the need for UHS protocol. Oh well, happy hunting.

"UHS" in this case refers to USB Host Stack, not Ultra High Speed. That wouldn't make sense anyway; there's no need to have a special device node for UHS SD cards versus non-UHS SD cards.

 

[thisisallowed]

"UHS" in this case refers to USB Host Stack, not Ultra High Speed. That wouldn't make sense anyway; there's no need to have a special device node for UHS SD cards versus non-UHS SD cards.

Yes

 

[EstPC13]

Here's another story kids :

To access USB (That is called UHS) the Wii U Games/App use a function called ioctl (or ioctlv or ioctlv_async) what means "Input/Output Controller" that is a syscall for I/O (In/Out) Operations who can't be executed from a classic system devices.

But for UHS shit. We need IOSU.

Why can't we just call the function an grant uhs access ?

Because, while the ARM pocessor is processing the request it does check for the command sender, and it DOES, sadly, check for User Permission !
User Permission have multiple level :

- Higher : IOSU Permission
- Lower : A Non-Signed code permission (Like userspace)

But we got Kernel Permission but that's not enough.

Advanced Developers can told me that we have MCP Permission and that MCP communicate with UHS. That's true but when we call the function MCP_InstallTitleAsync, like WUPInstaller it does works but, who is ioctl'ing UHS Access to install a title update, the MCP Function (OS Function Perm) or us (Kernel Perm) ?

Until nobody find a IOSU Exploit, you'll not have any USB Support for Loadiine.

(Like @EstPC13 said)

Second Way :

User ask to nsysuhs.rpl (Dynamic Librairies containing Nintendo USB functions) if he can access to the librairie but same thing, Permission control :/

Cool, let's keep this going for 8 more seasons

 

[NWPlayer123]

I posted about this before, there are different kinds of USB, storage is called UHS (USB Host Stack) and it is what is blocked, the device is using HID or Human Interface Device to send its communications, same as the GameCube adapter, you could theoretically cheat and make some device but it would be slowed and I don't think any developer wants to try

 

[GR-DRACULA]

wiikaraokeu doesn't have usb access btw? (it's also an option to load games)

 

[NexoCube]

I posted about this before, there are different kinds of USB, storage is called UHS (USB Host Stack) and it is what is blocked, the device is using HID or Human Interface Device to send its communications, same as the GameCube adapter, you could theoretically cheat and make some device but it would be slowed and I don't think any developer wants to try

I know it have nothing to see, but could you or @Marionumber1 make a GX2 Exploit technical description ?
Because i'm glad you tried to help me 2 months ago but i wasn't happy because i didn't know what i really was doing. For gpr and srr0

And ; How did you find gx2_data ?

 

[NWPlayer123]

I know it have nothing to see, but could you or @Marionumber1 make a GX2 Exploit technical description ?
Because i'm glad you tried to help me 2 months ago but i wasn't happy because i didn't know what i really was doing. For gpr and srr0

And ; How did you find gx2_data ?

I didn't work on it, MN1 did most of it and Matt helped, MN1's been offline for a week and a half so you're probably not getting an answer for a while

 

[NexoCube]

I didn't work on it, MN1 did most of it and Matt helped, MN1's been offline for a week and a half so you're probably not getting an answer for a while

Oh okay nvm i can wait ^^ And what about a little rop chain introduction with Thread Stack ? (On Skype)

About stack, the only thing i understand is that the last 8 bytes correspond to the save adress

 

[NWPlayer123]

Oh okay nvm i can wait ^^ And what about a little rop chain introduction with Thread Stack ? (On Skype)

From my understanding, it uses GX2SetSemaphore to lock access on the area with kernel data which it can for some reason access, does a flush to make sure it's clean, and then we're free to edit an allocated OSDriver cause this thread/piece of code has control of it through the Semaphore, then we just edit the address of the OSDriver's SaveArea to the syscall table, and copy our data to it

 

[NexoCube]

From my understanding, it uses GX2SetSemaphore to lock access on the area with kernel data which it can for some reason access, does a flush to make sure it's clean, and then we're free to edit an allocated OSDriver cause this thread/piece of code has control of it through the Semaphore, then we just edit the address of the OSDriver's SaveArea to the syscall table, and copy our data to it

Oh okay that was easy. So that piece of code who have the control is GX2SetSemaphore + 0x2c
And what about the stack[0x8bytes/4];
Could you tell me more about the structure of the stack ?

(I know that the last 8 bytes = Save Area)