Hacking Wii U Hacking & Homebrew Discussion

[shinyquagsire23]

yep I read through those threads, from what I saw they haven't been able to from what I surmised. I imagine smealum had to do something because he had a nand mod. I wonder if he posted how he did it.

Well then what about what we did with ps3? Overwrite sysnand

You must dump and restore both the TSOP/SLC and MLC/eMMC NAND at the same exact time. Parts of SLC and MLC are linked together, and restoring only one or the other risks bricking or instability. Also, I found the pinouts on the wiki but I've never actually made it work, smea did though.

 

[Phantom64]

You must dump and restore both the TSOP/SLC and MLC/eMMC NAND at the same exact time. Parts of SLC and MLC are linked together, and restoring only one or the other risks bricking or instability. Also, I found the pinouts on the wiki but I've never actually made it work, smea did though.

hi can i have iosu thanks

 

[Conn0r]

hi can i have iosu thanks

That's not how this works.

Edit: but if this is how this works @shinyquagsire23 , I'll take 3 IOSU hacks pls.

 

[dimok]

Wow it's @dimok. Nice to see you around again.

I can definitely agree with some points there, there's a point where if you're reimplementing the exact same thing that you really can't help but get extremely close to the SDK, especially in this case since everything is almost purely headers. Basically the main issue came down to not being able to validate the origin of code, most of it comes from code which was already open, but a lot of headers were not able to be validated in your absence, and as such I wrongly assumed. My mistake there, in that case. My basic train of thought was that I'd rather be safe and have my code in the clear vs. risking things, but even then once you've seen another implementation you can't really code another which is totally different (and even then, my current GX2 init is extremely similar to your which is extremely similar to initialization in some games).

I will say though that the memory management bit was rewritten without referencing the original, referencing only decaf, but it only ended up happening because someone in #wiiu-emu made a fuss about it (but, again, can't really prove that this was the case). In my opinion it's just one of those things which it doesn't matter how you rewrite it, it's the same code. The devoptab however originated from ctrulib and was readapted to Wii U, and I personally think it came out a bit better that case since it implements some things which weren't present in yours.

It may be worth clearing things up with decaf-emu developers if your code is in fact in the clear. It was very much suggested to me, when I started contributing, to avoid public headers because they might be SDK-derived (this was some time after the memory.c deal), so I simply avoided them when contributing things. Most of my choices with C and texture2D were just from personal preference but that also factored in a bit. I'd much rather work in C than C++ and it was very difficult for me to figure out how to work with the GX2 from public samples, unless I just pulled everything in.

I'm not quite sure on the interacting with hardware registers directly thing though, mostly because loader.elf is a pain already and I can't imagine replacing it while keeping existing RPX loading. At the very minimum you would still have to interact with IOS directly if you were replacing coreinit FS functionality, and in some cases it might just not be worth the work? But again, using Nintendo's existing libraries is already kinda funky because you end up with headers which are inherently just SDK headers but renamed. I dunno.

Yeah I agree. You can't reinvent the wheel over and over again especially if almost everything is already layed out. As for GX2 it took me weeks to just figure out how to initialize it and just get a freaking full colored screen. I dont even know how many times I had to turn off the console because of a hang. I looked through a lot of game and system RPX assembly just to understand the steps that are used there and the intention behind it. It might be looking easy once its done but it was a very long way to that point for me.
About the interfaces to the hardware, you are right in this point. It does not make sense to make a replacement for everything. The loader is the best example. We wouldnt want to replace that and there is no need for that. Though some parts like communication to devices, FS, WiiMote, etc. are well worth being rewritten to open source code. The FS stuff is interessting to replace if we want to ever access the SD or USB devices on the sector base and implement own filesystems other than FAT32 and the WiiU encrypted USB FS. Though it might be also just as well all solvable inside the IOS, I don't know that at this point as I did not convern much about the IOS yet. Of course you would have to interact with the IOS through the ioctlv commands to access the hardware registers by that access the device and I do know how to go about it from experience. And to be honest the FS implementation of the WiiU isnt very nice in my opinion but thats just a personal view of point.

