Yes.In plain English: with this Atmosphere updates the DNS blocking thing isn't working?
https://github.com/Atmosphere-NX/Atmosphere/issues/2862
Enable prodinfo-blanker. Glad I have that as default on my configs
Yes.In plain English: with this Atmosphere updates the DNS blocking thing isn't working?
Checking just in case. HavingEnable prodinfo-blanker. Glad I have that as default on my configs![]()
cal0blank=1 on all relevant boot entries in hekate_ipl.ini should blank it, right?Just new to the whole thing but stuff like this makes my head spin. I'll just wait for the updates before I take the Switch out of Airplane Mode.Having a piHole or similar setup for the whole home is worth it any day, just for ads and malware. But on days like this, it pays off extra.
Checking just in case. Havingcal0blank=1on all relevant boot entries inhekate_ipl.inishould blank it, right?
Yes, I have custom DNS as wellHaving a piHole or similar setup for the whole home is worth it any day, just for ads and malware. But on days like this, it pays off extra.
Checking just in case. Havingcal0blank=1on all relevant boot entries inhekate_ipl.inishould blank it, right?
If I add these lines (or replace old ones) I'm good?Yes, I have custom DNS as wellRemoving malware and ads. But I feel sad for people not knowing this issue right now. Ninjas are celebrating.
In exosphere.ini
blank_prodinfo_emummc=1
and in hekate_ipl.ini :
[CFW - emuMMC]
pkg3=atmosphere/package3
emummcforce=1
cal0blank=1
sure is a newbie question
update hekate and atmosphere
Boot Hekate 6.5.4 and boot Emummc working but not sys MMC, error
[Atmosphere (Emummc)]
fss0=atmosphere/package3
emummcforce=1
atmosphere=1
icon=bootloader/res/Atmoslogo.bmp
usb3force=1
[Atmosphere (sysMMC)]
fss0=atmosphere/package3
emummc_force_disable=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp
usb3force=1
[config]
autoboot=1
autoboot_list=0
bootwait=1
backlight=100
noticker=0
autohosoff=0
autonogc=1
updater2p=1
bootprotect=0
[CFW - emuMMC]
pkg3=atmosphere/package3
emummcforce=1
cal0blank=1
icon=bootloader/res/emu_boot.bmp
[Stock - sysMMC]
pkg3=atmosphere/package3
emummc_force_disable=1
stock=1
icon=bootloader/res/stock_boot.bmp
[exosphere]
debugmode=1
debugmode_user=0
disable_user_exception_handlers=0
enable_user_pmu_access=0
enable_mem_mode=0
blank_prodinfo_sysmmc=0
blank_prodinfo_emummc=1
allow_writing_to_cal_sysmmc=0
log_port=0
log_baud_rate=115200
log_inverted=0
Thank you I will reviewThe fss0 configuration key was deprecated in Hekate v6.3.0 and replaced by the pkg3 key
I have this for hekate_ipl.ini
Code:[config] autoboot=1 autoboot_list=0 bootwait=1 backlight=100 noticker=0 autohosoff=0 autonogc=1 updater2p=1 bootprotect=0 [CFW - emuMMC] pkg3=atmosphere/package3 emummcforce=1 cal0blank=1 icon=bootloader/res/emu_boot.bmp [Stock - sysMMC] pkg3=atmosphere/package3 emummc_force_disable=1 stock=1 icon=bootloader/res/stock_boot.bmp
And exosphere.ini
Code:[exosphere] debugmode=1 debugmode_user=0 disable_user_exception_handlers=0 enable_user_pmu_access=0 enable_mem_mode=0 blank_prodinfo_sysmmc=0 blank_prodinfo_emummc=1 allow_writing_to_cal_sysmmc=0 log_port=0 log_baud_rate=115200 log_inverted=0
How do I activate the 16MB?Trying to understand the sentence about the memory available for custom system modules, I looked at the previous release note and it is quite blurry for me. I hope someone can help me figuring it out.
Here is what I understood from changelog and discussions here:
- Prior to HOS 19.0.0 -> 40 MB available for custom modules (edited)
- HOS 19.0.0 -> 24 MB available (edited / thanks @Hayato213 for the correction)
- HOS 20.0.0 -> 14 MB available, but ams.mitm footprint reduced by 20 MB. Does this mean 14 MB or 34 MB available in the end?
- HOS 21.0.0 -> quantity available reduced by 10 MB, so @impeeza suggested 3.86 MB available and @SciresM answered the 19th of November 2025 that latest tests were given 16 MB
- HOS 23.0.0 -> quantity available reduced to 7 MB but Atmosphere team was able to "steal" 9 MB from Nintendo's modules, leading to 16 MB available back. Why the changeling mentioning "we can no longer launch browser applets (e.g.: eshop) without crashing."? Was 7 MB not enough for Atmosphere to run without any module installed by the user?
Is this summary correct? What happened with HOS 21.0.0? Is it recommended to upgrade to 23.0.0 or to remain on older HOS version?

