Hacking Homebrew To people still running an emuNAND on your 3DS, what is your reasoning

[Dionicio3]

Before I even start this thread, I'm aware that talking about anything that heavily deviates from 3ds.hacks.guide will attract some rather unsavory opinions. I'm not asking why using either emuNAND or sysNAND is better, or which CFW is superior, I just wanna ask two main questions.

1. What is your reasoning for continuing to stick with an emuNAND solution rather that using CFW on sysNAND?
2. How is your sys/emuNAND setup configured?

I'm aware of the reasons that using an emuNAND used to be best practice, but I don't see how these reasons work with the current advancements in 3DS homebrew.

• "It allows me to keep sysNAND on an exploitable firmware and have emuNAND on the latest to play the latest games & play online." Nowadays, the entry point for CFW is firmware independent, with all firmwares being exploitable anyways.
• "It helps prevent hard bricks." Hard bricks aren't really possible anymore due to ntrboot, the only way I can think of is messing with the MCU, which an emuNAND wouldn't protect against anyways.
• "It makes making NAND backups easier (simply insert SD into PC to backup)." While this is true, most users, even advanced users, won't be doing anything that directly touches critical parts of the NAND (in fact the only thing I can think of that the average user does that touches the NAND is installing .cias, but that's not necessary a "critical" part unless you're directly overriding system titles, which most users won't). Additionally, most users only need a single backup, from when they initially installed CFW.
• "It allows me to safely run a custom version of [insert sysmodule/system title here]." Correct me if I'm wrong, but nowadays Luma3DS allows for this via LayeredFS and the "Enable loading external FIRMs" option.
• "It works already, why change how I run things?" This is honestly the only legitimate reason I can think of that still applies today. I understand not wanting to change how things are done because they "just work."

If there's any reasons I forgot to list, including reasons that you know don't apply in [current year], let me know. Additionally, please vote on the poll telling me how your NANDs are set up, I'm genuinely curious.

 

[godreborn]

my guess is that they just go with what works. no need to overcomplicate things.

 

[Dionicio3]

my guess is that they just go with what works. no need to overcomplicate things.

That's actually my last bullet point, though, it's arguably more complicated to maintain an emuNAND than to just use sysNAND

 

[godreborn]

I've done a few times with consoles, but I usually like to be on the latest of everything or at least the latest possible without any unnerving side effects.

 

[wownmnpare]

idk if im using sysnand or emunand, it been so long since i mod it and forgot it. one thing for sure is that my 3ds is still alive and still playing games it.

 

[Dionicio3]

I've done a few times with consoles, but I usually like to be on the latest of everything or at least the latest possible without any unnerving side effects.

Honestly, the only time I've used an emuNAND for anything is on the Nintendo Switch (though I guess that's technically an emuMMC lol). However, I tend to keep both sysMMC and emuMMC on the latest, unless it breaks compatibility with atmosphere, where I'd only update sysNAND in that case.

idk if im using sysnand or emunand, it been so long since i mod it and forgot it. one thing for sure is that my 3ds is still alive and still playing games it.

If you are using Luma3DS, you can enable "Show NAND or user string in System Settings" from the settings to see (hold select on boot to access Luma3DS settings, then open system settings)

 

[godreborn]

Honestly, the only time I've used an emuNAND for anything is on the Nintendo Switch (though I guess that's technically an emuMMC lol). However, I tend to keep both sysMMC and emuMMC on the latest, unless it breaks compatibility with atmosphere, where I'd only update sysNAND in that case.

If you are using Luma3DS, you can enable "Show NAND or user string in System Settings" from the settings to see (hold select on boot to access Luma3DS settings, then open system settings)

I've been a part of most scenes since nearly the beginning, so I've encountered emunand every now and then. I've learned that emunand/rednand is most of the time impossible with playstation consoles due to how much they already rely on digital media and whatnot.

 

[Dionicio3]

I've been a part of most scenes since nearly the beginning, so I've encountered emunand every now and then. I've learned that emunand/rednand is most of the time impossible with playstation consoles due to how much they already rely on digital media and whatnot.

Do PlayStation consoles even use a NAND/MMC/whatever chip for the main OS? I could've sworn the OS was held on the HDD/SSD ever since the PS3

 

[godreborn]

