Hacking How does SX OS Emunand work?

[vikviper]

- Everything is unmodified except for the USER partition, in which a few new files have been created (called NAND01.bin, NAND02.bin and so on)

WTF! Do you think N is not able to spot this one?!? What's the point?

Well 2 reasons:
1) Nintendo has never done so in the past, so why start now?
2) Even if Nintendo does start trying to detect it, it will be possible to circumvent it. And then Nintendo will need a new way to detect it and so forth. It'll turn into a cat and mouse game which Nintendo will lose and they probably know this

You must be joking! Why would N NOT to do it, is the real question!
The cat and mouse game you're talking about is not new at all, and what do you mean for N will lose?
What does N lose at banning modified console vs giving access to online services to pirates?!?
And remember that a user with a banned console has lost forever the possibility to login with the banned console ID, and doesn' care a fuck if N will "lose" anything! Tzk!
Spreading the fear of going online with modified console alone is enough of a result for N. Stay assured!

 

[DiscostewSM]

Thanks for the testing and clarification, @json.

This type of "EmuNAND" sounds like a good way to run homebrew and emulators with Stealth Mode enabled, allowing the OFW to run legit stuff with supposedly no problems, but, for someone wanting online, they couldn't keep OFW on 5.1.0, right? Going to 6.0 on OFW would burn a fuse, preventing the ability to go back to 5.1.0 should something special happen in the hacking community that utilized that FW.

 

[LadyNarnia]

I would like clarification on a couple of things if you're able to test it.
-The result of the "NANDTotalSize" telemetry before and after
-The result of the "NANDFreeSpace" telemetry before and after
-Whether logs in EmuNAND are kept separate from logs in the original NAND
(Alternatively, if anyone knows if the logs are stored in the USER partition, that would answer this enough for me to assume it's on the EmuNAND)

The NANDFreeSpace isn't as important if you can't prove it. It's a nice to know though. A downloadable result of the entire telemetry would be grand!
Thank you for doing this research! It's a great help. @json

Edit: Added additional request for whether logs are in USER Partition

 

[Mauste]

Thanks for the testing and clarification, @json.

This type of "EmuNAND" sounds like a good way to run homebrew and emulators with Stealth Mode enabled, allowing the OFW to run legit stuff with supposedly no problems, but, for someone wanting online, they couldn't keep OFW on 5.1.0, right? Going to 6.0 on OFW would burn a fuse, preventing the ability to go back to 5.1.0 should something special happen in the hacking community that utilized that FW.

I think you could use it this way:

1) Make Emunand on 5.1 (or whatever FW you started with).
2) Update OFW to latest and only use legit stuff on it and play online without problems.
3) Keep the Emunand on 5.1 with CFW (or whatever FW you started with), homebrew, stealth mode and others. Update it with ChoiDuJourNX without burning fuses so you can downgrade if need be (or would this not be possible?)

So, basically instead of keeping the Emunand on the latest firmware, you keep it on the lowest possible firmware / or update it with ChoiDuJourNX so you can always downgrade. And instead of keeping the OFW on as low FW as possible, you keep that one updated.

 

[bundat]

instead of keeping the OFW on as low FW as possible, you keep that one updated.

No that would burn your fuses when you boot in OFW (unless you always boot using SX OS or Hekate's stock option).

Emunand is like a virtual machine running on the host machine (sysnand)
i.e. whatever you do in emunand should have no effect in sysnand (well, except if you consider that the files nand00.bin and nand01.bin are stored in sysnand itself)
... well, it's technically more of a dualboot rather than a virtual machine, but "details details"...

These are the uses I see for SX OS's emunand:

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).

 

[Mauste]