So yeah I am thinking of starting with porting and adapt HBL to the RPX format. Maybe change it to auto-dump and use the texture2D. Did you actually started and created a parser for the gsh files? I started one almost a year ago but discontinued at some point. It was very basic and I had it parsing the vertex and pixel shader structures and the program (its not very complex) but it was still missing relocations of the structure pointers so the structure is not directly usable and there are still manual steps that have to be done after copying it. If you didn't start one here is what I had so far in case you or anyone else is interessted (I wrote it on PC so the be32 has to be removed for the WiiU):
http://pastebin.com/as0TTL3E

I guess for the simple texture2D it should be enough but it has to be extend to support geometry or compute shaders. If you have a more complete one, I would be interessted in it. Otherwise I might continue it at some point.

 

[TheZander]

You must dump and restore both the TSOP/SLC and MLC/eMMC NAND at the same exact time. Parts of SLC and MLC are linked together, and restoring only one or the other risks bricking or instability. Also, I found the pinouts on the wiki but I've never actually made it work, smea did though.

so you would have to do that SD card trick thing, as well as the Teensy dump at the same time for either to read properly? That's not possible right? Aren't they at the same state when the console is powered off? Since you said the pin outs never worked that means that no one must of been able to dump from it using those?

 

[shinyquagsire23]

Though some parts like communication to devices, FS, WiiMote, etc. are well worth being rewritten to open source code. The FS stuff is interessting to replace if we want to ever access the SD or USB devices on the sector base and implement own filesystems other than FAT32 and the WiiU encrypted USB FS. Though it might be also just as well all solvable inside the IOS, I don't know that at this point as I did not convern much about the IOS yet. Of course you would have to interact with the IOS through the ioctlv commands to access the hardware registers by that access the device and I do know how to go about it from experience. And to be honest the FS implementation of the WiiU isnt very nice in my opinion but thats just a personal view of point.

So yeah I am thinking of starting with porting and adapt HBL to the RPX format. Maybe change it to auto-dump and use the texture2D. Did you actually started and created a parser for the gsh files? I started one almost a year ago but discontinued at some point. It was very basic and I had it parsing the vertex and pixel shader structures and the program (its not very complex) but it was still missing relocations of the structure pointers so the structure is not directly usable and there are still manual steps that have to be done after copying it. If you didn't start one here is what I had so far in case you or anyone else is interessted (I wrote it on PC so the be32 has to be removed for the WiiU):
http://pastebin.com/as0TTL3E

I guess for the simple texture2D it should be enough but it has to be extend to support geometry or compute shaders. If you have a more complete one, I would be interessted in it. Otherwise I might continue it at some point.

The only thing I have against rewriting system .RPLs is like, it seems like a waste of time to me? It's about as bad an idea as the weird idea in the 3DS scene of rewriting all the system processes and the kernel and whatever, at that point why not just like, use Linux? Would certainly be way easier by that point, there's already open AMD drivers and whatnot. FS access is entirely handled by IOS, so implementing other filesystems or USB access is entirely an IOS thing, PPC can't actually access USB drives because the IOS restricts that. Even then, adding an extra FS driver to IOS would, in itself, be a massive task.

Also, the main problem I have with texture2D at the moment is that it has no per-vertex colors, so for screen transitions it doesn't exactly work well, because you can't set alpha or color with it. I also never did a .gsh parser, don't really know enough about the format to do that. But ultimately in the long run, I think it would be worth looking at the LLVM compilers for the R600 series and using that to just compile GLSL, but again, I really don't know much about GPU stuff, I just needed something that would work and work decently. Grabbing texture2D.gsh from Health and Safety without IOS modification would be extremely tricky because you would have to take over Health and Safety, read the shader to somewhere, and then go back to Mii Maker or similar to write it to SD. With IOS you can disregard permissions and fsBindMount the Health and Safety content/ directly and just read it.