it depends on which console. most store it on the flash chip. it's true that most of the firmware is on the hdd/sdd, but none of the most important stuff is or they'd be easy to hack.

 

[Dionicio3]

it depends on which console. most store it on the flash chip. it's true that most of the firmware is on the hdd/sdd, but none of the most important stuff is or they'd be easy to hack.

That's right, I already knew this but completely forgot. Hell, I remember researching this when I wanted to mod my PS3 (before it unfortunately died at the hands of the YLoD)

 

[godreborn]

someone had a poc. jcraib or something was his name. it redirected the nand to a flash drive. nor has most of the firmware in a virtual flash on the hdd, which might be what you were thinking of. that's about 90%. the core os is still on the chips. I think the chips store about 16MBs, which is more than enough for the core os. the emmc units like the 12GB superslim have all firmware on the chips, same as Nand consoles. when I used an internal hdd for my stuff on a superslim, it was slow as hell. goes to show that the ps3 is extremely outdated.

 

[The Real Jdbye]

I suppose an emuNAND is good if you're testing/messing around with stuff that has a high likelihood of bricks, because it's so simple to reflash emuNAND and you're not relying on a NAND backup that is useless if corrupted or lost.
I don't see any other legitimate reasons to use an emuNAND, certainly not as your primary, since it's more hassle and presents compatibility issues with GBA/DSiWare.

 

[DeadSkullzJr]

The concept of EmuNAND works much like having a virtual machine running whatever operating system(s) you wish. General users won't ever see a reason for it since everything they want to do can be done with SysNAND. Personally I don't categorize myself as a general user, I actually do a lot of testing and work with the systems I have, and I do mostly main EmuNAND as a result of this, though it's not to say I don't have systems with SysNAND only custom firmware, but I hardly use those as frequently as my EmuNAND variants. In the time I've been using the systems the way I do, I've gotten lots of comments from various individuals, the rude variants, the preference based variants, and variants that seem logical on paper, but lack certain points to make the logic a stable point(s). I'll skip the rude comments since they aren't necessary here, but here are some of the things I've been told as to why EmuNAND isn't necessary.


1. "There's no point in using EmuNAND when you can do everything with SysNAND."

A: Maybe you can do everything from SysNAND, but I do more with my systems than just run games on them all the time.


2. "Bricking isn't a real issue anymore to warrant using EmuNAND."

A: I have to disagree with this, true installing custom firmware these days is a lot safer than it used to be in the past, obviously the popular homebrew software used also doesn't warrant any bricks either, however I will say that bricking is not entirely out of the equation, much like malware, viruses, etc. on a computer, there is always a possibility that something you run can brick your system if intentionally coded to do so. Examples have existed over time for various game consoles out there, the Nintendo 3DS being included in the bunch that has been targeted in more than one occasion, even as recent as a couple or so years ago in the form of a plug-in. An extended variant of this reason has also been presented to me, with the addition of NTRboothax in the mix, and it's true, NTRboothax can definitely be a life saver, however from my experiences, most people don't want to spend money at all for one of those, one key reason they seek free methods for custom firmware installations as it is. Not everyone has a flash cartridge sitting around, let alone does everyone have one that may even be compatible with NTRboothax to begin with. This in turn leaves me to believe that what was told to me is mostly preference based and not about general use.


3. "EmuNAND lacks AGB and TWL capabilities."

A: True, you can't run Game Boy Advance hypervised titles or DSiWare titles in EmuNAND currently (and I mean this in a proper state, not using SysNAND to do half the dirty work), however it has nothing to do with it being impossible, this mostly has to do with developers never going to the extent of figuring out how to reroute any of these functions for EmuNAND properly. EmuNAND ended up sort of abandoned once things changed to be in favor of SysNAND usage only, which is most unfortunate, but the good thing is it's still possible to make things work with the information that is out there regarding EmuNAND and how it works, just a matter of picking up what was left behind.


Other reasons have been listed, but the first three are the most common from people I've talked to. At the end of the day, nobody technically has a real say on whether or not others should use EmuNAND or not, it's preference based much like running an operating system of your choice through virtual machines or bare metal. There is use cases for these things whether you see it or not, preferences are not indicative of reality, maybe your version of reality, but not universal standards of reality. The choice is for the individual who received the system in the form of paying for it, being gifted with it, etc.

