Hacking Worried about SX's Emunand 'correct' usage

[AlexTCGPro]

Hey guys, so I was taking a look once again at the release notes of latest SX OS update and found a part that really perplexed me:

The Switch uses a NAND Flash storage chip to store all of the system software, as well as your save games and other assets. With EmuNAND we create a shadow copy of this storage from which you can run SX OS. The benefits from doing this are that you keep your SX OS "world" separated from your original firmware. This also means you can keep your switch on an older firmware, while running the latest and greatest firmware inside of your EmuNAND. As we all know, older is better.. when it comes to defeating system security at least. And newer is better when it comes to enjoying the latest content!

From: https://team-xecuter.com/sx-os-v2-0-announcement/

The part I don't get is that is says that we are supposed to leave sysnand as it is and keep emunand up to date with newer firmware? Like... Exactly the opposite of what everyone was thinking on doing?

This brings many questions to mind...

Are we supposed to mess with hacks in sysnand and leave emunand untouched? Can Nintendo detect emunand?

Since updating sysnand will no doubt burn fuses, we are supposed to not connect it online ever?
Downgrading will be impossible?
Will emunand even load if we have more fuses burnt than needed?

(Can someone actually try this:
Make emunand in 5.1, update sysnand to 6.0 (through ChoNX so you don't connect online ever to be safe) and check if emunand 5.1 will still load even when having more burnt fuses than needed?)

Since they never say anything about online features, (they keep insisting that we use stealth mode actually) are we supposed to only use this emunand as an alternative to back ups instead of having a legit firmware and another hacked?

They really need to come and explain themselves a little better...

 

[M7L7NK7]

You're loading without using the official bootloader so it will skip the fuse check

 

[Kubas_inko]

Leaving ofw lower makes sense, because of exploits and such.
Not directly, but they can detect it.
EmuNAND will always load because it goes thru RCM and sx payload.
Probably. It is definitely not safe to go online on any of those (someone is already banned xd ).

And if your Switch hangs in middle of emunand installation, you will brick.

 

[AlexTCGPro]

You're loading without using the official bootloader so it will skip the fuse check

The check is through the bootloader and not the ofw then? I see, autorcm won't be needed anymore to protect fuses then? What do you think about the correct usage then? Should we mess with emunand or sysnand? The release notes implied we should only keep emunand up to date so sysnand will obviously not be able to connect online, but emunand will clearly show only 15 gb of total storage that Nintendo will no doubt notice

 

[M7L7NK7]

No you're loading SX os not horizon so it won't burn fuses, obviously you can't load SX without RCM though

 

[stewacide]

The release notes don't seem to make sense in that regard. The whole point is seemingly to go online clean with sysnand, which requires the latest firmware. Emunand can be whatever firmware you want (5.1 would be best for hackability)

 

[Myron49485]

The Switch uses a NAND Flash storage chip to store all of the system software, as well as your save games and other assets. With EmuNAND we create a shadow copy of this storage from which you can run SX OS. The benefits from doing this are that you keep your SX OS "world" separated from your original firmware. This also means you can keep your switch on an older firmware, while running the latest and greatest firmware inside of your EmuNAND. As we all know, older is better.. when it comes to defeating system security at least. And newer is better when it comes to enjoying the latest content!

I would like to try it but I don't have SX OS, so based on that here's what I think...

Their intention for an emuNAND is slightly different from ours.

For SX users, the only purpose of having an emuNAND is to keep their sysNAND on an older firmware. The sysNAND would be unused, while the emuNAND is where everything is done. Their emuNAND has nothing to do with protecting from bans. That's what their 'stealth mode' is for.

For us, the SX emuNAND is just an alternative to using ChoiDjNX+autoRCM to upgrade without burning fuses. With SX emuNAND you won't need autoRCM, hence you will be able to boot to OFW / shut down from horizon without loading a payload.

 

[stewacide]

Based on that, here's what I think...

Their intention for an emuNAND is slightly different from ours.

For SX users, the only purpose of having an emuNAND is just to keep their sysNAND on an older firmware. The sysNAND would be unused, while the emuNAND is where everything is done. Their emuNAND has nothing to do with protecting from bans. That's what their 'stealth mode' is for.

For us, the SX emuNAND is just an alternative to using ChoiDjNX+autoRCM to upgrade without burning fuses. With SX emuNAND you won't need autoRCM, hence you will be able to boot to OFW / shut down from horizon without loading a payload.

"Stealth mode" prevents you from getting banned by blocking all Nintendo online services. If you're using stealth mode and SX exclusively then you've already self-banned so emunand really does nothing for you.

What this does for SX users is allow them to go online with sysnand, while being able to install NSPs to emunand (they could already run XCIs without getting banned).

 

[Myron49485]

"Stealth mode" prevents you from getting banned by blocking all Nintendo online services. If you're using stealth mode and SX exclusively then you've already self-banned so emunand really does nothing for you.

What this does for SX users is allow them to go online with sysnand, while being able to install NSPs to emunand (they could already run XCIs without getting banned).

Anyone can use it however they want, but their intention isn't to go online with sysNAND. According to them:

This also means you can keep your switch on an older firmware, while running the latest and greatest firmware inside of your EmuNAND

Going online won't be possible on an older firmware because like what you said, it requires the latest firmware. Also, they never mentioned anything about going online.

Their intention for an emuNAND is slightly different from ours.

This wouldn't be an ideal emuNAND for us. It's probably just their solution for keeping switches on a lower firmware.

 

[stewacide]

• Another upside of consolidating your SX OS usage from your original firmware usage is vastly reducing the risk of a network ban. You can run SX OS in EmuNAND, of course with our Stealth Mode enabled, and anything that is littered on the EmuNAND's filesystem is not visible to the switch in Original Firmware mode.

As they say, mess around on emunand, go online in OFW.

 

[Myron49485]

• Another upside of consolidating your SX OS usage from your original firmware usage is vastly reducing the risk of a network ban. You can run SX OS in EmuNAND, of course with our Stealth Mode enabled, and anything that is littered on the EmuNAND's filesystem is not visible to the switch in Original Firmware mode.

As they say, mess around on emunand, go online in OFW.

I see, that's conflicting. It's like they want to say that emunand lets you go online with a clean sysnand, but also lets you keep an old firmware. In reality it's one or the other (or both is you use ChoiDjNX?).

I still won't trust SX with anything online though.

 

[stewacide]

Agree they give two contradictory use-cases, but given the future-proof RCM exploit, I can only see a scenario where you'd want the latest firmware on sysnand (for online) and perhaps an older firmware in emunand that's more exploited for piracy/homebrew (but right now even the latest firmware is also fine for that).

 

[Deleted User]

I guess its multiple scenerios depending on the user.... Some people are still on FW 1.0.0 oreven 3.0.0 because theyre waiting for coldboot etc.
I would guess in that case they would leave they sysnand and have an upto date emunand so they can at least use their switch to play the latest games (offline obviously)
Some users dont care about coldboot and update to 6.0.0 in that case you would go online with your sysnand carefully updating when its safe and use emunand on what ever you need to, to get games working..

 

[Resaec]

I guess its multiple scenerios depending on the user.... Some people are still on FW 1.0.0 oreven 3.0.0 because theyre waiting for coldboot etc.
I would guess in that case they would leave they sysnand and have an upto date emunand so they can at least use their switch to play the latest games (offline obviously)
Some users dont care about coldboot and update to 6.0.0 in that case you would go online with your sysnand carefully updating when its safe and use emunand on what ever you need to, to get games working..

But for that same goal those users can make a NAND backup, update using ChoiduJour and start with hekate and disabled GC (important if you want back below GC update1).

 

[bundat]

I think there are two use cases for emunand:
#1 - keep sysnand on a low FW version (for future exploits), have emunand at latest (for playing newest games)
#2 - keep all things that make a NAND "dirty", like CFW/NSPs in an emunand, to keep sysnand clean for online play

I think SX OS' solution works fine for #1.
You won't be able to use it online, as sysnand is on an old FW, and emunand is dirty (having all the NSPs, as well as all SX OS CFW logs/traces, and also being 15 GB smaller). But you can have a low FW version, and play games on the latest FW version, without burning fuses and having autoRCM.

For #2... I think it's not really safe, but I don't think it's detectable YET, for now.

The EMUNAND0 magic at the end of BOOT1, as well as the nand00.bin and nand01.bin files stored in the USER partition, are easily detectable. It MIGHT be safe at this moment (as Nintendo should not have had any code to detect these back when 6.0.0 was released), and I THINK they can't add that detection without releasing a new FW version, but I still think it's really dirty how it leaves traces in the sysnand, like that signature in BOOT1 or those files.

Whereas if it were implemented like: having an emunand kip/sys-module, plus having the emunand files in the SD card, then it should leave no traces in the sysnand (unless directly intended by the user), like running Lakka or running a payload in RCM (like Hekate).

---

So I think the "correct" usage is #1 only.

 

[der:Tom]

I think there are two use cases for emunand:
#1 - keep sysnand on a low FW version (for future exploits), have emunand at latest (for playing newest games)
#2 - keep all things that make a NAND "dirty", like CFW/NSPs in an emunand, to keep sysnand clean for online play

This. I needed some time to wrap my head about the release notes but as you wrote, TX gives us 2 choices how to use their emunand.

 

[Deleted User]

But for that same goal those users can make a NAND backup, update using ChoiduJour and start with hekate and disabled GC (important if you want back below GC update1).

I think the point is SX OS is going for an easy non technical solution, your paying for convince.
2nd I think even though it may be possible as a do it your self solution, you've paid for a product why not update it so its automated