Hacking Discussion Logistics of emunand

[Hernie]

Although I understand the concept of emunand and what it's intended to achieve, I have never actually used one on any system. How exactly is the emuNand updated? Will there be a program like choidujournx, and you select "update emuNand" instead of "update sysnand"? Will I just be able to use my clean backup to create my emuNand? Can I have 1 clean and 1 modified essentially having 2 emuNands, so that my ofw can stay on a lower version.

Any ideas or speculations on how things might be implemented?

 

[Ashura66]

From what i can understand, this "emunand" is nothing but a smaller copy of your sysnand. As such, it functions EXACTLY like the sysnand does, the exception being that since it has to go trough RCM to start, it wont burn any fuses. As for updating, as long as it's the "emunand" that's running you should be able to update it the same way as your sysnand, unless TX comes up with their own version of ChoiDuJourNX. Also i think you're confusing OFW(official Firmeware) with Sysnand. When you say "so that my ofw can stay on a lower version" i think you mean you want your sysnand to stay on a lower OFW version while updating just the "emunand". And yes, SUPPOSEDLY, that's how it works

 

[Chocola]

A real emunand only can load on custom firmwares, so the idea it's let the sysnand with a clean official firmware without any mods (on the most lower version possible if you like wait for exploits and prevent the fuse burn) and the emunand, that works like a mirror of sysnand on CFW, on the last version to enjoy all features.

The swap betwen sysnand or emunand are on boot stage, so you don't need any selector on the software, when you boot with emunand all things that you do and all file operations only affect to it, leaving the sysnand intact.

Ocurrs the same when you boot with the sysnand on OFW, all things that you do only affect to sysnand and don't touch anything of your emunand.

For now we don't have any emunand working for Switch, only SX OS have a similar system but aren't real emunand.

 

[Hernie]

Thanks for your responses, but that's not exactly what I was asking. I know the gist of what emuNand is.

On SXOS' emuNand, it basically copies the sysnand that is currently on the switch and then runs that. There is no way to choose a different backup. Also, there is currently no way to update that without going online.... Which we all know is a no no. (I' that's even possible??)

Say I'm on 4.1.0, and I go to set up an emuNand. Will I be able to use one of my current backups to create an emuNand that is clean? I want to have two, one clean and one modified, both updated.

Now say that I have created an emuNand and have booted into it. If I use a program like choidujournx, will it update the firmware that I'm booted on? ... And not the sysnand's firmware?

I know these are all speculations, but I'm sure it's been implemented on other systems and curious as to how those worked.

 

[bundat]

Now say that I have created an emuNand and have booted into it. If I use a program like choidujournx, will it update the firmware that I'm booted on? ... And not the sysnand's firmware?

Think of emunand as a virtual machine, which is running in the host machine, which is the sysnand. It's not really like that (it's more like a dualboot), but it is functionally the same in the way that the emunand cannot see or modify anything in the host (i.e. sysnand), and all changes made while running emunand will only affect emunand.

Also, DON'T go online in emunand, it's 15 GB smaller than sysnand and will definitely get you banned
(as telemetry includes NANDTotalSize).
It's not "all speculation" how it works in updating it etc... using ChoiDujourNX to update emunand actually works and is the recommended way of doing so.
Here's a guide:

I am on the exact same situation as you. So here are the steps I took to bring my emuNAND to fw 6.0.0:

Requirements: Latest build of ChoiDujourNX installed into your homebrew dir and a copy of N's v6.0.0 FW files (google for multiple ways to get them)

1. boot on your OFW and change the theme to the opposite of your preference (if you prefer dark, change it to white or vice-versa). This will help you to visually identify which of the fw versions you're booting from now on.
2. Boot SX OS while keeping the vol+ pressed so you can get into SXOS menu
3. Setup emuNAND
4. Make sure you boot into emuNAND version of 4.1.0 (as it was just copied from your OFW). This can be confirmed by going into the album and checking if the SXOS logo states "2.0 EMUNAND"
5. Go into the settings and change the theme to your preference. Now we can always identify which one is booting since you'll have te visual queue
6. go into homebrew, run ChoiDujourNX, select your NX6 fw folder, select exfat or no-exfat (depending on your taste) and proceed.
7. When finished, you'll be prompted to reboot. Even with SXOS running, doing so will reboot you to your OFW 4.1.0. You'll be able to easily spot this as you'll see the old theme showing up -> This is OK. Just long-press power until you get to the power menu and power off your console
8. Boot SXOS again with your jig+dongle/px/phone/whatever

You should now be on 6.0.0 emuNAND while your 4.1.0 is preserved together with your fuses. This can be confirmed if you boot Hekate and check that you still retain 5 burnt fuses instead of 7
Bonus on top of this, if you go back and boot the OFW 4.1.0, the card slot is still usable.

...which people have successfully used:

I went from 4.1.0 (exfat) straight to 6.0.0-5.0 (exfat) directly and it worked out

