Adding isfshax as an advanced/alternative exploit

[jbmagination]

Me and some others were talking about this so I figured it would be worth making a GitHub issue about since I fully expect we're not the only ones thinking about it.

I think isfshax should be added to the guide - but NOT as the main exploit. I have gripes with it that make it difficult for me to fully sell it as the main exploit for what is largely intended to be a noob-friendly guide.

• Autobooting cannot be setup within the minute_minute GUI - it must be done as a configuration file on your SD card. If you don't set it up, you must use your Power and Eject buttons to navigate which option you want - without access to the GamePad - every time you boot up your Wii U. You also cannot use autobooting without your SD card inserted - the minute_minute GUI will appear every time.
• Enables sigpatches, which were on the guide before when Tiramisu was a thing but were removed when the guide started mainly recommending Aroma instead - and I think that's the right choice. With the Homebrew on Menu plugin, sigpatches are basically unnecessary (unless I'm forgetting something important!)
• Potential SLC corruption. It is considered quite safe, but for this reason, people who want to set it up are currently still advised to make a backup of their SEEPROM, OTP, and SLC.
• Hynix MLCs - who need something like this the most - only make up ~2.5% of Wii U's on the Wii U System Database (link is sorted by MLC). For everyone else, I feel that it's largely not worth the hassle.

However, if they do set it up - especially if they have Hynix MLCs, like myself - and don't fuck things up in the process of setting it up, which I nearly did more than once - it serves as very good brick protection. I am one who likes to tinker and break and touch things I really shouldn't be touching, and isfshax with some backups has already saved my ass quite a few times. It also provides a minimal CFW even if you don't choose to setup direct PayloadLoader access into something like Aroma.

[VannyBuns]

We already have ISFShax on the wiki. There's just no place for it on the guide. Even so, it's up to @Lazr1026

[Lazr1026]

I do want isfshax to be on the main guide eventually, but I don't see it as absolutely necessary. It's main purpose atm is just to recover consoles

Autobooting cannot be setup within the minute_minute GUI

You can set up the fastboot minute on the SLC, which will init the bare minimum for minute to function and automatically load plugins from the SLC and boot the console, but if something goes wrong with haxcopy, users will have to deal with ftp and users are not very smart most of the time..

sigpatches are basically unnecessary

The only use they have anymore that isn't straight piracy is for VC injects.

Potential SLC corruption

While this is a valid concern, the isfshax superblocks are installed to the very last superblocks on the SLC NAND, so I doubt there will be any corruption with it if the SLC isn't already dying.

Hynix MLCs

You mean you don't like playing with fire!?

[jbmagination]

The only use they have anymore that isn't straight piracy is for VC injects.

AFAIK that's not on the guide or the wiki; correct me if I'm wrong. My main concerns with sigpatches are someone installing malicious homebrew that tampers with the system (which there are still avenues for, but two - the Homebrew on Menu and SDCafiine plugins - are better than three) and piracy :P But if VC injects are / will be on the guide then that kind of negates this concern

You mean you don't like playing with fire!?

I once considered uninstalling OSv10 and replace it with an older one. I was about to actually do it, and then alarm bells went off in my head so I looked up what I was about to do before doing it and learned from your friend's blog post that I was messing with the wrong application and that that might not be a good idea 🔥

but if something goes wrong with haxcopy, users will have to deal with ftp and users are not very smart most of the time..

See previous comment

[danny8376]

AFAIK that's not on the guide or the wiki;

It is on uwuvci’s guide page, as like said above, this is the only legit case you need sigpatch now

[jan-hofmeier]

You also cannot use autobooting without your SD card inserted - the minute_minute GUI will appear every time.

If you have minute on the SLC it will autoboot with the plugins from the SLC, if no SD is detected.
If neither the SD nor a fw.img on the SLC is detected by ISFShax it will boot with minimal patches. To most users that would look stock, the only difference is in the eco mode or IOSU reload behavior. Meaning even if standby services are enabled, the console will shutdown properly and turn off the dram. It will take a few seconds longer to boot, then starting from the standby mode, where iosu is already in dram. ECO mode does still work.
When you leave the settings a stock system does an IOSU reload, with the minimal patches a full reboot is done, which takes a little longer

Enables sigpatches, which were on the guide before when Tiramisu was a thing but were removed when the guide started mainly recommending Aroma instead - and I think that's the right choice. With the Homebrew on Menu plugin, sigpatches are basically unnecessary (unless I'm forgetting something important!)

I am not 100% sure why stroopwafel has them and if they can be removed without breaking anything. Apparently they aren't even complete since someone complained about them not working properly. I don't intend to fix them.
One legit use case is to use them to launch an installed Homebrew Channel which gives you exec on the PCC without additional CFW. For ARM stuff, there could be a mocha stroopwafel plugin. That even already exists as a PoC. But this usecase probably isn't really relevant since we have Aroma

Potential SLC corruption. It is considered quite safe, but for this reason, people who want to set it up are currently still advised to make a backup of their SEEPROM, OTP, and SLC.

The wiiu.hacks.guide also tells users to backup the same things. Having otp and seeprom is useful for recovering stuff from USB even if the console dies completely. SLC is also nice to have, but we never needed it.
SLC corruption that we saw was usually a result of iosu having the wrong OTP and therefore wrong SLC keys. That happened for example with defuse when the otp on the SD was missing or running a stroopwafel without otp redirection on or when running a stroopwafel with otp redirection but minute not supplying the otp in the right way. To prevent that the mechanism to pass the otp was changed and newer minutes lock out older stroopwafels. The redirection now will only happen if mi Ute really supplies a otp in the right way. The newer minute usually doesn't supply a otp on ISFShax, except with an option for redNAND and only if also the SLC is redirected too.
In addition the latest isfshax plugin blocks the SCFM from formatting the SLC (which it tries to do when the wrong otp is supplied. This block is also included in the minimal patches that happen if no fw.img is found.

ISFShax always felt more risky to me too, but rationally I could argue it's safer than coldbooting Payloader. ISFShax requires just the writing of a working superblock. If the write failes, the hmac is wrong and it will just be ignored. Also a user can't easily supply a wrong superblock, since the installer checks the sha which is supplied in a second file and will refuse to install in case of a mismatch.

With the Payloadloader the system.xml has to be changed, which is arguably a more complex operation. If the system.xml is broken you will need defuse. (But that doesn't mean coldbooting Payloader is unsafe, Maschell put a lot of effort into checks and making sure everything is correct, that we can all take a moment to appreciate. Also there are no bricks caused by that known to me).

Also if people use homebrew to mess with system files over ftp, they better have ISFShax than not. There are enough bricks caused by people accidentally deleting something important or breaking the home menu or something like that.

I already talked with Maschell about using ISFShax as the entry exploit and I think the as that would be the long-term goal. But to take full advantage of ISFShax we wouldn't just use it as the entry exploit but also use it to load mocha as a stroopwafel plugin to get rid of the IOSU exploit and to patch Cafe OS to get rid of the cafe is exploit. That then would require some changes that would likely deprecate running aroma from payloadloader or the the browser exploit (else we would have to maintain two mocha versions )

So maybe we should just wait a little more and see what @Maschell thinks. But I don't think this has a high priority to him atm since he is working on other cool stuff