so you would have to do that SD card trick thing, as well as the Teensy dump at the same time for either to read properly? That's not possible right? Aren't they at the same state when the console is powered off? Since you said the pin outs never worked that means that no one must of been able to dump from it using those?

The pinout definitely works, however I bricked that Wii U before I managed to make them useful, no idea how I bricked but I suspect somehow I ended up writing something to TSOP which made boot0 freak.

 

[AboodXD]

If you didn't start one here is what I had so far in case you or anyone else is interessted (I wrote it on PC so the be32 has to be removed for the WiiU):
http://pastebin.com/as0TTL3E

You might want to look at my GTX Extractor. I have noticed that GTX and GSH are the same formats, but GTX can be used to store textures/shaders, and GSH can be used to store shaders only.

I documented both formats here.

Theoretically, GSH may be able to store textures too, since GTX can also store shaders... Which doesn't make any sense because GTX stands for GX2 texture, while GSH stands for GX2 shader

 

[dimok]

The only thing I have against rewriting system .RPLs is like, it seems like a waste of time to me? It's about as bad an idea as the weird idea in the 3DS scene of rewriting all the system processes and the kernel and whatever, at that point why not just like, use Linux? Would certainly be way easier by that point, there's already open AMD drivers and whatnot. FS access is entirely handled by IOS, so implementing other filesystems or USB access is entirely an IOS thing, PPC can't actually access USB drives because the IOS restricts that. Even then, adding an extra FS driver to IOS would, in itself, be a massive task.

Also, the main problem I have with texture2D at the moment is that it has no per-vertex colors, so for screen transitions it doesn't exactly work well, because you can't set alpha or color with it. I also never did a .gsh parser, don't really know enough about the format to do that. But ultimately in the long run, I think it would be worth looking at the LLVM compilers for the R600 series and using that to just compile GLSL, but again, I really don't know much about GPU stuff, I just needed something that would work and work decently. Grabbing texture2D.gsh from Health and Safety without IOS modification would be extremely tricky because you would have to take over Health and Safety, read the shader to somewhere, and then go back to Mii Maker or similar to write it to SD. With IOS you can disregard permissions and fsBindMount the Health and Safety content/ directly and just read it.

The USB access is of course completely in the IOS but you can pass it down and backwards to/from PPC. That's how it was done on the Wii.
If the texture2D does not allow a change of the alpha in form of a uniform then its not gonna be enough. I didn't look that far yet. That's too bad. About dumping it, I would have went through the Health screen and back to mii maker but since its not that usefull i guess i can save me that part. Maybe its time to address GLSL compiling and the LLVM translation chains but its not as simple as some people think as there are a lot of incompatibilities in the way. Its not just a straightforward R600/R700 translation. Its something in between with several special instructions.

You might want to look at my GTX Extractor. I have noticed that GTX and GSH are the same formats, but GTX can be used to store textures/shaders, and GSH can be used to store shaders only.

I documented both formats here.

Theoretically, GSH may be able to store textures too, since GTX can also store shaders... Which doesn't make any sense because GTX stands for GX2 texture, while GSH stands for GX2 shader

Nice I will take a look it it. Thanks.

 

[AboodXD]

Keep note that the documentation is still not complete, for example all image data/mipmaps are swizzled. Swizzling has been reverse-engineered but still not documented in that page.

You can find the swizzling code inside of GTX Extractor.
I can still add it to that page.

Edit: Added. This documentation is now kind of enough for other people so they can write their own GTX w
extractors...

 

[TheZander]

