Hacking How does SX OS Emunand work?

[Deleted User]

Since everbody seems to have an idea how Emunand works by just looking at the release notes, I thought I'd try and find out myself how exactly Emunand in SX OS actually works. No bullshit claims, real facts.

So what I did was create a NAND backup without emunand, and then make another NAND backup after emunand was created.

Here's what I found out so far:

- boot0 is unmodified
- boot1 is modified with EMUNAND0 tacked at the end (some unused area)

- GPT is UNMODIFIED
- All partition locations / sizes are UNMODIFIED
- 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)

That means NO resizing has taken place. Only new files have been created, like regular Nintendo OS would do.

So from what we can conclude so far: OFW mode is actually perfectly safe. Nintendo would need to actively start detecting the EMUNAND0 magic in boot1 or start to detect the new files, which would be hilarious if they would start to do so. This detectable point is actually moot, because with EmuNAND stored on the microSD, Nintendo would be able to detect it too if they actively start to do so.

The resized partition claims that everyone has been spouting are bullshit.


Ok so now lets take a look from what exactly is in these NAND bin files?

As it turns out, it mimics the layout of the Switch eMMC but inside the NAND files! It's layout it split into multiple NAND bin file parts.

Here's what I found out :
- boot0 in emunand is 100% exactly the same as the real one
- boot1 in emunand is 100% the same as the real one (without the EMUNAND0 magic)
- GPT in emunand is SAME as real one
- All partitions are the SAME except the USER partition.

So far everything is the same, and now here comes the difference: The emunand USER partition volume size is 15GB. SMALLER than the real one.
That's it. That's the only difference.

I think it is possible to have the USER partition claim it is the same size as the real USER partition, but fill up the FAT table with clusters marked as USED.
HEY TX ARE YOU LISTENING? This would make it EXACTLY the same as real USER partition from the Switch's standpoint!

But with that said, I don't see any telemetry sending the USER partition size so it does not really matter for now.
If I am mistaken on this, let me know what telemetry it is sending and I will amend it here.

The "NANDTotalSize" telemetry seems something people claim is changed but I have not checked it yet. I will do so later.

That's it for now what I managed to discover, but I think it is safe to say people are spouting bullshit so far without actual FACTS.



One more note: Since the NAND bin files are located inside the USER partition, this cannot be supported with trivial changes to the FS sysmodule.

For this to work you need to actually .. say.. EMULATE the eMMC read/write commands with patches in the FS sysmodule.

 

[xabier]

Good to know some real facts

 

[SpaceJump]

Finally someone who really took the time to analyze how it works instead of making asumptions.

 

[HtheB]

@json Like always, you're the man!

 

[HellaJvke]

thanks for clearing this up as there are tons of posts about the split partitioning and telemetry.

plz update us on the NANDTotalSize telemetry when you have a chance

also if thats really you OP in your profile pic, you have a rad beard

 

[JoeBloggs777]

someone who has SX OS and knows what they are doing instead of people guessing what it does. good work json

 

[alimao]

possible ?
because I thought start emunand with reinx and not sx

sd with files reinx

Is emunand a copy of the correct original firmware?

 

[SpaceJump]

I don't see the NANDTotalSize parameter being different if the "emuNand" is stored on the storage as files like you described. But keep us updated

 

[JJTapia19]

Would it be possible in the future to do all the nand redirection stuff to the sd via the payload itself without modifying anything on sysnand?

 

[whyyes]

Legit. Finally something that isn't FUD

 

[Bakugo]

because with EmuNAND stored on the microSD, Nintendo would be able to detect it too if they actively start to do so.

You could just remove the SD before going back to OFW to avoid this.

 

[mariogamer]

Thanks for the info.

 

[magico29]

Since everbody seems to have an idea how Emunand works by just looking at the release notes, I thought I'd try and find out myself how exactly Emunand in SX OS actually works. No bullshit claims, real facts.

So what I did was create a NAND backup without emunand, and then make another NAND backup after emunand was created.

Here's what I found out so far:

- boot0 is unmodified
- boot1 is modified with EMUNAND0 tacked at the end (some unused area)

- GPT is UNMODIFIED
- All partition locations / sizes are UNMODIFIED
- 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)

That means NO resizing has taken place. Only new files have been created, like regular Nintendo OS would do.

So from what we can conclude so far: OFW mode is actually perfectly safe. Nintendo would need to actively start detecting the EMUNAND0 magic in boot1 or start to detect the new files, which would be hilarious if they would start to do so. This detectable point is actually moot, because with EmuNAND stored on the microSD, Nintendo would be able to detect it too if they actively start to do so.

The resized partition claims that everyone has been spouting are bullshit.


Ok so now lets take a look from what exactly is in these NAND bin files?

As it turns out, it mimics the layout of the Switch eMMC but inside the NAND files! It's layout it split into multiple NAND bin file parts.

Here's what I found out :
- boot0 in emunand is 100% exactly the same as the real one
- boot1 in emunand is 100% the same as the real one (without the EMUNAND0 magic)
- GPT in emunand is SAME as real one
- All partitions are the SAME except the USER partition.

So far everything is the same, and now here comes the difference: The emunand USER partition volume size is 15GB. SMALLER than the real one.
That's it. That's the only difference.

I think it is possible to have the USER partition claim it is the same size as the real USER partition, but fill up the FAT table with clusters marked as USED.
HEY TX ARE YOU LISTENING? This would make it EXACTLY the same as real USER partition from the Switch's standpoint!

But with that said, I don't see any telemetry sending the USER partition size so it does not really matter for now.
If I am mistaken on this, let me know what telemetry it is sending and I will amend it here.

The "NANDTotalSize" telemetry seems something people claim is changed but I have not checked it yet. I will do so later.

That's it for now what I managed to discover, but I think it is safe to say people are spouting bullshit so far without actual FACTS.



One more note: Since the NAND bin files are located inside the USER partition, this cannot be supported with trivial changes to the FS sysmodule.

For this to work you need to actually .. say.. EMULATE the eMMC read/write commands with patches in the FS sysmodule.

thank you very much for let us know,now the non sense threads started by TX haters will stop. thank you very much again.

 

[Purple_Shyguy]

BASED

 

[isoboy]

"HEY TX, ARE YOU LISTENING?"

 

[mowsie]

Wow, this post is a breath of fresh air

You're doing God's work

 

[Deleted User]

You could just remove the SD before going back to OFW to avoid this.

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.

 

[taxco]

After you create emunand, can you boot to it without autorcm? or payload etc?

 

[Deleted User]

After you create emunand, can you boot to it without autorcm? or payload etc?

Emunand does not change anything regarding autoRCM or non-autoRCM boot up. It's same as before, you either need the jig or have auto-RCM installed to your sysNAND.

 

[SpaceJump]

Hm, I would have imagined that this thread would be crowded a lot more just like the other SX OS threads...