Hacking Discussion SX Core and SX Lite: Anti Atmosphère code

lordelan · Jun 12, 2020

Is it just me or is there really no thread about this yet?

SciresM figured out SX OS bootmenu (that one that you would use to chainload other payloads) includes code that prevents you from chainloading other custom firmwares (and even Linux):

https://arch.b4k.co/vg/thread/294913983/#295272750

However this code is only included on Mariko units and not SX OS for unpatched units as it appears.
It doesn't matter that much though since there's no mariko-adjusted payload yet anyway.
And there will be one there's still the workaround of altering the boot.dat with CTCaer's python script.

Credits: @Brawl345 for pointing this out on wiidatabase.de

ragestaker21 · Jun 12, 2020

Yare yare daze

Deleted User · Jun 12, 2020

@lordelan The 3.0 beta published by TX does NOT have the TZRAM and SE context save. That shit is only present in the LEAKED version. These guys get more disingenuous each day just to hate on TX. SAD!

You can boot any CFW just fine with the payloads option from SXOS boot menu. All features will work just fine, nothing is being feature limited by TX. All the rest is just FUD spread by TX haters

_hexkyz_ · Jun 12, 2020

lordelan said:
And there will be one there's still the workaround of altering the boot.dat with CTCaer's python script.

That's not possible anymore.
The new boot.dat format includes a RSA encrypted chunk which contains a copy of the hash for stage2 (same hash as the one in the main header). Only TX has the key to encrypt this chunk, which means no more custom boot.dat files.

For all purposes and effects, running any other CFW via custom stage2 is implicitly blocked by the modchip.

json said:
@lordelan The 3.0 beta published by TX does NOT have the TZRAM and SE context save. That shit is only present in the LEAKED version. These guys get more disingenuous each day just to hate on TX. SAD!

You can boot any CFW just fine with the payloads option from SXOS boot menu. All features will work just fine, nothing is being feature limited by TX. All the rest is just FUD spread by TX haters

The beta and the leaked versions are pretty much identical, the only changes are code cleanup and a number of fixes for applications and the Loader KIP.

Wasn't me who found that about TZRAM and SE context save, but I can check anyway.

8BitWonder · Jun 12, 2020

All the more reason for clones to pop up in the market if gateway wants to gate-keep what's boot-able on mariko units.

_hexkyz_ · Jun 12, 2020

Looking into 3.0.0 bootloader, this is the function that does the relevant cleanup.

3.0.0 beta:

Code:

sub_88000020()
{
  __int64 v0; // x19
  __int64 v1; // x0
  unsigned int v2; // w19
  __int64 v3; // x0
  __int64 v5; // x0
  char v6[16]; // [xsp+30h] [xbp+30h]
  char v7; // [xsp+40h] [xbp+40h]

  v0 = 0i64;
  do
  {
    v6[v0] = get_time();
    v1 = get_time();
    *(&v7 + v0++) = BYTE1(v1);
  }
  while ( v0 != 0x10 );
  v2 = 0;
  if ( is_mariko() )
  {
    do
    {
      se1_clear_keyslot(v2);
      v3 = v2++;
      se2_clear_keyslot(v3);
    }
    while ( v2 != 0xE );
  }
  else
  {
    do
    {
      se1_clear_keyslot(v2);
      v5 = v2++;
      se2_clear_keyslot(v5);
    }
    while ( v2 != 0xC );
  }
  se1_set_keyslot(5i64, (__int64)v6, 0x10u);
  se1_set_iv((__int64)&v7);
  se_decrypt_with_keyslot(5u, 0x81000000i64, 0x81000000i64, 0x190000i64);
  se_decrypt_with_keyslot(5u, 0x81300000i64, 0x81300000i64, 0x190000i64);
  se_decrypt_with_keyslot(5u, 0x88000000i64, 0x88000000i64, 0x40000i64);
  se_decrypt_with_keyslot(5u, 0x81000000i64, 0x81000000i64, 0x40000i64);
  return;
}

3.0.0 leaked:

Code:

sub_88000020()
{
  __int64 v0; // x19
  __int64 v1; // x0
  unsigned int v2; // w19
  __int64 v3; // x0
  __int64 v5; // x0
  char v6[16]; // [xsp+30h] [xbp+30h]
  char v7; // [xsp+40h] [xbp+40h]

  v0 = 0i64;
  do
  {
    v6[v0] = get_time();
    v1 = get_time();
    *(&v7 + v0++) = BYTE1(v1);
  }
  while ( v0 != 0x10 );
  v2 = 0;
  if ( (unsigned int)is_mariko() )
  {
    do
    {
      se1_clear_keyslot(v2);
      v3 = v2++;
      se2_clear_keyslot(v3);
    }
    while ( v2 != 0xE );
    se_ctx_save();
    tzram_ctx_save();
  }
  else
  {
    do
    {
      se1_clear_keyslot(v2);
      v5 = v2++;
      se2_clear_keyslot(v5);
    }
    while ( v2 != 0xC );
  }
  se1_set_keyslot(5i64, (__int64)v6, 0x10u);
  se1_set_iv((__int64)&v7);
  se_decrypt_with_keyslot(5u, 0x81000000i64, 0x81000000i64, 0x190000i64);
  se_decrypt_with_keyslot(5u, 0x81300000i64, 0x81300000i64, 0x190000i64);
  se_decrypt_with_keyslot(5u, 0x88000000i64, 0x88000000i64, 0x40000i64);
  se_decrypt_with_keyslot(5u, 0x81000000i64, 0x81000000i64, 0x40000i64);
  return;
}

se_ctx_save() and tzram_ctx_save() were removed in the beta version as part of code cleanup. In fact, it doesn't seem to have been included before for any other reason than just an accidental copy-paste.

Deleted User · Jun 12, 2020

Thanks for confirming!

For those that don't understand: It means you can load any payload you want on Mariko and still have a working warmboot (if you are so inclined to use official Nintendo's warmboot or find a way to bypass Nvidia's warmboot sigcheck).

There's no reason why Atmosphere, Hekate or even ReiNX would not work on the new chips, bar adding an update for the changed Mariko subsystems

Brawl345 · Jun 12, 2020

_hexkyz_ said:
se_ctx_save() and tzram_ctx_save() were removed in the beta version as part of code cleanup

Thanks for the clarification. I only reported on what Scires explained on 4chan, but he never said that it was from the leaked version...

lordelan · Jun 13, 2020

Yeah thanks @_hexkyz_ and @json for clarifying!

Hacking Discussion SX Core and SX Lite: Anti Atmosphère code

Well-Known Member

Well-Known Member

Deleted User

Guest

Well-Known Member

Small Homebrew Dev

Well-Known Member

Deleted User

Guest

Well-Known Member

Well-Known Member

Similar threads

Popular threads in this forum