The reason to turn it on before creating emuMMC is so that emuMMC already has it on when you boot to it for the first time & doesn't connect to your wifi. As stated, you can turn it off in stock sysMMC and use the online features.
The reason to turn it on before creating emuMMC is so that emuMMC already has it on when you boot to it for the first time & doesn't connect to your wifi. As stated, you can turn it off in stock sysMMC and use the online features.
- Joined
- Sep 2, 2020
- Messages
- 1,283
- Trophies
- 0
- Age
- 39
- Location
- TORONTO
- Website
- form.jotform.com
- XP
- 2,218
- Country
As long as you are aware of the banned risk, yes you always can go online from cfw sysnand with dns protection disabled
- Joined
- Sep 2, 2020
- Messages
- 1,283
- Trophies
- 0
- Age
- 39
- Location
- TORONTO
- Website
- form.jotform.com
- XP
- 2,218
- Country
Why does the github for deepsea toolbox say it is version 4.0.4
but when I install it on my switch it says 4.0.2?
but when I install it on my switch it says 4.0.2?
When using autorcm it says to backup boot0 first. How much MB will that use?
Switch is currently in AutoRCM Mode. TegraRcmGUI immediately detects my Switch (RCM Device detected) the moment I connect my USB-C cable from my PC to the Switch. How do I disable AutoRCM so I can boot into the Factory OS whenever necessary? Once disabled, do I need to remove the right joy-con and use the jog in order to boot into RCM mode?
After following the NH Switch Guide, I’m now able to boot into Hekate by injecting the payload (hekate_ctcaer_6.1.0.bin) through the use of TegraRcmGUI on my laptop. The guide instructed me to place the following files on my SD Card:
• The latest release of Hekate (Download the hekate_ctcaer_(version).zip release of hekate)
• The hekate config file: hekate_ipl.ini
How can I launch Hekate using my portable RCMLoader whenever I’m out and about and don’t have access to my laptop? There are various folder (boot) options available on the RCMLoader. These are the default optins according to the text file held within the Loader itself
After following the NH Switch Guide, I’m now able to boot into Hekate by injecting the payload (hekate_ctcaer_6.1.0.bin) through the use of TegraRcmGUI on my laptop. The guide instructed me to place the following files on my SD Card:
• The latest release of Hekate (Download the hekate_ctcaer_(version).zip release of hekate)
• The hekate config file: hekate_ipl.ini
How can I launch Hekate using my portable RCMLoader whenever I’m out and about and don’t have access to my laptop? There are various folder (boot) options available on the RCMLoader. These are the default optins according to the text file held within the Loader itself
LED Color | Folder Name | Built-in Payload |
| Blue | ATMOSPHERE_HEKATE | HEKATE_CTCAER_6.1.0_Nyx_1.6.0 |
| Green | REINX | REINX_3.0 |
| RED | SXOS | SX_loader_1.0 |
| Yellow | USER 1 | |
| Magenta | USER 2 | |
| Cyan | USER 3 |
If I remember correctly, reboot to Hekate, go to Tools > Archive Bit - AutoRCM > Disable AutoRCM.
That's correct, or any other (similar) method that allows you to boot into RCM.
You can choose whether or not to update your RCMLoader with the latest hekate_ctcaer_x.x.x.bin file because bootloader/update.bin will be checked and, if newer, it will get loaded instead. It's already included with the zip archive you extract when you're updating your Hekate build.
Not that v6.1.1 has been released so do update to the latest whenever you're able to as you'll need it for the latest 18.0.0 firmware. Same goes for the Atmosphere's latest release, v1.7.0.
Note that, if you were using sigpatches for game backups to work, they will no longer work with the latest official Atmosphere (v1.7.0 and newer). You have a few options:
1) Use the latest sys-patch (v1.5.1) module.
2) Use the latest sigpatches, but load Atmosphere's package3 via Hekate's fss0 (to do so, extract the previously downloaded sigpatches ZIP archive to the root of your SD card, reboot to Hekate, go to Launch and select CFW - emuMMC or CFW - sysMMC, depedning on which one you use) or use a modified fusee.bin payload with ips kip patches support.
How did you manage to dig up a post from last year??? Anyways, boot0 is only around 4 MB so its very small and easy to dump.
ok so i finally decided to use auto boot and autorcm, and was quickly reminded why not too. so after turning them on evrything ok i turned it off it loaded backup fine. then i wanted to know how do i get back into Hekate cuz the Vol - wasn't working. so iread you can load the bin from Tinfoil so i did that. then got this error but it loaded hekate then i tried loading cfw emummc and got same error. then loaded fusee.bin from payloads now i got nothing, it feels bricked
EDIT: ok it flashed when i inserted my jig but just loaded to a black screen
here is what my ipi looks like now
[config]
autoboot=3
autoboot_list=0
bootwait=3
backlight=100
noticker=0
autohosoff=0
autonogc=1
updater2p=1
bootprotect=0
EDIT: ok it flashed when i inserted my jig but just loaded to a black screen
here is what my ipi looks like now
[config]
autoboot=3
autoboot_list=0
bootwait=3
backlight=100
noticker=0
autohosoff=0
autonogc=1
updater2p=1
bootprotect=0
Attachments
Last edited by laz305,
That isn't your full hekate.ipl file because your autoboot setting is set to 3 and we have no idea what "3" is. You have to post the full hekate_ipl.ini file with your boot profiles as well.
I've been following the NH Switch guide and most things seem to be working fine (when I first tried to boot emuMMC with Atmosphere I got an error message but fixing the archive bit helped). The update to 17.0.1 on my emuMMC through Daybreak also worked, my sysNAND is still on 16.0.3. I have not connected to the internet yet on either.
First question: Is there actually a point in ever booting sysNAND w/ Atmosphere? Seems like that would only make sense if I did homebrew stuff while still trying to be able to connect to Nintendo.
Second (block of) question(s): Is setting up exosphere literally as easy as creating the respective exosphere.ini files in the root of your SD card for the sysNAND and in emuMMC/RAW1 for emuMMC? Also what exactly is the former for? I assume exosphere is a component of atmosphere, so if I just boot my stock sysNAND it wouldn't do anything, would it? I also setup DNS MITM with the list of domain names from the NH Switch guide as I previously posted. Is there a way to check my setup or should I take any further steps before I connect to the Internet again?
Third (block of) question(s): What would happen if I accidentally updated to 18.0.0 on sysNAND? I'd assume my emuMMC would remain on 17.0.1, but I wouldn't be able to boot into it until I update Hekate/Atmosphere? Is there a point in updating to latest FW besides accessing the online component on sysNAND and potentially running games that require a higher FW?
Fourth question: I simply overwrote the hekate_ipl.ini from the NH Switch guide with the one included in the latest sigpatches. Is that correct? (Edit: I went ahead and checked the differences between both files:
Not sure what the additional entries in the config section are doing but for the three boot options it merely changed the icons (which is smth I noticed) and replaced the kip1 entry with kip1patch.
Last (block of) question(s): What is the best way to downpatch a game? What is the best app to use?
I appreciate all the help I can get, there's so much info out there on this topic it's a little difficult to handle.
First question: Is there actually a point in ever booting sysNAND w/ Atmosphere? Seems like that would only make sense if I did homebrew stuff while still trying to be able to connect to Nintendo.
Second (block of) question(s): Is setting up exosphere literally as easy as creating the respective exosphere.ini files in the root of your SD card for the sysNAND and in emuMMC/RAW1 for emuMMC? Also what exactly is the former for? I assume exosphere is a component of atmosphere, so if I just boot my stock sysNAND it wouldn't do anything, would it? I also setup DNS MITM with the list of domain names from the NH Switch guide as I previously posted. Is there a way to check my setup or should I take any further steps before I connect to the Internet again?
Third (block of) question(s): What would happen if I accidentally updated to 18.0.0 on sysNAND? I'd assume my emuMMC would remain on 17.0.1, but I wouldn't be able to boot into it until I update Hekate/Atmosphere? Is there a point in updating to latest FW besides accessing the online component on sysNAND and potentially running games that require a higher FW?
Fourth question: I simply overwrote the hekate_ipl.ini from the NH Switch guide with the one included in the latest sigpatches. Is that correct? (Edit: I went ahead and checked the differences between both files:
[config]
ADDED autoboot=0
ADDED autoboot_list=0
ADDED bootwait=0
ADDED autohosoff=0
ADDED autonogc=1
ADDED backlight=100
[CFW emuMMC]
DELETED kip1=atmosphere/kips/*
ADDED kip1patch=nosigchk
ADDED atmosphere=1
REPLACED icon=bootloader/res/emu_boot.bmp WITH icon=bootloader/res/icon_payload.bmp
[CFW sysMMC]
DELETED kip1=atmosphere/kips/*
ADDED kip1patch=nosigchk
ADDED atmosphere=1
REPLACED icon=bootloader/res/sys_cfw_boot.bmp WITH icon=bootloader/res/icon_payload.bmp
[Stock sysMMC]
REPLACED icon=bootloader/res/stock_boot.bmp WITH icon=bootloader/res/icon_switch.bmp
Not sure what the additional entries in the config section are doing but for the three boot options it merely changed the icons (which is smth I noticed) and replaced the kip1 entry with kip1patch.
Last (block of) question(s): What is the best way to downpatch a game? What is the best app to use?
I appreciate all the help I can get, there's so much info out there on this topic it's a little difficult to handle.
Last edited by NeoYggdrasill,
- There are reasons for booting CFW on sysMMC. The main reason, which I do, is to update your firmware without burning fuses. This can be accomplished without even running homerew. If you want to know the full details, just ask
- Exosphere, as well as Incognito, prevent your console from booting if you're on firmware 17.0 or higher. You can mitigate this by setting up either dns.mitm or 90DNS in tandem but at that point, you don't need exosphere/Incognito. In either event, while I don't know how you test if dns.mtm is working, 90DNS has its own tester to ensure its working. And I've always recommended 90DNS because not only does it predate exosphere, Incognito, and dns.mitm, but it has always functioned
- sysMMC and emuMMC operate independently of each other aside from the hardware they share. If you update sysMMC only to 18.0, you would still be able to launch emuMMC on 17.0.1 without the need for updating Atmosphere/Hekate. Regardless, the only need for updating to 18.0 is accessing the eShop and playing games online. Its too new for any games to require that firmware as of the time of writing.
- Basically the latest Atmosphere stopped supporting kips which is why you had to delete those lines in your hekate_ipl.ini file. However this is only an issue if you use fusee to boot Atmosphere. I don't recommend the NH Switch guide so I have no idea what method they use to load Atmosphere but I'm going to assume they make you chainload fusee via Hekate which leads to the same effects as simply loading fusee. For a beginner, I guess its fine but personally, everyone should be using Hekate to directly launch Atmosphere because not only does it avoid the problem with the newest Atmosphere but it avoids the need for fusee
- As sad as it makes to admit this, that honor will have to go to DBI. The reason it makes me sad is because the developer announced that they are going to stop supporting it meaning there is no title manager that is being actively developed. But I guess its the only practical option for downgrading games nowadays.
First of all, thanks for the answer! Unfortunately, there are a lot of things that I don't really understand yet.
1. What do you mean by burning fuses? I figured I'd just update the sysNAND through Wifi as usual if it becomes a necessity in the future (however CFW gives more control over which version you'd want to update to and if I'd wanted to do that I could use Daybreak again, but this time on sysNAND /w Atmosphere).
2. This is a situation where one experienced and seemingly knowledgable user tells me one thing and the other tells me something else. I've found so much info about this and contradictory statements it's really confusing.
The NH Switch guide suggested using this emummc.txt file in atmosphere/hosts as your DNS-MITM redirection config (note how the top line comment mentions this is a "90 DNS equivalent":
# 90DNS-equivalent
# 90DNS-equivalent
127.0.0.1 *nintendo.com
127.0.0.1 *nintendo.net
127.0.0.1 *nintendo.jp
127.0.0.1 *nintendo.co.jp
127.0.0.1 *nintendo.co.uk
127.0.0.1 *nintendo-europe.com
127.0.0.1 *nintendowifi.net
127.0.0.1 *nintendo.es
127.0.0.1 *nintendo.co.kr
127.0.0.1 *nintendo.tw
127.0.0.1 *nintendo.com.hk
127.0.0.1 *nintendo.com.au
127.0.0.1 *nintendo.co.nz
127.0.0.1 *nintendo.at
127.0.0.1 *nintendo.be
127.0.0.1 *nintendods.cz
127.0.0.1 *nintendo.dk
127.0.0.1 *nintendo.de
127.0.0.1 *nintendo.fi
127.0.0.1 *nintendo.fr
127.0.0.1 *nintendo.gr
127.0.0.1 *nintendo.hu
127.0.0.1 *nintendo.it
127.0.0.1 *nintendo.nl
127.0.0.1 *nintendo.no
127.0.0.1 *nintendo.pt
127.0.0.1 *nintendo.ru
127.0.0.1 *nintendo.co.za
127.0.0.1 *nintendo.se
127.0.0.1 *nintendo.ch
127.0.0.1 *nintendo.pl
127.0.0.1 *nintendoswitch.com
127.0.0.1 *nintendoswitch.com.cn
127.0.0.1 *nintendoswitch.cn
95.216.149.205 *conntest.nintendowifi.net
95.216.149.205 *ctest.cdn.nintendo.net
So I'm kinda assuming it at least tries to accomplish the exact same thing as 90DNS (which I've also seen other people saying shouldn't be used anymore). After a suggestion from another user, I also looked at the rentry guide on DNS-MITM and Exosphere. What I have right now is basically the file above (cause it includes all the redirects from the rentry guide) and exosphere.ini files in the root of my SD card and emummc/RAW1. My emuMMC is on 17.0.1, so what you're saying is if I were to remove the emummc.txt then exosphere would prevent my console from booting into what, both sysNAND (still on 16.0.3) and emuNAND? So it's essentially another layer of security that ensures that DNS-MITM is doing its thing?
And just to clarify, your suggestion would be to use 90DNS only?
Edit: I read into this more. So basically, 90dns is a configured dns that also blacklists the domains above. Using both 90dns and MITM would be redundant, but the latter gives more control over what gets blocked + there's no risk of accidentally resetting your DNS settings when switching networks.
3. Okay, that is good to know. Makes me wonder though why I saw people saying they were fucked after accidentally updating to 18.0.0 (how can that even happen if you block the Nintendo servers?).
4. I can't tell what exactly the difference is between those two methods because I don't know what's happening in the background, what I do is inject the hekate_ctcaer_6.1.0.bin payload, inside hekate I just launch into emuMMC, sounds like the method you're recommending. So just overwriting the hekate_ipl.ini was actually right. Still, there might be an issue with my sigpatches, but I need to look into it further.
5. Alright, mental note taken, thank you.
Last edited by NeoYggdrasill,
Did you turn off the console or did you leave it in sleep mode? If you powered it off, how did you power it off? Personally, I have a console with AutoRCM and I have left it for months with no issues so I can safely your issue is not due to AutoRCM.
Patches are only needed for launching backups.
First of all, thanks for the answer! Unfortunately, there are a lot of things that I don't really understand yet.
1. What do you mean by burning fuses? I figured I'd just update the sysNAND through Wifi as usual if it becomes a necessity in the future (however CFW gives more control over which version you'd want to update to and if I'd wanted to do that I could use Daybreak again, but this time on sysNAND /w Atmosphere).
2. This is a situation where one experienced and seemingly knowledgable user tells me one thing and the other tells me something else. I've found so much info about this and contradictory statements it's really confusing.
The NH Switch guide suggested using this emummc.txt file in atmosphere/hosts as your DNS-MITM redirection config (note how the top line comment mentions this is a "90 DNS equivalent":
# 90DNS-equivalent # 90DNS-equivalent 127.0.0.1 *nintendo.com 127.0.0.1 *nintendo.net 127.0.0.1 *nintendo.jp 127.0.0.1 *nintendo.co.jp 127.0.0.1 *nintendo.co.uk 127.0.0.1 *nintendo-europe.com 127.0.0.1 *nintendowifi.net 127.0.0.1 *nintendo.es 127.0.0.1 *nintendo.co.kr 127.0.0.1 *nintendo.tw 127.0.0.1 *nintendo.com.hk 127.0.0.1 *nintendo.com.au 127.0.0.1 *nintendo.co.nz 127.0.0.1 *nintendo.at 127.0.0.1 *nintendo.be 127.0.0.1 *nintendods.cz 127.0.0.1 *nintendo.dk 127.0.0.1 *nintendo.de 127.0.0.1 *nintendo.fi 127.0.0.1 *nintendo.fr 127.0.0.1 *nintendo.gr 127.0.0.1 *nintendo.hu 127.0.0.1 *nintendo.it 127.0.0.1 *nintendo.nl 127.0.0.1 *nintendo.no 127.0.0.1 *nintendo.pt 127.0.0.1 *nintendo.ru 127.0.0.1 *nintendo.co.za 127.0.0.1 *nintendo.se 127.0.0.1 *nintendo.ch 127.0.0.1 *nintendo.pl 127.0.0.1 *nintendoswitch.com 127.0.0.1 *nintendoswitch.com.cn 127.0.0.1 *nintendoswitch.cn 95.216.149.205 *conntest.nintendowifi.net 95.216.149.205 *ctest.cdn.nintendo.net
So I'm kinda assuming it at least tries to accomplish the exact same thing as 90DNS (which I've also seen other people saying shouldn't be used anymore). After a suggestion from another user, I also looked at the rentry guide on DNS-MITM and Exosphere. What I have right now is basically the file above (cause it includes all the redirects from the rentry guide) and exosphere.ini files in the root of my SD card and emummc/RAW1. My emuMMC is on 17.0.1, so what you're saying is if I were to remove the emummc.txt then exosphere would prevent my console from booting into what, both sysNAND (still on 16.0.3) and emuNAND? So it's essentially another layer of security that ensures that DNS-MITM is doing its thing?
And just to clarify, your suggestion would be to use 90DNS only?
3. Okay, that is good to know. Makes me wonder though why I saw people saying they were fucked after accidentally updating to 18.0.0 (how can that even happen if you block the Nintendo servers?).
4. I can't tell what exactly the difference is between those two methods because I don't know what's happening in the background, what I do is inject the hekate_ctcaer_6.1.0.bin payload, inside hekate I just launch into emuMMC, sounds like the method you're recommending. So just overwriting the hekate_ipl.ini was actually right. Still, there might be an issue with my sigpatches, but I need to look into it further.
5. Alright, mental note taken, thank you.
- The Switch has anti-downgrade fuses. If you've ever owned an Xbox 360, its the same technology. These fuses make downgrading to lower firmware versions inaccessible. The only reason you'd ever want to downgrade is because a lower firmware version has an exploit you want to take advantage of such as an untethered coldboot. For this reason, there is merit in saving your fuses. And as of the time of this writing, Nintendo has never banned for only a mismatched fuse count although there was a time when Nintendo banned people for updating their firmware before it was publicly available. Therefore, it is objectively better to preserve your fuses than to preserve them if you are willing to put in the work.
- In that case, you should ask them why not use 90DNS. And I can tell you that most of the time, they will tell you its because you are putting your faith in 90DNS remaining up as well as blocking the correct URLs which is just paranoia. Not only is it run by a trusted member of the community but its been endorsed by ReSwitched who are the same people that make Atmosphere. So if there are ever any issues with 90DNS, it will be noticed very quickly and adjusted accordingly. The only reason I do not recommend dns.mitm is that it only works in CFW which you might think makes sense because you do not want to transmit info to Nintendo in CFW. But the problem is the Switch can collect telemetry even when offline so even if you block Nintendo's servers in CFW, unless you restore a clean eMMC backup, you will wind up sending that info when you boot OFW without dns.mitm. After 17.0, no sane person should be recommending exosphere/Incognito because they don't work without 90DNS/dns.mitm which already accomplish the former's job. Anyways, 90DNS and dns.mitm are both fine; I just personally push 90DNS because I feel like the community doesn't support it like they used to and it can work in OFW unlike dns.mitm. The one pro of dns.mitm is that it works in both emuMMC and sysMMC by default while 90DNS would have to be setup manually in both but I don't see the point of running either 90DNS or dns.mitm in sysMMC.
- Thing is those people aren't blocking the servers on sysMMC because most people play online using sysMMC. As stated previously, there isn't much reason to block Nintendo's servers on sysMMC. New firmware updates only drop every few weeks or months so its not much of an excuse to have the servers blocked when it might be a long time until Nintendo updates the firmware. What people should be doing is being a bit more mindful when going through the motions when going online because you never know when Nintendo will drop an update
- From the end-user perspective, there isn't much of a difference. Heck, there was a point when booting with Hekate was faster than fusee. But as of the newest Atmosphere, if you use the normal patches, they won't work anymore if you use fusee. If you want to see which method you are using, you can take a peek at your hekate_ipl.ini file. If it says fss0, then you aren't using fusee. Also remember that every time you update either Atmosphere or your firmware, you must update the patches.
1. I see,. You talked about updating the firmware, so I didn't take downgrading into consideration. That seems like a fairly specific use case (I'm actually interested in potentially running a second emuMMC on lower FW sometime in the future, but that should be different). For now I'll ignore sysMMC w/ Atmosphere.
2. You quoted me before my edit, I did some further reading on the topic.
That last part is kind of an argument, but I agree with your general sentiment that both are very viable options.
3. I was moreso thinking that an accidental update on sysMMC wouldn't affect your emuMMC. The only thing you'd temporarily use access to is CFW on sysMMC and to me - as a beginner - that doesn't seem too problematic (unless you want do do stuff like you mentioned under #1). Or maybe those people never used emuMMC in the first place.
4. Alright, I'm not using fusee then. The current sigpatches in this thread also work for 17.0.1 though, right? I'm using Atmosphere 1.6.2.
At the very least, I'd prefer someone pick dns.mitm after weighing it against 90DNS rather than everyone just echoing to use dns.mitm instead of 90DNS. People ignore the fact that not only did it come out first but it has advantages that not even the likes of exosphere, Incognito, or dns.mitm can boast.
You are correct. What is more likely is that these people use CFW on sysMMC for a variety of reasons. While not routinely recommended, using a save manager on sysMMC is the best way to move save data from sysMMC to emuMMC without remaking your emuMMC. If you don't care about the risks, its a perfectly acceptable use case.
All patches are always backwards compatible unless stated otherwise. Its similar to how the latest version of Atmosphere also supports all previous firmware versions. If something doesn't work on an earlier firmware, that's a problem and needs to be addressed.
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
@
SylverReZ:
You can make a post on the DS forum about your findings, and they'll do their best to respond. They have a GBAtemp account here, you know. -
@
Materia_tofu:
oh ye i made a post i did forget they had an account i prob shouldve tagged them in the post+1
tbh -
-
-
-
-
@
BakerMan:
Update on my brother: He's home now, tired and hungry, obviously, but other than that, seems to be doing fine.+2 -
-
-
@
BakerMan:
Well, from what I've heard from my parents, he had a seizure last night, perhaps an epileptic episode, fucking died, had a near death experience, my dad called the paramedics, they showed up, took him to the hospital, and he woke up covered in tubes, and started complaining.
-
-
-
-
-
-
-