I also went from 5.1 to 6.0.0 and it works like a charme.
Thx for your tutorial @rrocha!

confirmed it works, tried on 3.0.1 with a few additional steps

I personally want 2 emunands as well, both on 6.0, one clean for online, one full of NSPs and NROs, and sysnand at 4.1.

SX OS emunand can't do this (it's not even a full sized 32 GB emunand), it's only good for creating an isolated environment where you can leave traces of hacks like installing NSPs.
Then you can either

• keep sysnand at lower firmware (thus not burning fuses while running 6.0),
• or keep sysnand "clean" at 6.0, and risk it online
  • (it's not really "clean" though with the EMUNAND0 magic at the end of BOOT1 and the stray nand00.bin and nand01.bin files in USER, but I THINK 6.0 shouldn't have any code to detect this YET, so it MIGHT be safe for now... but who knows what integrity checks they have built-in)

 

[thaikhoa]

Keep in mind that when using emunand function by default the both nands share the same storage folder on the memory card. The problem is they have different ticketblob so when one of the nand (emunand for example) installed more data than another (sysnand for example) with less recored tickets. The data on emunand will be wiped out completely (archived) or vise versa when attempting to use sysnand.

The solution is to factory restore sysnand without memory card plugged in (if you're on latest firmware) to unlink the two nands and rename Nintendo folder to NintendoSYS/ NintendoEMU or Horizon will ask you to DELETE because it won't recognize the data of Nintendo folder of another nand. When booting to a specific nand, just rename the folder to Nintendo of according nand.

 

[rrocha]

Keep in mind that when using emunand function by default the both nands share the same storage folder on the memory card. The problem is they have different ticketblob so when one of the nand (emunand for example) installed more data than another (sysnand for example) with less recored tickets. The data on emunand will be wiped out completely (archived) or vise versa.

The solution is to factory restore sysnand (if you're on latest firmware) to unlink the two nands and rename Nintendo folder to NintendoSYS/ NintendoEMU or Horizon will ask you to DELETE because it won't recognize the data of Nintendo folder of another nand. When booting to a specific nand, just rename the folder to Nintendo of according nand.

Or to solve that, reflash your OFW partition with 4.1.0 non-exfat version and use exfat for your emuNAND partition. This way, whenever you boot to OFW it will not mess up your SDCARD as it will ask to update before it even touches the files

 

[thaikhoa]

Or to solve that, reflash your OFW partition with 4.1.0 non-exfat version and use exfat for your emuNAND partition. This way, whenever you boot to OFW it will not mess up your SDCARD as it will ask to update before it even touches the files

It is. Someone wants to play online on pure sysnand so that's why.

 

[Hernie]

Thank you guys for your answers, I think I'm going to wait for Atmosphere to have emuNand.

Also, DON'T go online in emunand, it's 15 GB smaller than sysnand and will definitely get you banned
(as telemetry includes NANDTotalSize).
It's not "all speculation" how it works in updating it etc... using ChoiDujourNX to update emunand actually works and is the recommended way of doing so.

Oh, trust me, I would never go online with SX's implementation of emuNand. Not until Atmosphere has a full emuNand on the SDcard.

 

[Ashura66]

Thank you guys for your answers, I think I'm going to wait for Atmosphere to have emuNand.



Oh, trust me, I would never go online with SX's implementation of emuNand. Not until Atmosphere has a full emuNand on the SDcard.

I wouldn't hold out for them. Word is they HAD Emunand or at least were working on it but completely canceled it cause of the dev's anti-piracy views. Mind you i don't know if this is accurate or not

 

[Resaec]

I wouldn't hold out for them. Word is they HAD Emunand or at least were working on it but completely canceled it cause of the dev's anti-piracy views. Mind you i don't know if this is accurate or not

Fair point. My guess is that this speculation came from the fs_mitm module. It does stuff with redirection and things, but thats sadly not the same as a whole system running from the SD.

 

[Yami Anubis ZX]

Im using it as a backup for incase my switch bricks, it's not a good implemented emunand but it will help incase the switch bricks cause if it does, you can fall back on sysnand.

Also I realised that you don't need to Color code each nand for if you go into SX OS, it tells you if your in emunand or not.

 

[8BitWonder]

I wouldn't hold out for them. Word is they HAD Emunand or at least were working on it but completely canceled it cause of the dev's anti-piracy views. Mind you i don't know if this is accurate or not

Looks like the issue is still open and was slated for Atmosphere 1.0 on Aug 2nd.
https://github.com/Atmosphere-NX/Atmosphere/issues/8

I figure they would have closed/removed the issue by now if they had no plans for it.

 

[Ashura66]

Looks like the issue is still open and was slated for Atmosphere 1.0 on Aug 2nd.
https://github.com/Atmosphere-NX/Atmosphere/issues/8

Interesting. I hope they go ahead with it, THAT would be a major step forward for the scene