# hekate and Nyx: a graphical bootloader for hacked Nintendo Switch consoles > The most complete homebrew bootloader for the Nintendo Switch, written in C, with a touchscreen GUI, an ini-driven boot configuration, partition and emuMMC tooling, and a release train that follows every firmware update. **CTCaer/hekate** — hekate - A GUI based Nintendo Switch Bootloader - Repository: https://github.com/CTCaer/hekate - Stars: 8,763 · Forks: 683 - Language: C - License: GPL-2.0 - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/ctcaer-hekate ## What the bootloader actually does at boot time hekate is a custom bootloader for the Nintendo Switch, and Nyx is its graphical environment: a launcher with a touchscreen, Joycon input, launcher-style icons, and background and colour themes. The README describes the whole package as bootloader, firmware patcher, tools and more, which undersells the scope. The feature list covers booting custom firmware sysmodules and emulated, official firmware and stock, plus Android and Linux payloads, which is the part that makes it more than a bootloader. The operational pieces matter as much as the boot entry. There is a payload launcher, eMMC and emuMMC backup and restore tools, an SD card partition manager that prepares an SD card for any combination of Switch, Android and Linux, an emuMMC creation and migration manager, a flasher for Switch Android and Linux, USB mass storage that turns the console into an SD or eMMC reader, and a USB gamepad mode that exposes the Joycons as a HID controller. There is also a hardware and peripherals info screen covering SoC, fuses, RAM, display, touch, eMMC, SD, battery, PSU and charger. Underneath, it is C built against devkitARM with NVIDIA's Tegra boot chain in mind. The `Makefile` refuses to run without `DEVKITARM` set, and its object list gives you a decent map of the source: hardware drivers for `bpmp`, `sdram`, `minerva`, `fuse`, `kfuse`, `sdmmc`, `emmc` and `bq24193`, OS loaders for `l4t`, `hos`, `pkg1`, `pkg2`, `pkg3` and `secmon_exo`, and libraries for `lz4`, `blz`, FatFs and `elfload`. ```text TARGET := hekate BUILDDIR := build OUTPUTDIR := output SOURCEDIR = bootloader ``` That build shape is worth understanding because it explains the folder layout in the README. Source lives under `bootloader/`, the Tegra components under `bdk/`, and the GUI under `nyx/`. ## The bootloader folder and the files that must not go missing The README documents the on-SD layout as a table, which is unusual and useful. The `bootloader/` directory is the main folder, and inside it `hekate_ipl.ini` holds the main configuration and the boot entries that appear in the Launch menu, while `nyx.ini` configures the GUI. `patches.ini` is where you add external patches and can be skipped, with a template at `./res/patches_template.ini`. Some entries are load-bearing and the README says so with an emphasis marker on `bootloader/sys/`. That folder holds hekate and Nyx system modules: `emummc.kipm` for emulated eMMC, `libsys_lp0.bso` for sleep mode, `libsys_minerva.bso` for DRAM frequency training, `nyx.bin` for the GUI itself, `res.pak` for its resource bundle, and `thk.bin`, the Atmosphere Tsec Hovi keygen. The same folder has an `l4t/` subdirectory for firmware relevant to L4T, which is the Android and Linux side. Alongside those, `bootlogo.bmp` is your startup logo, used when no `logopath` key is configured and safe to skip, `bootloader/res/` holds Nyx resources such as `background.bmp` and the default `icon_switch.bmp` and `icon_payload.bmp`, `bootloader/screenshots/` receives Nyx screenshots, and `bootloader/libtools/` is listed as reserved. `update.bin` is the other one to understand: if a newer version exists it gets loaded at boot, and it is normally there for modchips, auto updated and created at first boot. The `bootloader/payloads/` folder feeds the Payloads menu, and the README is precise that all CFW bootloaders, tools and Linux payloads are supported there, but autoboot only works for payloads included in an ini. `bootloader/ini/` holds individual configs for the More configs menu, again with autoboot support, and the files are ASCII ordered, which matters because the autoboot list can be read from that folder. ## Configuring hekate through the config section of hekate_ipl.ini Global configuration lives in the special `[config]` section of `hekate_ipl.ini`, and every other section in the file is a boot entry that has to be edited by hand. Nyx exposes the same settings under Options, so the GUI is an editor for that one section rather than for the whole file. The keys are documented as a table, and a few are worth explaining in plain terms. `autoboot=0` disables autoboot or takes an entry number to boot automatically. `autoboot_list=0` chooses whether the autoboot entry is read from `hekate_ipl.ini` or from the ini folder. `bootwait=3` sets the seconds you have to hold a volume button to reach the menu, capped at 20, and setting it to 0 also disables the bootlogo. `autohosoff=1` covers waking from an RTC alarm, showing the logo and powering off, with a value of 2 for no logo and an immediate power off. Three of the keys are hardware-fuse aware. `autonogc=1` automatically applies the nogc patch if unburnt fuses are found and a HOS of 4.0.0 or later is booted. `updater2p=0` forces an update of the reboot2payload binary to hekate when needed, which matters for RCM-based boot flows. And `bootprotect=1` protects the bootloader folder by disallowing reading or editing it from HOS, which is the setting you want if the console can run anything that a user might run. Two more are cosmetic but explain the startup screen: `backlight=100` sets the screen backlight level on a 0 to 255 scale, and `noticker=0` draws an animated line during a custom bootlogo showing the time left before the menu, with 1 disabling it. ```ini autoboot=0 bootwait=3 autohosoff=1 autonogc=1 backlight=100 ``` Those five lines are the whole global configuration for most people. There is also a template at `./res/hekate_ipl_template.ini` if you would rather start from a complete file than a blank one. ## Boot entries as key and value combinations A boot entry is a sequence of replacements rather than a single binary path, and the README's table for entries is a component-by-component list. `warmboot={FILE path}` replaces the warmboot binary, `secmon={FILE path}` replaces the security monitor, `kernel={FILE path}` replaces the kernel, and `kip1={FILE path}` replaces or adds a kernel initial process, with several allowed. A folder form, `kip1={FOLDER path}/*`, loads every .kip and .kip1 inside a directory. That granular model is the design decision that keeps hekate useful as firmware moves. When a new HOS version changes pkg2 or pkg3, the fix is usually a new set of keys in a boot entry rather than a new bootloader, and entries live in plain text that you can read, diff and comment. The README also uses a small notation for the file itself: square brackets are boot entries, curly braces are captions, a hash is a comment, and a bare newline is a cosmetic blank line in the ini. A separate table covers boot entry combinations for Exosphere specifically, since the security monitor path differs depending on which CFW you are booting. If you use a different CFW, that is the part of the documentation to read most carefully. Payload storage is documented as its own section, and it is straightforward: payloads go in `bootloader/payloads/` and appear in the Payloads menu. The catch, as noted above, is autoboot, which only applies to payloads referenced from an ini, not to files dropped in the folder. ## Release cadence driven by Nintendo firmware versions hekate's release notes read like a changelog for the console rather than for the tool, because that is what determines whether a release matters. The v6.5.3 release, published on 2026-06-16 alongside Nyx v1.9.3, headlines HOS 22.5.0 support and the line about no more SD card removals, which refers to his newer approach to running the bootloader without unmounting the card first. The emuMMC layer in the same release lists matching HOS 22.5.0 support and restates that it is based on m4xw's emuMMC, which is the dependency to keep an eye on. The Nyx half of those notes is the most detailed part. v1.9.3 improved SD card information with SD Express detection, better SD DDR200 detection that is still marked experimental, and vendor plus reserved bit registers. It also added warnings for wrong PMIC versions, with a request to contact the author if another revision ships officially, fixed wafer limits again, and fixed a GPT validation issue that made the partition manager appear to hang. The previous release, v6.5.2 with Nyx v1.9.2 on 2026-03-19, added HOS 22.0.0 and 22.1.0 support and HOS Auto Memory Size, where `memmode=1` lifts a memory limit so 8GB configurations can use 8GB inside HOS instead of 4GB, with a dependency on an updated Exosphere or Atmosphere. The release carries an explicit disclaimer that booting HOS 22.0.0 through hekate required waiting for updated Atmosphere. That caveat is the clearest statement of the project's real dependency graph. The BDK changes in v6.5.3 include a breaking rename, `sdmmc_storage_execute_vendor_cmd` to `sdmmc_storage_vendor_cmd`, plus added SDMMC commands and vendor info functions. For anyone tracking the tree closely, that rename is the kind of change to catch before a build breaks. The repository's last push was on 2026-06-16, the same date as the v6.5.3 tag. ## Scale, licensing and what the README leaves out Some context that the README does not spell out. hekate has around 8,700 stars and 680 forks, it is licensed GPL-2.0, it is written in C, and it carries 32 open issues at the moment. The topic tags are bootloader, hekate, nintendo-switch-bootloader, nyx, tools and uefi, which is a fair summary of what it is. The README is unusually complete for a homebrew project: full folder and file tables, every global configuration key, boot entry tables for both CFW paths, payload storage, and a Nyx configuration section for `nyx.ini`. There is also a separate `README_BOOTLOGO.md` in the tree, so custom bootlogo work is documented on its own rather than squeezed into the main file. Build prerequisites are stated plainly, which is rarer: `DEVKITARM` must be exported or the Makefile stops with an explicit error. What the README does not do is explain the modding side: how to get into RCM in the first place, which fuses matter for a given console revision, or how to pair hekate with a specific CFW build. Those live in the Atmosphere, Exosphere and Sigpatches documentation, and the release notes name them as the required counterparts. Nor does the README cover Android or Linux payload configuration beyond saying `l4t/` exists, which is fair since those payloads are separate projects. The practical read is that hekate is the stable, well-documented centre of a wider ecosystem rather than a standalone tool. Its own repository is in good shape; the volatility is upstream, in firmware releases and in the CFW projects that must be updated to match them. ## Conclusion hekate is the piece of the Switch homebrew stack that other tools assume exists. Almost every other bootloader or payload workflow ends with an entry in `hekate_ipl.ini`, and Nyx is the reason people stay inside it instead of editing text on a computer. What the repository is unusually honest about is the moving target: support for a given HOS version depends on Atmosphere and Exosphere catching up, and the emuMMC layer tracks m4xw's emuMMC upstream, so a new firmware can leave you waiting on other people's releases. The configuration reference in the README is complete enough to write a full `hekate_ipl.ini` from scratch. Start there, use the Nyx Options menu for the global keys, and check which firmware version the current hekate release supports before assuming a boot entry will work. ## FAQ ### What is hekate and Nyx on the Nintendo Switch? hekate is a custom bootloader for the Nintendo Switch and Nyx is its graphical interface. The pair boots custom firmware, official firmware and stock, launches payloads for Linux and Android, and provides partition, emuMMC backup and hardware inspection tools through a touchscreen menu. ### How do I configure hekate through hekate_ipl.ini? Global settings go in the `[config]` section of `bootloader/hekate_ipl.ini`, which is also editable from Nyx under Options. Keys include `autoboot`, `bootwait`, `autohosoff`, `autonogc`, `updater2p`, `backlight`, `noticker` and `bootprotect`. Every other section in the file is a boot entry and has to be edited manually. A template lives at `./res/hekate_ipl_template.ini`. ### Why does hekate not boot the latest Switch firmware? Because the bootloader, the CFW and the firmware version move together. Release notes pair each hekate build with a supported HOS version, and some combinations need a matching Atmosphere or Exosphere update, as the v6.5.2 notes say for HOS 22.0.0. The emuMMC layer also follows m4xw's emuMMC upstream, so a new firmware can leave parts of the stack waiting. ### What does the bootloader/sys folder need to contain? The README marks it as important. It holds `emummc.kipm` for emulated eMMC, `libsys_lp0.bso` for sleep mode, `libsys_minerva.bso` for DRAM frequency training, `nyx.bin` for the GUI, `res.pak` for Nyx resources and `thk.bin`, the Atmosphere Tsec Hovi keygen, plus an `l4t/` subdirectory for the Linux and Android side. ## Sources - [CTCaer/hekate on GitHub](https://github.com/CTCaer/hekate) - [Issues](https://github.com/CTCaer/hekate/issues) - [License: GPL-2.0](https://github.com/CTCaer/hekate/blob/master/LICENSE) - [README](https://github.com/CTCaer/hekate/blob/master/README.md) - [Releases](https://github.com/CTCaer/hekate/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ctcaer-hekate