mirrors/Atmosphere
1
0
Fork 0
mirror of https://github.com/Atmosphere-NX/Atmosphere.git synced 2024-11-10 14:11:43 +00:00
Code Issues Releases Activity

Merge pull request #929 from hexkyz/master

Browse source 
docs: re-write documentation
This commit is contained in:
hexkyz 2020-05-01 18:10:56 +01:00 committed by GitHub
commit b56f9966b7
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
43 changed files with 873 additions and 645 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
docs/building.md
View file

@ -1,8 +1,27 @@
# Building Atmosphère
The process for building Atmosphère is similar to building Fusée Gelée payloads and other Switch apps.
Building Atmosphère is a very straightforward process that relies almost exclusively on tools provided by the [devkitPro](https://devkitpro.org) organization.
In order to build Atmosphère you must have devkitARM and devkitA64 installed on your computer. You can find instructions on how to install and setup devkitARM and devkitA64 on various OSes [here](https://devkitpro.org/wiki/Getting_Started). You'll need to install the following packages via (dkp-)pacman: switch-dev switch-freetype switch-libjpeg-turbo devkitARM devkitarm-rules
## Dependencies
+ [devkitA64](https://devkitpro.org)
+ [devkitARM](https://devkitpro.org)
+ [Python 2 or 3](https://www.python.org) (optional)
+ [PyCryptodome](https://pypi.org/project/pycryptodome) (optional)
sept requires you have python installed with the pycryptodome PyPi packages (`pip install pycryptodome`). You may also want to install the zip package from your package manager of choice to support the `make dist` recipe.
## Instructions
1. Follow the guide located [here](https://devkitpro.org/wiki/Getting_Started) to install and configure all the tools necessary for the build process.
Once you have finished installing the devkitPro-provided toolchain/libraries, python, and the dependencies, simply clone the Atmosphère repo (clone with the -r flag), change your directory to it and run `make`.
2. Install the following packages via (dkp-)pacman:
+ `switch-dev`
+ `switch-libjpeg-turbo`
+ `devkitARM`
+ `devkitarm-rules`
3. (Optional) In order to build [sept](components/sept.md) the pycryptodome PyPi package is required, which can be installed by running `pip install pycryptodome` under the installed Python environment of your choice or by installing the complete zip package to support the `make dist` recipe. This is an optional step included for advanced users who have the ability to provide the necessary encryption/signing keys themselves.
4. It is, instead, possible to build [sept](components/sept.md) by providing previously encrypted/signed binaries distributed by official Atmosphère release packages. In order to do so, export the following variables in your current environment:
+ `SEPT_00_ENC_PATH` (must point to the `sept-secondary_00.enc` file)
+ `SEPT_01_ENC_PATH` (must point to the `sept-secondary_01.enc` file)
+ `SEPT_DEV_00_ENC_PATH` (must point to the `sept-secondary_dev_00.enc` file)
+ `SEPT_DEV_01_ENC_PATH` (must point to the `sept-secondary_dev_01.enc` file)
5. Finally, clone the Atmosphère repository and run `make` under its root directory.

29
docs/changelog.md
View file

@ -1,4 +1,5 @@
# Changelog
## 0.12.0
+ Configuration for exosphere was moved to sd:/exosphere.ini.
+ This is to facilitate BIS protection changes described below.
@ -47,6 +48,7 @@
+ A bug was fixed that could cause boot to fail sporadically due to cache/tlb mismanagement when doing physical ASLR of the kernel.
+ A number of other minor issues were addressed (and more of Atmosphere was updated to reflect other changes in 10.0.x).
+ General system stability improvements to enhance the user's experience.
## 0.11.1
+ A bug was fixed that could cause owls to flicker under certain circumstances.
+ For those interested in technical details, in 10.0.0 kernelldr/kernel no longer set cpuactlr_el1, assuming that it was set correctly by the secure monitor.
@ -54,6 +56,7 @@
+ This caused a variety of highly erratic symptoms, including causing basically any game to crash seemingly randomly.
+ A number of other major inaccuracies in exosphere were corrected.
+ General system stability improvements to enhance the user's experience.
## 0.11.0
+ Support was added for 10.0.0.
+ Exosphere has been updated to reflect the new key import semantics in 10.0.0.
@ -77,6 +80,7 @@
+ In particular, code implementing the os namespace is significantly more accurate.
+ In addition, Nintendo's allocators were implemented, allowing for identical memory efficiency versus Nintendo's implementations.
+ General system stability improvements to enhance the user's experience.
## 0.10.5
+ Changes were made to the way fs.mitm builds images when providing a layeredfs romfs.
+ Building romfs metadata previously had a memory cost of about ~4-5x the file table size.
@ -89,6 +93,7 @@
+ Romfs building can be made even more memory efficient, but unless games show up with even more absurdly huge file tables it seems not worth the speed trade-off.
+ A bug was fixed that caused Atmosphere's fatal error context to not dump TLS for certain processes.
+ General system stability improvements to enhance the user's experience.
## 0.10.4
+ With major thanks to @Adubbz for his work, the NCM system module has now been re-implemented.
+ This was a major stepping stone towards the goal of having implementations everything in the Switch's package1/package2 firmware.
@ -111,6 +116,7 @@
+ Atmosphere's fatal error context now dumps 0x100 of TLS.
+ This will make it much easier to fix bugs when an error report is dumped for whatever caused the crash.
+ General system stability improvements to enhance the user's experience.
## 0.10.3
+ Support was added for 9.2.0.
+ Support was added for redirecting manual html content for games.
@ -125,6 +131,7 @@
+ `ro` has been updated to reflect changes made in 9.1.0.
+ The temporary auto-migration added in 0.10.0 has been removed, since the transitionary period is well over.
+ General system stability improvements to enhance the user's experience.
## 0.10.2
+ hbl configuration was made more flexible.
+ Up to eight specific program ids can now be specified to have their own override keys.
@ -159,6 +166,7 @@
+ For now, users may re-enable this mitm by use of a custom setting (`atmosphere!enable_deprecated_hid_mitm`) to ease the transition process some.
+ Please note: support for this setting may be removed to save memory in a future atmosphere release.
+ General system stability improvements to enhance the user's experience.
## 0.10.1
+ A bug was fixed that caused memory reallocation to the system pool to work improperly on firmware 5.0.0 and above.
+ Atmosphere was always trying to deallocate memory away from the applet pool and towards the system pool.
@ -187,6 +195,7 @@
+ Please ensure your homebrew is updated.
+ Random number generation now uses TinyMT instead of XorShift.
+ General system stability improvements to enhance the user's experience.
## 0.10.0
+ Support was added for 9.1.0
+ **Please note**: The temporary hid-mitm added in Atmosphere 0.9.0 will be removed in Atmosphere 0.10.1.
@ -251,6 +260,7 @@
+ An off-by-one was fixed that could cause memory corruption in server memory management.
+ ... and too many more bugs fixed to reasonably list them all :)
+ General system stability improvements to enhance the user's experience.
## 0.9.4
+ Support was added for 9.0.0.
+ **Please note**: 9.0.0 made a number of changes that may cause some issues with homebrew. Details:
@ -270,6 +280,7 @@
+ Newer hardware uses new, per-firmware device key to generate BIS keys instead of the first device key, so previously the wrong keys were generated as backup.
+ This only affects units manufactured after ~5.0.0.
+ General system stability improvements to enhance the user's experience.
## 0.9.3
+ Thanks to hexkyz, fusee's boot sequence has been greatly optimized.
+ Memory training is now managed by a separate binary (`fusee-mtc`, loaded by fusee-primary before fusee-secondary).
@ -293,6 +304,7 @@
+ Incorrect display output ("2000-0000") has been fixed. Fatal will now correctly show 2162-0002 when this occurs.
+ A longstanding bug in how fatal manages the displays has been fixed, and official display init behavior is now matched precisely.
+ General system stability improvements to enhance the user's experience.
## 0.9.2
+ A number of emummc bugfixes were added (all thanks to @m4xw's hard work). The following is a summary of emummc changes:
+ Support for file-based emummc instances was fixed.
@ -316,10 +328,12 @@
+ The rewritten modules consistently have lower memory footprints, and should be easier to maintain going forwards.
+ The `sm`, `boot`, `spl`, `ro`, and `loader` modules have been tackled so far.
+ General system stability improvements to enhance the user's experience.
## 0.9.1
+ Support was added for 8.1.0.
+ Please note, emummc is still considered **beta/experimental** -- this is not the inevitable bugfix update for it, although some number of bugs have been fixed. :)
+ General system stability improvements to enhance the user's experience.
## 0.9.0
+ Creport output was improved significantly.
+ Thread names are now dumped on crash in addition to 0x100 of TLS from each thread.
@ -344,6 +358,7 @@
+ This can be set to any arbitrary directory by setting `emummc!emummc_nintendo_path`.
+ To create a backup usable for emummc, users may use tools provided by the [hekate](https://github.com/CTCaer/hekate) project.
+ If, when using emummc, you encounter a bug, *please be sure to report it* -- that's the only way we can fix it. :)
## 0.8.10
+ A bug was fixed that could cause incorrect system memory allocation on 5.0.0.
+ 5.0.0 should now correctly have an additional 12 MiB allocated for sysmodules.
@ -360,6 +375,7 @@
+ NAND repair occurs when an unexpected shutdown or error happens during a system update.
+ This fixes a final edge case where AutoRCM might be removed by HOS, which could cause a user to burn fuses.
+ General system stability improvements to enhance the user's experience.
## 0.8.9
+ A number of bugs were fixed, including:
+ A data abort was fixed when mounting certain partitions on NAND.
@ -385,6 +401,7 @@
+ `spl` (Secure Platform Services) is responsible for cryptographic operations, including all communications with the secure monitor (exosphère).
+ In the future, this may be used to provide extensions to the API for interacting with exosphère from userland.
+ General system stability improvements to enhance the user's experience.
## 0.8.8
+ Support was added for firmware version 8.0.0.
+ Custom exception handlers were added to stratosphere modules.
@ -392,6 +409,7 @@
+ A bug was fixed in creport that caused games to hang when crashing under certain circumstances.
+ A bug was fixed that prevented maintenance mode from booting on 7.0.0+.
+ General system stability improvements to enhance the user's experience.
## 0.8.7
+ A few bugs were fixed that could cause fatal to fail to show an error under certain circumstances.
+ A bug was fixed that caused an error when launching certain games (e.g. Hellblade: Senua's Sacrifice).
@ -407,6 +425,7 @@
+ Please note, this feature is **experimental**, and may cause problems. Please use at your own risk (and back up your saves before enabling it), as it still needs testing.
+ This can be enabled by setting `atmosphere!fsmitm_redirect_saves_to_sd` to 1 in `system_settings.ini`.
+ General system stability improvements to enhance the user's experience.
## 0.8.6
+ A number of bugs were fixed, including:
+ A case of inverted logic was fixed in fs.mitm which prevented the flags system from working correctly.
@ -444,6 +463,7 @@
+ fs.mitm will also now cause requests to mount the HtmlDocument content for HBL's title to open the `sdmc:/atmosphere/hbl_html` folder.
+ By default, this just contains a URL whitelist.
+ General system stability improvements to enhance the user's experience.
## 0.8.5
+ Support was added for overriding content on a per-title basis, separate from HBL override.
+ This allows for using mods on the same title that one uses to launch HBL.
@ -465,6 +485,7 @@
+ A bug was fixed that would cause Atmosphère's fatal screen to not show on 1.0.0-2.3.0.
+ A bug was fixed that caused Atmosphère's automatic ProdInfo backups to be corrupt.
+ General system stability improvements to enhance the user's experience.
## 0.8.4
+ Support for 7.0.0/7.0.1 was added.
+ This is facilitated through a new payload, `sept`, which can be signed, encrypted, and then loaded by Nintendo's TSEC firmware.
@ -480,6 +501,7 @@
+ Performing a reboot from the reboot menu now reboots to atmosphere. This can be configured via `system_settings.ini`.
+ Performing a shutdown from the reboot menu now works properly with AutoRCM, and does a real shutdown.
+ General system stability improvements to enhance the user's experience.
## 0.8.3
+ A custom warmboot firmware was implemented, which does not perform anti-downgrade fuse checks.
+ This fixes sleep mode when using a downgraded NAND.
@ -500,6 +522,7 @@
+ Fatal will now use this to reboot to sdmc:/atmosphere/reboot_payload.bin if present, when a vol button is pressed.
+ An example homebrew ("reboot_to_payload") was also written and is now included with Atmosphère.
+ General system stability improvements to enhance the user's experience.
## 0.8.2
+ A number of bugs were fixed causing users to sometimes see `Key Derivation Failed!`.
+ KFUSE clock enable timings have been adjusted to allow time to stabilize before TSEC is granted access.
@ -509,6 +532,7 @@
+ A bug was fixed causing sleep mode to not work with debugmode enabled.
+ As a result, debugmode is now enabled in the default BCT.ini.
+ General system stability improvements to enhance the user's experience.
## 0.8.1
+ A bug was fixed causing users to see `Failed to enable SMMU!` if fusee had previously rebooted.
+ This message will still occur sporadically if fusee is not launched from coldboot, but it can never happen twice in a row.
@ -530,6 +554,7 @@
+ On fatal error, the user can now choose to perform a standard reboot via the power button, or a reboot into RCM via either volume button.
+ A custom message was added to `fatal` for when an Atmosphère API version mismatch is detected (2495-1623).
+ General system stability improvements to enhance the user's experience.
## 0.8.0
+ A custom `fatal` system module was added.
+ This re-implements and extends Nintendo's fatal module, with the following features:
@ -563,6 +588,7 @@
+ By default, new keys will automatically be derived without user input.
+ Support is also present for loading new keys from `atmosphere/prod.keys` or `atmosphere/dev.keys`
+ General system stability improvements to enhance the user's experience.
## 0.7.5
+ DRAM training was added to fusee-secondary, courtesy @hexkyz.
+ This greatly improves the speed of memory accesses during boot, resulting in a boot time that is ~200-400% faster.
@ -571,6 +597,7 @@
+ This matches the improvement Nintendo added to official creport in 6.1.0.
+ The code region detection heuristic was further improved by checking whether an address points to .rodata or .rwdata, instead of just .text.
+ This means that a crash appears in a loaded NRO (or otherwise discontiguous) code region, creport will be able to detect all active code regions, and not just that one.
## 0.7.4
+ [libstratosphere](https://github.com/Atmosphere-NX/libstratosphere) has been completely refactored/rewritten, and split into its own, separate submodule.
+ While this is mostly "under the hood" for end-users, the refactor is faster (improving both boot-time and runtime performance), more accurate (many of the internal IPC structures are now bug-for-bug compatible with Nintendo's implementations), and significantly more stable (it fixes a large number of bugs present in the old library).
@ -591,11 +618,13 @@
+ PM now only gives full FS permissions to the active KIPs. This fixes a potential crash where new processes might be unable to be registered with FS.
+ The `make dist` target now includes the branch in the generated zip name.
+ General system stability improvements to enhance the user's experience.
## 0.7.3
+ Loader and fs.mitm now try to reload loader.ini before reading it. This allows for changing the override button combination/HBL title id at runtime.
+ Added a MitM between set:sys and qlaunch, used to override the system version string displayed in system settings.
+ The displayed system version will now display `<Actual version> (AMS <x>.<y>.<z>)`.
+ General system stability improvements to enhance the user's experience.
## 0.7.2
+ Fixed a bug in fs.mitm's LayeredFS read implementation that caused some games to crash when trying to read files.
+ Fixed a bug affecting 1.0.0 that caused games to crash with fatal error 2001-0106 on boot.

4
docs/components/emummc.md Normal file
View file

@ -0,0 +1,4 @@
# emummc
emummc is a collaborative project that provides eMMC storage emulation.
Please refer to the project's repository [here](https://github.com/m4xw/emuMMC) for detailed instructions and documentation.

82
docs/components/exosphere.md
View file

@ -1,10 +1,76 @@
# Exosphère
Exosphère is a reimplementation of Arm's TrustZone (TZ), also known as Secure Monitor (Secure_Monitor.bin). It has the highest privilege mode available on the Switch’s processor, and has access to everything on the console.
Exosphère will potentially play a big role in Jamais Vu and Déja Vu, which are upcoming software exploits for the Switch, allowing one to launch Atmosphère on a Fusée-Gélee patched (ipatched) Switch console, and will also enable one to launch into CFW directly from the Switch itself without the use of any sort of external device, such as a computer or RCM jig, provided they are on a low enough system firmware.
## TrustZone/Secure Monitor
TrustZone is responsible for all the cryptographic operations on the Switch. The idea behind the way it operates is that all the keys stay in the TrustZone, and userspace only gets "handles" to them. This would make sure that keydata never leaks and is kept secure. It also has a few more responsibilities, such as power management, providing a source of random numbers, and providing access to various pieces of information that are stored in the fuses.
# exosphère
exosphère is a customized reimplementation of the Horizon OS's Secure Monitor.
The Secure Monitor follows the same design principle as Arm's TrustZone and both terms can be used interchangeably in this context. It runs at the highest privilege mode (EL3) available to the main processor and is responsible for all the sensitive cryptographic operations needed by the system as well as power management for each CPU.
## Extensions
Exosphère currently only contains one extension, an SMC allowing homebrew to find which version of Atmosphère is currently running, in order to find out what extensions are allowed to be used.
exosphère expands the original Secure Monitor design by providing custom SMCs (Secure Monitor Calls) necessary to the homebrew ecosystem. Currently, these are:
```
uint32_t smc_ams_iram_copy(smc_args_t *args);
uint32_t smc_ams_write_address(smc_args_t *args);
uint32_t smc_ams_get_emummc_config(smc_args_t *args);
```
Additionally, exosphère expands the functionality of two SMCs provided by the Horizon OS for getting/setting configuration items. The following custom configuration items are provided by exosphère:
```
CONFIGITEM_EXOSPHERE_VERSION = 65000,
CONFIGITEM_NEEDS_REBOOT = 65001,
CONFIGITEM_NEEDS_SHUTDOWN = 65002,
CONFIGITEM_EXOSPHERE_VERHASH = 65003,
CONFIGITEM_HAS_RCM_BUG_PATCH = 65004,
CONFIGITEM_SHOULD_BLANK_PRODINFO = 65005,
CONFIGITEM_ALLOW_CAL_WRITES = 65006,
```
### smc_ams_iram_copy
This function implements a copy of up to one page between DRAM and IRAM. Its arguments are:
```
args->X[1] = DRAM address (translated by kernel), must be 4-byte aligned.
args->X[2] = IRAM address, must be 4-byte aligned.
args->X[3] = Size (must be <= 0x1000 and 4-byte aligned).
args->X[4] = 0 for read, 1 for write.
```
### smc_ams_write_address
This function implements a write to a DRAM page. Its arguments are:
```
args->X[1] = Virtual address, must be size-bytes aligned and readable by EL0.
args->X[2] = Value.
args->X[3] = Size (must be 1, 2, 4, or 8).
```
### smc_ams_get_emummc_config
This function retrieves configuration for the current [emummc](emummc.md) context. Its arguments are:
```
args->X[1] = MMC id, must be size-bytes aligned and readable by EL0.
args->X[2] = Pointer to output (for paths for filebased + nintendo dir), must be at least 0x100 bytes.
```
### CONFIGITEM_EXOSPHERE_VERSION
This custom configuration item gets information about the current exosphere version.
### CONFIGITEM_NEEDS_REBOOT
This custom configuration item is used to issue a system reboot into RCM or into a warmboot payload leveraging a secondary vulnerability to achieve code execution from warm booting.
### CONFIGITEM_NEEDS_SHUTDOWN
This custom configuration item is used to issue a system shutdown with a warmboot payload leveraging a secondary vulnerability to achieve code execution from warm booting.
### CONFIGITEM_EXOSPHERE_VERHASH
This custom configuration item gets information about the current exosphere git commit hash.
### CONFIGITEM_HAS_RCM_BUG_PATCH
This custom configuration item gets whether the unit has the CVE-2018-6242 vulnerability patched.
### CONFIGITEM_SHOULD_BLANK_PRODINFO
This custom configuration item gets whether the unit should simulate a "blanked" PRODINFO. See [here](../features/configurations.md) for more information.
### CONFIGITEM_ALLOW_CAL_WRITES
This custom configuration item gets whether the unit should allow writing to the calibration partition.
## lp0fw
This is a small, built-in payload that is responsible for waking up the system during a warm boot.
## sc7fw
This is a small, built-in payload that is responsible for putting the system to sleep during a warm boot.
## rebootstub
This is a small, built-in payload that provides functionality to reboot the system into any payload of choice.

22
docs/components/fusee.md Normal file
View file

@ -0,0 +1,22 @@
# fusée
fusée is a custom bootloader used to start the Atmosphère environment.
It is divided into three sub-components: fusée-primary, fusée-mtc and fusée-secondary.
fusée is also capable of chainloading other payloads (e.g.: Android).
fusée's behavior can be configured via the [BCT.ini](../features/BCT.md) file located on the SD card.
## fusée-primary
fusée-primary is the first piece of Atmosphère's code that runs on the hardware.
It is distributed as a standalone payload designed to be launched via RCM by abusing the CVE-2018-6242 vulnerability.
This payload is responsible for all the low-level hardware initialization required by the Nintendo Switch, plus the extra task of initializing the SD card and reading the next fusée sub-components from it.
## fusée-mtc
fusée-mtc is an optional, but heavily recommended sub-component that performs DRAM memory training.
This ensures a proper environment for running the final fusée sub-component.
## fusée-secondary
fusée-secondary is the last fusée sub-component that runs on the system.
It is responsible for configuring and bootstrapping the Atmosphère environment by mimicking the Horizon OS's design.
This includes setting up the cryptosystem, mounting or emulating the eMMC, injecting or patching system modules and launching the exosphère component.

73
docs/components/fusee/BCT.md
View file

@ -1,73 +0,0 @@
# BCT.ini
BCT.ini is the configuration file used by fusée-primary and fusée-secondary. It is read by fusee-primary.bin to setup and boot fusee-secondary.bin and is also read by fusee-secondary.bin to configure Exosphère, specify the environment it should boot, or configure other miscellaneous options such as setting a custom boot splashscreen.
## Configuration
This file is located in the `atmosphere` folder on your SD card. The default configuration file will look similar to this.
```
BCT0
[stage1]
stage2_path = atmosphere/fusee-secondary.bin
stage2_addr = 0xF0000000
stage2_entrypoint = 0xF0000000
[exosphere]
; Note: Disabling debugmode will cause parts of ams.tma to not work, in the future.
debugmode = 1
debugmode_user = 0
[stratosphere]
; To force-enable nogc, add nogc = 1
; To force-disable nogc, add nogc = 0
```
## Adding a Custom Boot Splashscreen
Add the following lines to BCT.ini and change the value of `custom_splash` to the actual path and filename of your boot splashscreen.
```
[stage2]
custom_splash = /path/to/your/bootlogo.bmp
```
The boot splashscreen must be a BMP file, it must be 720x1280 (1280x720 rotated 90 degrees left/counterclockwise/anti-clockwise) resolution, and be in 32-bit ARGB format. You can use image editing software such as GIMP or Photoshop to export the image in this format.
## Configuring "nogc" Protection
Nogc is a feature provided by fusée-secondary which disables the Nintendo Switch's Game Card reader. Its purpose is to prevent the reader from being updated when the console has been updated without burning fuses from a firmware lower than 4.0.0, to a newer firmware that is at least 4.0.0 or higher. By default, Atmosphère will protect the Game Card reader automatically, but you are free to change it.
To change its functionality, add the following line to the `stratosphere` section and change the value of `X` according to the following list.
```
nogc = X
```
```
1 = force-enable nogc, so Atmosphère will always disable the Game Card reader.
0 = force-disable nogc, so Atmosphère will always enable the Game Card reader.
```
## Changing Target Firmware
Add the following line to the `exosphere` section and replace the `X` according to the following list if you have trouble booting past the firmware version detection.
`target_firmware` is the OFW major version.
```
target_firmware = X
```
```
1.0.0 = 1
2.X.X = 2
3.X.X = 3
4.X.X = 4
5.X.X = 5
6.X.X = 6
6.2.0 = 7
7.X.X = 8
```
Note that 6.X.X indicates 6.0.0 through 6.1.0.
## Configuring Debugging Modes
By default, Atmosphère signals to the Horizon kernel that debugging is enabled while leaving usermode debugging disabled, since this can cause undesirable side-effects. If you wish to change these behaviours, go to the `exosphere` section and change the value of `X` according to the following list.
```
debugmode = X
debugmode_user = X
```
```
1 = enable
0 = disable
```

20
docs/components/fusee/fusee.md
View file

@ -1,20 +0,0 @@
# Fusée
Fusée (not to be confused with Fusée Gelée) is a custom bootloader needed to start Atmosphère and replaces Nintendo's Package1loader/bootloader. It currently utilizes the [Tegra X1 RCM Vulnerability](https://nvidia.custhelp.com/app/answers/detail/a_id/4660/~/security-notice%3A-nvidia-tegra-rcm-vulnerability) in order to function.
Fusée is split into two separate parts: fusée-primary and fusée-secondary. This is due to the RCM Vulnerability only allowing payloads of a limited filesize to be sent to the device.
As of June 2018, there are new Switch systems being sold that prevent Fusée (or any payload that requires the Fusée Gelée exploit) from working due to having an ipatched bootrom. All ipatched systems share the HAC-S-JXE-C3 product code. While Fusée cannot work on these ipatched units, they still come on firmware 4.1.0, which is vulnerable to the upcoming Déja Vu software exploit. Note that if you update past 4.1.0 on one of these ipatched units, your odds of being able to install Atmosphère or run any homebrew become practically non-existent.
Additionally, a hardware revision of the Switch known as “Mariko” is believed to be in development. No such units have been seen in stores yet, but it is expected Nintendo will roll them out silently. The Mariko units will most likely patch the bootrom vulnerability Fusée Gelée, which is currently used to access CFW, and will likely have their own proprietary bootloader.
## Fusée-Primary
Fusée-primary is the payload file (fusee-primary.bin) sent to the Switch from an external device. Once sent, fusée-primary makes initial preparations before loading fusée-secondary from the Switch’s SD Card.
Fusée-primary can be configured via the [BCT.ini](../fusee/BCT.md) file located on the Switch’s SD card.
## Fusée-Secondary
Fusée-secondary is a payload file that stays on the root of the Switch’s SD Card (fusee-secondary.bin). It is automatically launched once fusée-primary has finished, and is responsible for preparing the Switch’s hardware for future running environments, such as the homebrew menu. Fusée-secondary is also responsible for validating and launching Exosphère.
Fusée-secondary contains various [.kip modules](/docs/main.md#modules). These modules modify existing features in the OS, and can also add new ones.
Fusée is also capable of chainloading other payloads such as Linux.

15
docs/components/fusee/sept.md
View file

@ -1,15 +0,0 @@
# sept
Sept is a payload that facilitates booting Atmosphère when targeting firmware version 7.0.0+.
It consists of a primary and a secondary payload.
## Sept-Primary
Sept-primary is essentially a stand-in for Nintendo's package1ldr, on 7.0.0+. To use it, the caller (normally Fusée-secondary) loads the sept-primary binary to `0x4003F000`,
loads the 7.0.0+ TSEC firmware to `0x40010F00`, and loads a signed, encrypted payload to `0x40016FE0`.
This signed, encrypted payload is normally Sept-secondary.
## Sept-Secondary
Sept-secondary is a payload that performs 7.0.0+ key derivation, and then chainloads to `sept/payload.bin`.
It is normally stored encrypted/signed; if one wishes to build sept-secondary instead of using release builds, one must bring his/her own keys.

11
docs/components/libraries.md Normal file
View file

@ -0,0 +1,11 @@
# libraries
This is a collection of libraries for doing operating system development for the Nintendo Switch.
## libmesosphere
libmesosphere is a work-in-progress C++ library implementing functionality for the Horizon Kernel.
## libstratosphere
libstratosphere is a work-in-progress C++ library for development of system modules for the Nintendo Switch.
## libvapours
Common boilerplate code for various purposes.

3
docs/components/mesosphere.md Normal file
View file

@ -0,0 +1,3 @@
# mesosphère
mesosphère is a work in progress customized kernel reimplementation.
The Horizon OS's kernel follows microkernel design principles and runs at the EL1 level. It is currently subdivided into a loader (kernel_ldr) and the main kernel code.

35
docs/components/modules/ams_mitm.md Normal file
View file

@ -0,0 +1,35 @@
# ams_mitm
This module provides methods to intercept services provided by other system modules. It is further sub-divided according to the service it targets.
## bpc_mitm
bpc_mitm enables intercepting requests to power control services. It currently intercepts:
+ `am` system module (to intercept the Reboot/Power buttons in the overlay menu)
+ `fatal` system module (to simplify payload reboot logic significantly)
+ [nx-hbloader](https://github.com/switchbrew/nx-hbloader) (to allow homebrew to take advantage of the feature)
## fs_mitm
fs_mitm enables intercepting file system operations. It can deny, delay, replace, or redirect any request made to the file system. It enables LayeredFS to function, which allows for replacement of game assets.
## hid_mitm
hid_mitm enables intercepting requests to controller device services. It is currently disabled by default. If enabled, it intercepts:
+ [nx-hbloader](https://github.com/switchbrew/nx-hbloader) (to help homebrew not need to be recompiled due to a breaking change introduced in the past)
Note that hid_mitm is currently deprecated and might be removed entirely in the future.
## ns_mitm
ns_mitm enables intercepting requests to application control services. It currently intercepts:
+ Web Applets (to facilitate nx-hbloader web browser launching)
## set_mitm
set_mitm enables intercepting requests to the system settings service. It currently intercepts:
+ `ns` system module and games (to allow for overriding game locales)
+ All firmware debug settings requests (to allow modification of system settings not directly exposed to the user)
### Firmware Version
set_mitm intercepts the `GetFirmwareVersion` command, if the requester is `qlaunch` or `maintenance`.
It modifies the `display_version` field of the returned system version, causing the version to display
in settings as `#.#.#|AMS #.#.#|?` with `? = S` when running under system eMMC or `? = E` when running under emulated eMMC. This allows users to easily verify what version of Atmosphère and what eMMC environment they are running.
### System Settings
set_mitm intercepts the `GetSettingsItemValueSize` and `GetSettingsItemValue` commands for all requesters.
It does so in order to enable user configuration of system settings, which are parsed from `/atmosphere/system_settings.ini` on boot. See [here](../../features/configurations.md) for more information on the system settings format.

4
docs/components/modules/boot.md Normal file
View file

@ -0,0 +1,4 @@
# boot
This module is a reimplementation of the Horizon OS's `boot` system module, which is responsible for initializing and configuring hardware.
Atmosphère's reimplementation displays its own black and white splash screen and battery icons as replacements for the original assets used during display initialization.

4
docs/components/modules/boot2.md Normal file
View file

@ -0,0 +1,4 @@
# boot2
This module is a reimplementation of the Horizon OS's `boot2` system module, which is responsible for launching all the other necessary system modules.
Atmosphère's reimplementation allows launching user provided system modules from the SD card. See [here](../../features/configurations.md) for more information.

4
docs/components/modules/creport.md Normal file
View file

@ -0,0 +1,4 @@
# creport
This module is a reimplementation of the Horizon OS's `creport` system module, which is responsible for managing crash reports.
Atmosphère's reimplementation redirects writing of generated crash reports to the SD card under the folder `/atmosphere/crash_reports/`. It also prevents the automatic uploading of said crash reports.

42
docs/components/modules/dmnt.md Normal file
View file

@ -0,0 +1,42 @@
# dmnt
This module is a reimplementation of the Horizon OS's `dmnt` system module, which provides a debug monitor.
## Extensions
Atmosphère implements an extension to provide cheat code functionality.
### Cheat Service
A HIPC service API is provided for interacting with the cheat code manager through the service `dmnt:cht`. See [here](../../features/cheats.md) for more information on the cheat code format.
The SwIPC definition for `dmnt:cht` follows:
```
interface ams::dmnt::cheat::CheatService is dmnt:cht {
[65000] HasCheatProcess() -> sf::Out<bool> out;
[65001] GetCheatProcessEvent() -> sf::OutCopyHandle out_event;
[65002] GetCheatProcessMetadata() -> sf::Out<CheatProcessMetadata> out_metadata;
[65003] ForceOpenCheatProcess();
[65004] PauseCheatProcess();
[65005] ResumeCheatProcess();
[65100] GetCheatProcessMappingCount() -> sf::Out<u64> out_count;
[65101] GetCheatProcessMappings(u64 offset) -> sf::OutArray<MemoryInfo> &mappings, sf::Out<u64> out_count;
[65102] ReadCheatProcessMemory(u64 address, u64 out_size) -> sf::OutBuffer &buffer;
[65103] WriteCheatProcessMemory(sf::InBuffer &buffer, u64 address, u64 in_size);
[65104] QueryCheatProcessMemory(u64 address) -> sf::Out<MemoryInfo> mapping;
[65200] GetCheatCount() -> sf::Out<u64> out_count;
[65201] GetCheats(u64 offset) -> sf::OutArray<CheatEntry> &cheats, sf::Out<u64> out_count;
[65202] GetCheatById(u32 cheat_id) -> sf::Out<CheatEntry> cheat;
[65203] ToggleCheat(u32 cheat_id);
[65204] AddCheat(CheatDefinition &cheat, bool enabled) -> sf::Out<u32> out_cheat_id;
[65205] RemoveCheat(u32 cheat_id);
[65206] ReadStaticRegister(u8 which) -> sf::Out<u64> out;
[65207] WriteStaticRegister(u8 which, u64 value);
[65208] ResetStaticRegisters();
[65300] GetFrozenAddressCount() -> sf::Out<u64> out_count;
[65301] GetFrozenAddresses(u64 offset) ->sf::OutArray<FrozenAddressEntry> &addresses, sf::Out<u64> out_count;
[65302] GetFrozenAddress(u64 address) -> sf::Out<FrozenAddressEntry> entry;
[65303] EnableFrozenAddress(u64 address, u64 width) -> sf::Out<u64> out_value;
[65304] DisableFrozenAddress(u64 address);
}
```

4
docs/components/modules/eclct.stub.md Normal file
View file

@ -0,0 +1,4 @@
# eclct.stub
This module is a reimplementation of the Horizon OS's `eclct` system module, which collects error reports.
Atmosphère's reimplementation is a stub to remove any and all functionality pertaining to error report collection.

4
docs/components/modules/erpt.md Normal file
View file

@ -0,0 +1,4 @@
# erpt
This module is a reimplementation of the Horizon OS's `erpt` system module, which is responsible for managing error reports.
Atmosphère's reimplementation redirects writing of generated error reports to the SD card under the folder `/atmosphere/erpt_reports/`.

4
docs/components/modules/fatal.md Normal file
View file

@ -0,0 +1,4 @@
# fatal
This module is a reimplementation of the Horizon OS's `fatal` system module, which is responsible for managing fatal reports.
Atmosphère's reimplementation prevents error report creation and draws a custom error screen, showing registers and a backtrace. It also attempts to gather debugging info for any and all crashes and tries to save reports to the SD card under the folder `/atmosphere/fatal_reports/`.

4
docs/components/modules/jpegdec.md Normal file
View file

@ -0,0 +1,4 @@
# jpegdec
This module is a reimplementation of the Horizon OS's `jpegdec` system module, which is responsible for JPEG format decoding.
Atmosphère's reimplementation allows two sessions instead of 1, so homebrew can use it for software JPEG decoding in addition to the OS itself.

106
docs/components/modules/loader.md Normal file
View file

@ -0,0 +1,106 @@
# loader
This module is a reimplementation of the Horizon OS's `ldr` system module, which is responsible for creating processes from executable NSO images and registering their access control.
## Extensions
Atmosphère extends this module to allow executables to be replaced or patched by files stored on the SD card. Note that a few services are required for SD card access and therefore cannot be replaced or patched in this manner.
### Exefs Replacement
Atmosphère's reimplementation allows replacing executable files in the file system.
#### Partition Replacement
It is possible to replace the full exefs partition at once with a PFS0 file. In that case, Atmosphère will load the following file:
```
/atmosphere/contents/<program id>/exefs.nsp
```
#### File Replacement
When a process is created, loader will search for several NSO filenames in the program's exefs directory.
These filenames are, in this order:
- rtld
- main
- subsdk0
- subsdk1
- ...
- subsdk9
- sdk
Each NSO that is found will be loaded into the process contiguously. The process's entrypoint is at the first NSO to be loaded, usually `rtld` or `main`.
Additionally, when a process is loaded, loader will search for a `main.npdm` file in the exefs directory specifying the program's permissions.
Atmosphère extends this functionality by also searching for these files on the SD card. When searching for a file, loader will first check if it exists on the SD card. If it does, that file will be used instead. Otherwise, it will use the copy located in the exefs, if that is present. The following directory will be searched:
```
/atmosphere/contents/<program id>/exefs/
```
This allows the replacement of applets, system modules, or even games with homebrew versions.
##### File Stubbing
In order to prevent an NSO from being loaded even if it exists in the exefs, loader will also check if a stub file exists. If such a file exists, the NSO will not be loaded. The files should be named like `rtld.stub`, `main.stub`, etc. and may be empty.
##### Technical Semantics
loader's semantics for content override can (as you may observe from reading the above) be complicated to understand. The following is an abbreviated description of the very technical semantics by which loader decides what content to read when trying to read a file for a program id.
* If an external content filesystem exists for the program id, the external content filesystem is used directly with no further redirection.
* Otherwise, if the program ID is being overridden with [nx-hbloader](https://github.com/switchbrew/nx-hbloader/releases) (see Homebrew Support below), the nsp filesystem for hbl is used directly with no further redirection.
* Otherwise, if content redirection is enabled for the program ID (controlled by a configurable button combination) and a loose file exists on the SD card, the loose file is used.
* Otherwise, if a stub file exists, a "Not Found" error is returned.
* Otherwise, if an SD card executable filesystem ("exefs.nsp") exists, it is used without further redirection.
* Finally, the "real"/base code file system is used without further redirection.
In addition, there are a few other technical details relevant to Atmosphere's redirection:
* When overriding with nx-hbloader, the real code filesystem must exist. When "main.npdm" (a program capabilities descriptor file) is read, the content from the real code filesystem is read in order to determine whether an applet or an application is being overridden. This allows nx-hbloader to automatically support both applet and application environments.
* When overriding applications, the real code filesystem must exist and contain valid content. This is required to perform accurate-to-Nintendo content verification procedures.
* When programs are launched, both a program id and a "storage id" are specified by the launch requester. When the storage id specified is "none" (normally always invalid), Atmosphere assumes that a custom system module is attempting to be launched. This removes the aforementioned requirement on base content validity; the above procedure is still used to determine how to redirect content, however reads to the "real"/base code file system may return "Not Found" errors if the real/base code file system does not exist.
### NSO Patching
When an NSO is loaded, Atmosphère's reimplementation will search for IPS patch files on the SD card in the following locations.
```
/atmosphere/exefs_patches/<patchset name>/<nso build id>.ips
```
This organization allows patch sets affecting multiple NSOs to be distributed as a single directory and also allows patches from multiple patch sets to be stacked. Patches will be searched for in each patch set directory. The name of each patch file should match the hexadecimal build ID of the NSO to affect, except that trailing zero bytes may be left off. Because the NSO build ID is unique for every NSO, this means patches will only apply to the files they are meant to apply to.
Patch files are accepted in either IPS format or IPS32 format.
Because NSO files are compressed, patch files are not made between the original version of a compressed NSO and the modified version of such an NSO. Instead, they are made between the uncompressed version of an NSO and the modified (and still uncompressed) version of that NSO. This also means that a patch file cannot be manually applied to the compressed version of an NSO; it must be applied to the uncompressed version. Atmosphère's reimplementation will correctly apply these patches while loading the process regardless of whether the NSO it finds is compressed or not.
When authoring patches, [hactool](https://github.com/SciresM/hactool) can be used to find an NSO's build ID and to uncompress NSOs. Recent versions of the [ReSwitched IDA loaders](https://github.com/reswitched/loaders) can be used to load uncompressed NSOs into IDA in such a way that you can [apply patches to the input file](https://www.hex-rays.com/products/ida/support/idadoc/1618.shtml). From there, any IPS tool can be used to create the patch between the original NSO and the patched NSO. Note that if the NSO you are patching is larger than 16 MiB, you will have to use a tool that supports IPS32.
### Homebrew Support
Atmosphère provides first class support for [nx-hbloader](https://github.com/switchbrew/nx-hbloader/releases) and [nx-hbmenu](https://github.com/switchbrew/nx-hbmenu/releases).
Launching of the nx-hbloader process is controlled by configurable button inputs. See [here](../../features/configurations.md) for more detailed information.
In addition, loader has extensions to enable homebrew to launch web applets. This normally requires the application launching the applet to have HTML Manual content inside an installed NCA. Atmosphère's reimplementation will automatically ensure that the commands used to check this succeed, and will redirect the relevant file system to the `/atmosphere/hbl_html/` subdirectory.
### IPC Commands
Atmosphère's reimplementation extends the HIPC loader services' API with several custom commands.
The SwIPC definition for the `ldr:pm` extension commands follows:
```
interface ams::ldr::pm::ProcessManagerInterface is ldr:pm {
...
[65000] AtmosphereHasLaunchedProgram(ncm::ProgramId program_id) -> sf::Out<bool> out;
[65001] AtmosphereGetProgramInfo(ncm::ProgramLocation &loc) -> sf::Out<ProgramInfo> out_program_info, sf::Out<cfg::OverrideStatus> out_status;
[65002] AtmospherePinProgram(ncm::ProgramLocation &loc, cfg::OverrideStatus &override_status) -> sf::Out<PinId> out_id;
}
```
The SwIPC definition for the `ldr:dmnt` extension commands follows:
```
interface ams::ldr::dmnt::DebugMonitorInterface is ldr:dmnt {
...
[65000] AtmosphereHasLaunchedProgram(ncm::ProgramId program_id) -> sf::Out<bool> out;
}
```
The SwIPC definition for the `ldr:shel` extension commands follows:
```
interface ams::ldr::shell::ShellInterface is ldr:shel {
...
[65000] AtmosphereRegisterExternalCode(ncm::ProgramId program_id) -> sf::OutMoveHandle out;
[65001] AtmosphereUnregisterExternalCode(ncm::ProgramId program_id);
}
```

4
docs/components/modules/ncm.md Normal file
View file

@ -0,0 +1,4 @@
# ncm
This module is a reimplementation of the Horizon OS's `ncm` system module, which is responsible for content management.
Atmosphère's reimplementation is currently opt-in only. See [here](../../features/configurations.md) for more information.

4
docs/components/modules/pgl.md Normal file
View file

@ -0,0 +1,4 @@
# pgl
This module is a reimplementation of the Horizon OS's `pgl` system module, which is responsible for launching programs and was introduced by firmware version `10.0.0`.
Currently, Atmosphère's reimplementation doesn't backport this module's functionalities to firmware versions lower than `10.0.0`.

30
docs/components/modules/pm.md Normal file
View file

@ -0,0 +1,30 @@
# pm
This module is a reimplementation of the Horizon OS's `pm` system module, which is responsible for tracking running processes on the system, and managing resource limits.
## Extensions
Atmosphère extends this module with extra IPC commands and memory restriction changes.
### IPC Commands
Atmosphère's reimplementation extends the HIPC loader services' API with several custom commands.
The SwIPC definition for the `pm:dmnt` extension commands follows:
```
interface ams::pm::dmnt::DebugMonitorServiceBase is pm:dmnt {
...
[65000] AtmosphereGetProcessInfo(os::ProcessId process_id) -> sf::OutCopyHandle out_process_handle, sf::Out<ncm::ProgramLocation> out_loc, sf::Out<cfg::OverrideStatus> out_status;
[65001] AtmosphereGetCurrentLimitInfo(u32 group, u32 resource) -> sf::Out<s64> out_cur_val, sf::Out<s64> out_lim_val;
}
```
The SwIPC definition for the `pm:info` extension commands follows:
```
interface ams::pm::info::InformationService is pm:info {
...
[65000] AtmosphereGetProcessId(ncm::ProgramId program_id) -> sf::Out<os::ProcessId> out;
[65001] AtmosphereHasLaunchedProgram(ncm::ProgramId program_id) -> sf::Out<bool> out;
[65002] AtmosphereGetProcessInfo(os::ProcessId process_id) -> sf::Out<ncm::ProgramLocation> out_loc, sf::Out<cfg::OverrideStatus> out_status;
}
```
### Extra System Memory
Atmosphère's reimplementation shrinks the APPLET memory pool by 24 MiB by default, giving this memory to the SYSTEM pool. This allows custom system modules to use more memory without hitting the SYSTEM memory limit.

16
docs/components/modules/ro.md Normal file
View file

@ -0,0 +1,16 @@
# ro
This module is a reimplementation of the Horizon OS's `ro` system module, which is responsible for loading dynamic libraries and was introduced by firmware version `3.0.0`.
Atmosphère's reimplementation backports this module's functionalities to firmware versions lower than `3.0.0` where said functionalities were provided by the `ldr` system module instead.
## Extensions
Atmosphère extends this module to allow libraries to be patched by files stored on the SD card.
### NRO Patching
When an NRO is loaded, Atmosphère's reimplementation will search for IPS patch files on the SD card in the following locations.
```
/atmosphere/nro_patches/<patchset name>/<nro build id>.ips
```
This organization allows patch sets affecting multiple NROs to be distributed as a single directory. Patches will be searched for in each patch set directory. The name of each patch file should match the hexadecimal build ID of the NRO to affect, except that trailing zero bytes may be left off. Because the NRO build ID is unique for every NRO, this means patches will only apply to the files they are meant to apply to.
Patch files are accepted in either IPS format or IPS32 format.

47
docs/components/modules/sm.md Normal file
View file

@ -0,0 +1,47 @@
# sm
This module is a reimplementation of the Horizon OS's `sm` system module, which is responsible for service management.
## Extensions
Atmosphère extends this module with extra IPC commands and new services.
### Debug Monitor
Atmosphère's reimplementation provides an interface `sm:dmnt` to allow a debug monitor to query the service manager's state.
The SwIPC definition for `sm:dmnt` follows:
```
interface ams::sm::DmntService is sm:dmnt {
[65000] AtmosphereGetRecord(ServiceName service) -> sf::Out<ServiceRecord> record;
[65001] AtmosphereListRecords(u64 offset) -> sf::OutArray<ServiceRecord> &records, sf::Out<u64> out_count;
[65002] AtmosphereGetRecordSize() -> sf::Out<u64> record_size;
}
```
### IPC Commands
Atmosphère's reimplementation extends the HIPC loader services' API with several custom commands.
The SwIPC definition for the `sm:` extension commands follows:
```
interface ams::sm::UserService is sm: {
...
[65000] AtmosphereInstallMitm(ServiceName service) -> sf::OutMoveHandle srv_h, sf::OutMoveHandle qry_h;
[65001] AtmosphereUninstallMitm(ServiceName service);
[65002] Deprecated_AtmosphereAssociatePidTidForMitm();
[65003] AtmosphereAcknowledgeMitmSession(ServiceName service) -> sf::Out<MitmProcessInfo> client_info, sf::OutMoveHandle fwd_h;
[65004] AtmosphereHasMitm(ServiceName service) -> sf::Out<bool> out;
[65005] AtmosphereWaitMitm(ServiceName service);
[65006] AtmosphereDeclareFutureMitm(ServiceName service);
[65100] AtmosphereHasService(ServiceName service) -> sf::Out<bool> out;
[65101] AtmosphereWaitService(ServiceName service);
}
```
The SwIPC definition for the `sm:m` extension commands follows:
```
interface ams::sm::ManagerService is sm:m {
...
[65000] AtmosphereEndInitDefers(os::ProcessId process_id, sf::InBuffer &acid_sac, sf::InBuffer &aci_sac);
[65001] AtmosphereHasMitm(ServiceName service) -> sf::Out<bool> out;
[65002] AtmosphereRegisterProcess(os::ProcessId process_id, ncm::ProgramId program_id, cfg::OverrideStatus override_status, sf::InBuffer &acid_sac, sf::InBuffer &aci_sac);
}
```

2
docs/components/modules/spl.md Normal file
View file

@ -0,0 +1,2 @@
# spl
This module is a reimplementation of the Horizon OS's `spl` system module, which is responsible for providing secure platform services such as cryptographic operations.

14
docs/components/sept.md Normal file
View file

@ -0,0 +1,14 @@
# sept
Sept is a payload that facilitates booting Atmosphère when targeting firmware version 7.0.0+.
It consists of a primary and a secondary payload.
## sept-primary
sept-primary is essentially a stand-in for Nintendo's package1ldr, on 7.0.0+. To use it, the caller (normally fusée-secondary) loads the sept-primary binary to `0x4003F000`, loads the 7.0.0+ TSEC firmware to `0x40010F00`, and loads a signed, encrypted payload to `0x40016FE0`.
This signed, encrypted payload is normally sept-secondary.
## sept-secondary
sept-secondary is a payload that performs 7.0.0+ key derivation, and then chainloads to `sept/payload.bin`.
It is normally stored encrypted/signed. Therefore, if one wishes to build sept-secondary instead of using release builds, one must bring their own keys.

29
docs/components/stratosphere.md
View file

@ -1,10 +1,21 @@
# Stratosphère
Stratosphère allows customization of the Horizon OS and Switch kernel. It includes custom sysmodules that extend the kernel and provide new features. It also includes a reimplementation of the loader sysmodules to hook important system actions.
# stratosphère
stratosphère provides customization of the Horizon OS at the system level. This includes a reimplementation of several system modules and additional, custom system modules that extend or add a variety of features.
The sysmodules that Stratosphère includes are:
+ [boot](../modules/boot.md): This module boots the system and initalizes hardware.
+ [creport](../modules/creport.md): Reimplementation of Nintendo’s crash report system. Dumps all error logs to the SD card instead of saving them to the NAND and sending them to Nintendo.
+ [fs_mitm](../modules/fs_mitm.md): This module can log, deny, delay, replace, and redirect any request made to the File System.
+ [loader](../modules/loader.md): Enables modifying the code of binaries that are not stored inside the kernel.
+ [pm](../modules/pm.md): Reimplementation of Nintendo’s Process Manager.
+ [sm](../modules/sm.md): Reimplementation of Nintendo’s Service Manager.
## Modules
The modules currently provided by stratosphère are:
+ [ams_mitm](modules/ams_mitm.md)
+ [boot](modules/boot.md)
+ [boot2](modules/boot2.md)
+ [creport](modules/creport.md)
+ [dmnt](modules/dmnt.md)
+ [eclct.stub](modules/eclct.stub.md)
+ [erpt](modules/erpt.md)
+ [fatal](modules/fatal.md)
+ [jpegdec](modules/jpegdec.md)
+ [loader](modules/loader.md)
+ [ncm](modules/ncm.md)
+ [pgl](modules/pgl.md)
+ [pm](modules/pm.md)
+ [ro](modules/ro.md)
+ [sm](modules/sm.md)
+ [spl](modules/spl.md)

7
docs/components/thermosphere.md
View file

@ -1,4 +1,3 @@
# Thermosphère
Thermosphère is a hypervisor based implementation of emuNAND.
Thermosphère is currently planned to be included in a future release of Atmosphère.
# thermosphère
thermosphère is a work in progress hypervisor implementation.
This aims to provide functionality at the EL2 level which remains unused by the Horizon OS.

7
docs/components/troposphere.md
View file

@ -1,2 +1,5 @@
# Troposphère
Troposphère contains various application-level modifications to the OS, such as launching homebrew directly from the homemenu or executing cheat/gameshark codes, similar to Luma3DS. Troposphère is not yet implemented in Atmosphère.
# troposphère
troposphère provides customization of the Horizon OS at the application level.
## reboot_to_payload
Sample application to perform a system reboot into a payload of choice.

191
docs/cheats.md → docs/features/cheats.md
View file

@ -6,25 +6,24 @@ By default, Atmosphère will do the following when deciding whether to attach to
+ Retrieve information about the new application process from `pm` and `loader`.
+ Check whether a user-defined key combination is held, and stop if not.
+ This defaults to "L is not held", and can be configured the same way as `fs.mitm` override keys.
+ This defaults to "L is not held", but can be configured with override keys.
+ The ini key to configure this is `cheat_enable_key`.
+ Check whether the process is a real application, and stop if not.
+ This guards against applying cheat codes to the homebrew loader.
+ Attempt to load cheats from `atmosphere/titles/<title_id>/cheats/<build_id>.txt`, where `build_id` is the hexadecimal representation of the first 8 bytes of the application's main executable's build id.
+ This guards against applying cheat codes to the Homebrew Loader.
+ Attempt to load cheats from `/atmosphere/contents/<program_id>/cheats/<build_id>.txt`, where `build_id` is the hexadecimal representation of the first 8 bytes of the application's main executable's build id.
+ If no cheats are found, then the cheat manager will stop.
+ Open a kernel debug session for the new application process.
+ Signal to a system event that a new cheat process has been attached to.
This behavior ensures that cheat codes are only loaded when the user would want them to.
In cases where dmnt has not activated the cheat manager, but the user wants to make it do so anyway, the cheat manager's service API provides a `ForceOpenCheatProcess` command that homebrew can use. This command will cause the cheat manager to try to force itself to attach to the process.
In cases where `dmnt` has not activated the cheat manager, but the user wants to make it do so anyway, the cheat manager's service API provides a `ForceOpenCheatProcess` command that homebrew can use. This command will cause the cheat manager to try to force itself to attach to the process.
By default, all cheat codes listed in the loaded .txt file will be toggled on. This is configurable by the user, and the default can be set to toggled off by editing the `atmosphere!dmnt_cheats_enabled_by_default` entry to 0 instead of 1.
By default, all cheat codes listed in the loaded .txt file will be toggled on. This is configurable by the user by editing the `atmosphere!dmnt_cheats_enabled_by_default` [system setting](configurations.md).
Users may use homebrew programs to toggle cheats on and off at runtime via the cheat manager's service API.
## Cheat Code Compatibility
Atmosphère manages cheat code through the execution of a small, custom virtual machine. Care has been taken to ensure that Atmosphère's cheat code format is fully backwards compatible with the pre-existing cheat code format, though new features have been added and bugs in the pre-existing cheat code applier have been fixed. Here is a short summary of the changes from the pre-existing format:
+ A number of bugs were fixed in the processing of conditional instructions.
@ -37,21 +36,18 @@ Atmosphère manages cheat code through the execution of a small, custom virtual
+ The pre-existing implementation did not correctly synchronize with the application process, and thus would cause heavy lag under certain circumstances (especially around loading screens). This has been fixed in Atmosphère's implementation.
## Cheat Code Format
The following provides documentation of the instruction format for the virtual machine used to manage cheat codes.
Typically, instruction type is encoded in the upper nybble of the first instruction u32.
### Code Type 0: Store Static Value to Memory
Code type 0 allows writing a static value to a memory address.
#### Encoding
`0TMR00AA AAAAAAAA VVVVVVVV (VVVVVVVV)`
+ T: width of memory write (1, 2, 4, or 8 bytes)
+ M: memory region to write to (0 = Main NSO, 1 = Heap)
+ T: Width of memory write (1, 2, 4, or 8 bytes).
+ M: Memory region to write to (0 = Main NSO, 1 = Heap).
+ R: Register to use as an offset from memory region base.
+ A: Immediate offset to use from memory region base.
+ V: Value to write.
@ -59,23 +55,20 @@ Code type 0 allows writing a static value to a memory address.
---
### Code Type 1: Begin Conditional Block
Code type 1 performs a comparison of the contents of memory to a static value.
If the condition is not met, all instructions until the appropriate conditional block terminator are skipped.
#### Encoding
`1TMC00AA AAAAAAAA VVVVVVVV (VVVVVVVV)`
+ T: width of memory write (1, 2, 4, or 8 bytes)
+ M: memory region to write to (0 = Main NSO, 1 = Heap)
+ T: Width of memory write (1, 2, 4, or 8 bytes).
+ M: Memory region to write to (0 = Main NSO, 1 = Heap).
+ C: Condition to use, see below.
+ A: Immediate offset to use from memory region base.
+ V: Value to compare to.
#### Conditions
+ 1: >
+ 2: >=
+ 3: <
@ -86,28 +79,23 @@ If the condition is not met, all instructions until the appropriate conditional
---
### Code Type 2: End Conditional Block
Code type 2 marks the end of a conditional block (started by Code Type 1 or Code Type 8).
#### Encoding
`20000000`
---
### Code Type 3: Start/End Loop
Code type 3 allows for iterating in a loop a fixed number of times.
#### Start Loop Encoding
`300R0000 VVVVVVVV`
+ R: Register to use as loop counter.
+ V: Number of iterations to loop.
#### End Loop Encoding
`310R0000`
+ R: Register to use as loop counter.
@ -115,11 +103,9 @@ Code type 3 allows for iterating in a loop a fixed number of times.
---
### Code Type 4: Load Register with Static Value
Code type 4 allows setting a register to a constant value.
#### Encoding
`400R0000 VVVVVVVV VVVVVVVV`
+ R: Register to use.
@ -128,38 +114,33 @@ Code type 4 allows setting a register to a constant value.
---
### Code Type 5: Load Register with Memory Value
Code type 5 allows loading a value from memory into a register, either using a fixed address or by dereferencing the destination register.
#### Load From Fixed Address Encoding
`5TMR00AA AAAAAAAA`
+ T: width of memory read (1, 2, 4, or 8 bytes)
+ M: memory region to write to (0 = Main NSO, 1 = Heap)
+ T: Width of memory read (1, 2, 4, or 8 bytes).
+ M: Memory region to write to (0 = Main NSO, 1 = Heap).
+ R: Register to load value into.
+ A: Immediate offset to use from memory region base.
#### Load from Register Address Encoding
`5TMR10AA AAAAAAAA`
+ T: width of memory read (1, 2, 4, or 8 bytes)
+ M: memory region to write to (0 = Main NSO, 1 = Heap)
+ T: Width of memory read (1, 2, 4, or 8 bytes).
+ M: Memory region to write to (0 = Main NSO, 1 = Heap).
+ R: Register to load value into.
+ A: Immediate offset to use from register R.
---
### Code Type 6: Store Static Value to Register Memory Address
Code type 6 allows writing a fixed value to a memory address specified by a register.
#### Encoding
`6T0RIor0 VVVVVVVV VVVVVVVV`
+ T: width of memory write (1, 2, 4, or 8 bytes)
+ T: Width of memory write (1, 2, 4, or 8 bytes).
+ R: Register used as base memory address.
+ I: Increment register flag (0 = do not increment R, 1 = increment R by T).
+ o: Offset register enable flag (0 = do not add r to address, 1 = add r to address).
@ -169,22 +150,19 @@ Code type 6 allows writing a fixed value to a memory address specified by a regi
---
### Code Type 7: Legacy Arithmetic
Code type 7 allows performing arithmetic on registers.
However, it has been deprecated by Code type 9, and is only kept for backwards compatibility.
#### Encoding
`7T0RC000 VVVVVVVV`
+ T: width of arithmetic operation (1, 2, 4, or 8 bytes)
+ T: Width of arithmetic operation (1, 2, 4, or 8 bytes).
+ R: Register to apply arithmetic to.
+ C: Arithmetic operation to apply, see below.
+ V: Value to use for arithmetic operation.
#### Arithmetic Types
+ 0: Addition
+ 1: Subtraction
+ 2: Multiplication
@ -194,11 +172,9 @@ However, it has been deprecated by Code type 9, and is only kept for backwards c
---
### Code Type 8: Begin Keypress Conditional Block
Code type 8 enters or skips a conditional block based on whether a key combination is pressed.
#### Encoding
`8kkkkkkk`
+ k: Keypad mask to check against, see below.
@ -206,7 +182,6 @@ Code type 8 enters or skips a conditional block based on whether a key combinati
Note that for multiple button combinations, the bitmasks should be ORd together.
#### Keypad Values
Note: This is the direct output of `hidKeysDown()`.
+ 0000001: A
@ -239,31 +214,27 @@ Note: This is the direct output of `hidKeysDown()`.
---
### Code Type 9: Perform Arithmetic
Code type 9 allows performing arithmetic on registers.
#### Register Arithmetic Encoding
`9TCRS0s0`
+ T: width of arithmetic operation (1, 2, 4, or 8 bytes)
+ T: Width of arithmetic operation (1, 2, 4, or 8 bytes).
+ C: Arithmetic operation to apply, see below.
+ R: Register to store result in.
+ S: Register to use as left-hand operand.
+ s: Register to use as right-hand operand.
#### Immediate Value Arithmetic Encoding
`9TCRS100 VVVVVVVV (VVVVVVVV)`
+ T: width of arithmetic operation (1, 2, 4, or 8 bytes)
+ T: Width of arithmetic operation (1, 2, 4, or 8 bytes).
+ C: Arithmetic operation to apply, see below.
+ R: Register to store result in.
+ S: Register to use as left-hand operand.
+ V: Value to use as right-hand operand.
#### Arithmetic Types
+ 0: Addition
+ 1: Subtraction
+ 2: Multiplication
@ -278,14 +249,12 @@ Code type 9 allows performing arithmetic on registers.
---
### Code Type 10: Store Register to Memory Address
Code type 10 allows writing a register to memory.
#### Encoding
`ATSRIOxa (aaaaaaaa)`
+ T: width of memory write (1, 2, 4, or 8 bytes)
+ T: Width of memory write (1, 2, 4, or 8 bytes).
+ S: Register to write to memory.
+ R: Register to use as base address.
+ I: Increment register flag (0 = do not increment R, 1 = increment R by T).
@ -294,23 +263,21 @@ Code type 10 allows writing a register to memory.
+ a: Value used as offset when O is 2, 4 or 5.
#### Offset Types
+ 0: No Offset
+ 1: Use Offset Register
+ 2: Use Fixed Offset
+ 3: Memory Region + Base Register
+ 4: Memory Region + Relative Address (ignore address register)
+ 5: Memory Region + Relative Address + Offset Register
---
### Code Type 11: Reserved
Code Type 11 is currently reserved for future use.
---
### Code Type 12-15: Extended-Width Instruction
Code Types 12-15 signal to the VM to treat the upper two nybbles of the first dword as instruction type, instead of just the upper nybble.
This reserves an additional 64 opcodes for future use.
@ -318,13 +285,11 @@ This reserves an additional 64 opcodes for future use.
---
### Code Type 0xC0: Begin Register Conditional Block
Code type 0xC0 performs a comparison of the contents of a register and another value. This code support multiple operand types, see below.
If the condition is not met, all instructions until the appropriate conditional block terminator are skipped.
#### Encoding
```
C0TcSX##
C0TcS0Ma aaaaaaaa
@ -335,19 +300,18 @@ C0TcS400 VVVVVVVV (VVVVVVVV)
C0TcS5X0
```
+ T: width of memory write (1, 2, 4, or 8 bytes)
+ T: Width of memory write (1, 2, 4, or 8 bytes).
+ c: Condition to use, see below.
+ S: Source Register
+ S: Source Register.
+ X: Operand Type, see below.
+ M: Memory Type (operand types 0 and 1)
+ R: Address Register (operand types 2 and 3)
+ a: Relative Address (operand types 0 and 2)
+ r: Offset Register (operand types 1 and 3)
+ X: Other Register (used for operand type 5)
+ V: Value to compare to (operand type 4)
+ M: Memory Type (operand types 0 and 1).
+ R: Address Register (operand types 2 and 3).
+ a: Relative Address (operand types 0 and 2).
+ r: Offset Register (operand types 1 and 3).
+ X: Other Register (operand type 5).
+ V: Value to compare to (operand type 4).
#### Operand Type
+ 0: Memory Base + Relative Offset
+ 1: Memory Base + Offset Register
+ 2: Register + Relative Offset
@ -356,10 +320,109 @@ C0TcS5X0
+ 5: Other Register
#### Conditions
+ 1: >
+ 2: >=
+ 3: <
+ 4: <=
+ 5: ==
+ 6: !=
---
### Code Type 0xC1: Save or Restore Register
Code type 0xC1 performs saving or restoring of registers.
#### Encoding
`C10D0Sx0`
+ D: Destination index.
+ S: Source index.
+ x: Operand Type, see below.
#### Operand Type
+ 0: Restore register
+ 1: Save register
+ 2: Clear saved value
+ 3: Clear register
---
### Code Type 0xC2: Save or Restore Register with Mask
Code type 0xC2 performs saving or restoring of multiple registers using a bitmask.
#### Encoding
`C2x0XXXX`
+ x: Operand Type, see below.
+ X: 16-bit bitmask, bit i == save or restore register i.
#### Operand Type
+ 0: Restore register
+ 1: Save register
+ 2: Clear saved value
+ 3: Clear register
---
### Code Type 0xC3: Read or Write Static Register
Code type 0xC3 reads or writes a static register with a given register.
#### Encoding
`C3000XXx`
+ XX: Static register index, 0x00 to 0x7F for reading or 0x80 to 0xFF for writing.
+ x: Register index.
---
### Code Type 0xF0: Double Extended-Width Instruction
Code Type 0xF0 signals to the VM to treat the upper three nybbles of the first dword as instruction type, instead of just the upper nybble.
This reserves an additional 16 opcodes for future use.
---
### Code Type 0xFF0: Pause Process
Code type 0xFF0 pauses the current process.
#### Encoding
`FF0?????`
---
### Code Type 0xFF1: Resume Process
Code type 0xFF1 resumes the current process.
#### Encoding
`FF1?????`
---
### Code Type 0xFFF: Debug Log
Code type 0xFFF writes a debug log to the SD card under the folder `/atmosphere/cheat_vm_logs/`.
#### Encoding
```
FFFTIX##
FFFTI0Ma aaaaaaaa
FFFTI1Mr
FFFTI2Ra aaaaaaaa
FFFTI3Rr
FFFTI4X0
```
+ T: Width of memory write (1, 2, 4, or 8 bytes).
+ I: Log id.
+ X: Operand Type, see below.
+ M: Memory Type (operand types 0 and 1).
+ R: Address Register (operand types 2 and 3).
+ a: Relative Address (operand types 0 and 2).
+ r: Offset Register (operand types 1 and 3).
+ X: Value Register (operand type 4).
#### Operand Type
+ 0: Memory Base + Relative Offset
+ 1: Memory Base + Offset Register
+ 2: Register + Relative Offset
+ 3: Register + Offset Register
+ 4: Register Value

153
docs/features/configurations.md Normal file
View file

@ -0,0 +1,153 @@
# Configurations
Atmosphère provides a variety of customizable configurations to better adjust to users' needs.
## BCT.ini
This is the configuration file used by fusée.
This file is located under the `/atmosphere/config/` folder on your SD card and a default template can be found inside the `/atmosphere/config_templates/` folder.
### Adding a Custom Boot Splashscreen
Atmosphère provides its own default splashscreen which is displayed at boot time. However, this can be replaced at will.
The boot splashscreen must be a BMP file, it must be 720x1280 (1280x720 rotated 90 degrees left/counterclockwise/anti-clockwise) resolution, and be in 32-bit ARGB format. You can use image editing software such as GIMP or Photoshop to export the image in this format.
Add the following lines to BCT.ini and change the value of `custom_splash` to the actual path and filename of your boot splashscreen:
```
[stage2]
custom_splash = /path/to/your/bootlogo.bmp
```
### Configuring "nogc" Protection
"nogc" is a feature provided by fusée-secondary which disables the Nintendo Switch's Game Card reader. Its purpose is to prevent the reader from being updated when the console has been updated, without burning fuses, from a lower firmware version. More specifically, from firmware versions 4.0.0 or 9.0.0 which introduced updates to the Game Card reader's firmware. By default, Atmosphère will protect the Game Card reader automatically, but you are free to change it.
To change its functionality, add the following line to the `stratosphere` section and change the value of `X` according to the following list:
```
[stratosphere]
nogc = X
```
```
1 = force-enable nogc, so Atmosphère will always disable the Game Card reader.
0 = force-disable nogc, so Atmosphère will always enable the Game Card reader.
```
### NCM opt-in
Atmosphère provides a reimplementation of the [ncm](../components/modules/ncm.md) system module, but currently this is not enabled by default. If you wish to enable this reimplementation add the following line to the `stratosphere` section:
```
[stratosphere]
enable_ncm = 1
```
### Logging
This is an advanced feature aimed at developers trying to debug boot time issues. It enables logging of the fusée stages to be displayed on screen.
Add the following lines to BCT.ini and change the value of `X` according to the following list:
```
[config]
log_level = X
```
```
0 = NONE
1 = ERROR
2 = WARNING
3 = MANDATORY
4 = INFO
5 = DEBUG
```
A special level is also provided to prevent prefix creation. To use it, do a bitwise OR with this mask:
`0x100 = NO_PREFIX`
## emummc.ini
This is the configuration file used for the [emummc](../components/emummc.md) component.
This file is located under the `/emuMMC/` folder on your SD card.
Please refer to the project's repository [here](https://github.com/m4xw/emuMMC) for detailed instructions and documentation.
## exosphere.ini
This is the configuration file used by exosphère.
This file is located in the root of your SD card and a default template can be found inside the `/atmosphere/config_templates/` folder.
### Configuring Debugging Modes
By default, Atmosphère signals to the Horizon kernel that debugging is enabled while leaving usermode debugging disabled, but this can cause undesirable side-effects. If you wish to change this behavior, go to the `exosphere` section and change the value of `X` according to the following list.
```
[exosphere]
debugmode = X
debugmode_user = X
```
```
1 = enable
0 = disable
```
### Blanking PRODINFO
Atmosphère provides a way for users to blank their factory installed calibration data (known as PRODINFO) in either emulated or system eMMC environments. You can find more detailed information on this inside the respective template file. Usage of this configuration is not encouraged.
## override_config.ini
This file is located under the `/atmosphere/config/` folder on your SD card and a default template can be found inside the `/atmosphere/config_templates/` folder.
### Overrides Format
Overrides are parsed from the `/atmosphere/config/override_config.ini` file during the boot process.
By default `override_config.ini` is not configured. It can be used to select the behavior of certain buttons and bind them to functionalities such as launching the Homebrew Menu or enabling the cheat code manager.
You can modify the override_key entries in `override_config.ini` with this list of valid buttons:
| Formal Name | .ini Name |
| ----------- | --------- |
| A Button | A |
| B Button | B |
| X Button | X |
| Y Button | Y |
| Left Stick | LS |
| Right Stick | RS |
| L Button | L |
| R Button | R |
| ZL Button | ZL |
| ZR Button | ZR |
| + Button | PLUS |
| - Button | MINUS |
| Left Dpad | DLEFT |
| Up Dpad | DUP |
| Right Dpad | DRIGHT |
| Down Dpad | DDOWN |
| SL Button | SL |
| SR Button | SR |
To invert the behavior of the override key, place an exclamation point in front of whatever button you wish to use. It will launch the actual game while holding down that button, instead of going into the Homebrew Menu. For example, `override_key=!R` will run the game only while holding down R when launching it, otherwise it will boot into the Homebrew Menu. Afterwards you may reinsert your SD card into your Switch and boot into Atmosphère as you normally would. You should now be able to boot into the Homebrew Menu by launching your designated program of choice.
## system_settings.ini
This file is located under the `/atmosphere/config/` folder on your SD card and a default template can be found inside the `/atmosphere/config_templates/` folder.
### Settings Format
Atmosphère provides a way to override the firmware debug settings used by the system. These can be parsed from the `/atmosphere/config/system_settings.ini` file during the boot process. This file is a normal ini file, with some specific interpretations.
The standard representation of a setting's identifier takes the form `name!key`. This is represented within `system_settings.ini` as a section `name`, with an entry `key`. For example:
```
[name]
key = ...
```
Settings can have variable types (strings, integral values, byte arrays, etc). To accommodate this, `system_settings.ini` must store values as a `type_identifier!value_store` pair. A number of different types are supported, with identifiers detailed below.
Please note that a malformed value string will cause a fatal error to occur on boot. A full example of a custom setting is given below (setting `eupld!upload_enabled = 0`), for posterity:
```
[eupld]
upload_enabled = u8!0x0
```
#### Supported Types
* Strings
* Type identifiers: `str`, `string`
* The value string is used directly as the setting, with null terminator appended.
* Integral types
* Type identifiers: `u8`, `u16`, `u32`, `u64`
* The value string is parsed via a call to `strtoul(value, NULL, 0)`.
* Setting bitwidth is determined by the identifier (8 for 1 byte, 16 for 2 bytes, and so on).
* Raw bytes
* Type identifiers: `hex`, `bytes`
* The value string is parsed as a hexadecimal string.
* The value string must be of even length, or a fatal error will be thrown on parse.
## Content Specific Flags
Atmosphère supports customizing CFW behavior based on the presence of `flags` on the SD card.
The following flags are supported on a per-program basis, by placing `<flag_name>.flag` inside `/atmosphere/contents/<program_id>/flags/`:
+ `boot2`, which indicates that the program should be launched during the `boot2` process.
+ `redirect_save`, which indicates that the program wants its savedata to be redirected to the SD card.

12
docs/flags.md
View file

@ -1,12 +0,0 @@
# Flags
Atmosphère supports customizing CFW behavior based on the presence of `flags` on the SD card.
The following flags are supported on a per-title basis, by placing `<flag_name>.flag` inside `/atmosphere/titles/<title_id>/flags/`:
+ `boot2`, which indicates to PM that the title should be launched during the `boot2` process.
+ `fsmitm`, which indicates that `fs.mitm` should override contents for the title even if it otherwise wouldn't.
+ `fsmitm_disable`, which indicates that `fs.mitm` should not override contents for the title, even it it otherwise would.
+ `bis_write`, which indicates that `fs.mitm` should allow the title to write to BIS partitions.
+ `cal_read`, which indicates that `fs.mitm` should allow the title to read the CAL0/PRODINFO partition.
The following global flags are supported, by placing `<flag name>.flag` inside `/atmosphere/flags/`:
+ `hbl_bis_write` and `hbl_cal_read` enable the BIS write and CAL0 read functionality for HBL, without needing to specify its title id.

45
docs/main.md
View file

@ -1,29 +1,30 @@
# Atmosphère
Atmosphère is a work-in-progress customized firmware for the Nintendo Switch. Atmosphère consists of several different components, each in charge of performing different system functions of the Nintendo Switch.
Atmosphère is a work-in-progress customized firmware for the Nintendo Switch. Its design principle consists of a multi-layered approach where each layer replaces/modifies a different component of the Nintendo Switch's system.
The components of Atmosphère are:
+ [Fusée](../docs/components/fusee/fusee.md), a custom bootloader.
+ [Exosphère](../docs/components/exosphere.md), a fully-featured custom secure monitor.
+ [Stratosphère](../docs/components/stratosphere.md), a set of custom system modules.
+ [Thermosphère](../docs/components/thermosphere.md), a hypervisor-based emuNAND implementation. This component has not been implemented yet.
+ [Troposphère](../docs/components/troposphere.md), Application-level patches to the Horizon OS. This component has also not been implemented yet.
## Components
Atmosphère provides six core components, mimicking to some degree the various layers of the Earth's atmosphere:
+ [fusée](components/fusee.md)
+ [exosphère](components/exosphere.md)
+ [thermosphère](components/thermosphere.md)
+ [mesosphère](components/mesosphere.md)
+ [stratosphère](components/stratosphere.md)
+ [troposphère](components/troposphere.md)
### Modules
The Stratosphère component of Atmosphère contains various modules. These have a `.kip` extension. They provide custom features, extend existing features, or replace Nintendo sysmodules.
Additionally, Atmosphère also provides the following secondary components:
+ [emummc](components/emummc.md)
+ [sept](components/sept.md)
+ [libraries](components/libraries.md)
Stratosphère's modules include:
+ [boot](../docs/modules/boot.md)
+ [creport](../docs/modules/creport.md)
+ [fs_mitm](../docs/modules/fs_mitm.md)
+ [loader](../docs/modules/loader.md)
+ [pm](../docs/modules/pm.md)
+ [sm](../docs/modules/sm.md)
## Features
Atmosphère provides several original features which add or expand functionalities for the customized firmware environment:
+ [Cheats](features/cheats.md)
+ [Configurations](features/configurations.md)
### Building Atmosphère
A guide to building Atmosphère can be found [here](../docs/building.md).
## Building Atmosphère
A guide to building Atmosphère can be found [here](building.md).
### Upcoming Features
A list of planned features for Atmosphère can be found [here](../docs/roadmap.md).
## Upcoming Features
A list of planned features for Atmosphère can be found [here](roadmap.md).
### Release History
A changelog of previous versions of Atmosphère can be found [here](../docs/changelog.md).
## Release History
A changelog of previous versions of Atmosphère can be found [here](changelog.md).

2
docs/modules/boot.md
View file

@ -1,2 +0,0 @@
# boot
The boot module is responsible for booting the system and initalizing hardware. A second boot module known as boot2 is integrated with the [pm (process manager)](../modules/pm.md) sysmodule in Atmosphère, and launches other processes.

2
docs/modules/creport.md
View file

@ -1,2 +0,0 @@
# creport
creport is a reimplementation of Nintendo's crash reporter. Atmosphère's creport catches all error logs that would have been saved to the NAND and instead saves them to the SD card for debugging purposes. This is helpful because the errors no longer go to Nintendo and developers of homebrew can still see the errors to help with the debugging process. creport catches system errors, game crashes, and homebrew crashes.

38
docs/modules/dmnt.md
View file

@ -1,38 +0,0 @@
# dmnt
dmnt is a reimplementation of Nintendo's debug monitor. It provides Atmosphère a rich set of debugging functionality, so that users can easily analyze the behaviors of programs. In addition, Atmosphère implements an extension in dmnt to provide cheat code functionality.
## Atmosphère Cheat Extension
In addition to the functionality provided by Nintendo's debug monitor, Atmosphère's dmnt has an extension for providing cheat code functionality. A HIPC Service API is provided for interacting with the cheat code manager, through the service `dmnt:cht`.
Those looking for more information on the cheat code functionality may wish to read `cheats.md`.
The SwIPC definition for `dmnt:cht` follows.
```
interface DmntCheatService is dmnt:cht {
[65000] HasCheatProcess() -> bool;
[65001] GetCheatProcessEvent() -> KObject;
[65002] GetCheatProcessMetadata() -> CheatProcessMetadata;
[65003] ForceOpenCheatProcess();
[65100] GetCheatProcessMappingCount() -> u64;
[65101] GetCheatProcessMappings(u64 offset) -> buffer<MemoryInfo, 6>, u64 count;
[65102] ReadCheatProcessMemory(u64 address, u64 size) -> buffer<u8, 6> data;
[65103] WriteCheatProcessMemory(u64 address, u64 size, buffer<u8, 5> data);
[65104] QueryCheatProcessMemory(u64 address) -> MemoryInfo;
[65200] GetCheatCount() -> u64;
[65201] GetCheats(u64 offset) -> buffer<CheatEntry, 6>, u64 count;
[65202] GetCheatById(u32 cheat_id) -> buffer<CheatEntry, 6> cheat;
[65203] ToggleCheat(u32 cheat_id);
[65204] AddCheat(buffer<CheatDefinition, 5> cheat, bool enabled) -> u32 cheat_id;
[65203] RemoveCheat(u32 cheat_id);
[65300] GetFrozenAddressCount() -> u64;
[65301] GetFrozenAddresses(u64 offset) -> buffer<FrozenAddressEntry, 6>, u64 count;
[65302] GetFrozenAddress(u64 address) -> FrozenAddressEntry;
[65303] EnableFrozenAddress(u64 address, u64 width) -> u64 value;
[65304] DisableFrozenAddress(u64 address);
}
```

2
docs/modules/fs_mitm.md
View file

@ -1,2 +0,0 @@
# fs_mitm
fs_mitm is a sysmodule that enables intercepting file system operations. This module can log, deny, delay, replace, or redirect any request made to the filesystem. It enables LayeredFS to function, which allows for replacement of game assets.

126
docs/modules/loader.md
View file

@ -1,126 +0,0 @@
# loader
loader is a reimplementation of the loader sysmodule. This module is responsible for creating processes from executable NSO images and registering their access control with the kernel, sm, and fs.
## Atmosphère Extensions
Atmosphère extends this module to allow executables to be replaced or patched by files stored on the SD card. Note that a few services are required for SD card access and therefore cannot be replaced or patched in this manner. This includes psc, bus, and pcv.
### Exefs Replacement
TODO: details on buttons affecting this.
When a process is created, loader will search for several NSO filenames in the title's exefs directory.
These filenames are, in this order:
- rtld
- main
- subsdk0
- subsdk1
- ...
- subsdk9
- sdk
Each NSO that is found will be loaded into the process contiguously. The process's entrypoint is at the first NSO to be loaded, usually `rtld` or `main`.
Additionally, when a process is loaded, loader will search for a `main.npdm` file in the exefs directory specifying the title's permissions.
Atmosphère extends this functionality by also searching for these files on the SD card. When searching for a file, loader will first check if it exists on the SD card. If it does, that file will be used instead. Otherwise, it will use the copy located in the exefs, if that is present. The following directory will be searched.
```
sdmc:/atmosphere/titles/<title id>/exefs/
```
This allows the replacement of applets, sysmodules, or even games with homebrew versions.
In order to prevent an NSO from being loaded even if it exists in the exefs, loader will also check if a stub file exists. If such a file exists, the NSO will not be loaded. The files should be named like `rtld.stub`, `main.stub`, etc. and may be empty.
### NSO Patching
TODO: details on buttons affecting this.
When an NSO is loaded, the stratosphere implementatin of loader will search for IPS patch files on the SD card in the following locations.
```
sdmc:/atmosphere/exefs_patches/<patchset name>/<nso build id>.ips
```
This organization allows patchsets affecting multiple NSOs to be distributed as a single directory. Patches will be searched for in each patchset directory. The name of each patch file should match the hexadecimal build ID of the NSO to affect, except that trailing zero bytes may be left off. Because the NSO build ID is unique for every NSO, this means patches will only apply to the files they are meant to apply to.
Patch files are accepted in either IPS format or IPS32 format.
Because NSO files are compressed, patch files are not made between the original version of a compressed NSO and the modified version of such an NSO. Instead, they are made between the uncompressed version of an NSO and the modified (and still uncompressed) version of that NSO. This also means that a patch file cannot be manually applied to the compressed version of an NSO; it must be applied to the uncompressed version. The Stratosphere implementation of loader will correctly apply these patches while loading the process regardless of whether the NSO it finds is compressed or not.
When authoring patches, [hactool](https://github.com/SciresM/hactool) can be used to find an NSO's build ID and to uncompress NSOs. Recent versions of the [ReSwitched IDA loaders](https://github.com/reswitched/loaders) can be used to load uncompressed NSOs into IDA in such a way that you can [apply patches to the input file](https://www.hex-rays.com/products/ida/support/idadoc/1618.shtml). From there, any IPS tool can be used to create the patch between the original NSO and the patched NSO. Note that if the NSO you are patching is larger than 16 MiB, you will have to use a tool that supports IPS32.
### HBL Support
Atmosphère can use the loader module in order to turn any game on your Switch's home menu into a launchpoint for the Homebrew Menu, rather than launching it through the album applet. This allows one to launch the Homebrew Menu with access to the ~3.2GB of RAM that the Switch reserves for games and applications, as opposed to the 442MB of RAM we are limited to when launching the Homebrew Menu from the album. This also means that it is no longer necessary to install homebrew as `.nsp` files on your Switch so long as you are using this method, as the only reason to do so is to allow the homebrew to access all of the Switch's available memory.
In order to setup this method you will need the latest release of [hbmenu](https://github.com/switchbrew/nx-hbmenu/releases), and the latest release of [hbloader](https://github.com/switchbrew/nx-hbloader/releases). Place `hbmenu.nro` on the root of your Switch's SD Card, and place `hbl.nsp` in the atmosphere folder. From there, simply launch any title while holding the button specified in `loader.ini`.
In addition, loader has extensions to enable homebrew to launch web applets. This normally requires the application launching the applet have HTML Manual content inside an installed NCA; Atmosphère's loader will automatically ensure that the commands used to check this succeed, and will (in tandem with `fs.mitm`) redirect the relevant filesystem to the `sdmc:/atmosphere/hbl_html/` subdirectory.
### Button Overrides
By default `loader.ini` is configured to launch the Homebrew Menu when launching any game while holding down the override key (defaults to R). If you wish to change this, you can modify the override_key section of `loader.ini`. Alternatively, if you would like to only allow hbmenu on a specific app, configure `loader.ini` in the atmosphere folder by replacing the Title ID in the ini (title_id in the [hbl_config] section, it is the Title ID for the album by default) with the Title ID of whatever game you wish to use to launch the Homebrew Menu, and set override_any_app to false. A list of Title IDs for Switch Games can be found [here](https://switchbrew.org/wiki/Title_list/Games).
To invert the behaviour of the override key, place an exclamation point in front of whatever button you wish to use. It will launch the actual game while holding down that button, instead of going into the Homebrew Menu. For example, `override_key=!R` will run the game only while holding down R when launching it, otherwise it will boot into the Homebrew Menu. Afterwards you may reinsert your SD Card into your Switch and boot into Atmosphère as you normally would. You should now be able to boot into the Homebrew Menu by launching your designated title of choice.
A list of valid buttons can be found here:
| Formal Name | .ini Name |
| ----------- | --------- |
| A Button | A |
| B Button | B |
| X Button | X |
| Y Button | Y |
| Left Stick | LS |
| Right Stick | RS |
| L Button | L |
| R Button | R |
| ZL Button | ZL |
| ZR Button | ZR |
| + Button | PLUS |
| - Button | MINUS |
| Left Dpad | DLEFT |
| Up Dpad | DUP |
| Right Dpad | DRIGHT |
| Down Dpad | DDOWN |
| SL Button | SL |
| SR Button | SR |
### SM MITM Integration
When the Stratosphere implementation of loader creates a new process, it notifies [sm](sm.md) through the `AtmosphereAssociatePidTidForMitm` command to notify any MITM services of new processes' identities.
### IPC: AtmosphereSetExternalContentSource and AtmosphereClearExternalContentSource
Two additional commands are added to the [`ldr:shel`](https://reswitched.github.io/SwIPC/ifaces.html#nn::ro::detail::ILdrShellInterface) interface, called `AtmosphereSetExternalContentSource` and `AtmosphereClearExternalContentSource`.
Their command IDs are `65000` and `65001` on all system firmware versions.
`AtmosphereSetExternalContentSource` takes a `u64 tid` and returns a server-side session handle.
The client is expected to implement the `IFileSystem` interface on the returned handle. The next
time the title specified by the given title ID is launched, its ExeFS contents will be loaded from
the custom `IFileSystem` instead of from SD card or original ExeFS. NSOs loaded from external
content source may still be subject to exefs IPS patches. After the title is launched successfuly,
the `IFileSystem` is closed and the external content source override is removed. If
`AtmosphereSetExternalContentSource` is called on a title that already has an external content
source set for it, the existing one will be removed and replaced with the new one. It is illegal to
call `AtmosphereSetExternalContentSource` while the title is being launched.
If title launching fails, the external content source remains registered. The
`AtmosphereClearExternalContentSource` command can be used to clear an external content source if
title launch fails.
The `IFileSystem` only needs to implement `OpenFile` and `GetFileTimeStampRaw`. The paths received
by the `IFileSystem`'s `OpenFile` command begin with slashes, as in `/main`, `/rtld`, and `/main.npdm`.
A result code of 0x202 should be returned if the file does not exist. `GetFileTimeStampRaw` can just
be a stub. The `IFile`s returned from `OpenFile` only need to implement `Read` and `GetSize`.
The SwIPC definitions for the extension commands follow.
```
interface nn::ldr::detail::IShellInterface is ldr:shel {
...
[65000] AtmosphereSetExternalContentSource(u64 tid) -> handle<copy, session_server> ifilesystem_handle;
[65001] AtmosphereClearExternalContentSource(u64 tid);
}
```

23
docs/modules/pm.md
View file

@ -1,23 +0,0 @@
# pm
pm is a reimplementation of Nintendo's process manager. This module is responsible for tracking running processes on the system, and managing resource limits. pm is also required to create and manage processes for homebrew applications.
## Atmosphère Extensions
There are a few ways in which the Stratosphere implementation of pm differs intentionally from the stock pm.
### IPC: AtmosphereGetProcessHandle
The Stratosphere implementation of pm adds an additional command to the [`pm:dmnt`](https://reswitched.github.io/SwIPC/ifaces.html#nn::pm::detail::IDebugMonitorInterface) interface, called `AtmosphereGetProcessHandle`. Its command ID is `65000` on all system firmware versions. It takes a `u64 process_id` and returns a process handle for the specified process, if that process is known. Notable exceptions include KIPs, which are not known to pm. If the specified process cannot be found, error code 0x20F is returned.
The SwIPC definition for this command follows.
```
interface nn::pm::detail::IDebugMonitorInterface is pm:dmnt {
...
[65000] AtmosphereGetProcessInfo(u64 pid) -> handle<copy, process> process_handle, u64 title_id, u64 storage_id;
}
```
### Extra System Memory for Sysmodules
The Stratosphere implementation of pm shrinks the APPLET memory pool by 24 MiB by default, giving this memory to the SYSTEM pool. This allows custom sysmodules to use more memory without hitting the SYSTEM memory limit.

79
docs/modules/set_mitm.md
View file

@ -1,79 +0,0 @@
# set_mitm
set_mitm is a sysmodule that enables intercepting requests to the system settings service.
## Atmosphère Extensions
set_mitm intercepts the `GetFirmwareVersion` command, if the requester is `qlaunch` or `maintenance`.\
It modifies the `display_version` field of the returned system version, causing the version to display\
in settings as `#.#.# (AMS #.#.#)`. This allows users to easily verify what version of Atmosphère they are running.
set_mitm also intercepts the `GetSettingsItemValueSize` and `GetSettingsItemValue` commands for all requesters.\
It does so in order to enable user configuration of system settings, which are parsed from `atmosphere/system_settings.ini` on boot.\
The format for settings is described below.
### Atmosphère Settings Format
Settings are parsed from the `atmosphere/system_settings.ini` file during the boot process. This file is a normal ini file,\
with some specific interpretations.
The standard representation of a system setting's identifier takes the form `name!key`. This is represented within\
`system_settings.ini` as a section `name`, with an entry `key`. For example:
```
[name]
key = ...
```
System settings can have variable types (strings, integral values, byte arrays, etc). To accommodate this, `system_settings.ini`\
must store values as a `type_identifier!value_store` pair. A number of different types are supported, with identifiers detailed below.\
Please note that a malformed value string will cause a fatal error to occur on boot. A full example of a custom setting is given below\
(setting `eupld!upload_enabled = 0`), for posterity:
```
[eupld]
upload_enabled = u8!0x0
```
### Supported Types
* Strings
* Type identifiers: `str`, `string`
* The value string is used directly as the setting, with null terminator appended.
* Integral types
* Type identifiers: `u8`, `u16`, `u32`, `u64`
* The value string is parsed via a call to `strtoul(value, NULL, 0)`.
* Setting bitwidth is determined by the identifier (8 for 1 byte, 16 for 2 bytes, and so on).
* Raw bytes
* Type identifiers: `hex`, `bytes`
* The value string is parsed as a hexadecimal string.
* The value string must be of even length, or a fatal error will be thrown on parse.
### Atmosphère Custom Settings
At the time of writing, Atmosphère implements two custom settings, found in the `atmosphere` section.\
While not used for set_mitm, `power_menu_reboot_function` is loaded and controls the reboot behaviour of the console. By default, this value\
is "payload", where the console will automatically reboot into the RCM payload stored in `sdmc:/atmosphere/reboot_payload.bin`.\
(This payload is also used for fatal, upon a serious crash.) Setting the value to "rcm" reboots directly into RCM, and setting the value\
to "normal" skips these behaviours.
```
[atmosphere]
power_menu_reboot_function = str!payload
```
`dmnt_cheats_enabled_by_default` controls the behaviour of dmnt's cheat functionality. By default, this value is "0x1", enabling any cheats\
defined by the user. Check [cheats](../cheats.md) for more information about Atmosphère's cheat functionality.
```
[atmosphere]
dmnt_cheats_enabled_by_default = u8!0x1
```
`dmnt_always_save_cheat_toggles` controls the behaviour of dmnt's cheat toggle functionality. By default, this value is "0x0", causing toggles to\
only be saved on game quit if a toggle file existed on game boot. Check [cheats](../cheats.md) for more information about Atmosphère's cheat functionality.
```
[atmosphere]
dmnt_always_save_cheat_toggles = u8!0x0
```

125
docs/modules/sm.md
View file

@ -1,125 +0,0 @@
# sm
sm is a reimplementation of Nintendo's service manager. It allows Atmosphère to add or remove process handle limits, add new services, or intercept service calls. This allows high-level intercepting of Horizon OS functionality.
## Atmosphère Extensions
There are a few ways in which the Stratosphere implementation of sm differs intentionally from the stock sm.
### IPC: MITM Commands
The Stratosphere implementation of sm adds a few additional commands to the [`sm:`](https://reswitched.github.io/SwIPC/ifaces.html#nn::sm::detail::IUserInterface) port session.
Their SwIPC definitions follow.
```
interface nn::sm::detail::IUserInterface is sm: {
...
[65000] AtmosphereInstallMitm(ServiceName service) -> handle<port, move> service, handle<server_session, move> query;
[65001] AtmosphereUninstallMitm(ServiceName service);
[65002] AtmosphereAssociatePidTidForMitm(u64 pid, u64 tid);
}
```
Additionally, an interface `sm:dmnt` has been created to allow a debug monitor to query sm's state.
Its SwIPC definition follows.
```
interface nn::sm::detail::IDebugMonitorInterface is sm:dmnt {
[65000] AtmosphereGetServiceRecord(ServiceName name) -> SmServiceRecord;
[65001] AtmosphereListServiceRecords(u64 offset) -> buffer<SmServiceRecord, 6>, u64 count;
[65002] AtmosphereGetServiceRecordSize() -> u64 record_size;
}
```
#### AtmosphereInstallMitm
This command alters the registration for the named service, in order to allow services to intercept communication between client processes and their intended services. It is used by [fs_mitm](fs_mitm.md).
It takes the name of the service to install an MITM for, and returns two handles. The first is a port handle, similar to those returned from the [RegisterService](https://reswitched.github.io/SwIPC/ifaces.html#nn::sm::detail::IUserInterface(2)) command. The second is the server side of a session, called the query session. This session will used by sm to determine whether or not a new session should be intercepted, and to inform the MITM service of the identity of new processes.
The query session is expected to implement the following interface.
```
interface MitmQueryService {
[65000] ShouldMitm(u64 pid) -> u64 should_mitm;
[65001] AssociatePidTid(u64 pid, u64 tid);
}
```
The `ShouldMitm` command is invoked whenever a process attempts to make a new connection to the MITM'd service. It should return `0` if the process's connection should not be intercepted. Any other value will cause the process's connection to be intercepted. If the command returns an error code, the process's connection will not be intercepted.
The `AssociatePidTid` command is invoked on all MITM query sessions whenever a new process is created, in order to inform those services of the identity of a newly created process before it attempts to connect to any services.
If the process that installed the MITM attempts to connect to the service, it will always connect to the original service.
This command requires that the session be initialized, returning error code 0x415 if it is not.\
If the given service name is invalid, error code 0xC15 is returned.\
If the user does not have service registration permission for the named service, error code 0x1015 is returned.\
If the service already has an MITM installed, error code 0x815 is returned.\
If the service has not yet been registered, the request will be deferred until the service is registered in the same manner as IUserInterface::GetService.
#### AtmosphereUninstallMitm
Removes any installed MITM for the named service.
This command requires that the session be initialized, returning error code 0x415 if it is not.
#### AtmosphereAssociatePidTidForMitm
This command is used internally by the Stratosphere implementation of the [loader](loader.md) sysmodule, when a new process is created. It will call the `AssociatePidTid` command on every registered MITM query session.
If the given process ID refers to a kernel internal process, error code 0x1015 is returned. This command requires that the session be initialized, returning error code 0x415 if it is not.
#### AtmosphereGetServiceRecordSize
Retrieves `sizeof(SmServiceRecord)` for a service. The current format of `SmServiceRecord` structure follows.
```
struct SmServiceRecord {
uint64_t service_name;
uint64_t owner_pid;
uint64_t max_sessions;
uint64_t mitm_pid;
uint64_t mitm_waiting_ack_pid;
bool is_light;
bool mitm_waiting_ack;
};
```
#### AtmosphereGetServiceRecord
Retrieves a service registration record for a service.
#### AtmosphereListServiceRecords
Provides a list of service registrations records.
The command will return an array of `SmServiceRecord`s, skipping `offset` records. The number of records returned is indicated by `count`.
If `count` is less than the size of the buffer divided by `sizeof(SmServiceRecord)` (the buffer was not completely filled), the end of the service registration list has been reached. Otherwise, client code
should increment `offset` by `count` and call again. Client code should retrieve a record size using `AtmosphereGetServiceRecordSize`, and either make sure that the size of a record matches what it expects,
or should make sure to use the correct size as the stride while iterating over the array of returned records. Example pseudocode is shown below.
```
offset = 0;
record_size = AtmosphereGetServiceRecordSize();
do {
SmServiceRecord records[16];
count = AtmosphereListServiceRecords(offset, buffer(records));
for (i = 0; i < count; i++) {
SmServiceRecord record = {0};
memcpy(&record, &records[i], min(record_size, sizeof(SmServiceRecord));
/* process record */
offset++;
}
} while(count == sizeof(records) / record_size);
```
### Minimum Session Limit
When a service is registered, the sysmodule registering it must specify a limit on the number of sessions that are allowed to be active for that service at a time. This is used to ensure that services like `fs-pr`, `fs-ldr`, and `ldr:pm` can only be connected to once, adding an additional layer of safety over the regular service verification to ensure that those services are only connected to by the highly priveleged process they are intended to be used by.
By default, the Stratosphere implementation of PM will raise any session limits to at least 8, meaning that for services like `fs-pr` and those mentioned above, up to 8 processes will be able to connect to those sessions, leaving 7 sessions for homebrew to use.
### Weak Service Verification
In system firmware versions before 3.0.1, if a process did not call the [Initialize](https://reswitched.github.io/SwIPC/ifaces.html#nn::sm::detail::IUserInterface(0)) command on its `sm:` session, normally used to inform sm of the process's identity, sm would assume that the process was a kernel internal process and skip any service registration or access checks. The Stratosphere implementation of sm does not implement this vulnerability, and initialization is required on all firmware versions.

63
docs/roadmap.md
View file

@ -1,16 +1,49 @@
# Planned Features
The following features are planned to be added in future versions of Atmosphère:
+ Thermosphère, a hypervisor-based emunand implementation.
+ A feature-rich debugging toolset (a component of Stratosphère).
+ A custom debug monitor system module, providing an API for debugging Switch's processes. This may not be a reimplementation of Nintendo's own debug monitor.
+ This should include a gdbstub implementation, possibly borrowing from Luma3DS's.
+ This API should be additionally usable for RAM Editing/"Cheat Engine" purposes.
+ A custom shell system module, providing an means for users to perform various RPC (with support for common/interesting functionality) on their Switch remotely. This may not be a reimplementation of Nintendo's own shell.
+ This should support client connections over both Wi-Fi and USB.
+ A custom logging system module, providing a means for other Atmosphère components (and possibly Nintendo's own system modules) to log debug output.
+ This should support logging to the SD card, over Wi-Fi, and over USB.
+ An application-level plugin system.
+ This will, ideally, work somewhat like NTR-CFW's plugin system on the 3DS, allowing users to run their own code in a game's process in their own thread.
+ An AR Code/Gameshark analog implementation, allowing for easy sharing/development of cheat codes to run on device.
+ Further extensions to existing Atmosphère components.
+ General system stability improvements to enhance the user's experience.
atmosphère has a number of features that are either works-in-progress or planned. Please note that while time-estimates are given, they are loose, and things may be completed sooner or later than advertised.
The following descriptions were last updated in late April of 2020.
## system updater api
* **Description**: A planned extension api for stratosphere (tenatively `ams:su`), this will provide an interface for homebrew to safely install system upgrades or downgrades. This will allow for much more easily transitioning safely between different versions of the operating system.
* **Development Status**: Under active development by SciresM
* **Estimated Time**: May 2020
## settings reimplementation
* **Description**: A planned reimplementation of the settings system module, and with it a removal of the settings mitm. This will greatly simplify atmosphère's boot process, and will allow much more flexible control over the various system settings.
* **Development Status**: Undergoing research/initial development by Adubbz.
* **Estimated Time**: Mid 2020
## mesosphere
* **Description**: mesosphère is a reimplementation of the Horizon operating system's Kernel. It aims to provide an open-source reference for Nintendo's code.
* **Development Status**: Under semi-active development by SciresM; temporarily on pause while the System Updater API is completed.
* **Estimated Time**: Mid-to-Late 2020
## exosphere re-write
* **Description**: exosphère, atmosphère's reimplementation of Horizon's Secure Monitor, was the first component authored for the project in early 2018. It is written in C, and in a style very different from the rest of atmosphère's code. In addition, exosphère was written to conform to constraints that no longer apply in an environment where it is not launched from the web browser, and where using a custom firmware image to orchestrate wake-from-sleep is possible. exosphère currently uses all but 1 KB of the space available to it, putting it at risk of breaking as future firmware updates are supported. A re-write will solve these issues.
* **Development Status**: Planned.
* **Estimated Time**: 2020-2021.
## tma reimplementation
* **Description** tma ("target manager agent") is a system module that manages communication between the Switch and a client PC. Atmosphere's implementation will allow homebrew on the switch to communicate with a connected PC to do various operations such as exchanging data or interacting with files. It will also serve as the communicator for Atmosphère's planned debugger. This will also include PC-side software for interacting with the Switch.
* **Development Status**: Planned. Switch-side code is fully implemented but needs heavy refactoring/rebasing, as the code was originally authored in 2018.
* **Estimated Time**: Late 2020-2021.
## dmnt.gen2 reimplementation
* **Description**: A reimplementation of the Switch's debug monitor, dmnt will provide an interface for debugging applications or system modules running on the Switch. This will include a gdbstub for debugging actively-running system components or applications.
* **Development Status**: Planned
* **Estimated Time**: 2021
## fs reimplementation
* **Description**: Following mesosphère's completion, atmosphère will have reimplemented all components of the BootImagePackage firmware except for the filesystem services system module. Reimplementing fs will allow for fixing Nintendo bugs (such as corruption when using exFAT filesystems and encoding inconsistencies with UTF-8 and Shift-JIS).
* **Development Status**: Planned.
* **Estimated Time**: 2021-2022.
## thermosphère
* **Description**: A general-purpose hypervisor, thermosphère will enable the virtualization of the Switch's operating system; this is planned to enable debugging of the Switch's kernel.
* **Development Status**: Under semi-active development by TuxSH.
* **Estimated Time**: 2020-2021.
## other planned features
* **Description**: General system stability improvements to enhance the user's experience.
* **Development Status**: Undergoing active development by all members of the atmosphère team.
* **Estimated Time**: June 15th.