Home Menu

The Home Menu is the heart of the Nintendo 3DS. From there one can start games, applications, and access various processes including the friends list. It is launched by NS, and is always running in the background in 3DS-mode except when other programID-high 00040030 applications like Internet Browser, Friend-List, etc are running. Home Menu is still running while System Settings is running, however the System Settings application does not allow directly returning to home-menu. The system will normally re-launch Home Menu when the Home Menu process crashes/terminates. When this re-launch occurs while Home Menu is active, Home Menu displays an error message which says to manually reboot the system.

Nintendo devised a system, whereby updates would be delivered via two channels:

• Card Updates (CUP) - The Nintendo 3DS is updated with data from an update partition on retail gamecard title.
• Network Updates (NUP) - The Nintendo 3DS is updated by downloading data from Nintendo’s CDN.

CUPs will only deliver updates to core features, such as the Home Menu, Download Play etc. CUPs will not deliver updates to Network features, such as System Transfer, Internet Browser, StreetPass Mii Plaza or eShop.

NUPs can deliver updates to core features as well as (updated) Network Features.

As a result of deciding to make a distinction between what content could be updated and how, Nintendo split the system version displayed by System Settings into two parts: CVer (Console Version) and NVer (Network Update Version). Represented as:

<CVer Major>.<CVer Minor>.<CVer Micro>-<NUP Version><NUP Region>

The Console Version represents the version of the collectively installed core features. And the NUP Version represents the version of the collectively installed network features.

So if a 3DS’ System Firmware read 2.1.0-2U, it would indicate a console version of 2.1.0 and a NUP version of 2U.

NOTES:

• CUPs can only update core content, so NVer is never updated with CUPs.
• NUPs will not update NVer if network features are not updated. (Best seen with the USA vs JPN/EUR 6.0.0 NUP)

CUPs are implemented by adding a System Update CFA to retail NCSD gamecard images. Nintendo generally creates CUPs after NUPs are released.

When updating the system from 4.5.0-6 to 4.5.0-10, the following titles are updated(in the order of title download+install): Health and Safety Information, Nintendo 3DS Camera, eShop, System Transfer, Internet Browser, 0004009B00014102, 0004009B00014202, 0004009B00014302, NVer, and AGB_FIRM.

“ System/ Userland security flaws fixed*”: This includes known flaws, and any fixed flaws discovered via code bin-diff.

“ System/ Userland security flaws fixed*” and “3DS-mode homebrew affected” only apply to the changes done with that specific system-update(“affected” does not include hax codebases breaking *just* due to updated codebins).

When the Home Menu is initially loaded by NS, it checks the gamecard ExeFS:/ icon for the auto-boot flag. If the auto-boot flag is set, it will load the application on the cartridge and the home menu will not remain running in the background, or at least not in an operational state. Using software cues to return to the home menu, or sleep menu while in this state, causes a shutdown.

Notable features of demo titles:

• Auto-boot demos generally disable the functionality of the home button.
• The New Super Mario Bros 2 demo, retained the functionality of the home button, and had an timer which triggered the demo to quit after a period of inactivity.

Auto-boot cartridges, can bypass some of the functions of the Home Menu. Auto Booted software:

• Doesn’t show usage history in the Activity Log
• Bypasses Parental controls
• Bypasses Forced Game Card Updates
• Bypasses Initial 3DS Setup
• The console does not have a friends list presence.
• Is still subject to region lock(see below).

Region lock is still active, so the home menu will refuse to launch demos with incorrect region lock will not load, displaying “An Error has Occurred”. However, game card update partition checks are not done, which allows launching demos that have region free encoding, but have an alternate(or even invalid) region update partition.

The following auto-boot paths can be used by Home Menu, checked in the same order listed below(the above gamecard auto-boot is checked before this):

The following is only checked when the low u16 from config block 0x00110000 is value zero(normally this is non-zero). Thus, the below is only handled when a system setup is required.

One of the Home Menu’s functions, is to regulate region lockout. The region lockout data for any given title is held in the ICN data. There are 6 regions of which have their own region lockout, Japan, USA, Europe(including Nintendo Australia), China, Taiwan and Korea. There is also a value which makes a title exempt from region lockout, and consequently accessible from any region of 3DS.

The region-field stored in the ICN-data is only checked when Home Menu itself launches a title, not when other titles use NS to have Home Menu launch titles. This isn’t actually useful for gamecard region-free however, due to the gamecard system-updates, see below.

Also note that while some gamecard games are mostly region-free(main CXI is identical for all regions of the gamecard), those gamecards can’t actually be launched with all 3DS regions due to the gamecard system-update, see below. Note that the main CXI being identical for all regions of a gamecard also means the savedata keyY is identical for all regions of that gamecard too(except for old system-version <v2.2 games, in some cases, due to different cardIDs).

