SX OS 2.6 Beta released: full support for Nintendo Switch firmware 7.x

From Team Xecuter:

This new 2.6 BETA of SX OS adds full support for Nintendo Switch firmware 7.x, including ALL functionality you expect when using our product. We've been pioneering our own unique and proprietary solution for defeating any future firmware protection and we're quite happy with the results so far.

This release is marked as BETA because we changed things drastically under the hood to streamline future firmware updates and some things may inadvertently behave differently.

That does not mean it hasn't been vetted at all, so give it a shot today!

Of course, we haven't been sitting idly behind the scenes either. A lot of our development resources and attention has been dedicated to bringing SX OS to those "unhackable" switches. We are working hard to bring the SX OS experience to all of you who are stuck with an "unhackable" switch. Stay tuned for more news!

Download here: -REMOVED-
 
Last edited by linuxares,
What happens is that a key is set in keyslot 7 at the end of payload_98000000 and then patcher_BFC70000 does:
- Initialize tmp_buf as 16 0xAA bytes;
- Call se_aes_ecb_decrypt_block(0x07, tmp_buf, 0x10, seed_buf, 0x10);
- Call decrypt_data_into_keyslot(0x0C, 0x07, seed_buf, 0x10).

The se_aes_ecb_decrypt_block is useless and was likely there just for testing (it's still there on v2.6.1 and you can find it by looking for 0xAAAAAAAA in the disassembled code).
This was already being used in v2.6, but they also had a piece of code that would load the actual plaintext key from memory. On v2.6.1 the key and this leftover code was removed.

The user @Falo has shared an accurate screenshot comparison of v2.6 vs. v2.6.1 here: https://gbatemp.net/threads/sx-os-2...license-activation.533956/page-3#post-8559251
again this should be pinned and thread closed.
 
Depends on what pretend lawyer they are listening to really. Its still a DMCA violation, but then admitting that would remove links to a few favoured projects.

Nearly everything on this site is in violation of the DMCA. But not all violations are created equal.
 
Gateway was not a TX product, lol
The Switch is the first Nintendo product Team Xecuter has gotten involved with.
While theres no confirmation one way or the other, it is pretty widely suspected that thats untrue and the current Xecuter is the Gateway team. its on legal record that the TX branding was sold, so it certainly isnt the same team that did xbox modding.
 
  • Like
Reactions: Deleted User
So, are saying that you can't prove it?

I can't prove it, many people can't prove it, but we believe it.

But SXOS has to prove they don't use keys...

Aham...
There isn't even anything to prove about SX OS. It needs the key to boot 7.X.X and if they go through the lengths of acquiring it shows they have not fully pwned TSEC. So this is their only option besides using sept (which is out of the question for them).
 
TX didn't do anything to prove themselves for whether being guilty, even a single line the changelogs in details, the scene did the rest for free. So now, discussion is still on going whether TX is Gateway.
 
Last edited by thaikhoa,
  • Like
Reactions: gizmomelb
While theres no confirmation one way or the other, it is pretty widely suspected that thats untrue and the current Xecuter is the Gateway team. its on legal record that the TX branding was sold, so it certainly isnt the same team that did xbox modding.

Members of the team have come and gone since the 360 scene for sure. We're talking about decades here after all. I can assure you that, while consoles and hacking methods have changed significantly over the years, some of the people responsible for SX OS definitely go back to the 360 days.

I think the conspiracy theory regarding Gateway started because they may have used the same factory in China for manufacturing. TX is not a "Chinese company" though and never has been.
 
Remove what? They just explained that SX OS works basically the same way Sept/Atmosphere does with seed keys.
Except it does not. sept still uses Nintendos TSEC firmware. The key is stored nowhere in no form inside sept while it is stored obfuscated inside SX OS.
 
  • Like
Reactions: Deleted User
Remove what? They just explained that SX OS works basically the same way Sept/Atmosphere does with seed keys.

Aye, the block stands that is. Can't they just remove it and I get an OK from and Admin. Then we can allow it.

Nevermind @linuxares continue with the censhorip. I'm tired of this... Good day.
 
While theres no confirmation one way or the other, it is pretty widely suspected that thats untrue and the current Xecuter is the Gateway team. its on legal record that the TX branding was sold, so it certainly isnt the same team that did xbox modding.

Yeah, attacks on TX are mostly speculation based, so that's nothing new for anyone involved.
Just the way it goes I guess.

Oh and by the way, the key was not in "plain text" as cleverly phrased as it has been reported ... Go ahead and use a hex editor and view the boot.dat you won't see the key in plain text. You need Mike's scripts to decompress and view the content first. (I know... I know.... but it's worth mentioning) There are plenty of keys included in various works that have been posted here, so I am happy to see people pointing out the hypocrisy and biased practices in play. I'm not going to debate the politics of that, but I figured I would at least drop my opinion while visiting this place.

Looks like the TX Hate train went faster and faster until it finally derailed itself.
 
Except it does not. sept still uses Nintendos TSEC firmware. The key is stored nowhere in no form inside sept while it is stored obfuscated inside SX OS.

Are you really sure of that?

What happens is that a key is set in keyslot 7 at the end of payload_98000000 and then patcher_BFC70000 does:
- Initialize tmp_buf as 16 0xAA bytes;
- Call se_aes_ecb_decrypt_block(0x07, tmp_buf, 0x10, seed_buf, 0x10);
- Call decrypt_data_into_keyslot(0x0C, 0x07, seed_buf, 0x10).

The se_aes_ecb_decrypt_block is useless and was likely there just for testing (it's still there on v2.6.1 and you can find it by looking for 0xAAAAAAAA in the disassembled code).
This was already being used in v2.6, but they also had a piece of code that would load the actual plaintext key from memory. On v2.6.1 the key and this leftover code was removed.

The user @Falo has shared an accurate screenshot comparison of v2.6 vs. v2.6.1 here: https://gbatemp.net/threads/sx-os-2...license-activation.533956/page-3#post-8559251
 
Far as I am aware, generally speaking, there's actually a fairly good check on whether or not code being shared here uses (a.) copyrighted Nintendo code or (b.) contains any keys. Several of the repacker codes even specifically state they are their own product with no code from Nintendo. Some our helpers do not and cannot share dumps of Boot0/1 which are generic and of no harmful use, and purely exist to help in recovery processes.

Atmos and it's periphery all operate under either byok rules or use key-extraction/derivation on the system itself with no distribution of any copyrighted content or otherwise.

The thing is, and this has been publicly since December, SX fails the first hurdle immediately because the of MIPS VM containing the cart header blocks and a LOTUS certificate. They have been held to a lower standard than smaller devs on here who have gone out of their way to make their own code and have been, by the community, audited on its legality.

So the fact that we're now seeing the reverse cry of persecution is rather ironic.

Edit: Even the emulator teams ban use of Nintendo's tools/details for obvious reasons and built entirely from scratch and reverse engineering. So at current, MIPS VM as provided by TX is skirting all rules that everyone else has been observing for months.
 
Last edited by V-Temp,
Yeah, attacks on TX are mostly speculation based, so that's nothing new for anyone involved.
Just the way it goes I guess.

Oh and by the way, the key was not in "plain text" as cleverly phrased as it has been reported ... Go ahead and use a hex editor and view the boot.dat you won't see the key in plain text. You need Mike's scripts to decompress and view the content first. (I know... I know.... but it's worth mentioning) There are plenty of keys included in various works that have been posted here, so I am happy to see people pointing out the hypocrisy and biased practices in play. I'm not going to debate the politics of that, but I figured I would at least drop my opinion while visiting this place.

Looks like the TX Hate train went faster and faster until it finally derailed itself.
love how you tried to defend your company, but just ended up admitting you guys really fucked up this round of updates :rofl2:
 
So I can now update mSD file type emunand to latest version while still being on 3.02 sysnand? Any problem loading it?

Though I basically never used the Switch and no games that I want are coming out :wink:
 

Site & Scene News

Popular threads in this forum