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,
https://twitter.com/balika011/status/1107748638095220738?s=19

Triszka Balázs says:
"There is more to the story, and this is gonna be EPIC! They store the root key in plaintext, but they are not using it. On 7.0+ they set the tsec_root_keys + 0x10 then don't even touch it. It's a leftover. What they are using is a seed decrypted using slot 7. That they not clear."

Somebody can explain?

Mike Heskin says:
"This means the plaintext key was left by accident and there was already a system in place to use an obfuscated version. As of v2.6.1, the plaintext key is no longer present in the binary and the obfuscated path is taken just like before."
 
Last edited by oblid,
https://twitter.com/balika011/status/1107748638095220738?s=19

Triszka Balázs says:
"There is more to the story, and this is gonna be EPIC! They store the root key in plaintext, but they are not using it. On 7.0+ they set the tsec_root_keys + 0x10 then don't even touch it. It's a leftover. What they are using is a seed decrypted using slot 7. That they not clear."

Somebody can explain?

Mike Heskin says:
"This means the plaintext key was left by accident and there was already a system in place to use an obfuscated version. As of v2.6.1, the plaintext key is no longer present in the binary and the obfuscated path is taken just like before."

Basically they left the key in plain-text out of oversight/rush, and it was in no capacity used (in its plain-text form, just loaded) much like the code remnants of sept, though those still seem to have been left over. It has been removed in plaintext from the boot, and the method is an obfuscated use of seed slot 7 as balika points out.
 
Last edited by V-Temp,
  • Like
Reactions: gizmomelb and oblid
https://twitter.com/balika011/status/1107748638095220738?s=19

Triszka Balázs says:
"There is more to the story, and this is gonna be EPIC! They store the root key in plaintext, but they are not using it. On 7.0+ they set the tsec_root_keys + 0x10 then don't even touch it. It's a leftover. What they are using is a seed decrypted using slot 7. That they not clear."

Somebody can explain?

Mike Heskin says:
"This means the plaintext key was left by accident and there was already a system in place to use an obfuscated version. As of v2.6.1, the plaintext key is no longer present in the binary and the obfuscated path is taken just like before."
So I was right about it being temporary after all. As I've stated before, all this arguing over nothing.
 
  • Like
Reactions: gizmomelb
https://twitter.com/balika011/status/1107748638095220738?s=19

Triszka Balázs says:
"There is more to the story, and this is gonna be EPIC! They store the root key in plaintext, but they are not using it. On 7.0+ they set the tsec_root_keys + 0x10 then don't even touch it. It's a leftover. What they are using is a seed decrypted using slot 7. That they not clear."

Somebody can explain?

Mike Heskin says:
"This means the plaintext key was left by accident and there was already a system in place to use an obfuscated version. As of v2.6.1, the plaintext key is no longer present in the binary and the obfuscated path is taken just like before."

Ergo, SXOS is allowed to be linked here.
 
  • Like
Reactions: gizmomelb
I’m pretty sure they still have the key in it, it’s just obfuscated/hidden now

(at least that’s how I read hexkyz’s tweet)

And even if the key is completely removed there’s still other stuff in it that makes it violate this website’s rules
 
Last edited by ZachyCatGames,
I’m pretty sure they still have the key in it, it’s just obfuscated/hidden now

Yes... You are right. Balázs and Heskin? Who know them...

Like before? Before that 2.6? 2.5.3 was ok by gbatemp.
And the censorship of link come for keys. Already say that 2.5.3 was ok.
 
Last edited by oblid,
I know one day TX will drop support of SXOS. I bought it knowingly, while thinking about Gateway.
In the mean time, I'm really glad they found a way to run on 7.0.x.
Don't know why, but I really prefer xci loading than nsp installing.
Anyway, keep up the good work TX.
 
  • Like
Reactions: gizmomelb
Yes... You are right. Balázs and Heskin? Who know them...

Like before? Before that 2.6? 2.5.3 was ok by gbatemp.
And the censorship of link come for keys. Already say that 2.5.3 was ok.
Notice the edit that I made almost immediately after making that post...
 
Anybody still have issues getting this to run? I have sys on 7.0.1 and emunand on 6.2 but for some reason I still can’t boot just blackscreens :/
 
I know one day TX will drop support of SXOS. I bought it knowingly, while thinking about Gateway.
In the mean time, I'm really glad they found a way to run on 7.0.x.
Don't know why, but I really prefer xci loading than nsp installing.
Anyway, keep up the good work TX.
what is gateway?
 
Anybody still have issues getting this to run? I have sys on 7.0.1 and emunand on 6.2 but for some reason I still can’t boot just blackscreens :/
Try a couple of times. I'm also getting low boot rate on my emunand since 2.6. I've reported it on their forums.
 
  • Like
Reactions: metal921
I’m pretty sure they still have the key in it, it’s just obfuscated/hidden now

(at least that’s how I read hexkyz’s tweet)

And even if the key is completely removed there’s still other stuff in it that makes it violate this website’s rules

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
 

Site & Scene News

Popular threads in this forum