Official libiosuhax - PPC IPC library for communication to /dev/iosuhax

PPC IPC Library

If you are an end user just skip to next (FT2SD) section . Otherwise here is some explanation on what this is:

I was working on something for developers on the PPC side to allow them easier interaction with iosuhax. I created a new /dev/iosuhax node which can be accessed from the PPC side and which can receive many different commands. It has at least the power of the wupclient.py but is quite a bit faster as it uses the native PPC <-> ARM interprocess communication queue of the system.

Now I wrote up some IOCTL commands to allow easy FSA access and to allow SVC syscalls, memcpy in and out, IOS kernel read and other usefull stuff from the PPC side. This is still in development and can be extended with more usefull commands. You can see all the changes on my iosuhax fork here:
https://github.com/dimok789/iosuhax

You can build that fork for sysNAND or redNAND depending on what make target you use (either "make redNAND" or "make cfw").

Furthermore I prepared a (hopefully) easy to use library for PPC developers to link against. I called it libiosuhax. You can find the library here:
https://github.com/dimok789/libiosuhax

The library includes the necessary IOS_Ioctl wrappers to do the work for several functions and a quite usefull multi-functional devoptab which can be used to map different path within IOSU FS to a path accessible from the PPC. The devoptab lib can also mount different devices to a virtual path and map those for the PPC to access.

A little insight on a possible usage.

Code:

  // initialize IOSUHAX
  int res = IOSUHAX_Open();
  if(res < 0)
  {
  // handle error
  }
  // initialize FSA fd
  int fsaFd = IOSUHAX_FSA_Open();
  if(fsaFd < 0)
  {
  // handle error
  }
  // mount "/dev/odd03" to "/vol/storage_virt_odd" and bind it to our virt PPC path "odd:/"
  // if 3rd parameter is NULL it only binds the /vol path (e.g. /vol/system)  to our virt PPC path
  res = mount_fs("odd", fsaFd, "/dev/odd03", "/vol/storage_virt_odd");
  if(res < 0)
  {
  // handle error
  }

  FILE *pFile = fopen("odd:/code/some.rpx", "rb");
  // do some read/write I/O
  ...

This all shall help make user friendly IOSU applications on the PPC side. With this developers could actually access the IOSUHAX and do all kind of stuff in there directly from a (in best case) good looking GX2 PPC application.

FT2SD

So this above was all only usefull to developers. Now let's get to the part that is interessting for end users. I prepared something for you guys to play with. A tool which utilizes the new library and shows it in action and how to use it.

I created a new application called FT2SD (File Tree 2 SD). This application is a file tree dumper to SD. It can dump several (currently) predefined paths directly to your SD card, like for example game disc content, updates, tickets, slc content, vWii content, mlc...Think of this tool as a very pimped ddd alternative. It might even miss some interessting paths but those can be added quite easy.
The application is currently only a console application but I think i will improve it later with a GX2 GUI and make a nice explorer tool out of it where the user can change paths and copy stuff back and forth.

This is how it looks in action:


Here is a HBL ELF for that application which you have to run once you have a /dev/iosuhax node (a.k.a. run the custom fw.img). You can use it on both sysNAND or redNAND. It doesn't matter as long as you have the /dev/iosuhax node in your fw.img or some other launch method.

http://www2.zippyshare.com/v/VR6842HO/file.html

Have fun dumping stuff.

FTPiiu everywhere

Now this tool is only for advanced users ONLY. This is an extension to the existing ftpiiu tool. It mounts all the paths listed in the FT2SD tool and offers them on the FTP. This includes SLC and MLC! You can also add files or remove files on the FTP which makes it quite dangerous if you do this on sysNAND. So therefore here is a fair warning:

DO NOT TOUCH THIS TOOL IF YOU DON'T KNOW WHAT YOU DO. IF YOU MODIFY FILES ON sysNAND YOU MIGHT BE SCREWED!!!

If you brick your WiiU because you modified some files on sysNAND with this, then it is your own fault.

If you are aware of the risk and want to only explore the files on your WiiU here is the application:

http://www45.zippyshare.com/v/QHVbAby9/file.html



The same rules apply to this application as to the above

Sources

cfw redNAND and sysNAND fw.img:
https://github.com/dimok789/iosuhax

PPC IPC library for /dev/iosuhax:
https://github.com/dimok789/libiosuhax

FT2SD and FTPiiu everywhere:
https://github.com/dimok789/ft2sd
https://github.com/dimok789/ftpiiu/tree/ftpiiu_everywhere

How to compile

cfw redNAND and sysNAND fw.img:
There is a nice thread somewhere around made by FIX94 that explains it.

PPC IPC library for /dev/iosuhax:
Just use "make" and "make install". Then link the library with -liosuhax in your makefile and use it. There is a already build library in the releases section.

 

Usually odd03 has the content. Some games have content on odd04. The data you get from there is /code /content /meta, as required by loadiine. You dont get the wud image.

As described above its a direct copy and therefore quite faster.

 

I updated the lib and added FSA raw open/read/write/close functions as ioctl commands now.
@aliaspider @FIX94 now we can try and see if we can use libfat from PPC . Screw that Nintendo FS library with zero caching.

You are very likely not using a new build of the iosuhax. I uploaded the sources yesterday and you have to re-build it.

Actually this is how the system is intended to access FSA and hardware in generell in the first place, through IPC.
Changing permissions of files on the systems is usually a very bad idea as that is quite permanent. From my point of view this is actually not the way to go. At least not for normal users. What wupserver can do is quite awesome but accessing wupserver from PPC through a local TCP socket seems kind of weird when there is something on the system that is faster and is already designed exactly for that interprocess communication. This whole thing's purpose is for creating nice PPC applications.

Besides you still have to mount some devices as they are not always mounted so you have to have some communication to the ARM side.