The only thing I have against rewriting system .RPLs is like, it seems like a waste of time to me? It's about as bad an idea as the weird idea in the 3DS scene of rewriting all the system processes and the kernel and whatever, at that point why not just like, use Linux? Would certainly be way easier by that point, there's already open AMD drivers and whatnot. FS access is entirely handled by IOS, so implementing other filesystems or USB access is entirely an IOS thing, PPC can't actually access USB drives because the IOS restricts that. Even then, adding an extra FS driver to IOS would, in itself, be a massive task.

Also, the main problem I have with texture2D at the moment is that it has no per-vertex colors, so for screen transitions it doesn't exactly work well, because you can't set alpha or color with it. I also never did a .gsh parser, don't really know enough about the format to do that. But ultimately in the long run, I think it would be worth looking at the LLVM compilers for the R600 series and using that to just compile GLSL, but again, I really don't know much about GPU stuff, I just needed something that would work and work decently. Grabbing texture2D.gsh from Health and Safety without IOS modification would be extremely tricky because you would have to take over Health and Safety, read the shader to somewhere, and then go back to Mii Maker or similar to write it to SD. With IOS you can disregard permissions and fsBindMount the Health and Safety content/ directly and just read it.


The pinout definitely works, however I bricked that Wii U before I managed to make them useful, no idea how I bricked but I suspect somehow I ended up writing something to TSOP which made boot0 freak.

I must have dyslexia, I misread what you said. I read "I found the pinouts on the wiki but I've never actually made it work" as "I found the pinouts on the wiki never actually made it work" because I was also going to comment that you were the one that posted them. Now I get what you're saying.

I think i went through your old threads or something that attempted to dump the nand that way. That's where I thought that recent OTP pastebin thing came from, I forgot or didn't realize it could also be done via software.

If you were able to get that to dump with the resulting file be the equivalent to that fw.img thing? and the OTP being a part of it?

Since smealum posted his tools, couldn't anyone without the means of software accessibility be able to dump their nand this way, patch it with his tools, then write it back?

 

[AboodXD]

Since smealum posted his tools, couldn't anyone without the means of software accessibility be able to dump their nand this way, patch it with his tools, then write it back?

I guess theoretically, yes.

 

[shinyquagsire23]

I must have dyslexia, I misread what you said. I read "I found the pinouts on the wiki but I've never actually made it work" as "I found the pinouts on the wiki never actually made it work" because I was also going to comment that you were the one that posted them. Now I get what you're saying.

I think i went through your old threads or something that attempted to dump the nand that way. That's where I thought that recent OTP pastebin thing came from, I forgot or didn't realize it could also be done via software.

If you were able to get that to dump with the resulting file be the equivalent to that fw.img thing? and the OTP being a part of it?

Since smealum posted his tools, couldn't anyone without the means of software accessibility be able to dump their nand this way, patch it with his tools, then write it back?

fw.img is an encrypted file on the encrypted SLC/TSOP filesystem. OTP had to be dumped via software because it's part of the big CPU/GPU chip, if it could be done with hardware then getting keys wouldn't have been as big of a deal.

EDIT: Also can't edit fw.img, because it's checked against a hash in a file which is signed (TMD).

 

[TheZander]

I guess theoretically, yes.

From what I have seen searching is that no one has been able to successfully do it yet though. It seem's if it were doable there would be a plethora of attempts at it. Or if it even works like that.

--------------------- MERGED ---------------------------

fw.img is an encrypted file on the encrypted SLC/TSOP filesystem. OTP had to be dumped via software because it's part of the big CPU/GPU chip, if it could be done with hardware then getting keys wouldn't have been as big of a deal.

EDIT: Also can't edit fw.img, because it's checked against a hash in a file which is signed (TMD).

With the keys now known, you couldn't decrypt the hardware dump into something recognizable?

 

[NWPlayer123]

From what I have seen searching is that no one has been able to successfully do it yet though. It seem's if it were doable there would be a plethora of attempts at it. Or if it even works like that.

--------------------- MERGED ---------------------------


