Yeah I don't think you're getting it, like at all...YEA BUT ITS A RCM PAYLOAD...
Yeah I don't think you're getting it, like at all...YEA BUT ITS A RCM PAYLOAD...
but you cant launch EmuNAND without a updated CFW what we currently not haveYeah I don't think you're getting it, like at all...
No it is notYEA BUT ITS A RCM PAYLOAD...
cool that you explain the basics..No it is not
It launches rcm payloads
Its a warmboot exploit
Warmboot is when the console is on
Coldboot is like from rcm
@Draxzelex has already told you what it iscool that you explain the basics..
oh really at the name i really didnt recognized that@Draxzelex has already told you what it is
Nereba says its a "A warmboot bootrom exploit for the Nintendo Switch "
Again just to tell youoh really at the name i really didnt recognized that
why do complaining about yourself stop it and lets get back to the main threadAgain just to tell you
"The core of this exploit is not a Horizon OS vulnerability, but a vulnerability in the bootrom of the Tegra X1. During normal operation, when the Switch enters sleep mode, the main processor shuts down all but a few essential components of itself. The OS stores some state in RAM, which is kept on and its contents preserved. On wakeup, it re-executes the bootrom, and uses the state stored in RAM and in one of the regions kept on in the main processor. The bootrom takes a special codepath called the warmboot path, based on the presence of certain data (which can also be simulated on a reboot), and allows the console to wake up from sleep. One of the wakeup tasks is to get the RAM ready for usage, as it was put in a special mode before sleep. There are a set of parameters used to configure the RAM that are used during boot and wakeup. The bootrom assumes that these parameters do not change, as they are signed during a "coldboot" (power on reset), but Nvidia forgot to verify them during warmboot. This means they are able to be changed and thus the bootrom will use them to perform arbitrary writes. We can use these writes to take control of the bootrom using the built in ipatch system. Exploition on 1.0 is simple, as the region where the RAM parameters are stored is accessible easily with the nspwn exploit. This changed on later firmware versions; using this on firmware versions higher than 1.0 requires more complex exploits to achieve the same results."
But you were the one who derailed itwhy do complaining about yourself stop it and lets get back to the main thread
no i said only that emunand doesnt work without a patched CFWBut you were the one who derailed it
no i said only that emunand doesnt work without a patched CFW
If this was the case people could get banned just for buying used joycons. Seems a little far-fetchedsimple thing:
theory:
the JoyCon has a fuse and if its burn you get banned
then the EmuNAND burns it and the SysNAND reads it and bans the console but is currently not made by Nintendo
but if you already banned then you can use the Backup BUT think about the fact that your CERT gets banned and the banned CERT is in your backup too
yea yea was a theory you can use a fuse on the Mainboard tooIf this was the case people could get banned just for buying used joycons. Seems a little far-fetched
Yes, what you described was the point of emuNAND on other consoles.No, this was and never the intention of EmuNAND. Its just a side effect of the way its designed. EmuNAND is a way to update the firmware of the console while keeping SysNAND low so it can launch certain exploits. This was why Gateway implemented EmuNAND in the 3DS days since their exploit only worked on firmwares 4.1 to 4.5. On the Switch, there are firmware-specific exploits such as Deja Vu or the newly released Nereba which allow for CFW without a jig and USB cable so EmuNAND is far from useless for banned people. Heck, it wasn't meant for people who are not banned in the first place.
That doesn't change the fact there are still uses for EmuNAND for Fusee-Gelee vulnerable consoles. The ability to update without burning fuses and AutoRCM can be useful for people who fall for the AutoRCM rumors. Its also a great way to prevent SysNAND from being bricked since its much easier to recover from EmuNAND being bricked than SysNAND. Lastly, EmuNAND has been planned from the start of Atmosphere since it was initially planned to be used with Deja Vu which was slated to work with firmwares 4.1 and below. And there are plenty of people who will take a softmod over a pseudo-hardmod that has an extremely variable chance at succeeding.Yes, what you described was the point of emuNAND on other consoles.
But first of all, it's not the point of emuNAND on RCM-able Switches.
Your point of view is exactly the reason why only SX OS is the only one to give people an emuNAND solution right now. They're the only ones to actually see that what I described was something actually useful, and people like you only started to see the use of an emuNAND when ipatched Switches came out (because yeah in this case you need an exploitable firmware to boot into CFW but you probably want an updated firmware to play with), hence why Atmosphere devs implemented stuff like creport and all but only started working on an emuNAND recently.
Second of all, I was answering in the context of the first post, which says "I keep seeing people refer to EmuNAND as if it's a way to play online with a CFW Switch. Is that really the case?".
no i said only that emunand doesnt work without a patched CFW
Switch just will crash and that's it. Nothing will be damaged.what will happened if my sd card that contain emunand get corrupted?
You will lose emunand and have to recreate one after fixing your sdcard. Also regqrding sdcards, it has been a moot whether using emunand shortens the sdcards life as using it will meqn a constant read&write to the partition used by the emunand. While the concept may hold true, many, including me, have used emunand for quite a long time and none of our sdcards broke yet.what will happened if my sd card that contain emunand get corrupted?