No that would burn your fuses when you boot in OFW (unless you always boot using SX OS or Hekate's stock option).

Yeah, I forgot to mention that part. AutoRCM would be helpful in this case, so you do not accidentally burn your fuses. Or if that is too risky, then you just need to remember not to boot it normally.

 

[bundat]

Yeah, I forgot to mention that part. AutoRCM would be a must in this case, so you do not accidentally burn your fuses.

Then what would be the point of having a low FW emunand?
Whereas with my #1 method listed above, you can keep a low FW, have a 6.0 environment to play latest games, and not need AutoRCM while not burning your fuses.

Can't have BOTH #1 and #2 with SX OS's emunand.

If it were a full 32 GB emunand stored in SD card, I'd keep a 4.1 FW sysnand, and TWO emunands:

• one at 6.0 for online, with no NSPs or homebrew,
• and a dirty one, with all my NSPs and NROs, and deleted internet settings and stealth mode

Then you can have both #1 and #2. That's not what we got though.

 

[Mauste]

Then what would be the point of having a low FW emunand?
Whereas with my #1 method listed above, you can keep a low FW, have a 6.0 environment to play latest games, and not need AutoRCM while not burning your fuses.

Can't have BOTH #1 and #2 with SX OS's emunand.

If it were a full 32 GB emunand stored in SD card, I'd keep a 4.1 FW sysnand, and TWO emunands:

• one at 6.0 for online, with no NSPs or homebrew,
• and a dirty one, with all my NSPs and NROs, and deleted internet settings and stealth mode

Then you can have both #1 and #2. That's not what we got though.

You would not have to keep the emunand on low FW. As it would be "dirty" anyway, you could simply update it with ChoiDuJourNX, and if some exploits appear that need a lower firmware, you could downgrade the emunand to that firmware.

For example:

- Clean OFW /w AutoRCM (or careful booting) for online & legit play - Latest Firmware
- Dirty Emunand /w AutoRCM - Latest Firmware with the option for downgrade in case new exploits appear.

Does this make any sense? I barely slept last night, so maybe I am not thinking straight

 

[bundat]

You would not have to keep the emunand on low FW. As it would be "dirty" anyway

So you're basically just saying #2 in my list earlier, since you're not doing the #1 method I listed (which preserves fuses while having a 6.0 FW environment without AutoRCM).
And you're just using the old method of using AutoRCM to preserve fuses.
That's fine I guess.

 

[ehnoah]

I still love SX since it proofen more save. But wow, everytime they bring something (this time EmuNand)

I just visist GBATemp and see it is all "fake" It is quite interesting, how SX work, sadly they are still the only ones that support XCI =(

 

[Draxzelex]

I still love SX since it proofen more save. But wow, everytime they bring something (this time EmuNand)

I just visist GBATemp and see it is all "fake" It is quite interesting, how SX work, sadly they are still the only ones that support XCI =(

Even though .NSP is superior objectively? You cannot load DLC or updates as .XCI you know

 

[thaikhoa]

WTF! Do you think N is not able to spot this one?!? What's the point?


You must be joking! Why would N NOT to do it, is the real question!
The cat and mouse game you're talking about is not new at all, and what do you mean for N will lose?
What does N lose at banning modified console vs giving access to online services to pirates?!?
And remember that a user with a banned console has lost forever the possibility to login with the banned console ID, and doesn' care a fuck if N will "lose" anything! Tzk!
Spreading the fear of going online with modified console alone is enough of a result for N. Stay assured!

Keep in mind that N could detect atmosphere/switch/reinx/rajnx/hbmenu.nro/*.nro/ or even autorcm etc...as well.

 

[ehnoah]

Even though .NSP is superior objectively? You cannot load DLC or updates as .XCI you know

Is there a propper guide to convert XCI? I found 4XCI but no clue.

 

[Draxzelex]

Is there a propper guide to convert XCI? I found 4XCI but no clue.

• You can simply redownload the games into .NSP format as they are all widely available, BBB and Venom provided numerous scene releases of these
• 4NXCI does convert them and it is run via command prompt (you can check the GitHub page for the full list of support commands). Acquire the keys either from Google or using the latest release of kezplez by shchmue
• ZeroTwoXCI can directly install the .XCI files into your Switch since its a homebrew app but still requires feeding it external keys to work. Just like with 4NXCI, acquire the keys either from Google or using the latest release of kezplez by shchmue

 

[ehnoah]

• You can simply redownload the games into .NSP format as they are all widely available, BBB and Venom provided numerous scene releases of these
• 4NXCI does convert them and it is run via command prompt (you can check the GitHub page for the full list of support commands). Acquire the keys either from Google or using the latest release of kezplez by shchmue
• ZeroTwoXCI can directly install the .XCI files into your Switch since its a homebrew app but still requires feeding it external keys to work. Just like with 4NXCI, acquire the keys either from Google or using the latest release of kezplez by shchmue

kezplez seems not to work in 6.0 sadly. But it just requires the "normal" Keys or the console specific ones?

 

[Draxzelex]

kezplez seems not to work in 6.0 sadly. But it just requires the "normal" Keys or the console specific ones?

It doesn't require any console-specific keys (these are typically reserved for decrypting the NAND). If you can find a fully updated keys list on Google however, it should work. Maybe try searching "Nintendo Switch Retail Keys"

 

[ehnoah]

It doesn't require any console-specific keys (these are typically reserved for decrypting the NAND). If you can find a fully updated keys list on Google however, it should work. Maybe try searching "Nintendo Switch Retail Keys"

Well Garry always have them Up2date so

 

[xabier]

Even though .NSP is superior objectively? You cannot load DLC or updates as .XCI you know

You can simply run nsp and xci at the same time. You only need to choose one of them if you are not using sx os.

 

[Draxzelex]

You can simply run nsp and xci at the same time. You only need to choose one of them if you are not using sx os.

You misunderstood my point. What I was trying to say is that with or without .XCI support still leaves you unable to obtain updates and DLC "illegally". And I see no reason to be using .XCI and .NSP files together since you can accomplish everything with a .NSP file in the first place. For example, if I have an .XCI version of Super Mario Odyssey and I want to install its updates without going online, I have to obey the same "limitations" of using .NSP files if I want to do so. If I just had .NSP support, this thought would never have even crossed my mind since I am only using .NSP files. However with a .XCI, you must use .NSP files in order to bring out their true potential which makes .XCI files inferior objectively.

It also turns out that .NSP files have faster load times than .XCI files, up to about 4x faster. Source

 

[Deleted User]

You misunderstood my point. What I was trying to say is that with or without .XCI support still leaves you unable to obtain updates and DLC "illegally". And I see no reason to be using .XCI and .NSP files together since you can accomplish everything with a .NSP file in the first place. For example, if I have an .XCI version of Super Mario Odyssey and I want to install its updates without going online, I have to obey the same "limitations" of using .NSP files if I want to do so. If I just had .NSP support, this thought would never have even crossed my mind since I am only using .NSP files. However with a .XCI, you must use .NSP files in order to bring out their true potential which makes .XCI files inferior objectively.

It also turns out that .NSP files have faster load times than .XCI files, up to about 4x faster. Source

But isn’t the flip side that nsp is more “dangerous” than xci with regards to leaving a trace on the system? That’s a big factor if true