Hacking IOSU DECRYPTED

  • Thread starter Thread starter Drak0rex
  • Start date Start date
  • Views Views 20,054
  • Replies Replies 63
  • Likes Likes 2
Yay, another leak! :glare:
Whatever...

Yes, that's the Wii U's IOSU. Firmware version 5.3.2 to be more specific.
It's not a dumped retail image, it's a debug build that comes with certain official SDKs (targeted at special debugging units only). The retail version of the IOSU binary is named fw.img, while this one is fw.bu.img.
Also, this file was never encrypted to begin with, it comes unencrypted by default.
Can confirm this^^^ Also, you couldn't have honestly thought you guys were the only ones with access to this.

But, reality is there isn't much changed between fw.img "5.3.2" and fw.img "5.5".
That "firmware backup image" isn't too useful to anyone in the general public anyway.
Although, it could be fun to package it into a spoofed firmware update. Maybe modify the acceptance of unsigned code a little.


Grace U is coming soon....
 
Can confirm this^^^ Also, you couldn't have honestly thought you guys were the only ones with access to this.

But, reality is there isn't much changed between fw.img "5.3.2" and fw.img "5.5".
That "firmware backup image" isn't too useful to anyone in the general public anyway.
Although, it could be fun to package it into a spoofed firmware update. Maybe modify the acceptance of unsigned code a little.


Grace U is coming soon....

To pack the leaked IOSU into a retail FW update???
The Wii U is probably expecting an encrypted image to begin with and 2nd wouldn't probably work anyway because of the typical reason why dev shit doesn't work right away on retail units.
 
Can confirm this^^^ Also, you couldn't have honestly thought you guys were the only ones with access to this.

But, reality is there isn't much changed between fw.img "5.3.2" and fw.img "5.5".
That "firmware backup image" isn't too useful to anyone in the general public anyway.
Although, it could be fun to package it into a spoofed firmware update. Maybe modify the acceptance of unsigned code a little.


Grace U is coming soon....
Seriously 5.3.2? Dang and we low firmware guys are hoping for an easier exploit.
 
Seriously 5.3.2? Dang and we low firmware guys are hoping for an easier exploit.
Latest firmware or bust.


To pack the leaked IOSU into a retail FW update???
The Wii U is probably expecting an encrypted image to begin with and 2nd wouldn't probably work anyway because of the typical reason why dev shit doesn't work right away on retail units.
Same reason Hykem said the img by itself" is useless. One needs to take IOSU out for some drinks first and maybe slip her a mickey. Dev stuff can always work on retail so long as the dev hardware matches the retail. Just have to make the retail unit ignore its requirements. And the best way to make that happen is to disorient the software.
The wii was done with adding to a string..........How will the U-boot console reach its homebrew claim to fame?
 
@Xenon Hacks False. Anything can be useful if you have a use for it, even if it's not the "conventional" use. For instance, maybe somebody just wants the symbols from it for shits and giggles to get a vague idea about what goes into an OS, or similar deviations.
 
Nothing new at all. Nintendo included the decrypted iosu anacast image in sysupdate_for_sdk_2.12.13. This is for os_v10_ndebug.

sha1sum fw.bu.img
84e5a55f83b191e8db46733da83b14eabbca75ff *fw.bu.img

The elf header starts at offset 0x804. Trimming off the anacast header metadata we get:

sha1sum fw.bu.img.elf
712e7976eecdf898d570c8f1a4096ca82912c5b5 *fw.bu.img.elf

The firmware has been reverse engineered to some extent by comex, Hykem, Marionumber1, crediar and myself. The documentation can be found here:
http://wiiubrew.org/wiki/IOSU

People may wonder where reverse engineering starts. It's simple, with a strings dump of the memory. You can use those strings to start identifying device descriptors and their various ioctl functions. You can then backtrace the execution flow of the ioctl subroutines to find the device descriptors jumptable used to map ioctls to their corresponding opcodes. Once you determine the jumptable you can trace back even further into the IPC handler which is how the PPC and ARM processors communicate. Now you have a control flow graph of the complete execution flow from issuing an ioctl command from PPC to it running bare metal on the ARM processor. Mapping out the rest of the ioctl commands is easy because you can use the symbols in PPC rpls to determine their functions.

Once you have a basic idea of the system you can start looking for various memory corruption vulnerabilities through source code analysis and fuzzing. You can also try to determine various open source libraries that are included (like OpenSSL), and look for disclosed CVEs.

Well, that's a pretty comprehensive overview of how to develop exploits for IOSU. Two userland vulnerabilities have already been found (not including the one comex originally used to dump the OTP bank). Oh, I should also mention that the ARM926EJ-S doesn't support hardware DEP which makes hooking control flow a lot easier since ROP is not needed. However, IOSU has it's own kernel which needs it's own exploit.

Also, if you are curious to to know how to blindly reverse syscalls or want more information regarding other aspects of exploiting embedded systems please read: https://cturt.github.io/ps4.html
 
Last edited by Relys,
look, the decrypted iosu file we have for months now. the people who need to have it have it for a long time by now so this is old news and nothing to freak out over.
What are you working on atm? Nintendont has almost everything so do you have other scene projects?
 

Site & Scene News

Popular threads in this forum