Hacking SXCore Modchip Features question

[Snewman]

I have a couple of question on the operation of the SX Core modchip.

(1.) Once it is installed, can you deactivate and boot up with a unmodified firmware so that I can access the Nintendo Online service to access my game saves and also upload new game saves?
(2.) If you do this will Nintendo be able to detect that the console is modded.
(3) If you can't do this is there a way to save games so that you can access them later on a different console; or alternatively upload them to the Nintendo Online services?

Just curious about the functionality of the modchip.

Thanks.

Ben

 

[XD2020]

I'm not sure, but from what I understand from another poster the modded side and unmodded side don't talk to one another, so you should be able to dual boot from the SX Core screen. Game saves probably can't be transferred between the two but if you run your original game on the unmodified side you should be able to save as normal or upload those.

 

[anth4m]

If Nintendo could check the integrity of boot0, then they will probably know you are using a modchip, no matter you are in emunand or "unmodified" firmware. SX core replaces your boot0 with its custom bootloader when you boot from the modchip, which is also DRM protected that may not be reversible.

 

[XD2020]

If Nintendo could check the integrity of boot0, then they will probably know you are using a modchip, no matter you are in emunand or "unmodified" firmware. SX core replaces your boot0 with its custom bootloader when you boot from the modchip, which is also DRM protected that may not be reversible.

Hm, would be a nice feature to restore your boot0 file sometimes and then switch back with a certain button press/hardware signal. Good to know though, thank you.

 

[Hayato213]

I have a couple of question on the operation of the SX Core modchip.

(1.) Once it is installed, can you deactivate and boot up with a unmodified firmware so that I can access the Nintendo Online service to access my game saves and also upload new game saves?
(2.) If you do this will Nintendo be able to detect that the console is modded.
(3) If you can't do this is there a way to save games so that you can access them later on a different console; or alternatively upload them to the Nintendo Online services?

Just curious about the functionality of the modchip.

Thanks.

Ben

1. Once you boot into CFW on a clean NAND it is tainted so the NAND isn't clean, you won't be able to use online service if the NAND isn't clean.

2. It is physical hardware modification, it is just an entry point to allow you to boot into CFW.

3. You can backup save using Checkpoint if the unit is hacked, if the unit's NAND is clean as in no CFW you can use Nintendo cloud backup, can't mix the two.

 

[CompSciOrBust]

If Nintendo could check the integrity of boot0, then they will probably know you are using a modchip, no matter you are in emunand or "unmodified" firmware. SX core replaces your boot0 with its custom bootloader when you boot from the modchip, which is also DRM protected that may not be reversible.

I wonder if you could make a emunand then use Choi (pc) to undo the modifications then you can use sysnand for cfw and emunand for semi-stock. Since you already have code exec there's no need for the edited boot0 or bct on emunand.

 

[Zkajavier]

Give it a few more weeks, I'm pretty sure it will be clear soon.
Also, it seems they already cracked the Nvidia encription so... we might see additional options from non TX related solutions.

 

[anth4m]

I wonder if you could make a emunand then use Choi (pc) to undo the modifications then you can use sysnand for cfw and emunand for semi-stock. Since you already have code exec there's no need for the edited boot0 or bct on emunand.

How can you boot clean stock firmware from emunand?

 

[CompSciOrBust]

How can you boot clean stock firmware from emunand?

I'm pretty sure Hekate can do it. It still loads exosphere and the warmboot code but other than that it's stock. I haven't tried it though and the hekate readme isn't clear if it is supported or not.

 

[Deleted User]

How can you boot clean stock firmware from emunand?

Not to sure with new modchips core / Lite

Normally power on to original and hold volume + then power on to emunand

New chip autoboots tx os I guess you can poress + to enter menu then boot OFW. Not sure if theis way is 100% clean

 

[anth4m]

I'm pretty sure Hekate can do it. It still loads exosphere and the warmboot code but other than that it's stock. I haven't tried it though and the hekate readme isn't clear if it is supported or not.

