I just had a thought and I have a sane theory on how this exploit might work, or at least part of it.
If you can modify the drive firmware, you can modify what data is sent to the console. Hypothetically, when a specific file read happens, you would be able to send different data on each request, so you could send one set of data on the first read which the console verifies, and a second set on the second read which actually gets executed.
If the kernel is so poorly written that it reads the data once to verify it, just to read the data again before execution, when it could be cached in memory on the first read, that is kind of impressively badly coded and I would be just as amazed as the dev that the exploit actually works. But this sort of thing has actually happened. This is how DSi flashcarts work - they send a bunch of hardcoded responses when the console queries the game info, console sees a real game and allows it to boot, but when the flashcart is booted it loads the flashcart firmware instead and the console doesn't repeat the verification process on the code that *actually* gets loaded. It only verified the first part of the ROM (which includes the header) so only that part needed to be faked to pass verification.
Or - that was how they worked, until Nintendo got smarter and implemented more checks, which flashcart makers had to work around.
Even if that theory is correct, there is almost certainly more to it than that, as the dev specifically mentioned an exploit chain. If you could just exploit one bug and have the console load your code, that wouldn't be much of a chain.
It might not be modifying code, it could be any piece of data. Whatever you need to modify in order to trigger the exploit, this could allow you to bypass checks that would prevent you from doing so. That's just the first step though, as it's missing the main exploit. But hypothetically, if you had an exploit that allowed you to bypass checks on the HDD file system and modify files you're not supposed to and still have the console accept them as valid, even if you can't directly modify code, that would blow the doors wide open allowing exploits that were previously thought impossible. And the dev might have already had some potential targets in mind for that.
I might be way off, but that very last statement sounds a lot like the kind of discovery that would have someone scrambling to find a HDD they are able to mod the firmware of.
After all, a number of Wii U exploits are only possible because someone discovered that the meta partition of titles was not validated. This sort of vulnerability greatly increases the possible attack surface.
Source
pirated games already owns such a device, right? This softmod is just a convenience at this point. Scalpers would lose their hats if they tried to corner this market.
