Hacking How does SX OS Emunand work?

[kramdish]

There are about 3 things they can see:

1. The modification made to boot1
2. An up to 15 GB file stored in the USER partition which is full of files that are not supposed to be in there such as PRODINFO, boot0/boot1, etc.
3. Loading EmuNAND is going to create a mismatch in the NAND size which the Switch can document. It is unclear if TX is patching that or not

You are right.
It would be better to have emunand stored on the sd card, wouldn’t it?

 

[Draxzelex]

You are right.
It would be better to have emunand stored on the sd card, wouldn’t it?

Much better for multiple reasons. Of course, time will tell whether Nintendo can actually detect this or not but the theoretical risk is there and cannot be ignored or shoved aside. Not to mention that Nintendo is very aware of the existence of SX OS and is trying to take down as much of their content as possible. They are most likely also following the progress of their CFW so they know what to be on the lookout for and what to patch out.

 

[kramdish]

Much better for multiple reasons. Of course, time will tell whether Nintendo can actually detect this or not but the theoretical risk is there and cannot be ignored or shoved aside. Not to mention that Nintendo is very aware of the existence of SX OS and is trying to take down as much of their content as possible. They are most likely also following the progress of their CFW so they know what to be on the lookout for and what to patch out.

So for know, the best thing to do is backup virgin NAND and keep completely offline?

 

[jakkal]

You can be sure that Big N cannot see NSP on OFW but they can see the NAND size and ban-hammer because you used emuNAND

Did you even read the first post? Lol
Wow do yourself a favor and read

 

[Draxzelex]

So for know, the best thing to do is backup virgin NAND and keep completely offline?

I still believe its much safer especially since a NAND backup made before hacking is even cleaner than any EmuNAND that would come afterwards (technically, Nintendo can detect even an EmuNAND running off of the SD card but its harder to detect than the one TX implemented).

 

[Ryu Kenshin]

Did you even read the first post? Lol
Wow do yourself a favor and read

I read the article of json, he does not rule out the possibility that BigN could check any 15GB USER space missing and ban people

 

[jakkal]

I read the article of json, he does not rule out the possibility that BigN could check any 15GB USER space missing and ban people

As of now they don't check USER

 

[alexj9626]

There are about 3 things they can see:

1. The modification made to boot1
2. An up to 15 GB file stored in the USER partition which is full of files that are not supposed to be in there such as PRODINFO, boot0/boot1, etc.
3. Loading EmuNAND is going to create a mismatch in the NAND size which the Switch can document. It is unclear if TX is patching that or not

Thing is, are any of those sent on telemetry? I mean, if they dont "ask" for that information, theres no way they could tell, right?

The only one i know is the NAND size, but from OP we "know" that Ninti cant tell.

 

[Draxzelex]

Thing is, are any of those sent on telemetry? I mean, if they dont "ask" for that information, theres no way they could tell, right?

The only one i know is the NAND size, but from OP we "know" that Ninti cant tell.

If you read OP carefully, he said he's not sure if any of the telemetry is actually sent. He's confident some things aren't transmitted but full documentation on all telemetry is nowhere to be found. There are extensive lists crafted by hackers who work very closely with the Switch such as this one or here.

 

[Deleted User]

Correct. I didn't verify the telemetry yet. This is still an ongoing process and I will update the OP when I verify what exactly is sent in emunand vs non-emunand.

 

[Philourer]

You are right.
It would be better to have emunand stored on the sd card, wouldn’t it?

This is just a guess, but maybe they already thought of that. Maybe it's technically possible at this point. If so, why wouldn't they do that?

#1. Speed running the actual os off sd is too slow. There's a reason we use ssd for boot drives and mechanical for bulk data.

#2. SD cards are an unknown, while NAND is a fixed variable. I.e., the NAND is always setup a certain way (partitions, filesystem, etc.), and you can trust that if it says there's 15GB free, there's actually 15GB free. With an SD card, what would happen if it says 100GB free but only has 1GB (fake SD card)? I'm guessing it'd require more coding and testing.

