Hacking Atmosphere-NX - Custom Firmware in development by SciresM

  • Thread starter Thread starter Waze0613
  • Start date Start date
  • Views Views 2,815,988
  • Replies Replies 9,439
  • Likes Likes 93
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.

Enable prodinfo-blanker. Glad I have that as default on my configs:)
Checking just in case. Having cal0blank=1 on all relevant boot entries in hekate_ipl.ini should blank it, right?
 
sure is a newbie question
update hekate and atmosphere
Boot Hekate 6.5.4 and boot Emummc working but not sys MMC, error

it could be Mission Control "content folder"

[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
 
Last edited by alfonsovin,
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. Having 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. Having cal0blank=1 on all relevant boot entries in hekate_ipl.ini should blank it, right?
Yes, I have custom DNS as well :) Removing 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
 
  • Like
Reactions: Nephiel
Yes, I have custom DNS as well :) Removing 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
If I add these lines (or replace old ones) I'm good?

Don't wanna F things up.
 
  • Like
Reactions: Bigdrago
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

The 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

And use these DNS servers in network settings from 90dns/Lava team:
163.172.141.219
207.246.121.77
 
Last edited by Bigdrago,
The 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
Thank you I will review
I got working both system eliminate Mission Control that is not compatible with 23.0 firmware

PS: fusee.bin splash a yellow screen if try to use as payload (reboot payload.bin) or using in launcher PC. By now only use hekate payload to boot and reboot system
 
  • Like
Reactions: impeeza
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?
How do I activate the 16MB?
 
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)
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.
Post automatically merged:

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'll have to set up one one of these days. :D
 
Apparently DBI can get the right prodinfo while prodinfo is blanked
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.

the intent with blanking your console unique ssl certificate (thats whats in your prodinfo), is to make it so ssl communication (https) cannot be established, even if nintendos domains resolve correctly, for whatever reason.

also the feature being implemented into atmosphere had to do with the fork i ran for tinfoil back then, which became a big enough stink that he caved in and added it, alongside a setting to be able to read cal0 (and defaults being able to read it under emummc), also to counter the incognito / rcm / 2.0 variants that literally edited the prodinfo incorrectly
 
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)
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
 
Last edited by Hpshout,
When you say "my fork" do you mean Atmosphere being forked, or just the current one? Forgive my ignorance here!
He meant his fork with built in patches: https://github.com/borntohonk/Atmosphere/releases
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
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.
 
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
"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.
 
  • Like
Reactions: Blythe93
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'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.
"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.
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?

Either way nothing Nintendo on my Switch works, but it's probably down to profinfo blanking. Seems like for people without that literally everything works for them like eShop etc so their telemetry data has probably been sent over now 🥲
 
  • Like
Reactions: Blythe93
I've always have Exosphere blanking on so it's possible that, as I understand, their servers refuse the connection without a valid handshake?
no https communication established -> no traffic between their servers
no client certificate to use -> no ssl/https communication possible.

Yes, that's the core concept. Currently dns.mitm doesn't work (supposedly), which means ctest is the only domain going through in your usecase, paired with patches to NIM (you probably use sys-patch), as i added that patch to sys-patch (or .ips form from the sigpatches thread); which removes the crash condition from dns.mitm not being configured while blanking your certificate.


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 official browser applet that sphaira forces control over most likely respects the host file unconditionally, which dns.mitm most likely sets.

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.
 
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.
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.
Hopefully they just made certain DNS requests ignore the hosts file and it can be patched easily.
 
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.
Hopefully they just made certain DNS requests ignore the hosts file and it can be patched easily.
from what can be seen they changed the dns handler from easycurl/libcurl to c-ares

speculative:
host file ignored unless browser ...?
(if yes, dns.mitm has become obsolete - rip - would require rework of its current existence, or alternatively, just working 22.5.0 and below)
 
  • Like
Reactions: Nephiel
I've now manually added 90dns to my internet config just to stop any Nintendo pings at all... perhaps as expected the 'Test Connection' function now fails, which suggests the hosts file is indeed non-functional for sysmodules? Regardless of DNS settings in HOS the browser in Sphaira refuses to connect to any Nintendo server, but does work for say Google.

On a side note... did 23.0.0 improve Joycon connectivity at all? I've now switched from HATS to just creating my own setup with Atmosphere+Hekate+the stuff I want manually, and since 23.0.0 I have a lot more reliable Joycon connectivity now (before it was very sensitive to interference as if the range was very short). The things that could have caused issues I used to remove like MissionControl... so either 23.0.0 changed something or HATS broke something (I've heard they modify Atmosphere/package3/kernel/etc)
 

Site & Scene News