Every 3DS title regardless of location (NAND/SD Card/Game Card) is subject to region lockout scrutiny by the Home Menu. And the home menu treats ‘out-of-region’ titles by simply refusing to show them on the home menu. No messages are shown on the home menu to notify the user, the title is simply ignored. However out-of-region SD Card titles, will appear and quickly disappear, while all the SD Titles are being processed. In cases where access to the home menu GUI is not needed to launch the title (like in the case of kiosk demos), the home menu states an error has occurred, and launching of the title is stopped.

Either intentionally a region lock mechanism or not, the function which checks the game card update partition returns an error when it is detected the update is for a region other than the 3DS’s region (Most likely triggered by the absence of the correct CVer title). And errors returned from checking the update partition, will result in the home menu displaying “This Game Card cannnot be used”, when the user attempts to launch the title.

Home-menu originally used two domains with HTTPS for SpotPass. SpotPass stores this content in Home-menu’s NAND shared extdata.

• The system notifications are downloaded from: https://a248.e.akamai.net/f/248/103046/10m/npdl.c.app.nintendowifi.net/p01/nsa/<regionID>/<filename>/<langcode>/<filename> Where langcode is the two-character language codes from config, and regionID is from the below table. <filename> is bashoX/sysmsgX where X is 0-3.
• https://pls.c.shop.nintendowifi.net/pl/upload This URL is used for uploading data from the home menu NAND shared extdata, it’s unknown what this is used for. This data is uploaded every 24 hours.
• https://npul.c.app.nintendowifi.net/p01/recv/<regionID>/<filename> This is used for uploading unknown data from extdata. <filename> can be one of the following:
  • “phu”
  • “tiu” The POST data contains a list of BOSS taskIDs etc. This seems to be only for Nintendo titles?(system+eShop apps)
  • “splu”
  • “sendmgn” For this it appears SpotPass does a HTTP POST with data originally from Launcher.dat?

The SpotPass content payload for notifications begin with a header, followed by an icon and the UTF-16 text, and various metadata.

During startup, Home Menu loads “/versionList.dat” from NAND extdata 0xf000000e. This is downloaded via SpotPass, the file-data downloaded via HTTPS here is raw (no SpotPass container):

• Retail: 🔗 1
• Dev-unit: 🔗 2 The titles listed in this are not available on the normal CDN.

This is a list of title-updates available on the eShop, for regular app titles and update-titles. This is what Home Menu checks to determine whether the currently selected application needs to be updated or not. When an Internet connection is not available or wifi is disabled, Home Menu will skip VersionList handling/messages when you launch applications.

File structure:

Title entry structure:

Home Menu uses 4 hard-coded NsDataIds: 0x1, 0x2, 0x3, and 0x4, under a loop in the same function for writing to “bashotorya.dat”.

See Automatic System Update Download.

See here.

As of 11.0.0-33 Home Menu themes are only supported with USA, EUR, and JPN. CHN Home Menu was last updated with v7.0, and TWN doesn’t even have a Home Menu settings menu(just the old screen brightness config menu + an amiibo Settings icon on the right side of the browser icon).

KOR Home Menu doesn’t have the theme-settings menu button. While this does have the theme handling code, it isn’t actually usable since extdataID 0x0 is used for theme-extdata for non-<JPN/USA/EUR> regions(which is invalid).

The SD ExtData File System for Home Menu introduced with 2.0.0-X is as follows:

root
├── icon
├── boss
└── user
    ├── SaveData.dat
    ├── Cache.dat
    └── CacheD.dat

These two files work in tandem to allow the home menu to cache icon data for applications which are presented on the Home Menu. The size of both files suggests a maximum cache size of 360 icons. Cache.dat stores details about the cache icon data, and CacheD.dat stores the icon data. The icon cache stores icon data for *all* applications shown on the Home Menu, this includes DSi NAND Titles, and DS(i) cartridges. The format of cached DS(i) icon data is not understood, but they are the same size as 3DS icon data (0x36c0).

In Cache.dat the first 8 bytes are a header where the first byte is the format-version, then follows each icon slots’s entry in the format:

All unused entries have the Title IDs filled with “0xff”.

In CacheD.dat, the icon data is concatenated together, with the first icon at offset 0x0.

The icon arrays above are handled exactly the same way as Launcher.dat.

When the theme cache is enabled via the above fields, Home Menu loads the cache at startup(if the used theme structure is valid).

Theme entry structure:

When the theme-type is value1 the themeindex must be <9. When the theme-type is value2 the themeindex has to be non-zero, and the u8 at offset 0x4 must not be >=10.

