The team had to do some hardware otherwise GPIOGECKO would not have been possible. Someone had to find the gpio testpoints and registers so you could bit bang the miso mosi clk cs (4 pins). (6 pins total w/ vcc and gnd)
That's not a "hardware hack" in the sense of it being part of an attack/exploit. That was just a way of getting faster I/O to mini. We had the non-invasive FTDI comms over USB (GhettOHCI) before that - GPIOGecko was just faster at data transfer. We investigated hardware-related actual attacks but didn't yield anything useful from them.
I have to say I quite strongly disagree with the idea of ever making a persistent exploit. I personally really didn't like the fact that the Homebrew Channel was persistent on Wii as it greatly increases the risk of bricking to go anywhere near the file system, and worse it's trivially detectable leading to a lot of paranoia about warranties or detection on the vWii for example.
Volatile hacks have their place, and I wish more people had the kind of mindset to be paranoid about any persistent modifications. Our goal with HBC was to provide an option for the many people who do want persistence - to avoid the need for any other system modifications - because we know we're paranoid enough to do a good job at making a safe installation process, and we would've been able to make a low-level cleaner had it ever been necessary. If there's one thing about fail0verflow I'm very proud of, it's our care for the safety of our users' consoles. I truly think we do a better job at that particular aspect than anyone else releasing persistent hacks out there. I'd say we had pretty good success; although there's no stopping some people from doing silly things to their consoles, I think the vast majority found dangerous modifications unnecessary, and low-level recovery tools like BootMii-boot2 have probably helped recover many otherwise permanent bricks.
As far as I'm concerned, now we have a ppc kernel exploit we can do anything we would want to do with legitimate homebrew, loading an application as if it were a real one.
You're still bound by what IOSU lets you do, and by the identity that it assigns to you (e.g. the title ID currently loaded). Depending on what you want to do, this may or may not be appropriate. For example, I still think that a Linux-kernel-based ecosystem would be much more productive in the long run, but making Linux run on top of IOSU for things like TCP/IP is just not going to happen.
Going any deeper just makes it easier for pirates for the sake of the slight convenience of having a Homebrew button on the menu.
Not necessarily. Unlike the Wii, the Wii U actually verifies titles on load - on the Wii, persistence was trivial, you just install things. On the Wii U, it would have to take the form of an at-boot exploit. It's entirely plausible that you could exploit the kernel or the system menu via configuration files on boot, without having to touch IOSU. This would be equivalent to the browser exploit, except with persistence.
I'm not even particularly fussed about the common key, I've certainly not had access to it or any decrypted binaries (though I know the team behind the browser exploit did). I would much rather sit through the 20 extra seconds it would take to go into the browser and click a bookmark, so I'm certainly not looking for an IOSU exploit.
Sure - assuming Nintendo doesn't do a better job of following up on exploits this time around, the browser is a pretty good vector, all things considered (much better than e.g. game exploits on the Wii). But I wouldn't put all my hopes on that alone. It's going to be patched sooner or later, and newer games will require newer system updates.
True, but it's not like we'd be free to leave updates on either way, just like Wii. For the longest time there was no Homebrew on 4.3.
What? 4.3 was released on June 21, 2010, while HBC 1.0.7 (with an IOS exploit for 4.3) came out on July 26th, 2010 - and that lag was more about prepping (and thoroughly testing) a release with lots of unrelated changes and updates, and less about the actual exploit. Meanwhile, game exploits still worked as an initial vector, until Letterbomb was released the next year. I don't think one month of holding off on updating to 4.3 qualifies as "the longest time".
Furthermore we could stockpile Browser and other medium exploits ready for the next update. I really don't think it puts us in a bad position, you're at the mercy of updates regardless.
You should always have at least one stockpiled full-compromise (at least as good as your current one - i.e. at least through to the kernel) exploit before releasing anything - and you should strongly prefer one that can be ported blind to a new version instead of relying on known offsets. This allows you to get binaries for an updated version to develop the next exploit once it is released. Pretty much every successful exploit team (e.g. the folks doing iPhone jailbreaks) works like this. This is also where the common key helps - unlike on iPhones, where the iPhone "common key" (GID key) is burned into hardware and nobody has ever been able to extract it, the common key is readily extractable on a Wii U with the right kind of system compromise, and this allows you to port your stockpiled exploits white-box instead of black-box.