#3. I don't know about the rest of you, but one of the first things I'd try if emunand was stored on sd would be to run an emunand from a different switch. It's possible that running a different switch's emunand at this point would cause bad things to happen.

No idea if any of the above are true, just saying that there are some possible reasons emunand was initially released this way other than "they r stupid lol!"

 

[danhern]

This is just a guess, but maybe they already thought of that. Maybe it's technically possible at this point. If so, why wouldn't they do that?

#1. Speed running the actual os off sd is too slow. There's a reason we use ssd for boot drives and mechanical for bulk data.

#2. SD cards are an unknown, while NAND is a fixed variable. I.e., the NAND is always setup a certain way (partitions, filesystem, etc.), and you can trust that if it says there's 15GB free, there's actually 15GB free. With an SD card, what would happen if it says 100GB free but only has 1GB (fake SD card)? I'm guessing it'd require more coding and testing.

#3. I don't know about the rest of you, but one of the first things I'd try if emunand was stored on sd would be to run an emunand from a different switch. It's possible that running a different switch's emunand at this point would cause bad things to happen.

No idea if any of the above are true, just saying that there are some possible reasons emunand was initially released this way other than "they r stupid lol!"

Don't spout BS. #1 is not an issue, #2 will be an issue using any kind of homebrew and wouldn't be something you take into account, as all homebrew would be fucked, and #3 is both untested, not useful, and even if it did cause problems wouldn't be something that would actively prevent emunand use.

 

[Philourer]

Don't spout BS. #1 is not an issue, #2 will be an issue using any kind of homebrew and wouldn't be something you take into account, as all homebrew would be fucked, and #3 is both untested, not useful, and even if it did cause problems wouldn't be something that would actively prevent emunand use.

I never said they were issues. I said they were plausible reasons why the developers did what they did.

For #1, I'm going to assume you never tried to run Windows off a cheap SD card.

For #2, I never said it was an issue unique to SX OS. Rather, it would require more testing. If you want to be the first to market, you may need to cut corners. This is likely one of them.

And for #3, do you really see no value in running an emunand from a different console? Even if you don't, I have a feeling someone somewhere is trying it out right now. IF there is an issue doing so with the current implementation, TX may just be covering their butts by not making it easy to mess up. Imagine the uproar IF copying the wrong emunand files could brick your system, there'd be lots of pissed off customers, including me.

Of course, the reason could in fact be completely incompetent developers. But that theory has been covered quite thoroughly already.

 

[thaikhoa]

Confirmed.We can unlink the two nands BUT they're sharing the same Nintendo data that causes Horizon forces to [Delete].
Solution: rename Nintendo folder to [Nintendo-emu]/ [Nintendo-sys] then alternately rename to [Nintendo] which nand we are in.

Linked nands: Before downloading any games on eshop (redownload the archived games as well) we must reject memory card (sdmc) for games to download to Sysnand.

Update:
- Try to restore as factory settings for processing emunand much faster (5-10 mins)
- Ticketblob is different between the 2 nands
- Total size in Data management isn't as actual size.


SX made my day.

Cheers.

 

[stewacide]

Is there an option in the SX loader, with emunand set up, to wipe the emunand files/flags? (i.e. to restore it to the pre-emunand condition)

 

[GeraltOfRivia]

I was reading this part on tx announcement about Sx 2.0 :

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

But I wonder how is this possible?? If the shadow nand is directly connected to the real nand how could be the two run a different firmware?? Is this possible in any way or it's just "science fiction"?

 

[The Real Jdbye]

That's good news. Loopback filesystems like this affect R/W performance a little, but I don't think that would matter too much. It does mean more layers of encryption though, assuming the contents of the .bin files are encrypted as well, which would slow down things further. But hopefully not enough to affect performance.

