There was once a pinned topic on how we should wait for that, I really hope that poster (or anybody on his side) can step up and say something.
https://gbatemp.net/threads/a-few-words-on-iosu-rednand-and-iosuhax.445953/
This was the (now deleted) post(thanks raphamotta)
https://gbatemp.net/threads/a-few-words-on-iosu-rednand-and-iosuhax.445953/
This was the (now deleted) post(thanks raphamotta)
So, you've probably seen the news all over GBAtemp about how WiiUBru has cracked IOSU! and cracked redNAND!
The entire thing was worked on publicly in IRC and on the forums, which has led to a lot of cross-posting here. The exploit code is pretty good, and is fine for release, since it's not useful without a developer to build something with it. Sadly, this has led to a lot of unstable code being posted here, often without the input of team members.
While it is true that they have the IOSU kernel exploit implemented and booting iosuhax + redNAND does work, it's also not ready for public release. At all. If you've tried to use the NAND dumper that was (annoyingly) linked in my private guide that was posted in places, you'll find that it's a hacked together mess of iosuhax code that barely functions. From what I remember, it's just gutted iosuhax patches set up to jump directly to the dumper code. This doesn't work well, considering one tester took 17 attempts before they got a successful result.
From there, you have iosuhax itself. Booting a redNAND is pretty stable, but it's completely and utterly useless right now - until someone comes along and hacks together a solution for installing titles. What you then get is a fragmented community, think A9LH vs menuhax. SALT's solution is ridiculously more elegant than this, with actual tools designed specifically for this, and doesn't use butchered code from someone's project designed for their own test use. If someone does manage title install before SALT releases, what you can expect is people asking "why should I use this? what I have works fine!" when they're using duct-tape code on an area of the system that could brick you without any chance of recovery.
The redNAND implementation itself is also pretty bad. It wastes almost 10GB on an SD, writes in raw sectors, and doesn't compress the image at all. You'll only get 22GB of usable space on 64GB+ SDs. smea used hardcoded offsets, which works fine for him. It's not intended for people to be using wide-scale.
I hope something here helps you to understand why SALT is spending so much time on their tools, and why you should avoid anything to do with smea's iosuhax on your console. SALT truly knows what they're doing with this stuff, and they've been working on it for a long time with their own code, not some guy's personal stuff that kinda works. I'm not trying to say that open development is bad, far from it. But it's been mishandled and allowed bad code to be released without any input. So please -
Wait for a real release.
Last edited by JimmyZ,