Well, if so the first thing is asking TX to allow third-party payloads, which is very likely impossible. Evidence shows that TX is preventing users to boot from other payloads at present.

 

[CompSciOrBust]

Well, if so the first thing is asking TX to allow third-party payloads, which is very likely impossible. Evidence shows that TX is preventing users to boot from other payloads at present.

My understanding after reading a post by Hexkyz is that was a bug on the leaked build of SXOS only because of something they were doing to the trust zone and tsec to make other payloads boot but in the process made it impossible to boot other cfw by accident or the stuff that stopped it was only for debugging.

I tried to explain why this is required but each time what I wrote was far too long and I have gaps in my knowledge (wouldn't want to spread misinformation). The main differences I know of (based on info provided by SciresM and Hexkyz on twitter) are that the bug which lets you patch the boot rom in ram (iram / sdram?) isn't present on Mariko and Mariko initialises boot rom memory to have the same value as the CPU infinite loop instruction. Unless TX does something for compatability I could see this easily breaking payloads with the og switch in mind and in their attempt to add it they made it worse. This is fixed in the non-leaked SXOS 3.0.0.

Even if this was malicious why would TX advertise a existing feature, go out of their way to break that feature on Mariko only, then not remove the option from the UI making their boot loader look buggy to the end user? They already have your money and I doubt they care enough about trolling SciresM to cost themselves money by doing something most consumers will dislike and possibly not buy their chip over once they hear what they want to use it for is impossible.

 

[anth4m]

My understanding after reading a post by Hexkyz is that was a bug on the leaked build of SXOS only because of something they were doing to the trust zone and tsec to make other payloads boot but in the process made it impossible to boot other cfw by accident or the stuff that stopped it was only for debugging.

I tried to explain why this is required but each time what I wrote was far too long and I have gaps in my knowledge (wouldn't want to spread misinformation). The main differences I know of (based on info provided by SciresM and Hexkyz on twitter) are that the bug which lets you patch the boot rom in ram (iram / sdram?) isn't present on Mariko and Mariko initialises boot rom memory to have the same value as the CPU infinite loop instruction. Unless TX does something for compatability I could see this easily breaking payloads with the og switch in mind and in their attempt to add it they made it worse. This is fixed in the non-leaked SXOS 3.0.0.

Even if this was malicious why would TX advertise a existing feature, go out of their way to break that feature on Mariko only, then not remove the option from the UI making their boot loader look buggy to the end user? They already have your money and I doubt they care enough about trolling SciresM to cost themselves money by doing something most consumers will dislike and possibly not buy their chip over once they hear what they want to use it for is impossible.

I know finally they will support that but I assume they can extend the time for ReSwitched guys to work on, and users probably have no other options before an open-source hardware or a software exploit is announced. They can make more money in this way.

You guys should all check these posts:
https://wiidatabase.de/sx-os-enthaelt-anti-atmosphere-code-auf-mariko-geraeten/
https://gbatemp.net/threads/sx-core-and-sx-lite-anti-atmosphere-code.567309/

 

[3DSDSXL]

Hope other soulotions come out i have a brand new switch lite and a new switch with long battery life sitting in boxes

 

[CompSciOrBust]

I know finally they will support that but I assume they can extend the time for ReSwitched guys to work on, and users probably have no other options before an open-source hardware or a software exploit is announced. They can make more money in this way.

You guys should all check these posts:
https://wiidatabase.de/sx-os-enthaelt-anti-atmosphere-code-auf-mariko-geraeten/
https://gbatemp.net/threads/sx-core-and-sx-lite-anti-atmosphere-code.567309/

Even in the Wii database article you linked there is a update at the top of the page reaffirming what I said. Being unable to boot other CFW is just a bug in the leaked version of SXOS 3.0.0. in the official release booting other payloads works.

They won't make profit by limiting the payloads you can run because the core comes with a free license anyway so it doesn't matter what CFW you have TX won't be making any more money from you.