Edit:
Just noticed the pole, sucks I can only choose one option provided I actually use multiple setups differently from one another.

 

[Dionicio3]

The concept of EmuNAND works much like having a virtual machine running whatever operating system(s) you wish.

I kinda get what you were trying to say here, but I wouldn't say the use of an emuNAND is like virtualization at all. Virtualization implies a host and guest OS are running at the same time, which isn't the case here. A better comparison would be dual booting, which is basically what using an emuNAND is.

Maybe you can do everything from SysNAND, but I do more with my systems than just run games on them all the time.

There's plenty of people who do more than run games on their console. However, this comment doesn't address the fact that most homebrew and games do not directly touch critical parts of the NAND, so using sysNAND or emuNAND makes no difference in terms of safety whatsoever.

however I will say that bricking is not entirely out of the equation, much like malware, viruses, etc. on a computer, there is always a possibility that something you run can brick your system if intentionally coded to do so.

I am aware of various examples of malware for the 3DS, however I'm not aware of any that intentionally bricked consoles. The 2 main pieces of malware I can think of were both for data exfiltration, those being UnbanMii 2.0 (though this was unintentional), and something that was specially targeted at Sono to steal their Discord token from DiscordCTR. The only other possibile thing I can think of is Gateway bricking consoles when using cloned versions of their flashcarts, but if you have links to proper examples, I'd be interested in seeing them. Additionally, I don't even think homebrew that runs in the main 3DS OS is even capable of fully erasing the NAND, as Luma3DS has protections that prevent any write operations to the FIRM partitions, meaning that if something does try to brick, you'll always be able to boot into GodMode9 to restore your NAND/perform a ctrtransfer without the need of additional hardware.

from my experiences, most people don't want to spend money at all for one of those, one key reason they seek free methods for custom firmware installations as it is.

This is definitely a fair point, nobody wants to spend extra money on stuff that isn't strictly necessary. But I feel like if you're the type of user/developer that messes with their NAND in unconventional ways, even if you are using an emuNAND, not having a working ntrboot cart just in case is just plain dumb (after all, what's stopping any potential application being incompatible with emuNANDs and somehow accidentally corrupting sysNAND, or, as you said, one that intentionally tries messing with sysNAND, even when booted through emuNAND.

True, you can't run Game Boy Advance hypervised titles or DSiWare titles in EmuNAND currently

Actually regarding TWL_FIRM, there is an unmerged pull request on the Luma3DS GitHub that somewhat negates the need for sysNAND for DSi software. While this is definitely a personal preference, I feel that the need for AGB_FIRM to be fixed simply isn't necessary due to the release of open_agb_firm.

There is use cases for these things whether you see it or not, preferences are not indicative of reality, maybe your version of reality, but not universal standards of reality.

I probably should've worded my questioning a bit better. I was more or less trying to say that using an emuNAND for pretty much any purpose just seems like unnecessary added complexity. I still fail to see any real advantage other than simply not wanting to change how things are done.

 

[SylverReZ]

Much more easier to maintain everything on an SysNAND than an EmuNAND because you can easily upgrade SD cards than having to redo the EmuNAND partition from scratch.

 

[Dionicio3]

you can easily upgrade SD cards than having to redo the EmuNAND partition from scratch.

That isn't true at all, you can copy partitions between different SD cards without redoing everything.

 

[SylverReZ]

That isn't true at all, you can copy partitions between different SD cards without redoing everything.

How do I do that? Saying that "it isn't true at all" doesn't even help, let everyone have their own opinions.

 

[Dionicio3]

How do I do that?

This thread isn't meant to be a support/how to guide of any sort. There's plenty of tutorials online on how to backup partitions and write them to a new device, this isn't a 3DS specific thing

 

[SylverReZ]

This thread isn't meant to be a support/how to guide of any sort. There's plenty of tutorials online on how to backup partitions and write them to a new device, this isn't a 3DS specific thing

Yeah but its still on-topic. I was thinking of that as well, don't know if they have to written in a different way.

 

[ghjfdtg]

A reason i have not seen mentioned here for having emuNAND (i think this name is stupid because nothing is emulated but redirected) is reducing wear on the internal eMMC in your 2/3DS. I don't use it but i feel like this could be a pro argument for someone. Replacing the eMMC is possible but a pain. At some point it will die just like any flash based storage media.