With the keys now known, you couldn't decrypt the hardware dump into something recognizable?

If you use IOSU kernel access cause of per-console storage keys, probably, but at that point why not dump via software (dunno how fast each method is but it gets the same job done)

 

[shinyquagsire23]

From what I have seen searching is that no one has been able to successfully do it yet though. It seem's if it were doable there would be a plethora of attempts at it. Or if it even works like that.

--------------------- MERGED ---------------------------


With the keys now known, you couldn't decrypt the hardware dump into something recognizable?

If you use IOSU kernel access cause of per-console storage keys, probably, but at that point why not dump via software (dunno how fast each method is but it gets the same job done)

Or just like, use the CDN contents like everyone else. Most everything on SLC can be gotten from CDN, and everything else isn't all that interesting really. syslog stuff is interesting I guess but not worth dumping SLC to be honest.

 

[uyjulian]

Or just like, use the CDN contents like everyone else. Most everything on SLC can be gotten from CDN, and everything else isn't all that interesting really. syslog stuff is interesting I guess but not worth dumping SLC to be honest.

It's possible that Nintendo will remove older versions from CDN, like they did with the 3DS...

 

[TheZander]

Or just like, use the CDN contents like everyone else. Most everything on SLC can be gotten from CDN, and everything else isn't all that interesting really. syslog stuff is interesting I guess but not worth dumping SLC to be honest.

If you use IOSU kernel access cause of per-console storage keys, probably, but at that point why not dump via software (dunno how fast each method is but it gets the same job done)

It makes sense if you had the access or ability to dump whatever you wanted by software it would be the only logical choice. If you didn't have an IOSU exploit today though, with the keys that are public could a hardware nand be decrypted? Then patched, and written back to?

There were stirrings awhile ago where a mod chip company claimed to have a product that would do something along those lines, I think it fell through. But I think the WiiU or it's hacking community was in it's infancy. Without any keys or dumps to go by, as well as the documentation available on the wiki I don't see how they could program what ever nand patches or nand stuff they would need.

I guess what I am getting at is, if it was feasible to interface with the NAND via hardware modchip developers would be all over that and cash in. Now though it wouldn't be worth the investment because of the WiiU being obsolete also the rumors of a soft-mod being so prevalent.

Not even that though, because there should be a ton of people who would want to mod the console themselves like they do with the PS3. Willing to solder a teensy to their wiiu. I just don't get why people who don't have iosu access but have the capabilities to do hardware mods haven't cracked it.

Have you tried to do the teensy thing again since then? Do you plan on doing it in the future or anything?

 

[Zulnoth]

Curious, is paper Mario color splash a 5.5.1 disc firmware? Does anyone know?

 

[NWPlayer123]

Curious, is paper Mario color splash a 5.5.1 disc firmware? Does anyone know?

I don't think there's any way to tell without having someone on 5.3.2 trying to use it or a raw disc dump which isn't happening any time soon, I'm looking at the app cos and meta.xml and there's no way to tell either :\

 

[wiiman.au]

I highly doubt we will ever see a iosu for the Wii U, the console has been out now for 5 years and no one has been able to successfully crack it, one group said they hacked it and then said they weren't going to release it, you don't have to be Einstein to realise that there was never a hack made, as for the salt team this is to them if you actually exist, put your money where your mouth is, show us some hard evidence as to the progress that you have made with IOSU, it's not hard to do a you tube video or make a thread on here to substantiate your progress to the wider community, at a educated guess another false misleading rumour.

as said above by TheZander you are spot on the money with your comment "because there should be a ton of people who would want to mod the console themselves like they do with the PS3. Willing to solder a teensy to their wiiu. I just don't get why people who don't have iosu access but have the capabilities to do hardware mods haven't cracked it. "

the thing is if someone was going to make a mod chip style mod it would have been done long ago same with a sofmod hack..

Sorry if I have offended the small minded, but this is the way I see it..