The theme-loader code (besides the AM code) handles all theme-types >=2 the same way. However, it seems all DLC AM code involving checking the currently-used theme DLC only gets executed when the theme-type is value2. The code in the theme-loader for that also checks that a certain Home Menu state flag is non-zero, before running the AM DLC code(it’s unknown where this flag value comes from).

The Home Menu code for writing the updated SaveData.dat to FS is broken when the filesize is smaller than expected due to being from an older format-version originally. When writing to the file, Home Menu checks the filesize then attempts to use FSFile:SetSize on mismatch, but FSFile:SetSize can’t be used with extdata(error from FSFile:SetSize appears to be ignored). When writing to SaveData.dat the write-size is the one for the current format-version, but since extdata files are fixed-size this will only result in the first {original filesize} bytes being written(result-code = 0xE0E046C1).

Basically, unless the extdata is deleted from the SD card FS manually, the SaveData.dat filesize will never be successfully updated from an old filesize to the current-format filesize by Home Menu.

The filesystem for this extdata is as follows:

root
├── icon
├── boss
└── user
    ├── ThemeManage.bin
    ├── BodyCache.bin
    ├── BgmCache.bin
    └── nsalist

BodyCache.bin and BgmCache.bin contain cached theme data for the currently used DLC theme. ThemeManage.bin is loaded by Home Menu during startup. The cached theme data is loaded at startup when a DLC theme is selected. This also contains theme-shop SpotPass data.

BodyCache.bin and BgmCache.bin are all-zero when no theme is selected.

Starting with 9.3.0-X Home Menu can use more files in this extdata, for theme shuffling. “theme:/ThemeManage.bin” “theme:/BgmCache_%02d.bin” “theme:/BodyCache_rd.bin”

The total filesize is 0x800-bytes, normally the data starting at offset 0x1C is all-zero.

When no theme is actually used, the only non-zero fields are the following: the u32 stored at offset 0x0 in ThemeManage.bin is value 0x1, with offset 0x10 u32 set to value 0x1.

The filesystem for this extdata(when it actually exists) is as follows:

root
├── icon
├── boss
└── user
    ├── BadgeData.dat
    └── BadgeMngFile.dat

The file size must match 0xD4A8, otherwise the Home Menu code returns an error.

The filesystem for this extdata(when it actually exists) is as follows:

root
├── icon
├── boss
└── user
    └── MngFile.dat

Layout entries structure:

The filesize must match 0x004D1280, otherwise the Home Menu code returns an error. The saved Home Menu layouts are stored here.

When saving a layout, the total layout field is increased, then a new layout entry is created with the contents of the current Home Menu System_SaveData(NAND savedata) Launcher.dat + a screenshot of the main Home Menu screen is written. When loading a layout, Launcher.dat in savedata is written with the current Launcher.dat data already stored in memory(unknown if any data gets changed for it here), then data from the layout entry is copied into the Home Menu System_SaveData Launcher.dat.

Home Menu *only* accesses this file with the Home Menu layout-settings menu / when entering that menu.

Parameters can be provided to APT:JumpToHomeMenu to perform certain actions when jumping to the home menu.

If the command requires extra arguments, this header will be padded and the arguments will start at offset 0x8. Otherwise it is just 0x5 bytes large as presented here.

The following is what Home Menu does at startup(converted from cmd-logs), from 9.4.0-21, in the same order Home Menu does it.

Originally Home Menu mounted sdmc in main(), starting(?) with 6.0.0-11 Home Menu only has sdmc mounted while handling SD_Savedata_Backups.

During Home Menu start-up it uses APT:PrepareToStartNewestHomeMenu. If that doesn’t return an error(normally NS returns 0xC8A0CFFC for that), Home Menu starts a hardware reboot with APT:StartNewestHomeMenu etc.

On retail this essentially means a hardware-reboot will automatically trigger if configmem SYSCOREVER doesn’t match FIRM_SYSCOREVER, or when the current APPMEMTYPE doesn’t match the default APPMEMTYPE for this Old3DS/New3ds model. The latter can happen with running New3DS NATIVE_FIRM with Old3DS system-titles, for example.

When returning to Home Menu from an application that didn’t properly shutdown(like with an exception), PTM module writes data to the PTM system savedata. Then the system terminates Home Menu, and starts Home Menu again.

• 🔗 http://www.nintendo.com/consumer/systems/3ds/en_na/menu_update.jsp
• 🔗 http://www.nintendo.co.jp/netinfo/3ds/JPN/ja.html
• 🔗 https://yls8.mtheall.com/ninupdates/reports.php

Category:Nintendo Software