You do not need to do anything, atmosphère do it for you.How do I activate the 16MB?

Thanks for the info! I do remember hearing that blanking prodinfo is probably not enough and that SciresM added that feature just so that people would stop blanking their prodinfo and more often than not losing their prodinfo backup. Apparently DBI can get the right prodinfo while prodinfo is blanked and that makes me wonder if big N can do that as well? In any case, 90DNS or similar seems to be the go-to option for now.it will however cause people who run nothing but dns.mitm, to send all and everything to nintendo, and have the people whom that happen to, end up being banned from dauth (eshop)
(my fork will now force enable the atmospheres prodinfo blanking option as consequence, and will keep it that way in the future)
I'll have to set up one one of these days.Having a piHole or similar setup for the whole home is worth it any day, just for ads and malware. But on days like this, it pays off extra.
I'm assuming this is fetching the backup file(s) atmosphere makes automatically on the sd card, not that there are many legitimate reasons for a homebrew to touch your console unique certificate.Apparently DBI can get the right prodinfo while prodinfo is blanked
When you say "my fork" do you mean Atmosphere being forked, or just the current one? Forgive my ignorance here!We was at the "we are doomed" point right now, we only "stole back" 9MB in 23.0.0 by trimming down reserved memory pool 3 official applets use by using convoluted patches.
or well, the only people doomed are the ones who insist on running unecessary sysmodules
Post automatically merged:
supposedly dns.mitm isn't functional in 23.0.0 with atmosphere 1.12.0;
doesn't impact people who are banned from nintendos domains, or people who use third-party DNS servers / have prodinfo-blankers (such as the exosphere option).
it will however cause people who run nothing but dns.mitm, to send all and everything to nintendo, and have the people whom that happen to, end up being banned from dauth (eshop)
(my fork will now force enable the atmospheres prodinfo blanking option as consequence, and will keep it that way in the future)

He meant his fork with built in patches: https://github.com/borntohonk/Atmosphere/releasesWhen you say "my fork" do you mean Atmosphere being forked, or just the current one? Forgive my ignorance here!
Either banned, have prodinfo blanked already or 90DNS (or similar) doing its job? Most of the users just had DNS MITM set up and therefore it connected to the Nintendo servers when they went online after the firmware update.I am unsure how some people's Switch seems to be downloading eShop updates for games though... mine does not connect to anything even nintendo.com via the browser
"the browser" -> no such thing as an official browser provided by Nintendo or atmosphere.When you say "my fork" do you mean Atmosphere being forked, or just the current one? Forgive my ignorance here!
I am unsure how some people's Switch seems to be downloading eShop updates for games though... mine does not connect to anything even nintendo.com via the browser
I've always have Exosphere blanking on so it's possible that, as I understand, their servers refuse the connection without a valid handshake? Currently not banned though as tested it on OFW just now and eShop works. I guess it remains to be seen whether Exosphere blanking was enough or we'll get a ban wave soon.He meant his fork with built in patches: https://github.com/borntohonk/Atmosphere/releases
Either banned, have prodinfo blanked already or 90DNS (or similar) doing its job? Most of the users just had DNS MITM set up and therefore it connected to the Nintendo servers when they went online after the firmware update.
I was using the browser in Sphaira (which I understand is the hidden Nintendo browser they use for web applets). The browser is probably just respecting the hosts file as not using the new resolver?"the browser" -> no such thing as an official browser provided by Nintendo or atmosphere.
theres a probability whatever homebrew you're referencing respects the hosts file (placebo), and doesn't actually query through sfdnsres ( nn::socket::resolver::IResolver ) which dns.mitm routes the queries through.

no https communication established -> no traffic between their serversI've always have Exosphere blanking on so it's possible that, as I understand, their servers refuse the connection without a valid handshake?
The official browser applet that sphaira forces control over most likely respects the host file unconditionally, which dns.mitm most likely sets.I was using the browser in Sphaira (which I understand is the hidden Nintendo browser they use for web applets). The browser is probably just respecting the hosts file as not using the new resolver?
At first I thought the new update might have added DoH, but someone in Github already checked the changes for hard-coded servernames or IPs and apparently none was found.the issue is that official sysmodules, that aren't the browser, have other ways, not using any browser, to access services, which primarily uses sfdnsres, and in 23.0.0 seemingly does not respect the hosts file. Before 23.0.0 it did respect the hosts file. Right now is figuring out why or what changes.
from what can be seen they changed the dns handler from easycurl/libcurl to c-aresAt first I thought the new update might have added DoH, but someone in Github already checked the changes for hard-coded servernames or IPs and apparently none was found.
Hopefully they just made certain DNS requests ignore the hosts file and it can be patched easily.


