Alright, I'm fairly sure this post will have close to no effect towards all the fighting and bickering, but here it goes: TX did stumble on a roadblock with TSEC, but it's naive to assume they won't be able to get out of the situation.
A lot of people seem to be under the impression there's only one way to have 7.x+ support and that only a handful of people are capable of pulling it off... forever. This is false for a number of reasons, but it's probably easier to explain it this way: software development and the current team behind TX may not really go hand-in-hand, but they know their way around hardware.
While the current 7.0.0 SecureBoot TSEC payload goes to great lengths to prevent leaking keys through glitching, there are still a number of plausible attacks on other components involved that should suffice to extract the only key that is really necessary to continue the boot chain (the tsec_root_key).
The whole point behind Sept's splash screen was really just to mess with them and we obviously know it won't stop SX's development. In TX's words, one may look at it like "a perfectly safe and easily reversible hacker challenge we put in place for
aspiring hackers".
Anyway, I wouldn't count on TX just giving up and using Sept, but I also wouldn't count on TX explaining to their users that they have been stuck trying to hack the TSEC for a month now.
The main reason being presented for the delay is that SX OS has extra features that need time to port and test. But, if you think about it for a while, all the features exclusive to SX would take less than a week to port over to 7.0.0/7.0.1:
- Cheat Engine: its code lives in their custom Loader KIP and it only needs IPC and access to the debug SVCs to function. Nothing in 7.0.0 changed enough to force an update of this feature. In fact, its current iteration (v2.5.3) works without any modification on 7.0.0 and 7.0.1.
- XCI Loader: this feature is contained in a MIPS VM inside the custom Loader KIP. Aside from obfuscation changes that happen on every single SX OS version, this feature hasn't and doesn't need to be updated since the introduction of version 2 gamecard images.
- USB support for mass storage (HDD): the USB sysmodule did change in 7.0.0, but only to introduce a new unrelated service (usb:qdb) and an applet exclusive version of usb:hs (usb:hs:a). SX uses the usb:hs interface to provide support for mass storage devices, but in terms of functionality nothing changed for usb:hs. Thus, the current code in v2.5.3 is still functional on 7.x+ without any changes.
- EmuNAND: the creation and management of NAND images (either on NAND or SD card) is performed really early by their bootloader and is completely independent of firmware versions. The patches for the FS sysmodule, on the other hand, do need to be updated, but once again, nothing changed in SDMMC functions so adding support for 7.x+ patches is trivial.
Something that did change was the introduction of an extra measure to prevent title installation, but this is something completely external to SX OS (and rather an issue for title installers). It's obvious that the delay is related to TSEC, but admitting that would be a terrible marketing choice.
If this is something that matters to you so much, please don't just take mine or anyone else's words for it and try to research for yourself. Reverse engineering is becoming slightly more accessible and the resources and tools are out there in the open. For example, you can de-obfuscate SX OS, grab Ghidra (which is remarkably powerful and free) and achieve a decent decompilation of what makes SX tick. Even if you don't have the knowledge or time to invest, you can always end up finding other like-minded people who may help you in the process.
More often than not, people just tell what others want to hear, doesn't matter if it's a piracy tool, an open source project or a full blown game developer company.