No you can't remove the microSD before booting because in this scenario your emunand would live on microSD, and pulling it out would mean the system cannot boot.

EDIT: You're talking about booting OFW. Sorry, you're right. For OFW, you can always remove microSD. But then.. you'd never have microSD in OFW boot. That's really bad.

You could just have a separate MicroSD for legit stuff. Probably a good idea anyway if you want to be as stealthy as possible.

I was reading this part on tx announcement about Sx 2.0 :

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

But I wonder how is this possible?? If the shadow nand is directly connected to the real nand how could be the two run a different firmware?? Is this possible in any way or it's just "science fiction"?

Think of it like running a Windows 10 VM inside an older Windows version. The VM's file system is stored in a file on your real computer's file system, but yet is completely separate. The VM can't access the files of the host unless you set up a file share, and the host can't access the files of the VM without extra software to open the file containing the VM's file system.

 

[liomajor]

1. emuNAND will still use ALL the same ID's, Account Data, Cert and logins without modifing it
2. Why emuNAND is in original NAND is because using a microSD can have side effects (such as slowdowns & extra crashes)
3. Using emuNAND not only takes away space, your useable space in nand is smaller for OFW AND CFW >>> use microSD to extend useable space.
4. You have Database(s) in NAND and emuNAND, keeping up a clean record is useless if you get banned
5. Using emuNAND doesn't help to use Nintendo Online Services or workaround a ban
6. Having the choice to use emuNAND might lead to the idea having two different Firmware Versions, possible risk to eFuse burn and ban!

The best choice is to backup your important data like nand and keys before installing homebrew or games!

Even having emuNAND you should stay offline and block any internet access for your switch.

 

[Deleted User]

There are about 3 things they can see:

1. The modification made to boot1
2. An up to 15 GB file stored in the USER partition which is full of files that are not supposed to be in there such as PRODINFO, boot0/boot1, etc.
3. Loading EmuNAND is going to create a mismatch in the NAND size which the Switch can document. It is unclear if TX is patching that or not

As for point 3, The emuNAND will be offline thus blocking all telemetry so the NAND size mismatch is irrelevant right? isn't that the whole point of it? Or are you suggesting this data gets logged in a location other than the NAND that we have no access too?

 

[thaikhoa]

Confirmed.We can unlink the two nands BUT they're sharing the same Nintendo/save/ data that causes Horizon forces to [Delete].
Solution: Backup [save] folder to [save-emu]/ [save-sys] then alternately rename to [save] which nand we are in.

Linked nands: Before downloading any games on eshop (redownload the archived games as well) we must reject memory card (sdmc) for games to download to Sysnand.

SX made my day.

Cheers.

1. emuNAND will still use ALL the same ID's, Account Data, Cert and logins without modifing it
2. Why emuNAND is in original NAND is because using a microSD can have side effects (such as slowdowns & extra crashes)
3. Using emuNAND not only takes away space, your useable space in nand is smaller for OFW AND CFW >>> use microSD to extend useable space.
4. You have Database(s) in NAND and emuNAND, keeping up a clean record is useless if you get banned
5. Using emuNAND doesn't help to use Nintendo Online Services or workaround a ban
6. Having the choice to use emuNAND might lead to the idea having two different Firmware Versions, possible risk to eFuse burn and ban!

The best choice is to backup your important data like nand and keys before installing homebrew or games!

Even having emuNAND you should stay offline and block any internet access for your switch.

Before creating emunand, try to reinject ticketblob from the first nand backup (e1 and e2 in SYSTEM/save/) or just delete e1 to clean it.

Then you can factory restore sysnand to unlink the two nands with the two different ticketblobs with clean ticketblob on sysnand. The problem is that they're sharing the same Nintendo folder > Rename it or just Nintendo/save/ folder to where it came from.

Just delete all wifi profiles when being on emunand or just use stealth mode.

Until the next banning party, we don't know whether Nintendo will act as they could be extremely careful on the ban because it will probably ban their legitimate customers.